Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Work in Progress / Road to PlayBasicFX

Author
Message
Kevin Picone
21
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Australia
Posted: 28th Oct 2010 20:11 Edited at: 27th Jul 2011 16:22
Round up: Some Tidbits from the current (and ongoing) work in progress.



PlayBASIC V1.64M Beta #25 - Polygon (Quad) Hit Map (Continued)

The polygon to map routines are proving to be a bit of a sticking point. Those will long memories might remember that FX prototypes have some of this functionality built into them. This thing is, while writing those implementations (which are bit heavy in terms of work load) I'd always wanted to try adding a prescreening ability to reduce the work load where possible. Which is the main idea behind the current tests. That being the routine works out what blocks the polygon is going to impact with, then we can do a quick trivial reject/inclusion at this point, rather than needing to jump straight into the pixel to pixel level impacts.

It's in this speed up that's causing the issues, the first past has to be fast and accurate. Which is something of an oxymoron, normally when you optimize for speed, accuracy is compromised. In this case when it's not 100% accurate it can return false positives or miss obvious (to the naked eye) intersections. Which just means that i've been tinkering with a number of different methods of doing the initial classification pass, but without much luck at this point. The most accurate method so far is also super slow, defeating the purpose of the pass completely.

Ideally, If i can resolve the accuracy issues, such a routine would be handy for scene occlusion purposes.



PlayBASIC V1.64M Beta #26 - Ellipse/Circle to Map

Been working my way through the actual implementation of the Ellipse/Circle Hit Map function. The pre-scanning part of the method is in and working well. So when the interior solid part of the circle/ellipse covers the map, we can get an impacts. The beauty of this we don't actually need to read the maps pixel data.

All that's left for this version of the function is to add checks for those regions that circle/ellipse partly covers (those on the boundary). For this we need another collision method to quickly detect when Ellipse/Circle & Rect regions overlap.

Bellow i've been tinkering (in PlayBasic) with a few ways to detecting intersections between the two shapes (Since there's no built in method already, or at least I can't find it Smiley ). The first demo picture bellow is comparing the screen full of the square tiles to the ellipse. Those that intersect are highlighted in red. Giving much the same effect as some of the previous shots in this thread, but achieving it a completely different way. All that's left to do is port this into the maths library and we should finally be able to tick the CircleHitMap / EllipseHitMap functions off the the To DO List. Of course, then we need Pixel To Pixel level intersections.

The second shot shows the CircleToMap test, you can see it's highlighting the interior tiles of the circle, so if any of this map tiles have pixels in them, then there must and collision.

Edit: The third shot is showing the collision test up and running. In this shot, when the circle edges can now be compared against the maps blocks rects. So we can get a pretty good indication of what we've hitting.

Screen shots





PlayBASIC V1.64M Beta #26 - Ellipse/Circle to Map Video

Finally the Pixel collision version of these functions working very early this morning. Rather than post another screen shot, decided to make a little video.

You can watch CircleHitMapPixels video on our PlayBasic channel on YouTube






PlayBASIC V1.64M Beta #27 - Quad Hit Map Pixels Collision

Another day and another feature collision featured ticked off the To do list. Yesterday I was getting the vector version of this command running, now we have the pixel version running. The vector versions of collision commands detect a collision with the mathematical region that shape in question represents. The pixel versions that this further and attempt a pixel to pixel level impact. Where and when you'd use them largely depends upon what you're trying to do.






PlayBASIC V1.64M Beta #28 - Shape Hit Map Pixels Collision

This is the Pixel Version of the command, which is currently about 95% up and running, there's a few little oddities left to iron out (namely when the shape is moved to a negative y position it crashes). Shapes unlike the Triangle and Quad polygon routines (which are always convex) are a little more of a hand full in these types of situations. As a shape can not only only represent convex polygons, but they can also be concave and even complex (edges that intersect). So I can't reply upon the same redundancy assumptions, making this one of the more brute force routines when deal with maps.







Check the
PlayBasic V1.64M (Work In Progress) Gallery thread for code snippets, bigger pictures and the latest beta downloads.

Attachments

Login to view attachments
Kevin Picone
21
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Australia
Posted: 21st Nov 2010 16:47 Edited at: 27th Jul 2011 17:27
Round up: Some Tidbits from the ongoing work in progress of PlayBasic V1.64M.



PlayBASIC V1.64M Beta #29 - Shape Hit Map Pixels Collision(Tweaked)

This has been really bothering me all night, but after much head scratching finally tracked down the cause the negative Y crashes, which turned out be how the shape was being span converted. So that issue has been fixed in today's revision, another thing that's bothering me with the pixel to pixel versions is the amount of overhead.

Some of the overhead was from the debug code drawing the shapes bounding box... erm.. Smiley - But a bigger problem was the routine had no obvious way of making an early impact detection. So i've split the process up. The separation allows the routines to catch impacts upon solid blocks and exit early. This change enables us to bypass a lot of the brute force work underneath. So overlapping big shapes over a map should generally be much faster.

The logic changes give the ShapeHitMapPixels function a nice little speed boost, bringing it more inline with the Circle/Ellipse & polygon methods. Bellow in this piccy we're comparing 440 odd shapes to the map scene. This time the shapes aren't all sitting on top of each other, so the we're getting a more realistic idea of the performance impact. Previous snippets compare the same shape in the same position to the map. So they're either all missing completely, partly or they're all near miss at pixel level. The latter is the worst case, since to resolve them it requires the routine do a brute force compare with the pixels.




PlayBASIC V1.64M Beta #29/30 - Sprite Hit Map Pixels Collision(Tweaked)

It's been another long night digging through some of the long lost (and previously opt'd) collision routines, but it's been a worthwhile exercise as now we can perform pixel to pixel level impacts between sprites and the map. Pictured bellow is the first version of the SpriteHitMapPixels function in action. This function will be used when you want to 'compare' the pixels with the map. The SpriteHitMap function will use the Sprites current collision mode. So a sprites that's set to the rotated rectangle, will compare the a rectangle volume rather than the pixel data. If it's set to circle, it'll use the circle volume and so on. If it's set to pixel, then it'll do a Pixel level impact.

Speed wise the routine is only about 50% slower than the straight vector to pixels methods above when doing a 1000 tests. Although it really depends upon the situation. A near miss is the slowest situation. By that I mean, when the routine has to check lots of pixel data that's very close to the sprite, but not actually overlapping it. Accuracy wise there's bound to be some variations between the collision span routines and rendering span routines (they use different accuracy). But that's par for the course I'm afraid.




PlayBASIC V1.64M Beta #31 - Sprite Hit Map / Supporting all collision modes

The current task has been getting SpriteHitMap Functions to support various sprite collision modes, which are the Rect, Rotated,Circle,Shape and Pixels. Here we've looking at the a sprite set to shape mode (with a rough shape outline) in both m,odes. The first is detecting if the regions overlap, the second is stepping down to pixels.





PlayBASIC V1.64M Beta #34 - RectOccludeMap - Manual Occlusion

Occlusion support is one of things I've been wanted to implement for some time, but there's always the little stumbling block of just how. For those not familiar, occlusion is a series of conceptual techniques (often customized to the problem) that are used to remove redundant drawing operations from the screen refresh. The idea being to preemptively prohibit the graphics engine from drawing images that's won't actually be visible to the player, due to being behind something else, so why draw them.

A common situation occurs when drawing a multiple map layers over each other. If we imagine a scene with 2 or more layers, then normally we'd draw them all over each other regardless of what was in screen. So with 3 layers, we're potentially draw every pixel 3 times. With modern hardware this is not really that big of a deal (assuming a medium screen resolution), but if you want your games to run on more than just modern windows boxes, then it's worth seeing if we can cull out any of the redunant rendering. This will help speed up the layer rendering, which could potentially boost you games performance not only on the older machines but newer ones too. Which means you'll be able to squeeze more action into the game then without it.

So to help programmers start tackling such problems with maps, i've been implementing a RectOccludeMap function. This function works out what blocks it's covering within the level, then clears them. So when the level is rendered, at section will be blocked out. To demostrate this , i've made a little demo with a backdrop picture and single scrolling in the foreground. The Mouse is moved over the frame and the region it covers is culled from the backdrop.




PlayBASIC V1.64M Beta #34 - 3 Map Layers With Occlusion

The following pic's and code are an extension of the previous two layer demo. Except this time, we've added a third layer and some occlusion zones to help masking out the middle background layer. To build the layers, I've simply drawing a large picture then cut them up into tiles in code. The middle layer is some random tube things and front layer is of some bricks with a sine wave cut out of it. Neither are optimization into the most minimal block set, but will do for the sake of an example.

Without occlusion the demo runs nicely around the 250-270 fps make. It varies as the on screen pixel count varies frame to frame. With occlusion the rate sit around the 310-330 fps. Which in this demo, is about the speed of rendering the two back layers without occlusion. So we're virtually getting the third layer for free.





PlayBASIC V1.64M Beta #35 - Quad (Polygon) Occlude Map

Tonight I'm putting the final touches on the occlusion commands, with the addition of the Circle / Ellipse & QuadOccludeMap functions. They work via the same principal as the Rect version, you give it a shape and it cuts that region out of map level. Supporting different zones should make it easier for those creative programmers to tweak their games performance just that little bit more.






PlayBASIC V1.64M Beta #36+37 -Optimization Stage

Been sifting through the Shape Library this afternoon trying to improve the speed of the some core functions like PointHitShape, but without altering it's functionality. So far the results have been fairly pleasing seeing around a 40% gain in performance over a 10000 calls. This caries through to other routines like the LineHitShape and Shape intersections due to their usage of PointHitShape in certain circumstances. Giving a nice little boost to demos that usage a lots of shape collisions.



Visit PLayBAsic V1.64 Gallery WIP thread to follow the final stages of V1.64 Development (and pictures + code snippets)

Kevin Picone
21
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Australia
Posted: 28th Nov 2010 11:44 Edited at: 27th Jul 2011 17:21
PlayBASIC V1.64M Beta #38 -Enters Final Testing Phase

Beta 38 moves us more into the very final stages of beta testing this update. In fact, the only changes in this version (from revision 37) are all bugs/tweaks related.


Visit PLayBAsic V1.64 Gallery WIP thread for downloads / snippets.

edit: sig update.

Attachments

Login to view attachments
Kevin Picone
21
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Australia
Posted: 2nd Dec 2010 06:38 Edited at: 27th Jul 2011 17:24



PlayBASIC V1.64M _Retail Upgrade_ is Now Available (1st, Dec, 2010)


