PlayBASIC V1.65 (Work In Progress) Gallery

kevin · January 10, 2017, 06:59:56 AM

PlayBASIC V1.65B - Beta 2

It's strange how life and art seem to emulate each other from time to time, but the last few coding sessions have been mainly house keeping, which is what I've been doing mainly in my real life too. The V1.65 runtime is in strange place at the moment, a huge amount of work has been done, but there's still some bridges to cross, or at least from what I can tell in comments/doc's I'd been jotting down.

Some of the remaining changes are the kind of stuff I'm not ready to take on today, as they tend to create nasty cascading side affects (as they're project wide) , so might have to limit myself to small but achievable things within the time frame available.

One task I've set myself of far is simply wandering through the shared/combo VM and culling anything that outgrown it's usefulness, of which there's a lot of legacy VM stuff hanging around, a bit like a boat anchor.. Ripped a bunch of array function double up (and more to come) which can itself be a painful, as routines you wouldn't expect are used in some other command set, often as some short cut here and there. Which might have been useful back in the day, but it's none the less annoying now...

In terms of bug hunting, form what I can tell so far (from the few things listed), the reported issues occur from either opcodes having different behaviours (to 1.64 and older) or in some cases simply don't have any support in the new runtime or compiler of some legacy ability. In other words there's opcodes that haven't been added yet... but ya get that :)

kevin · January 27, 2017, 02:24:16 AM

PlayBASIC V1.65B BETA #4 (Retail Compiler Only Beta) - (Avail for Registered Users ONLY) (27th,Jan,2017)

V1.65B Beta #4 is the 9th public build of V1.65. This build contains a fix that could break the compipler during big sources (maybe some more of those in tghere) and the DeleteArray wasn't hooked up in the newer runtime.

Bug Reporting

See->> PlayBASIC V1.65 Bug Reports (login required).

Download

Get PlayBASIC V1.65B Beta4 (login required) (27th,Jan,2017)

kevin · January 29, 2017, 01:34:05 AM

PlayBASIC V1.65B - Beta 5

Been tweaking the type variable/array/list reading code (it's all the same thing), which used to allow programs to access types that doesn't exist (ie not allocated) within the container. It's important to remember that Dim creates the container at runtime, and not the actual structure(s).

ie

PlayBASIC Code: [Select]

     Type Stuff
            a,b,c
     EndType  
 
  ;  The DIM defines the variable THIS of type STUFF at compile time, and at runtime DIM allocates THIS's container.
  ;   But the structure (of type stuff) hasn't been used created.   
     Dim This as Stuff

   ; To create/alloc  it we'd..
      This = New Stuff

   ;  So NEW allocates the memory and returns a type handle for us to store in the container.

Now, what users often do with typed arrays is they read fields from types that don't yet exist.. Take a look at this, which is legal in old version of PB.. but isn't in the current build of V1.65

PlayBASIC Code: [Select]

      Max = 100

     Type tObject
              Status
              Xpos#,Ypos#
              Sprite
     EndType  
 

     Dim Character(Max) as tObject
     

      For lp =0 to Max
      
        if Character(lp).Status=true
        
                 ; do character stuff etc
           
        
        endif
        
      next

What's wrong with it ? - Well, the type structures inside the array haven't been allocated. So the code Character(lp).Status is reading memory from a Type that doesn't exist. Old PB runtimes trap this and let you get away with it. It's not something i'm fond of..

So the current builds would pop a runtime error with the above code.

What you should do, is read the array for each types handle first, before accessing any fields within it. So If there's handle (any none zero value), it that type exists. If the value returned is ZERO, that cell is empty and there's nothing in this container as yet, be it Typed Variable or Typed Array..

PlayBASIC Code: [Select]

    Max = 100

     Type tObject
              Status
              Xpos#,Ypos#
              Sprite
     EndType  
 

     Dim Character(Max) as tObject
     

      For lp =0 to Max
      ; check if this type is allocated ??
      ; if it's not null then it must exist.

        if Character(lp) <> NULL
        
                 ; do character stuff etc
        
        endif
      next

kevin · February 03, 2017, 06:25:43 PM

PlayBASIC V1.65B BETA #5 (Retail Compiler Only Beta) - (Avail for Registered Users ONLY) (4th,Feb,2017)

V1.65B Beta #5 is the 10th public build of V1.65. This build contains two changes, the first one just one tweaks ATAN to return an ANGLE rather than RADIANS, so you might well find one code that will break in this build.. The other is more likely to hit you in the face, as the runtime now traps a read accesses from types that don't exist and will pop a runtime error..

Here's a post about type changes in PlayBASIC V1.65B - Beta 5

Update: newer build bellow

kevin · February 08, 2017, 12:51:32 AM

PlayBASIC V1.65B BETA #7 (Retail Compiler Only Beta) - (Avail for Registered Users ONLY) (8th,Feb,2017)

V1.65B Beta #7 is the 11th public build of V1.65. This revision fixes a problem found in the CallDLL instructions. The older 1.65 versions would decode types passed through using the legacy Type structures which of course at some point have been removed and now replaced. So the new opcodes just needed to be tweaked to pull the structure info from the new APP structure. So slowly but surely the legacy runtime components are vanishing into far distant memory.

Bug Reporting

See->> PlayBASIC V1.65 Bug Reports (login required).

Download

Newer build bellow.

kevin · February 12, 2017, 07:43:17 AM

PlayBASIC V1.65B BETA #8 - Linking Commands Sets Into New VM & APP format

Unfortunately the hiatus has sucked the life out of the project generally, but there are some up sides though, which is extra time between sessions tends to give you more strange ideas on how things can be linked together more easily.. So without a lot of effort, which I like the idea of mainly..

In V1.65 the new app format & it's instruction set only covers the 'core' instructions behind your program. This is the real nuts and blots stuff, but the the majority of command sets aren't handled through it at all. Well that's not entirely true, some things that are considered part of core are already in, while most specific command sets stuff is zoned as external command set. So stuff like string functions for example would be in core (as they're universal) but commands like the Sprite commands are not..

While developing PB2DLL a lot of work had was made to PB in an effort to externalize the command sets in a way that can be plugged into a program based upon a usage. Old PB runtime don't generally work like that, they tended to have a opcode decoded as part of the Vm (although there's a few variations of that basic theme).. Which was handy in some ways, but totally breaks when you have something like PB2DLL . This is because you need to call a command directly.

In todays build I'm working on a way of encoding instructions that will hopefully means they can be moved more easily into the new runtime without really having to to do a lot of hands on coding.. Not into that.. Ideally it should be possible to call any command from the set without breaking the existing stuff.. The basic optimizations prolly won't work (come to think of it) but it should mean that I can move 100's of commands over rather than a block at a time...

The benefit of this is basically speed for the short term. Currently any unknown opcodes on the new VM side, abort execution and fall back to the legacy runtime to be picked up there.. Which is very expensive.. I'm hoping we'll see a 25 to 50% calling gain.. Perhaps more on some commands, but we'll see...

Update:

After a bit of messing around I've managed to get one block of commands working using this method. The comands set is the just colour commands (The RGB stuff) but the bench mark now runs about twice as quick..

What's missing though is error trapping, which is handled in different ways.. I 'm assuming that If i drop in a status check into the general decoder, we'll loose some of that speed for the time being.. At least until I can make a cleaner.

But it works !

kevin · February 24, 2017, 06:34:44 AM

PlayBASIC V1.65B BETA #11 - Command Set Decoupling

Well we're getting some of the new VM problems sorted as time goes by, have sort far moved about a third of the internal command set to the new decoupled system and the results as very good, it makes the VM simpler and they perform better. But... there's a BUT... Annoyingly I've had to reshuffle the core 2d primitives command sets to get them to work. It's annoying for two reasons, first is I'd forgotten they still had some inline code in the legacy VM in them and second is that the really granular commands like Dot & FASTdot turn out to be about 20->25% slower, which is not a nice finding after all the work that's gone into it.

I used the same tests between versions, you know year in , year out. The FastDot one boils to a full screen fill which is something like this (all the test code is on dev box)

PlayBASIC Code: [Select]

    For ylp=0 to Heigt-1
      For xlp=0 to Width-1
            fastDot Xlp,Ylp,Colour
      next 
      Colour+=SomeValue
    next

Now the clued in coder would notice that's a pretty awful code, but as it's just drawing strips of colour, but it's really a test of the how fast the loop + fastdot functions can be called.

While on the subject, here's a few ways to write pixels.. Some need a bit more work, but with that comes higher performance.

PlayBASIC Code: [Select]

   Constant BumpValue=$111

   Method=0
   Do

         Cls 0

         if SpaceKey()=1 and Toggle=0
               Method=Method+1
               if FunctionExist("Test"+str$(MEthod))=false
                     Method=0
               endif
         endif
      
         Toggle=ScanCode()<>0
         
   
         CallFunction "Test"+str$(MEthod)

         print fps()
         print "Space to Cycle Test"


      Sync
   loop



// -----------------------------------------------------------------------------
// ----------------------------[TEST0 -  DOT]--------------------------------
// -----------------------------------------------------------------------------
// -----------------------------------------------------------------------------