This upgrade is perhaps one of the largest we've ever attempted, spanning some seven months of development time, and addressing virtually everything in the core command sets from DEBUGGER, FONTS, SHAPES, SPRITES through to MAPS. There's way too much to pick through now, so I highly recommend looking through the V1.64M WIP gallery for some insight in what new additions are hidden away in this release.


For more information about PlayBASIC, please visit www.PlayBasic.com, download the free learning edition and dive in.


WIP Gallery









Download Upgrade

Download PB V1.64M Upgrade





Community Awards

Edit: Also it's awards time.. Nominations are open now.

PlayBASIC 2009/2010 Community Nominations

Attachments

Login to view attachments
Kevin Picone
21
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Australia
Posted: 22nd Dec 2010 04:53 Edited at: 22nd Dec 2010 04:55
The following tiny (10 second) video is just a small tech demo i've been writing in PlayBASIC V1.64. When complete, the resulting video will end up as a the site slide show.. This versions a few days old now, as i'm till adding some wacky effects to it, for no other reason than because I can..




Kevin Picone
21
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Australia
Posted: 21st Jan 2011 02:40 Edited at: 27th Jul 2011 17:25
Bit of round up


PlayBASIC V1.64 M2 BETA #1 (Retail Compiler Only Beta)

This is a Beta in name only, the only real changes from this to the V1.64M release build is the addition of optimization logic to the assignment/expression optimizer in compiler. As such, this can be safely used with the runtimes from V1.64M upgrade. The new parser changes allow the compiler to reduce the amount of the moves opcodes in certain expressions, namely those involving build in functions that return strings or bit wise operators such as AND / OR / XOR and some string functions.

Note: While i've been testing these changes a lot myself (without error), I can't be 100% sure that optimizer won't break some special case string function in your code.

Download from the maintenance board as usual.



Permutation Printer + Sheet Music Rendering + Bezier Shapes

Been working on various music games in PlayBASIC, I won't bore you with the back story, but the following samples are of the some research in this area.



Permutation Printer

Found this project while looking for something else entirely, thought it lost actually.. It was originally written in DarkBasic way back in 10th,Oct,2000, but now it's part of the PlayBASIC family. The project originally started as an experiment for converting early DTAB files (Drum Tabs) into a sheet music representation. Surprisingly the idea of converting drum tabs to sheet music (at that time) went down like a led balloon, so the project got put on the back burner. Later, I turned it into this permutation builder as teaching aid.

The builder is a way of generating independence exercises on mass, 625 exercises to be exact. It's currently hard coded to build snare line against feet combination's. Not too sure what i'll do with it, but at least it's not lost..




Sheet Music Rendering

Been working on various music related projects the past week or so, which are all related in some way. In these projects there comes a time when we need display a sheet music representation. The previous attempts at this (the 625 permutation printer above for example) all takes fixed size graphical approach. While easier, the down side is that the render output can't be sized to the resolution of the printer surface or monitor for that matter. You can scale it, but it's messy and suffers from a loss of detail. So this is an experiment is rendering promotional sheet music (for drum kit) using a vector graphic approach.




Bezier Shapes