Function Test0()
   Height   =GetScreenHeight()
   Width      =GetScreenWidth()
   lockbuffer
      ThisRGB=Point(0,0)
      Colour =0

     For ylp=0 to Height-1
         For xlp=0 to Width-1
               DotC Xlp,Ylp,Colour
         next 
         Colour+=BumpValue
    next 
   unlockbuffer
   Print "Test0: DOTC"
   
EndFunction





// -----------------------------------------------------------------------------
// ----------------------------[TEST1 - FAST DOT]--------------------------------
// -----------------------------------------------------------------------------
// -----------------------------------------------------------------------------

Function Test1()
   Height   =GetScreenHeight()
   Width      =GetScreenWidth()
   lockbuffer
      ThisRGB=Point(0,0)
      Colour =0

     For ylp=0 to Height-1
         For xlp=0 to Width-1
               fastDot Xlp,Ylp,Colour
         next 
         Colour+=BumpValue
    next 
   unlockbuffer
   Print "Test1: FastDOT"
   
EndFunction




// -----------------------------------------------------------------------------
// ----------------------------[TEST2 - POkeINT]--------------------------------
// -----------------------------------------------------------------------------
// -----------------------------------------------------------------------------

Function Test2()
   Height   =GetScreenHeight()
   Width      =GetScreenWidth()

   lockbuffer
      ThisRGB=Point(0,0)
      Ptr         =GetImagePtr(0)
      MOdulo   = GetImagePitch(0)
      Depth      =GetScreenDepth()
      Colour =0

     For ylp=0 to Height-1

         if Depth=32
         
            RowPtr=Ptr+(yLP*MOdulo)
            For xlp=0 to Width-1
                  PokeInt RowPTR+(xlp*4),Colour
            next 
         endif
   
         Colour+=BumpValue
    next 
   unlockbuffer
   
   Print "Test2: Direct Memory Access: PokeInt"
   
   
EndFunction






// -----------------------------------------------------------------------------
// ----------------------------[TEST3- Pointer Array ] ----------------
// -----------------------------------------------------------------------------
// -----------------------------------------------------------------------------

   Type tRawRow
         Row(8192)   
   EndTYpe


Function Test3()
   Height   =GetScreenHeight()
   Width      =GetScreenWidth()

   lockbuffer
      ThisRGB=Point(0,0)
      Ptr         =GetImagePtr(0)
      MOdulo   = GetImagePitch(0)
      Depth      =GetScreenDepth()
      Colour =0

     For ylp=0 to Height-1

         if Depth=32
               DIm RowPtr as tRawRow pointer
               RowPtr=Ptr+(yLP*MOdulo)
               For xlp=0 to Width-1

Login required to view complete source code

Anyway, so getting back to the problem, I think we can get past some of the bottle necking with it, but we might have just have to live with it, at least for the time being..

kevin · March 25, 2017, 08:00:23 PM

PlayBASIC V1.65B BETA #14 (Retail Compiler Only Beta) - (Avail for Registered Users ONLY) (26th,Mar,2017)

V1.65B Beta #14 is the 12th public build of V1.65. This revision moves some of the core command sets so they execute on the new VM side 100%. Older revisions would flip flop between the new and old run times to do this, so this build executes such loops faster than previous V1.65 editions.

Bug Reporting

See->> PlayBASIC V1.65 Bug Reports (login required).

Download

New builds bellow

kevin · May 17, 2017, 09:28:56 AM

PlayBASIC V1.65B BETA #17 - Command Set Decoupling - Getting Simpler By The Day (18th,May,2017)-

Fired up the compiler/VM project the last few nights ripping into the left over command sets that are still suck on the old VM side on the runtime. Initially i was a little worried about this stuff as it's big (lots of commands) but after a few teething problems (ie not remember how some stuff works :) ) the sprites command blocks are now moved and working correctly. A few more sessions and they should just about all be detached, the error trapping isn't as pretty atm, but you'll have to live with that in the mean time. While looking over the caller code, it's very very generic, so there's some free speed sitting on the table once they're all everything moved over (10% or more on the call cost). So the losses from brute force functions like DOT drawing should be recovered.

kevin · May 25, 2017, 10:11:44 PM

PlayBASIC V1.65B BETA #21 (Retail Compiler Only Beta) - (Avail for Registered Users ONLY) (26th,May,2017)

V1.65B Beta #21 is the 13th public build of V1.65. This revision moves all the core command sets across to the new VM side. Progress wise it's now about 98% running on the new VM, there's couple of legacy (and common) commands that still execute on old VM side and some missing legacy features in the new VM, which will be moved, but i wanted to get some info about how this runs in the wild first.. If it's OK then we can build a retail and get stuck into the final part of the process.

See->> Read V1.65 Update Work In Progress gallery (login required) for some info on what's changed.. Lots of STUFF.

Bug Reporting

See->> PlayBASIC V1.65 Bug Reports (login required).

Download

old file removed, release build bellow

kevin · June 05, 2017, 09:00:23 AM

PlayBASIC V1.65B BETA #26 - Legacy Debugger To New Vm bindings

So as I was saying in the blog the other day the only set of command still running on the legacy VM side, is the debugger calls which aren't as easy to export, at least how they've been implemented into the old VM.. When you stop and pause a program for example, the VM included some special fall through logic, which works, but needed a bit of tweaking to get stuff functioning again ( as it's mostly broken in Beta21 above), which is what i've been doing over the last week.

It seems we might also be able to add a new deadlock feature or at least something to the current runtime that will post messages to the console when it thinks your code is chewing up too much VM time, without refreshing the scene (sync)... If you don't sync, you're not calling the message pump and windows doesn't like that and will start to think your app is dead..

Anyway, so it's starting to work again.. If I get it tweak tonight i'\ll throw up a another live beta later on today and fingers crossed we can build a retail edition.. yay !

kevin · June 08, 2017, 09:53:36 AM

PlayBASIC V1.65B BETA #26 (Retail Compiler Only Beta) - (Avail for Registered Users ONLY) (09th,June,2017)

V1.65B Beta #26 is the 14th public build of V1.65. This revision tweaks up the debugger so that it'll work with 165 VM, it's not 100% but that why we beta these things..

See->> Read V1.65 Update Work In Progress gallery (login required) for some info on what's changed.. Lots of STUFF.

Bug Reporting

See->> PlayBASIC V1.65 Bug Reports (login required).

Download

old files remove, release build bellow

kevin · June 22, 2017, 10:33:51 PM

PlayBASIC V1.65B _Retail Upgrade_ Now Available (23rd, June, 2017)

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

The V1.65B includes second release of the next generation of the PlayBASIC virtual machine. In this build 99.99% of the commands now execute on the new VM side, giving much higher execution performance. There are still some 'commands' tied to the legacy VM which mainly the debugger command set and few text commands such as Print and TEXT and the Sync command which is actually a VM TRIGGER..

Performance wise this is easily the fastest edition of PlayBASIC to date, even though the runtime is missing some of the byte code optimization modes found in the V1.64 builds, which will be tackled in the next revision of 1.65, but for now get stuck into it

Reminder: The new runtime doesn't support reading from types that don't exist, which can cause old programs to fail from time to time.. For a full V1.65B development story read the PlayBASIC V1.65 blogs and for V1.65 related errors, post them in the V1.65 bug reporting thread (login required).

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.

Blogs

PlayBASIC Video Blog Ep 0003 (2017 -06-24) (login required)

Downloads

Download PlayBASIC V1.65B Retail Upgrade (login required) (23rd,June,2017) (No download managers!)

kevin · August 14, 2017, 10:10:48 PM

PlayBASIC V1.65C BETA #2 - Debugger Fixes

Kicked off work on revision C too iron out the left over problems in V1.65B starting with tweaking up the debugger again, which still has legacy hooks into the old variable tables when looking at pointers and typed pointers in particular, which would either work or crash or both :) Skimming through it and there looks to be a few gremlins in the bowels of that code as well.. Mainly due to the new VM's application structure.. Some stuff is looking at old mirrored data from when code it would execute across the two runtimes, which are still present, but hopefully we can get rid of those legacy opcodes in this build and be done with it. Which will mean any mirrored data fetches will disappear also, which is better for the CPU caching and execution performance.

kevin · August 21, 2017, 09:40:27 AM

PlayBASIC V1.65C BETA #3 (Retail Compiler Only Beta) - (Avail for Registered Users ONLY) (21st Aug,2017)

V1.65C Beta #3 continues to clean up the V1.65 runtime and debugger. This version fixes a problem with the NOT operation which wasn't computing the target variable offsets correctly within the APP structure, so it was working but reading the wrong data. Making some stuff appear to work, but it didn't really..

The changes to the debugger, first we've go some fixes to viewing pointers and typed pointers can now resolve the structure and decode the memory. We might need a safe mdve here too, as it's possible a pointer is looking at memory that has been deallocated.. Another change is the addition of some extra information when viewing variables in the debugger. If you click on a Integer now, you'll see it's value as Integer ? Hex & Binary as before, but i've also added a colour and ASCII field also.. I've also tacked in a hex view into the String variable viewer. So it shows the length of the string, the raw character data then a hex view..

Bug Reporting

See->> PlayBASIC V1.65 Bug Reports (login required).

Download

Download PlayBASIC V1.65C Beta3 (login required) (21st,Aug,2017)

News:

PlayBASIC V1.65 (Work In Progress) Gallery