Continuing on from the notation rendering above, rather than create note heads by hand, I've been knocking a simple shape editor together. The idea being that the shape is constructed from set of control points and edges. Each edge has it's own 'curve' controls (which can't be edited yet), these default to being perpendicular to the edge. Which is why they bulge out. By moving the control points you can control how they curve. Which in sort of like how vector fonts work. Which might actually be be viable.. But that's another subject..

Screen Shots




Read More About Permutation Printer + Sheet Music Rendering + Bezier Shapes

Attachments

Login to view attachments
Kevin Picone
21
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Australia
Posted: 19th Feb 2011 01:34 Edited at: 19th Feb 2011 01:36
Forum Offline

  Yes the forums are currently offline for some routine maintenance.   While obviously this means going without a forum fix for a few days, this change also affects other parts of the www.underwaredesign.com and www.playbasic.com sites that link to pictures / files from the forums.  The same is true for blog threads such as this.    So many of the post will have broken links for the next couple of days.   Don't panic ! - It'll be up and running again over the weekend sometime. 

Kevin Picone
21
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Australia
Posted: 20th Feb 2011 20:46 Edited at: 27th Jul 2011 07:46
Forums Online

After some tweaking the forums are back online.



DtabPrinter

The sheet music rendering library has since turned into a helper application for DTAB users (which is a Drum Tab Editor) called DTabPrinter. The app imports DTAB files and renders them as sheet music.

Lots of changes since the previous post, so check out the WIP if you're interested. Here's a few pics anyway.


Screen Shots




Check out the Work In Progress thread here.

Attachments

Login to view attachments
Kevin Picone
21
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Australia
Posted: 18th Mar 2011 18:36 Edited at: 18th Mar 2011 18:44
Quick Round up..


DtabPrinter

Been working on DtabPrinter applications GUI the past couple of days. So far the interface is built from a variation of the standard libraries that I use for my PlayBASIC GUI programs, so it'd no doubt look familiar to PlayBASIC users. One of the benefits of using PB for this project apart from the ease factor, is that PlayBASIC is designed as a 2D graphical language, so throwing in the odd effect is perfectly viable. Which can be way too temping at times.


Just finishing off the preview controls this morning. Internally the Drum Tab to sheet music library renders the chart out to a virtual page. The page can be re-sized up or down. The music rendering is drawn proportional to it's internal virtual page size. Even at the default low quality the virtual music page is much larger than the screen.

So in order to view this the rendered music pages, they have to be scaled down to fit within the screens view port. Given they're being scaled, the frames are previously mip mapped during rendering. So the preview retains the basic line/pixel data even when scaled down to a third of it's actual size. The down side is that at that size, all of finer pixel quality is lost due to filtering. It's not lost from the high resolution music image, just the preview window.

The buttons on the bottom let the user flip through the pages of the chart, you can use the scroll button to zoom in/out and left click to pull the view. Which allows you to zoom into the hi detailed version and view any part of it, even if it's way off screen. Which it will be.

Bit of a sneak peek.





PlayBASIC Tutorial #1 - Hello World (Print & Ink commands)

This short fly-on-the-wall style tutorial is to help the newest of the new get some idea of what BASIC programming is all about.





PlayBASIC & PlayBASICFX

As you can see I've been off working on other things the past month or so, so there hasn't been lot of hands on PB development going on.

In PB terms there's a couple of V1.64M2 compiler replacements available, which make a few tiny corrections as well as some tech demos trialing some new image format functionality (possible Palette Mapping). Hoping to get to this towards the end of the month. Once that's done, we can focus more on PBFX. Got a few surprises up my shelve yet

Kevin Picone
21
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Australia
Posted: 22nd Mar 2011 21:44 Edited at: 10th Apr 2011 08:36
Catching Up With Old Videos

Found a bunch of old tech demo video captures from way back in around 2006 to 2007 and have been uploading them tonight (mostly as is)


Thesius XIII - This isn't the final tech demo, it's taken about 1/2 way through development. So it's missing a bunch of objects types, but you get the idea.

Thesius XIII - WIP Thread in TGC- Underwater Forest / City - Retro Shoot-Em-Up




Rugby



Fungus



Textured Twister


That's enough nostalgia for one night

Kevin Picone
21
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Australia
Posted: 26th Mar 2011 04:58
Been stuck making some tweaks to the PlayBasic homepages, all seems to up and running again.

Kevin Picone
21
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Australia
Posted: 10th Apr 2011 08:47 Edited at: 10th Apr 2011 09:07
The next round of work on PlayBASIC V1.64 revision N has kicked off. Current focus is mainly on tweaking the performance of the some of the older string engine components. Getting some even better results. Which is always pleasing.


PlayBASIC-V164N-WIP-GALLERY

Kevin Picone
21
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Australia
Posted: 16th Apr 2011 11:19 Edited at: 16th Apr 2011 11:20
2011 Easter Game Programming Challenge Begins

In the spirit of a little Easter holiday fun, we're setting the PlayBASIC community a week long design and programming challenge. The objective here is to cut through the fat and get to the core of your game idea fast, without the inevitable feature creep. So the game designer needs to formulate their concept, then build a working prototype of the game within 7 days or less. (16th/April/2011 - 24th/April/2011)

Visit the forums to Learn More

Kevin Picone
21
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Australia
Posted: 25th Apr 2011 18:59 Edited at: 27th Jul 2011 07:42
2011 Easter Game Programming Challenge Ended - Voting Begins

This is the community poll to the determine the winner of the Easter Mini game challenge.

We've two great submissions to the challenge, please download and play both games before voting.

Screen Shots



Go Here to vote

Attachments

Login to view attachments
Kevin Picone
21
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Australia
Posted: 1st May 2011 22:44
unfortunately an error has occurred in the previous poll, so I've had to start another one. If you voted last time, you'll have to vote again. Same link

Visit to Vote Again

Kevin Picone
21
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Australia
Posted: 5th May 2011 08:37
Looks like we have our winner....... Micky4Fun ..... takes out another competition!

Congratulations on such an excellent game made within a week.

Cliff Mellangard 3DEGS
Developer
18
Years of Service
User Offline
Joined: 20th Feb 2006
Location: Sweden
Posted: 6th May 2011 16:31 Edited at: 6th May 2011 16:32
I think its explorer 9 that is the problem with your page?
Really nice design and looks good!
I get this bugg?

Attachments

Login to view attachments
Andrew_Neale
14
Years of Service
User Offline
Joined: 3rd Nov 2009
Location: The Normandy SR-2
Posted: 7th May 2011 12:47 Edited at: 7th May 2011 12:52
I believe setting the flash parameter 'wmode' to 'transparent' will resolve that.



Kevin Picone
21
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Australia
Posted: 12th May 2011 16:15 Edited at: 12th May 2011 16:36
Thanks, will tweak it later.


edit: Yep, that does indeed fix it.. thanks!

Andrew_Neale
14
Years of Service
User Offline
Joined: 3rd Nov 2009
Location: The Normandy SR-2
Posted: 12th May 2011 19:10
No worries! I'm a web developer by trade and I struggle to "switch off".

Kevin Picone
21
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Australia
Posted: 29th Jun 2011 21:22
PlayBASIC Round Up

Just a quick update.. Firstly, there's a bunch new code snippets on the PlayBASIC Source Code Forum - Lots of different stuff as always.. Something of a gold mind really.

Currently labouring my way through a bunch of other projects, but the light at the end of the tunnel is indeed starting to shine through. Hopefully, we'll be able to get back to PB pretty soon.

Let's just say, i'm looking forward to it

Kevin Picone
21
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Australia
Posted: 11th Aug 2011 01:28
PlayBASIC Round Up (July/Aug)

Been back working in the PlayBASIC trenches since late June really. The main focus throughout this period has been on the replacement IDE project. What's wrong with the existing IDE ? - Well, nothing really... It's just not being actively developed anymore. It's a familiar story, you know, language needs IDE, excited programmer takes up the challenge and sooner or later moves onto something else. Which puts pressure on the overall PlayBASIC time line.

After looking for replacement options it became clear the only viable alternative was to build a replacement IDE myself. I actually started the project a while back, but ironically that was soon shelved, as that project was taken over by another 3rd party. But sadly the light flickered out all too well. So it's fallen back into my lap.

Now obviously writing something like an IDE, isn't a job that I take lightly, nor is it something that can be knocked together quickler either. Which means the initial releases of the package may well be missing some features from PlayWRITE. The upside is we get to build it exactly the suit the PlayBASIC + FX.

So far development of the tool is currently just entering the early Alpha testing stage. Consisting nothing more than the bare essentials to handle the life cycle of the your projects code. So you can create a project, edit, test and save it. That's about it.

The first thing existing users will notice and probably the biggest change thus far, would be the move away from the tabbed project interface, towards a more free range layout. So multi source projects are no longer only accessible through the tab across the top of your project window, but each sources roam free in separate window. All the main controls are located on a side panel also (subject to change), where you can manage the current project in focus. Stuff like adding new sources, removing them, changing the build order, default screen modes etc etc

Simplicity is a big focus this time around, we're really trying to weed out what's really necessary from the gloss. In fact the current ALPHA would be lucky to have a quarter of the controls from PlayWRITE at this point, without really missing any of the main functionality either. Which we feel is going to be lot better for new users.

It's not all about trimming the fat though, as the current build has a few nice new features also. Some that come to mind, would be the vastly improved project building speed (over 20K lines per second), better search engine for the doc's browser and the ability to toggle between compilers. Which means you can elect to build your project with PlayBASIC or PlayBASIC FX with a simple switch. Which is very handy.

So when will it be available ? - Dunno, we're expecting to move from Alpha to a light Beta testing phase in the coming weeks. So it could possibly see a public release after that. I'm not anticipating it being 'final' for some time though.

Kevin Picone
21
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Australia
Posted: 12th Sep 2011 03:02 Edited at: 12th Sep 2011 17:55
PlayBASIC IDE WIP Round up .. A lot of hours have been put into this last time, way too much to go over here, so here's just a couple of tidbits.



IDE VIDEO - 20K Line Plus Build Speed Test

This clip is of new IDE we've been working on for the PlayBASIC programming family. The version shown here is early _alpha_, so while the styling will no doubt change, the core functionality is evolving daily. Some of the features of the new IDE and the PlayBASIC compiler, are the speed of compile times as programs get larger, which is what this video is demoing.

In this clip we create a mock up program that's over 23,000 lines of code long by including four slabs of (basically useless) test code in a project. The code doesn't do anything interesting, what we're looking at here is the build speed from the IDE, and overall compile time . How fast is it ? - You'll have to watch the video





Music By:
http://www.ardvarc.net



PlayBASIC IDE Alternative V0.22d - All The Shiny Things

The F1 HELP feature has been expanded, it can now identify most of the basic code fragments (operators, literals, keywords ), allowing you to press F1 and get a more in tuned response.

...



IDE Alpha V0.26b - Auto Parameter Prompting

This dropped in pretty easily, even though this version has some hard coded short cuts in it, but the concept works. What's missing is the there's no real expression level parsing in this version, so it can't resolve the parent command if the expression has bracket layers and the cursor is beyond them. Not a big deal, just couldn't be bothered spending time on that up front as i wanted to see how well it work, and it seems to work ok.

What you'll notice now is the IDE doesn't need to be persuaded to show a built in command/function parameters, it'll do this automatically for you. This is bound to be a bit of culture shock for some people, but it'll make learning much easier for others. Now you can just load up a source and click on any command that has parameters and it'll show you right there and then, without needing to the hit a menu or any special key combo. Which should make learning a lot easier.






IDE Alpha V0.27a - Parameter Indexing in Parameter prompts

Had a few days off the IDE to focus on other tidbits, some PB stuff some external stuff. Obviously when working on PB stuff, I'm using the new IDE more and more. While it might still be alpha, but much of the big 'fall over' issues seems to have been tweaked up now, making writing code much easier. Anyway i digress, so during last update the auto parameter prompting was added. The first addition sees the parser looking at first parent keyword in the expression and just assuming that's the command/function you within. Which works, providing there's not a mix of function calls as parameters.

So this would work

ShadeBox 0,0,800,600,c1,c2,c3,c4

but this wouldn't

ShadeBox 0,0,800,600,Rgb(255,0,0),c2, |c3,c4

if you positioned the cursor in front of the C3 parameter (like above), the old routine would ID the RGB() function as parent function, when you're clearly editing the parameters of ShadeBox and not RGB.

So what the IDE has to do is parse this expression looking for the real parent command/function and give the parameter Index back to the rendering engine, which is what today's edition is able to do. What it can't do yet, is show this new information visually by highlighting the Parameter you're within. But that's the plan.. Should be doable.

Kevin Picone
21
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Australia
Posted: 18th Sep 2011 02:30
IDE Round up
-------------


IDE Alpha V0.27c

Alpha V0.27c rounds out the auto parameter tip feature with the inclusion of the parameter indexing within the expression. Which just means that it can work out where you are within the command/functions parameters and show it to you. There's a bit of an issue with the tips clipping width from time to time, but that's cosmetic.

Most of the changes this time around have been fleshing out some of the existing functionality. Stuff like the IDE now keeps track of the document changes so that CLOSE PROJECT can prompt upon closing. If the document hasn't changed it shouldn't prompt you. Dunno how reliable that actually is at this point though. Apart from that, there's the usual round of bugs and tweaks.

The main thing about this release though, would be the shift from one of caution, to something that's pretty stable. In fact i'm yet to have any saving issues (code mangling) and very few crashes while editing. That's not to suggest it's 100%, I highly doubt it, more that your less and less likely to hit issues now.

Project Status: This edition is considered tentatively stable. You're still advised to use caution (Ie. back up your source codes first) when using it with your projects.



IDE V0.28b Moves Into Public Beta

Revision 0.28b continues the clean up process with and bugs and tweaks, the main change is how rendering is handled. In this version, redraw is handled separate from the action. You can set the refresh rate through the SETTINGS dialog, using the Interval setting near the bottom. The setting is the number of ticks between refresh pulses. The redraw process doesn't have anything to do with the input process. The default redraw setting is about 40 ticks (from memory), which makes for a potential of (1000/40) =25 redraws per second. You can set it lower or higher. The smaller the value the higher the number of potential redraws, but it's limited at around 16 ticks (62 fps)

What this does is it decouples the rendering from the input process, so speed of the redraw doesn't get in the way of the things like dragging the viewport when scrolling and the user can't flood the redraw with requests.

Anyway, this doesn't mean the end of the ALPHA testing, the process will be generally geared toward Alpha testing, with beta releases at key points.

The beta is available on the UW maintenance board.

Kevin Picone
21
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Australia
Posted: 25th Sep 2011 05:50
PlayBASIC IDE Beta V0.30a

Revision V0.30a introduces Bookmarks, context based right click menus (Default/Selection and #include mode), as well as some bugs and highlighting tweaks.


Right Click Menus

This beta introduces a few changes, mostly around the right click pop up menu stuff, where previously it didn't matter what context the cursor was within, you'd always get the same pop up menu. Now there's 3 basic contexts. There's Selection menu, which are options to do with a selection chunk, #include menu, which allows you to load an include into your project to view it and the default menu, which is just basic options.

Much of the work in this revision has been focus on the include file loading, which has required a bit of restructure in places to make the process sit nicely. The process works much like PlayWrite i guess, you move your cursor over the file name in of the #include statement .. Ie #Include "Maps" you'd left click the maps literal, then right click to get context driven help. This will pop up a list of available options, which in this version consists of one option, that being Load Include.. If you select the load option, the IDE will try to work out where this file is and load it into the project manager. The source isn't considered part of your project though, so if you compile or save your project any manually opened sources will be left out. In future editions it'll allow you to modify and save the modified include as you save your project, or perhaps though a menu option.


Bookmarks

This works much the same as PlayWRITE with one key difference. While i'm trying to keep it fairly similar, i'm not a fan how book marks aren't project based. So in this version you have the same 10 bookmarks, where each bookmark can be on any source at any row. So if you goto a bookmark on a different source, it swaps to that window and scrolls to that position This allows you to jump between key parts of the code while developing. Adding the functionality was simple, the annoying bit is rendering this information back to the user. In this version it just shows a crude text overlay on the line number. It'd be nice to have some type of icon, but i can't be bothered looking for one at the moment.



V0.30b - Find Declarations

Start adding this yesterday, so far it's allows you to click on a user defined function/psub and it'll take you to the declaration. The implementation is pretty simple at this point so it's only able to find local declarations, but the idea is that will be expanded to be project wide.

Kevin Picone
21
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Australia
Posted: 29th Sep 2011 19:34 Edited at: 29th Sep 2011 20:44
Round up

IDE Alpha V0.30c

Alpha V0.30c - This introduces the Find Declaration functionality to editing environment. For those that aren't sure it's a right click menu option that will try and take you to the declaration of user defined variables/globals/locals/constants/arrays or functions within the project sources. This version of the search operation is fairly basic, it can find most declarations such as 'Dim stuff as integer', but it has no really knowledge of scope, so it's likely to make mistakes if the same variables/arrays names appear in different scopes.


IDE Alpha V0.31c - Live Function Parsing

So today it's looking likely we've got another brand new feature for the IDE which is Live User Defined Function parsing. This is something I've been struggling with for a while now, the main concern has always been the exponential growth of complexity as the source gets bigger. The deeper the view of the source, the more work required for the IDE keep up with what you're doing. Ideally, it'd be best have keyword level identification of every token in the source, but that really doesn't seem viable. So moving on from that, we end up with live parsing.

In this version you get a quick peek at the live parser implemented into source view. What it allows the IDE to do, is build a list of user defined Function names within the source. These are then used in the syntax highlighting. They're currently coloured blue so you can see whats the user function and whats the built in function.

Here we have a quick example of what i'm talking about.



Kevin Picone
21
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Australia
Posted: 2nd Oct 2011 18:12
Round Up.

PlayBASIC IDE Beta V0.32b

This revision rounds out Live User Function Parsing functionality to editing environment. Live parse feature monitors each source for user function & psub declarations, keeping track of function keywords while you edit. The Live parsing is interleaved through the IDE, so it's sharing resources where possible. Changes to the function names won't be shown immediately though, they'll generally get refreshed every 1/4 -> 1/2 of a second. The delay between refreshes will get longer the larger a source fragment is. It's set up to handle sources of 5000 lines long in around a parsing time of 1 second delay. Which seems fine to me. The parsing is also project wide in this version as well as supporting linkdll blocks.

Auto Parameter Help On User Defined Functions

So the live parsing means that user defined functions can be highlighted, so you can see instantly what's a built in function and what's user defined. As much of help that is, the obvious next step is to expand parameter assistance on user defined functions. Which can now be found in this edition. Which means that when you enter the parameter section of the user defined function, it'll give you the parameter hints live from the source while you edit it.



Kevin Picone
21
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Australia
Posted: 8th Oct 2011 08:05
IDE Alpha V0.32f - User Defined Type Field Assistance



Kevin Picone
21
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Australia
Posted: 11th Oct 2011 01:25
IDE Alpha V0.33b - Auto Field Completion Support Expands

So since meeting the first milestone over the weekend, i've been pressing on to expand it's view of the source, starting with supporting declarations within function/EndFunction statements and typed arrays. The only tricky bit was working out a way to slot the EndFunction declarations into how it works. Since the declaration matching requires a declaration prior to usage, which is not possible for returns (think about it), but there's a way around that.

Anyway, in this vid we knock up a little program that demo's some of the IDE's latest additions.



Kevin Picone
21
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Australia
Posted: 18th Oct 2011 05:10 Edited at: 18th Oct 2011 05:11
IDE Alpha V0.34d - Auto Completion / Data Type Suggestions

Work on the auto completion features keeps ticking away, here we're quickly looking at PlayBASIC IDE Alpha V0.34D. In this version, we've added the AS / NEW data type suggestions. So if you type AS followed by a SPACE it'll prompt you with a list of the available data types, ranging from the primitive types to user defined types. The IDE is scope aware for user defined types, so it'll give you those options available at this location within the source.



Kevin Picone
21
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Australia
Posted: 24th Oct 2011 04:49
IDE and upgrade V1.64N Round up

IDE Alpha V0.34e

V0.32e continues on with the auto completion and code assistance theme with the addition of auto complete trigger features on AS / NEW and EACH statements. So when you type one of those keywords and hit space up pops the auto complete dialog. The dialog is aware of the situation and screens the fields accordingly. So if you enter each it'll only should Typed List Handles, if you enter AS, it'll build a list made up on the primitive data types mixed with user defined types, where NEW will give you a list of the User Defined Type names. Which should take a lot of the guess out of programming as your code gets bigger.

The other collection of assistance features centers around the IDE inserting the closing statements given a particular circumstance, those being TYPE, SELECT & LinkDLL . So if you type TYPE name (and hit enter), it'll insert blank indented row for the fields and the closing statement on the same indentation as the opening statement. Which is basically the same as the Function/Psub helper. The Idea here is to not only reduce the amount of typing, but limit the possibilities of the mistakes. While the insert routines do parse the segment, it's not super smart, so such things could easily be confused. The Auto Assist is only engaged when you hit ENTER.

Since Type and linkdlls statements can't be nested, you're less likely to run into issues where the IDE is inserting code you might not want. Select/Case statements can be nested. Basically the insert assumes the state pair aren't being wrapped around another bit of code.

So if you type SELECT VARIABLE (HIT ENTER), it insert this basic structure. The cursor will be positioned after the CASE statement.



It doesn't insert CASE statements though. Which might be handy come to think of it.. Beyond this I'm going to try have a go at the other primarily loop structures and see how that goes. It'll take a bit of getting use to though


PlayBASIC V1.64N Beta #6 - Catching Up On Some Bugs

Been hammering away at catching up on bugs found in the V1.64M, although many of the expression issues date back to V1.64L revision. Bit of a mixed bag for what's been looked at this time around with the focus being largely on fix ups, rather than introducing anything new. There are some speed tweaks with some of the pixel strip copy/translates routines and even a few tweaks with the Point/DOT functions for 32bit surfaces, which win back a few ticks in the brute force tests. Can't imagine that translating into noticeable gains in regular every day programs though. The opt's are really only made to help some of the built in image processing functions deal better with the amount of raw pixel data, in particular when grabbing a map blocks. Would love to thread some of those routines but that seems bit too risky with how the engine handles the current surface, as the user would have to mange the surface and thread state. Can't imagine that being too successful.

Only planning on spending a few days on this release, so I wouldn't be too surprised to see a Release candidate in the near future.

PlayBASIC V1.64N WIP Gallery

Kevin Picone
21
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Australia
Posted: 26th Oct 2011 02:46
PlayBASIC V1.64 N BETA #8 (Retail Compiler Only Beta) - (Avail for Registered Users ONLY)

PlayBASIC V1.64 N Beta #8 is final test build of upcoming PBV1.64N retail upgrade. This revision is mostly (if not entirely) about addressing some of legacy 1.64M/V1.64L bugs mixed with a good layer of fine tuning.

Read Update Work In Progress gallery

Kevin Picone
21
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Australia
Posted: 16th Nov 2011 07:50
PlayBASIC V1.64 N BETA #13 (Retail Compiler Only Beta) - (Avail for Registered Users ONLY)

Had a bit of hurdle this last couple of weeks, which has pretty much halted all PlayBASIC development, apart from the odd optimzation and documentation revision session. So this version contain a number of optimzations spanning the image library, line draw modes, shapes, Help files and even a Mappy loader update.

Read Update Work In Progress gallery

Kevin Picone
21
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Australia
Posted: 20th Nov 2011 06:41 Edited at: 6th Jan 2012 15:02



PlayBASIC V1.64N _Retail Upgrade_ is Now Available (19th, Nov, 2011)



This release updates any of the PlayBASIC V1.63w2 to PB V1.64L retail versions up to the current retail release version of PlayBASIC V1.64N . If your current version is older than PB1.63W (pre June/July 2007), then you may need to install patch PB1.63w2 prior to this one ! (if you haven't already)


The PlayBASIC V1.64N package includes updates of PB Compiler, Release / Debug Runtimes, SLIBS, DOCS & IDE V1.17b.

This upgrade round off some of the open ends from the V1.64M upgrade in terms of bug fixes. It's not just about bugs though, it includes a wealth of new optimizations ranging from line draw modes, shapes clipping, image progressing and more. There's lots to pick through, so we highly recommend looking through the V1.64N WIP gallery for some more insight in what new additions are hidden away in this release.

Don't have a retail version of PlayBASIC ? and want to find out more information about PlayBASIC programming > please visit the www.PlayBasic.com and download the free learning edition.


Announcement

More On PlayBASIC1.64N Retail Upgrade

Kevin Picone
21
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Australia
Posted: 10th Jan 2012 06:41
PlayBASIC Round Up (Dec 2011 /Jan 2012)

November was a bit of wash out, spent most of the time house sitting, even so did manage to build a the PlayBASIC V1.64N release, but that's about it. Finally arrived home on the 1st opr 2nd second of December, can't remember now. But did manage to get some good work done prior to Christmas on VM3

Had myself something of external hard drive failure two days before christmas, so ended up spending most of my waking hours trying to back up the materials off it. That job is an ongoing one, as it's still not completely backed up, but thankfully the majority of my main personal data seems to either be intact or has been backed up onto disc previously.. Lost a few tidbits, but a lot better than losing everything.



Snippets From The VM3 Blog

6,Dec,2011

The VM (Virtual Machine) is the platform your code actually runs on. Basically it's a host, conceptually acting as the interface between your code and the physical machine the VM is running on. Each generation of the VM runs it's own instruction set. Older editions have a tighter relationship between 'opcode' and user command. Meaning that each user command was originally tied to, then ultimately became embedded into the VM instruction set for speed. So the 'command set' and the VM instruction set became one and same thing. This has some benefits in terms of building the project, but lots of cons also. One obvious being that the reuse of some code becomes impossible. All editions of PlayBASIC V1.64 (and bellow) run on some variation of this theme, later editions run on a sort of Frankenstein half breed.

The goal for the second generation VM2 was not only to stream line the instruction set and data structures as much as possible, but break everything into separate self contained chunks. So program execution becomes separate from the command sets. Looking over the existing state of the project found in the PBFX V1.77 prototypes, and the execution engine is almost capable of this today, with some fairly big hurdles sitting in it's way. One that comes immediately to mind is how the application launches.

In existing PBFX editions, the startup process contains hard coded initialization in the host. The host is the stub executable that initializes and runs everything and ends up sitting in loop calling the execute instruction. This problem is that this model creates a conflict if the VM and command sets are to be separate from one another. In current versions of the host it's doing the command set initializations. What we need is to do is move this startup code into PB itself. So the boot process is the same regardless of command sets that are bound to the language.

What this means in a nut shell is freedom, if the host and command set are independent of one another, then it becomes increasingly viable to bind not only in house command sets as PB commands, but 3rd party dll's as command sets also. For example, take the ColdSteel 3D engine, currently the functions can be bound into a PlayBASIC program. But, effectively when you do this both command sets are in memory together. Neither can really talk to each other, given they use completely different interfaces, but under the alternative model binding could just include the ColdSteel command set solo. Making it appear as if they was the in-house build in command set.

....

What is VM3 ?

It's the third edition of the virtual machine, and the natural progression of VM2, being based on the VM2 sources mainly but designed to be stand alone. I've been picking over the code for best part of the last week or so, with it only this morning starting to build correctly, it doesn't work mind you Smiley, but it builds which is a first step. So far, I'm yet to really write any new code really, more just splitting stuff up. Can see some opportunities for bringing some of the core GFX lib's into the VM as embedded services, stuff like image loading for example.

Splitting it up is just part of the challenge, another other rather daunting task is the required changes for compiler and run time host. Yet to really decide on a core model, given that winblows apps are all message pump based. There's a few issues since the host is handling the event clean up.. Which may or may not exist in some environments, so I can see this model needing to be revised some. The trick is going to be calling the Vm code from native environments.


14th,Dec 2011 - PBFX V1.77 Hosting VM3 - Running Cold Steel Terrain Demo


Sadly most of this stuff is probably going to sound like mumbo jumbo, but hopefully it's not too low level.. Anyway, been working on the VM3 all night and have reached the first (of many) milestones, which was to just get it running, which I can happily confirm that it now is running. What this means is the VM3 can import the pre-compiled byte code, build a program from it, then execute it on demand.

To date, i've been testing this process with tiny fragments of code, which are first compiled in a custom version of PBFX, which drops the byte code file to disc after each build. To make validating the load easier, I'm testing using a second PBFX program, which links to the new VM runtime. The loading process is pretty messy and the slightest mistake ends in crashes. So i'm basically using the PBFX program to debug the state of the loaded code and as the test host. Still finding the odd mistake, but it seems to be working correctly. To check the byte code has imported correctly, I'm just calling the attached VM to execute some code, then halting it, then checking the data tables, and repeating the process over and over.. Not what i'd call a fun job, but a necessary evil.

Now it's important to understand that VM3 on it's own, can't really do anything interesting, it handles the core maths, strings, arrays , user functions and structures, but there's no graphical command set. So in order to do something a bit more visually stimulating, It needs the command set to be linked to it. So I figured i've give the Cold Steel 3D terrain demo from year years and years ago a bit of a go. Basically, cold steel is a standalone 3d engine that comes in a single dll. PlayBASIC comes with a bindings for the library (we obviously can't include the dll since it's _commercial_), the binding links all the Cold steel commands (which are just list of functions) into the users program. This makes the external functions the same as native PlayBASIC functions. Once linked, the functions act like any other command set.

Anyway in the demo (avail through my blog) is a slightly modded version of the terrain demo (on the PB.com/sourcecodes site under cold steel), compiled in PBFX into byte code. The picture bellow shows the host program (a pbfx program) which is bound with the new VM. This program boots up VM3 by loading the pre-compiled byte code, building a program for VM3 and then sits back in an execution loop, waiting for the execution of the VM3 to halt. That's about the best i can explain it, it's complicated...

....

20th Dec,2011

....

With Christmas rapidly approaching you can imagine how much productive coding time has made it's way into PlayBASIC (or anything) lately, but it's not all bad news though, I've set up a nice shiny new set of projects for what i'm calling PBFX2 at this point (so it's separate from PB and previous PBFX prototypes), which are basically the copies of PBFX 1.77 stuff but with all the fat trimmed off the bone in regards to the legacy stuff. What's left is a nice clean dev area.

So Instruction set wise I've moved some of the missing legacy VM instructions into bound instructions, which makes the Cold Steel demo run with only one mod now, which is the removal of the breakkey off line, since that's a PB command set function. If VM3 sees this it'll just error. Now that this project is split from the PBFX, I can mess more around with how the byte code is stored and what operations need to be built in and so on.





Other Bits and Bobs




16th,Dec,2011 - Sonic the Hedgehog Loop Mock Up

In this demo, the sonic character runs through the screen and around the loop. It works by simply aligning the character to a path, the tricky bit (in this example) was creating a path that matched the backdrop picture or there abouts.



Source Code Thread



January 01, 2012 - 2d sidescroller engine in progress: DKC2 remake. Test dev.

lemon wizard has been having a bit of go at building his own version of a donkey kong country remake, starting with the editor & basic game play. Early days but it has some potential (demos + source included).


2D-Sidescroller-Engine-WIP-Donkey-Kong-Country-Remake

Kevin Picone
21
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Australia
Posted: 27th Feb 2012 15:53
PlayBASIC Round Up (Jan 2012 / Feb 2012)

It's hard to imagine, but we're nearing the point where PlayBASIC will be (if not already) 10 years old. It's been something of a strange period really, from the heights of 3D at the turn of the millennium, through to something of a 2D resurgence, largely if not exclusively helped with shifts in the technologies we play on, but still... it's nice to see that 2d isn't some distant memory.

So what's on my mind for the future of PlayBASIC ? - Well mostly continuing the long and winding road that is moving on from PB to PBFX. PBFX is really PlayBASIC V2.0, and while there are various prototypes, it's yet to see a official public release. Frustratingly there's been a number of obstacles in the projects way, but slowly they're falling by the way side.

Today the project is shaping up to the original design. For example, We're got a new IDE, new compiler, new linker, new Runtime (VM3) and soon an OpenGL based graphics engine/command set.

The new command set is made from a hybrid PlayBASIC V1.64N and PBFX1.77 (Direct3D based prototypes). This allows the engine to abstract the 3D interface behind it. Was never really happly with the older d3d versions of the gfx lib's from the design stand point. Too much pollution between the command interface and the inner engine.

So far the new graphics library is still in it's embryonic stage, with probably less than 30 commands in total, covering basic Screen / Input / Image and drawing controls (Dot/Point/Line/Circle/Ellipse/Box). But these work much like regular PB, allowing you to render primatives to the screen or images.

At this point the library is up and running, but there's really not enough meat on the bones to build an interesting game. But there's lots and lots of stuff port though

Kevin Picone
21
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Australia
Posted: 6th Apr 2012 23:58 Edited at: 7th Apr 2012 00:00
PlayBASIC Round Up (March)

March has been one of those months where you know, some of us do have to work for a living from time to time... But still managed to knock a number of tech demos where possible. Was finally able to catch up on some old legacy Amiga project videos that i've been putting off for years now. Still got a few more to post, but they're a lot more time consuming than i'd imagined. But it's good to get some of stuff out there.


In PBFX terms, been working (when time permits) on the speed of the core libraries. Speed is everything in a generic graphics engine and there's a lot of bottle necks that can get in your way if you're not careful. So it pays to revisit old code some time to time, just to make sure it's as clean as can be. This is one of those times where being a little obsessive, can have significant impacts.

One example of such behavior occurred as recently as yesterday, hadn't set out to tweak the math libs, but while staring at section of line clipping code that's been through the ringer multiple times now, it dawned on me that with a slight reshuffle, the routine can not only be made 25% or so shorter, the logic is more efficient without impacting the best case scenario. So it's a win, win.

Clipping is generally one of those long forgotten things that's easy to put in the 'it doesn't matter' pile. Its true, the gain from clipping a few lines is next to nothing. But were not running on 66mhz Pentium's anymore and user demands keep scaling up and up. So such benefits only reveal themselves when it's put under stress.

Imagine you needed to draw 100,000 lines. Clipping them will cost us significantly in raw performance, not to mention the cost of fetching the memory, even on modern behemoths, let alone some portable devices.

After a decade of looking at how people write demo/games in these BASIC styled generic graphics engines, every drop you can squeeue out of the command sets is going make somebodies project that little more viable.

Anyway, enough ramble.



PBFX GFX CORE Demo 0001 - Perspective Bubbles (Low-Quality)

Here's a short sneak peek of the perspective bubbles tech demo running on a the new OpenGL based graphics engine for PlayBASIC V2.0. The demo is perspectively projecting the bubble sprites, where each translucent sprite moves towards the camera much like in classic star field effect (Code can be found on the forums).

The effect isn't that interesting really, it's to give you a quick glimpse at the OpenGL graphics engine is in fact up and running, even if in an completely unoptimized state. The engine is linked to the PlayBASIC VM2 runtime, creating something of a Frankenstein version really just for testing. The final engine will only ship with PlayBASIC V2.0

Video By:
http://www.PlayBASIC.com
http://www.UnderwareDesign.com







Misc Videos

Here's a couple of little effect demo's for standard PLayBASIC. Pretty simple stuff, but you can find the code on forums.

Textured Tunnel


Rotating Column



Gouraud Shapes





Here's something for the RETRO AMIGA / AMOS Fans

Years ago (about 1996->98), I wrote a plug in graphics library for AMOS , that supported not only AGA , but a PLanar + Chunky screens also. Allowing for a collection 3D style stuff. The main problem with the library was it wasn't rounded out, and there weren't any meaningful demos. So i've been knocking some up.

It's kind of interesting what can be done in good old Amos, with a little help from AGE

AGE For AmosPro Dev BLog

Kevin Picone
21
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Australia
Posted: 27th Apr 2012 20:06
PlayBASIC V1.64N2 BETA #6 Avail for Registered Users ONLY)

PlayBASIC V1.64 N2 Beta #6, this revision contains all the latest runtime optimizations and Language files..

The V1.64N revision 2 is meant to address a few issues found in the V1.64N upgrade, so far it's been more of an optimization based upgrade, with various improvements being made to the PB VM.

The main changes found in this beta would be the new Compare operators, some conditional looping changes (repeat / Until - While / EndWhile), improved select case and last but not least Type Caching in the Math Operators.

Type caching is a method where the runtime can preserve info about type accesses across an expression. So far, it's implementation is limited to only being available within short cut math operators such as ++, --, +=, -=, *=, /* and logic operations.

Ie.


Internal tests show that caching gives us about around 25% gain in speed over the long hand version. Be aware though, if you try and do this on types that don't exist you'll get a runtime error. To create a type within the contain use the NEW operator as shown above.


Download

To learn more about this round of beta testing Read V1.64N2 Update Work In Progress gallery

Kevin Picone
21
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Australia
Posted: 4th Jun 2012 19:21 Edited at: 4th Jun 2012 19:24
PlayBASIC V1.64N2 Round Up (April/May)

The upgrade is basically complete, apart from another merry-go-round pass over the documentation. A lot has been happening with the compilers optimization in this version, revolving around type caching.

The following is cut'n'pasted from the WIP blog and covers some of the key points from the development of the new version. For Example Code / Pictures etc read the actual blog..




Beta #8 - Global Type Caching

Moving on from the expression type caching of previous PlayBASIC beta's, we head into the wild unknown wilderness that is global type caching. In beta 7, the caching is activated during assignments styled expressions and then turned off again, to avoid potential logical issues at runtime. Most of the logical stuff is fairly predictable, where caching could result in potentially runtime errors, it's the unforeseen stuff that worries me about this feature most of all. As such, caching is disabled by default, which reverts the parser to it's original behavior. To enable it, we set Bit 1 in OptExpression, Bit 0 is used to toggle the standard optimization (which is on by default), so to enable Both modes we set OptExpressions to an integer value of 3.

Currently, i'm slowly picking through the parser tagging the various situations where the cache should be flushed or disallowed completely. I'd like to say it's all working wonderfully well, but it isn't. Small stuff seems to work ok, but the bigger apps virtually all die at this point. Thus we'll focus on the small stuff for now Smiley - Like for example the 'Cached Type Reading' bench mark from above.

The post above, shows the results for PBV1,64N and V1,64N2 beta7 running the bench mark, now bellow we've got today's results. At first glance you might not see the big deal, but beta 8 can run a complete forth test in the time V1.64N can only run three of them. Whats more interesting is that the forth test is benching 3D typed array accesses. Now granted, the test code is set out to cache well, but I didn't think it'd work that well. To put the test in terms of bandwidth, the demo is pushing around 1/2 a gigabyte of bandwidth per second, not too bad for a 10 year old runtime, on almost 7 year old hardware.



Beta #9 - Disassembler

Work continued on the upgrade over the weekend, but with shift in focus geared more towards testing then anything else. I guess the only new addition a simple parser to convert string based Vector Stack expressions into an operations list for the resolve stack function, making the process a lot easier. Unlike the PlayBASIC compiler, the vector stack operation lists can be processed at runtime. Giving a bit of leeway in how an operation is solved.

Anyway, in terms of testing, my focus has been on trying to validate where and when the compiler is seeing cachable type operations. For some reason, some programs with heavy type usage, return little or no successful caches, even though the code was heavily serialized. After a lot of head scratching ended up coming to the conclusion that it'd be much easier to see exactly where and when it's failing if I could look a dis-assembly of byte code. Much older versions of the PlayBASIC had something similar built in, but was removed long ago. Luckily i had most of the material just sitting around.

The disassembler can currently decode about 50% of PB core instruction set (don't need all of it), in the initial version it just showed the opcode and parameter data, so you don't get anything even reassembling PlayBASIC code back. But yesterday added some 'clean up' routines that try to reconstruct that type of the expression that created this opcode, making it a lot more BASIC looking and easier to follow the logic. Some logic you could basically resource with a pretty high accuracy really, where as some bits, you can't as the information just doesn't exist or it requires multiple passes to try and guess the original logic.

The tool is currently working well enough for me to get an overview at just what the compiler is producing in various situations, and it's already revealing some rather interesting results. There seems to be the odd occasion where certain expressions generate extra MOVE operations, where they could be short cut. The odd extra operation isn't a big deal in a code that's executed infrequently , but the weigh is magnified in brute force situations. So it's well worth ripping them out.

Another oddity appears when initializing the function scope, where it seems to be writing some bogus data, dunno what's up with that. Perhaps the best thing about it so far, is that it reveals a few situations where merging some common operations could be used to reduce the vm overhead further. Some of which I think could be done a lot easier from a dedicated optimization pre-processing pass though, but well worth putting on the ideas board..


PlayBASIC V1.64N2 Beta #10 - Inner Workings Of Type Caching

Testing is going pretty well thus far, the more code I look over the dis-assembly outputs from, the more little potential tweaks appear. I think most of the problems i've been having with caching relate to array indexes where the index has changed between accesses. The parser isn't smart enough to trap those situations as yet. As a whole, the compiler takes a pretty nervous approach to caching, which you can see when picking over the code it's producing for various blocks. If i suss out the problem areas, then it should be able to be relaxed a bit more, which in turn will make further improvements.

The disassembler tool is working well, still LOTS of stuff it doesn't have a clue about, but for what i'm interested in (the core logic) it works well enough now. So well, i've dressed it a little more since yesterday. Now it allows us to see reconstructed BASIC styled versions of the instruction set. Some stuff, there's no obvious BASIC translation, but it's a lot more readable and easier to browse now than it was before.



PlayBASIC V1.64N2 Beta #11c - Smoothing Out Type Caching

Yesterdays Sprite/Map reshuffling passes ended up going a lot faster than i'd expected. It's not a lot of hands on coding work, it's just one of those things that often leads to broken instructions if your not careful, of which there were a few, but it all went pretty smoothly for once. Which leads me back for another round at type caching problem, which thankfully I've had a few more ideas about since last pass.

In previous versions, the type cache optimizer is intentionally set up to be rather over protective. So the moment it spots a user or built in function call within an expression, it turns caching off, regardless if the function/command damages the previous cached data or not. To combat this ,the command tables now have computed safety flag. The process is a bit like a shot gun really, where any function/command that accepts passed arrays as a parameter, is set to being potentially unsafe, the rest are tagged as safe. Now, yeah I know that just because a function is being passed an array it doesn't necessarily mean our cache data will be broken, but better safe than sorry.

Now that's ok for built in commands/functions, but for user functions there's really no easy way to accurately guess if the function destroys our cache data or not, so those calls disable caching until after the call. The reason this is such an issue is that we're caching a raw pointer to a previously known to exist thing, a type in this case. If we allow caching across user functions, and that function alters a previously cached type pointer, then we're in for a world of hurt. Best case scenario is it'll pop a runtime error, but I can't check at runtime where the cache data comes from. So if it's been corrupted unknowingly then any following accesses might just end up reading/writing from the wrong structure of the same type, or some different structure completely, potentially resulting in a horrible death.. It's possible to solve, but way too much work for the return.

Even so, what we're got now, is already able to chomp out slabs of bogus accesses from some of the bigger example programs, such as YAAC and THESIUS XIII for example. The tweaked optimizer spots around 100 caches in the YAAC demo (Yet Another Asteroids Clone) and almost 400 optimizers in the THESIUS demo, making around a 5/6 K saving in the byte code alone. Saving a few K is not a big deal, its just that's 5K less memory accesses the runtime now doesn't have to do, in order to do the same thing. So provided the opt's are in routines that are heavily used, we're gaining some more free performance. The down side, is that the Thesius demo is is still a little crash happy when caching is enabled globally. YAAC works fine, but its definitely not 100% at this time.

Anyway, I've also been able to address the changing variable issue mentioned earlier, now it's just matter of tracking down those last few annoying issues.



PlayBASIC V1.64N2 Beta #12b - Mmmmm Caching

After soooooo looooong...... tinkering with compiler/runtimes, there's not much in the PlayBASIC world that actually surprises me. Often a lot of work goes into the smallest of changes, sometimes we win some handy double digit performance back or expand something to make it that little more flexible, but such changes are generally pretty marginal. So imagine the look on my face tonight by simply re-blocking the cache instructions in the runtime, wins us back more performance that i'd even hoped for. So much I was initially assuming it was broken.. Couldn't possibly be down in the low teens.. But it is.

The test I'm using is the same basic type bench mark as always (Shown back here ) The test just goes through and does a bunch of read/writes to a 1D/2D/3D types arrays. Where each test is performed 25,000 times. Now in previous versions of V1.64N2, caching has shaved from between 17% up to a staggering 30% of the V1.64N speed. Which I was more than happy with to be honest. But today's edition of V1.64N2 beta 12b, is conservatively between 15-20% faster again. The 3D array is basically twice as fast.

Now even though the bench mark code is basically presenting a perfect situation for the optimizer to chew through the expressions, it'll certainly be able to improve the performance of your real world programs also. Since type usage is frequently serialized in programs, so if you have a loop that runs through and processes your game characters each frame (list or array) and there's multiple lines where the same structure is accessed (read /write), then those operations may be anywhere from 25% to 50% faster.. The amount of time won back, really comes down to how frequently the loop is executed.

Attached we have the results from the test running on V1.64N, V1.64N2 Beta11 and V1.64N2 beta12b.. Speaks for itself really..



WIP Blog

Been in documentation mode, but have been knocking up some more usage examples. Simple stuff like Sliding Collision, Vertical Sorting.

PlayBASIC V1.64N2 Development Blog




Kevin Picone
21
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Australia
Posted: 24th Jul 2012 23:00 Edited at: 26th Jul 2012 18:29



PlayBASIC V1.64N2 _Retail Upgrade_ is Available (25th, July, 2012)


The V1.64N2 upgrade was originally planned as a quick upgrade to just address a few bugs with a small documentation pass. But that quickie soon turned into one of the more important additions in years, with the introduction to the Type + Array Cache optimizers to the compiler. Beyond that, the upgrade features a number of low level speed improvements to every day operations ranging from the loops (For/next , For Each + Repeat/While loops) , General Comparisons through to complete opcode rearrangement of the Image/Sprite command sets. The goal of which being to shave as many wasted cycles from all of the every day operations as possible. It's this attention to detail that see's V1.64N2 being able to execute our standard performance benchmarks up to 1/2 a second quicker than V1.64N. Pretty impressive, given that I personally had thought V1.64N wouldn't be beaten, but things change.

In terms of the compiler, the TYPE CACHING features the are the real show pony of this upgrade. What caching does, is the compiler tracks Type and Array usage throughout a program. In older version of PlayBASIC, pretty much every time a typed variable/array or linked list was accessed, the compiler would drop the required (long hand) operations to resolve that operation. Even if the following operation was similar. This is where caching steps in, now the compiler can detects such situations and is able to use some short cut instructions when reading /writing type structures. Given that type usage is generally serialized in code blocks, this can double, even triplet the through put of some routines.

Now for the most surprising thing, Type Caching isn't enabled by default. Why ? - Well in classic version of PlayBASIC, the user is allowed to read types that doesn't actually exist, without the program falling over. Unfortunately this behavior can play havoc with caching in some programs, so the type cache mode is turned off the default. You can enable it by using the OptExpressions 3 command, it's perfectly safe provided your program only ever read/writes into types that exist. The optexpressions command allows the programmer to toggle the user controllable optimization modes on or off through out a program.


Here's an example of some code that can be potentially unsafe with caching enabled, that you might find in many older PlayBASIC programs.



What makes this unsafe is that the inner IF statement is attempting to read the STATUS field from every person in the array. When it's reading person at index #1 in the array, the expression is true and person is drawn as circle on screen. But on the next iteration of the loop, the IF statement is attempting to read a field from that cell in the array that doesn't exist. In other languages you might expect this give you a runtime error, but PB would original just return a zero from those reads. V1.64N2 keeps this behavior in order to run older PlayBASIC programs, but thing works differently when caching is fully enabled.


In this version, the IF statement isn't trying to read a FIELD from the various types in the people array, rather it's reading the array cell contents directly. Empty cells in the Typed array will be ZERO, anything else and a type exists at this position. So we can happily pre-screen for the existent of a type in array like the following.



This version is perfectly type caching firendly.


Documentation

This upgrade also features another fairly heavy pass over the documentation, which various tutorial additions and media & content additions. Tutorial wise there's a huge new tutorial all about sprites. Starting with Images and moving on through to the sprite commands, which turned out to be the way bigger than i'd ever expected. From memory it's the biggest tutorial ever.


Don't have a retail version of PlayBASIC and want to find out more information about PlayBASIC programming > please visit the www.PlayBasic.com and download the free learning edition.



Download

V1.64N2 WORK IN PROGRESS GALLERY

Kevin Picone
21
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Australia
Posted: 30th Sep 2012 21:02
PlayBASIC V1.64N2 turns into V1.64N3 Round Up (September)

It's been a strange couple months in PlayBASIC land. The V1.64N2 was slated as a simple 'quick bug fix' release, but given some changes in my day-to-day life, this quick fix turned into something of compiler update, with the addition of the type caching features. But like all good things, after the release a few (mostly) mapping bugs popped up in the N2 build. Hence, N3 was quickly slated to address those tidbits.

So starting the update, the plan was to get N3 out to the door in a week. Fixing bugs can sometimes be a bit of an adventure, you peel open some code you haven't look at in years and the ideas flood into your mind. The main issue with maps, was the block cutting code in the map library wasn't classifying the blocks correctly. Making some blocks draw incorrectly. Tracking that down was pretty tedious, but an easy fix in the end.

While poking around under the hood, ended up making some improvement to map libraries, which led to changes in the math and shapes (vector collision) lib's etc etc down int the core span rendering routines. Many of those are 3 or 4 years old. It's there we run into the legacy threading hooks.

A few years back we'd tried to add swarm based threading into the PlayBASIC classic graphics engine. Long story short, but it just wasn't viable without massive rewrites. So focus changed to the Blit FX library,. which is a set of big job functions that do drawing with transformations applied.

The original library was about as thread friendly as a shotgun, making the results as useful as a third nipple. So what's changed ? - Well i've been rewriting the interface to fix the sharing issues. The net result is a set of functions can be threaded all you want. The current implementation is for a single job, but once they're complete we'll drop in queue support.

Adding a queue, will mean you can write code where the rendering is more asynchronous. For example, if you used light mapping in your 2D scene. You can draw the 'unlit' screen as normal but push the light map rendering off to another thread. Depending on how well you balance the two sides tasks, this could potentially double the rendering performance on multi core system.

Currently in the last runs of beta testing for this 'quick' update. Hoping sometime this week we'll get it out.

MrValentine
AGK Backer
13
Years of Service
User Offline
Joined: 5th Dec 2010
Playing: FFVII
Posted: 30th Sep 2012 21:40
just jumping in...

this thread has been coming a looong way... whats the current status for V2?

Kevin Picone
21
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Australia
Posted: 15th Oct 2012 06:21 Edited at: 15th Oct 2012 06:27
MrValentine

Quote: "this thread has been coming a looong way... whats the current status for V2? "


I can't comment, other than it's a work _still_ in progress..




-----------------------------------------------




PlayBASIC V1.64N3 _Retail Upgrade_ is Now Available (13th, Oct, 2012)



The PlayBASIC V1.64N3 upgrade was slated as a bug fix, hence the version number, as after releasing V1.64N2 a few fairly major issues were discovered in the mapping command sets. While those issues have been addressed, we've again taken this opportunity to apply another round of bug the optimizations to the package. There's even some completely new functionality in way of multi core support with the addition of threading, being added to the Blit Image library functions.
[br][br]


Bug Fixes

Bug wise, the main changes would be the improved block classification routines in when importing blocks in the maps, as well as localizing the sprite to map collisions and tweaking the ray to map intersection commands, which would only work on the first level. But really the biggest issue that's been addressed, would be the legacy issues with recursive function calls. Where it seems older versions from the PB run time had some logic issues with how the stack was being managed in certain situations. After much research, it was decided that the best way to remedy the situation, would be to replace the how the run time uses the stack. While more work that i'd like for a quick upgrade, the results speak for themselves, by not only fixing the issues, but it uses less memory and is quicker at runtime.


New Feature: Multi Core / Threading

The addition is multi core support or threading support is big one. This features allows the programmer to push big blit image rendering tasks off your current cpu core onto a second cpu core on your system. The idea being, that you can [red]get your program doing two things at once[/red]. The threading commands in this version I consider to be prototypes. Meaning the function names and parameter many well change in future releases. But rather than hold this feature back, you can use it today !

Threading is disabled by default, so your programs will run entirely on the same cpu-core that they're started upon. The current implementation of threading only allows a single 'function' to the pushed onto the second core at once. So it's doesn't support queuing up render tasks. Yes, that's exactly what I've in mind, hence why the commands may change in the near future. Therefore the only commands that support threading are the BlitImage render functions. The reason being, they're generally large task functions, where if we can interleave our code, we'll get the best performance improvement. In other words, if you can work out a way to set up an effect where you can use a blitimage function to perform some action in the background, then that's an ideal situation.



As always we highly recommend reading through the V1.64N2 / V1.64N3 WORK IN PROGRESS GALLERY for some deeper insight in what new additions are hidden away in this release. There are lots of then !


Don't have a retail version of PlayBASIC ? and want to find out more information about PlayBASIC programming > please visit the www.PlayBasic.com and download the free learning edition.


Download

Download PlayBASIC 1.64N3 Retail Upgrade


How To Install Upgrades:

The upgrade process simply requires the user download the upgrade, then run it. The only interaction the upgrade process requires is agreement to the terms and conditions. Beyond that you just hit NEXT for each question.





Kevin Picone
21
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Australia
Posted: 30th Oct 2012 17:48
PlayBASIC V1.64N3b _Retail Upgrade_ is Now Available (31st, Oct, 2012)

This update includes a fix for some issues with some built in constants (like PBCompileMode) not responding to the compiler settings. Beyond that it also includes a number of mostly small tweaks to the variable/constant and literal searching routines. These tweaks improve the compile time by around 30% in programs that make heavy usage of lots of unique variables / constants or literals. Routinely getting a compile performance of 10,000 plus lines a second on 7 year old single core AMD system.


Release Announcement

Kevin Picone
21
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Australia
Posted: 29th Nov 2012 03:45
PlayBASIC V1.64N3c - Compiler Tweaks Round #2

Been off working on some other bits and bobs in the real world lately, but have been using PB for a lot of the grunt work, as such noticed some oddities in some program disassembles. The first being that the code didn't seem to screen out redundant moves between the same variable. So if the code had the line A = A, it'd drop a move operation for it, even though it's pointless. Not a big deal for the odd operation, but will certainly add up if such code exists in a tight loops.

Another oddity was occurring when reading the fields from a typed variable/array/list and storing that back in a variable. So if you had code like X#=Player.X#, the code generator would always drop there extra move operations. Not a big thing in every day code, but can quickly magnify in heavy loops. There's not a huge gain from this, it's more about stream lining the operations. Which can be seen when running the Type brute force bench mark, as there's only a about 1.5 milliseconds gain across the entire test. It'd be very handy if you cache lots of fields or they're modestly string fields.



PlayBASIC V1.64N3c - Compiler Tweaks Round #3

Dropped another session into peeking through some dis-assemblies and it would seem that reading from cached type fields also had the same problem where it'd drop extra move opcodes all the time, where they're only needed some of the time. So tweaked the code generator again and those bogus moves vanish.


PlayBASIC V1.64N3c _Retail Upgrade_ is Now Available (29th, Nov, 2012)

This update incorporates this weeks compiler and optimizer tweaks. Since the changes only alter code generation, it can be used with V1.64N3 runtimes, which haven't been included.


Release Announcement

Kevin Picone
21
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Australia
Posted: 8th Jan 2013 16:40
PlayBASIC V1.64N3d - Compiler Tweaks Round #4

Been working on various tweaks to PlayMAPPER this last week, and even though i've been able to rip a few 1000 lines out of it, the dieted version is still pretty big, weighing in just over 20,000 lines. Which when built (on average on my system) from V1.64N3 in about 3850 milliseconds. So almost 4 seconds to a person, which is lightning fast compared to the good old days. The build time is another 250/350 milliseconds quicker in the B and C revisions of V1.64N3 since they feature some of newer search optimizations, but there's a lot of function searching and Type Field searching in the program. And while there is in most programs, it seems to really impact the performance here.

So thought i'd take a look and see if the same thing that was applied to the constants/variables stuff would apply to everything else starting with Functions / TypeFields, if should, but just ya never know. Getting the function stuff working seemed to go without much of a hitch really. The type fields weren't so pleasant. But after a few hours of head scratching and good old fashion mind numbing fun, it seems to be working as normal again. The net result of what turned out into a few hours, is the build time is now averaging 2947 Milliseconds for the same project, so a second faster, which is very noticeable improvement to the user.

This might not sound like a big deal, but such changes not only make the compiler far more able to handle bigger programs without that rapidly raising the build time. They're what allow you to Edit->Test->Edit->Test in rapid succession. For many users the entire process is largely transparent. Which is how it should be.


PlayBASIC V1.64N3d - Compiler Tweaks Round #5

Made a few more tweaks the search routines tonight, but haven't really been able to win any serious time back. The build time felts really speedy on normal sized projects, which should help with productivity. Another tweak I've been messing with is screening out some redundant expressions in integer operations. I think the C revision has some of these, but the D revision includes a few more. Basically it's trapping expressions with one of the terms is literal zero/one or two. So an expression A=A+0 would have generate the addition operation, with possible a move operation. But now it produces nothing. Some other situations are thing like mults. Where you might have a A=A*1. Which will get stripped out.

In terms of the runtime performance, Addition is generally quicker than Multiplication. So knowing this, we can recast Integer expressions that include a 2 * something in them, like the expression A=B*2, this is recast as A=B+B. Today's build does this for you invisibly. PB actually includes a number of these types of tweaks today. In terms of performance, the bench bellow runs about 1/2 a millisecond quicker (15->20%) over 100K additions.






Release Announcement

Kevin Picone
21
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Australia
Posted: 18th Feb 2013 06:14 Edited at: 18th Feb 2013 06:23
Works started on the PlayBASIC V1.64O upgrade

PlayBASIC V1.64O Beta1 - Dynamic Function Calling

While under the hood, figured I'd tweak the searching up a little more in the CallFunction operation. If you call a function by name, then it has to search through the function names looking for a match. The search it self is nothing fancy, it's just a linear search, so figured it'd be a handy place for a hash level pre-screen.
With the hash, V1.64O is about 40% quicker than V1.64N3 using the original bench mark code.







Update:

Updated the search routine again, stripping another 5->6 milliseconds from the earlier update. I'd still strongly encourage user to pre-compute the function index prior, rather than dynamically searching for the function name (as a string) every single time. But it's viable either way.





PlayBASIC V1.64O Beta2 - Small Tweaks

Add a couple of tiny tidbits into today's build, the first is a constant to return the current Optimizer state. (PBOptimizeState), which allows an include to set the optimizer state it wants/requires without changing the state for the rest of the program. To do that, you just preserve the state in constant on entry to the code block then restore it at the end.

eg,





64bit Start Interval / End Interval (High Resolution timing)

Dropped a couple of functions in to query the number of high res ticks between the pair of calls. The first call stamps the start time, and the End call gets the number of the ticks that has past since the start call. Internally the timer resolution is 64bit, so the routine returns the interval in 32bit. On my system the high res timer is about 1000 ticks the resolution of the milliseconds. It'll actually be different for different CPU's... But ya get that..

The Functions can storing up to 128 (at this time) unique time points. Will most likely reduce that to 32 or something. The high resolution time is just like the millisecond timer, it's counting up regardless of what app is currently being executed.





PlayBASIC V1.64O Beta3 - String Fixes

Dunno how long this one been hanging around, but looking at the sources i'd say forever. Anyway today's little issue was found in the CutRight$() function, when the cut point is less than the first character. Previously it'd return the entire string, now it returns a null string like it should. I suspect the same fault occurs with cut left also. Assuming they're cut and paste of each other..





Edit: Yes, both function had similar issues, both run correct now.


To read all about the development of this upgrade check out PlayBASIC V1.64O Work In Progress Blog

Kevin Picone
21
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Australia
Posted: 25th Mar 2013 18:43
PlayBASIC V1.64O round up


PlayBASIC V1.64O Beta4

Just testing an alternative version of the RGB function, since the standard version expects the 0-255 values for the R components, however sometimes it's easy to use floating point representations in some algorithms. So in those cases you'd need to mult each component scalar by the 255.. Like so Rgb(255*R_Level#,255*G_Level#, 255*B_Level#) . The problem with this is two fold, first you've got the VM running 3 extra floating point mults plus there's no bounds clipping.

Performance wise the test function is about 40% faster, which should be handy little gain given it'd generally only be used in brute force loops. Currently it's called RGB2, Dunno what i'll actually be called though..





PlayBASIC V1.64O - Doc Builder V0.80 Updated

Been making some updates to the documentation and the documentation builder most of this week. The doc's are written in a kind of markup language that you'd find used in most forum software. The PB + UW web sites use a similar set of tags for the text. So text can be moved between sites without always having to reformat them for display.

Some tags that sites use that doc's didn't would be things font sizing and colour tags. So if we dragged some text over from the forum into the doc's they'd have to be reformatted. Pretty tedious stuff, where it's easier to just drop some code into the document parser in the builder.

The doc builder isn't updated very often, so when cracking open the project, it was soon obvious the parser was written to be quickly thrown to together, rather than easy to update. Most of the tags, it just use replaces$ statements on the raw text. Which is OK, but there are some situations where that approach fails (like when a tag contains a keyword another tag uses). So decided to write a more general purpose parser that new tags could be dropped into without logical problems.

The updated solution scans through the document looking for tags, when it finds a possible tag it attempts to decode it. If it's a known, we call the response function, if not, ignore and keep scanning. The parser supports all the old stuff (mostly just cut'n'pasted into the new routine) like automatic cross referencing of local links, pictures, indentation, inner menus and syntax highlighting PlayBASIC code blocks, through to a hand full of new tags for Font sizes and color controls. Which just improve the styling of the information. And when there's 1276 pages of documentation, we need all the styling help we can get.

Some other changes are better project copying support when building the manual. Previous versions would only copy projects with a single main source file. So example projects attached to articles can now have as many files as the author likes. Another addition that I can't believe hasn't made it's way into the tool sooner, is support for creation and edit dates within the articles. Which might not seem all that useful now, but we can finally track what articles are likely to be different between manual builds.




PlayBASIC V1.64O - Docs Docs Docs

Progress has been pretty slow on all fronts recently, still trying to wedge the odd documentation pass in wherever possible. Most sessions seem to focused around running the global replacement tool over the various command sets. The only problem with global replacements is they're indiscriminate. Making It a bit of a skill catching the various typo combinations without breaking other sections. The up side is that's pretty quick even though it's written in PlayBASIC classic.

It's not all about typo's though, there's a number of abbreviations that pop up throughout the manual, generally used within a hand full of variations. So I've been trying to catch them where ever possible. It actually needs some kind of glossary of terms also, just to keep it all self contained. Ideally so when it's finally put online it'll get more links in, than out. Some of that stuff could just be on the PB.com site though. Lots of terminology being thrown around that apparently almost nobody understands.

One thing the replacement tool doesn't handle though, is parsing the associated PlayBASIC examples that each articles may have. The doc's are really just a series of folders, each folder is a command set/region of the manual. Within each area, each command has it's own folder for it's attached projects. The replacement tool only looks at the article though, it doesn't load and parse attached project also, in fact it has no ideas about this concept. Meaning errors can't be trapped in the attached source files.

Not 100% sure when it'll be ready, but with the holidays fast approaching that should help things along. Probably only a few more hour sessions in it.. We'll see..

Kevin Picone
21
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Australia
Posted: 15th Apr 2013 05:13
PlayBASIC V1.64O blog round up continues


PlayBASIC V1.64O Beta 5- Dll Binding Tests

In PlayBASIC we can use system & custom external DLL's in a handful of ways, from dynamically calling the functions (CallDLL) through to binding them (via LinkDLL) so they appear as if they're internal functions. The latter is the better solution since the function pointers are resolved before program execution starts. When we use CallDLL, the operation has to solve the function pointer each call. It's not a huge overhead, but an overhead none the less.

Using DLL's can have a few issues tho, most notably that windows doesn't provide native 'load from memory' functionality. So If you write a custom expansion dll, then you're basically giving this code away every time you share the final program. In newer prototypes of the runtime (VM3) we've solved this problem already, but i've been wondering if it'd work in the legacy runtime at all ? And Yes.. it does.. sort of

So tonight's testing has been focusing on wedging the alternative loader layer into the runtime. In the test any dll linked with linkdll, is pre loaded into a chunk of memory and then manually initialized for execution. It's just defaulting to this behavior since it's the least amount of work required. After a few little catch 22 hiccups the test dll's seems to be working as normal.

Therefore, it appears that we should be able to bind custom dll's (dlls your program uses, NOT PB DLL's) into final EXE. There's probably some DLL's where this won't work (like wrappers of wrappers), but ya get that !



PlayBASIC V1.64O Beta 5- Resource Manager

Since DLL binding is working in the test, but there needs to be a system where the compiler/runtimes can attach/fetch linkdll resources as need be. To do this, I've got to build a resource manager with searching facilities into the core. Like most things, this turns out to be a little more work than i'd like, but the current incarnation seems to run pretty well (given limited testing). Each resource has it's own name (string), rather than hard pointer, allowing high level services to query the resource buffer for media by name, before continuing on an loading the thing off disc if it's not present. So in theory, pretty much anything could be attached and bundled in the same manner.

Managing the resources at runtime is one part of the problem, but the resource buffers also need to be included the byte code hunk. This is the point i'm at this afternoon, tentatively trying to solve some of the logic problems. But i think we'll get there in some way, shape or form, even if the first solution isn't as clean as I'd like.



PlayBASIC V1.64O Beta 5- Dll Resource Binding is a Go

Today's (well last nights) build of Beta 5, has binding up and running. Allowing 3rd party dll's to be packed into EXE modules, and loaded/ initialized from memory during compile and execution time also. To do this, the programmer simply adds an asterix character to the start of the LInkDLL declaration and PB does the rest.

ie



The only thing that I can see that's left to do, is try and drop some error messages in place of some of the little debug messages that can occur when somethings wrong. Namely if the DLL you try and bind can't be found.

Kevin Picone
21
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Australia
Posted: 16th May 2013 09:58 Edited at: 16th May 2013 10:01
Round Up:


PlayBASIC V1.64O Beta 6 - Replace$ Issue ? ( April 28, 2013)

Everything has pretty much ground to a halt at the moment, as while testing the Amos To PlayBASIC conversion tool, seem to be have uncovered a situation where Replace$ can fail. At least that's what it seems like on the surface. I'm more than a bit tentative pinning the blame on it as yet, after all, this is not my first rodeo and yesterday I'd traced the same issue back to the split to array function. These kind of issues are hard to track down and I'm tentative because the functions might turn out to be ok, but the strings it's passing in could be damaged. Which would definitely hang it, as the string engine assumes the VM always gives it are legal strings.. Either way something is looking fishy somewhere.

Another possible cause might be from man handling the arrays, the parser builds a tokenized view of the converted source code in nested types. Where there's the program parent type, which in turn allocates it's own line buffer, where each line is a typed array. Which not only means you can have as many programs in memory as need (I only actually need one), but each line of code is a separate 1D typed array. This removes the impact of moving lines and code fragments around. Now when the convert routines parses the tokenize code, the routine skim through looking for the Tagged Tokens. if there's a match if runs the reaction function to the token.

When changes need to be made to a line of code, it peeks into the array directly. This allows the program to move stuff without every really knowing what it's moving and without having to copy the string fragments directly. The thing is, when you start peeking and poke into an arrays memory, there's no "i think that'll work", it has to work correctly. Otherwise you run the risk of either leaking the string/type resource your moving, or your function corrupts the array data in some way. A leak would just have some information that was there, vanish so easy to track down (in most cases), but corruption can be bit more difficult. If types were being leaked, then we've see parts of the output code would vanish from final code, but it's unlikely to cause some other function down the line to die. Provided the bad routine that leaked that data, didn't insert a none existent thing into the line array. If this occurs now we've a lottery, as the bad data might actually make sense in some causes, but make it blow up in unexpected ways in others.

Anyway, while on the hunt have a found a few tidbits that were worth tweaking, but no smoking gun as yet.. well see..



PlayBASIC V1.64O Beta 7 - Boot Issues Resource Binding (: May 14, 2013)

While the resource binding stuff was added a few revisions ago now, but it's not really been tested in the wild. So wasn't that surprised to find some dependance dramas with attached dll's, in fact was expecting it. The issued turned out to be the order in which the hunks are loaded. If the function declarations are loaded before any bound Dlll they depend upon, then the address resolution will fail.. So the VM will exit when it runs into any function with a null address in user code. Another issue could occur if default command bindings and the user bindings both had resource hunks.

Been testing today's build Beta 7 with Amos-To-PlayBASIC and found another compiler dependency in the boot process on my 64bit Win7 system. Turned out to be an easy fix, runs as normal now. Not sure when that started but suspect the V1.64N revisions would have similar dramas in them but haven't tested them. No point now anyway.



PlayBASIC V1.64O Beta 9 - Tweaks & Things


Been picking through the map level collision functions looking for an issue with RectHitLevel, initially seemed the query function was pulling the wrong 'spans' from level data, but after some head scratching it turns out the routine pop's a true on any block that has been classified as solid, regardless of if they overlap or not, as they may not. Can't be sure, but are willing to bet there's some similar assumptions with other methods also. Wouldn't mind updating the Mapping stuff again actually, not a huge fan of 'pixel level operations', as masks would be better. Just not sure i can be bothered though.


To read all about the development of this upgrade check out PlayBASIC V1.64O Work In Progress Blog

Login to post a reply

Server time is: 2024-03-19 07:39:33
Your offset time is: 2024-03-19 07:39:33