PlayBASIC V1.64P (Work In Progress) Gallery

[kevin]

  PlayBASIC V1.64P Beta 21 - Data updates

     While building the data support into PlayBASIC to DLL, found a we issues with the VM data commands.   The main one was the Restore would allow a negative data pointer position.  Which would pull data from off the table, it's not clamped.    Another change is the FindDATA function had some dead weight in it and was missing the ability to search from the current DataPointer position.    This has been added as a switch in the position field, if you set the field to a -1 the command will use the existing data pointer to search from.  The position field is optional now and defaults to -1

PlayBASIC Code: [Select]

   Data 10, 20,30,40,50,10,10,50

   ; find the first instant of the Integer value 50
   ; and set the data pointer to the cell after that value
   Restore FindData(50)+1

   ; show us what where it is within the set   
   Print GetDataPointer()


   ; find the next instance of 50
   Restore FindData(50)

   ; show us where it is   
   Print GetDataPointer()
   
   sync
   waitkey

      Test Code.

PlayBASIC Code: [Select]

   Data "StartBaby"

Label1:
   Data 10
Label2:
   data 20,30,40,50

Label3:
   Data 111.111,222.222,333.333 ,444.444, 555.555

Label4:
   data "hello world1","hello world2","hello world3","hello world4","hello world5"


   DLL_DATATEST()

   sync
   waitkey
   


Function DLL_DATATEST()

      print GetDataPointer()


      Label4=100
      restore Label4


      print "Reading data types on heap"
      Count=GetDataQuantity()
      print "Count:"+str$(count)
   
      for lp=-10 to count
            restore lp
            DataType=getDataType()
            s$= Str$(lp)+"  ="+str$(getDataPointer())+" type="+str$(DataType)
            Select DataType
            
                  case 0
                        s$+="  Data="+str$( ReadData())
                  
                  case 1
                        s$+="  Data="+str$( ReadData#())
                  
                  case 2
                        s$+="  Data="+ReadData$()
            endselect
            print s$
      next
            
            
            
      print "restore tests"            
      restore "hello world2"
      print GetDataPointer()
      restore "StartBaby"
      print GetDataPointer()
      

      print "find Data tests"
      print FindData("hello world3",0)
      print FindData(50,0)
      print FindData(222.222,0)



      ; find the first instance of 50 from the current data pointer position
      print FindData(50)
      


EndFunction

[kevin]

 
  PlayBASIC V1.64P  Beta #21  - Download  

   Beta #21 fixes a few newly uncovered issues but mainly it brings everything into line with the latest builds of PlayBASIC to DLL.     The only new feature that comes to mind is the ability to search the data heap from the current heap pointer from the FindDATA function.  

     FindData originally would only search from the user defined position in the data heap, but if you pass the position as -1 now, it'll use the current data heap position (which you can read via GetDataPointer() ) as it's starting point.   The position and direction flags are optional, so the statement FindData(50)  would search for the next integer value on the heap of 50.  The direction defaults to forward.  The data pointer would then be pointing at this item.   If no such item can be found it'll return -1  

[kevin]

   PlayBASIC V1.64P Beta 23 - Opting Dead Weight from Byte Code

    When you look through enough code,  you'll see various ways people make use of the core command set.  Sometimes noticing code fragments that are effectively null.  In particular within decisions & loops where the decision expression is literal.  When such things occor, the compiler can remove/replace such statements when it notices them.  

    For example take the following Repeat/Until examples.   Both have literal expressions, so both can be solved at compile time.  In the first loop we're really just emulation a Do/LOOP,   so the parser now substitutes the Until False with a JMP statement.     In the second example, which would always fall through at runtime, the compiler now generates nothing.  

 Example #1                

PlayBASIC Code: [Select]

   setfps 60
   Repeat
         cls 
            print "running"
         sync   
   Until false

    Since the Until will always branch back to the repeat,  the decision isn't needed at all, so the code fragment actually compiles like it was this.

PlayBASIC Code: [Select]

   setfps 60
        do
         cls 
            print "running"
         sync   
   loop

   
 Example #2                

PlayBASIC Code: [Select]

   setfps 60
   repeat
         cls 
         print "running again"
         sync
   until true

       
  Since the Until is TRUE at compile time, the decision and branch aren't need at all, so the code fragment actually compiles like it was this.

PlayBASIC Code: [Select]

   setfps 60
         cls 
         print "running again"
         sync

[kevin]

  PlayBASIC V1.64P Beta 23 - Instruction Remapping

        Instruction sets are laid out in blocks inside the Virtual Machine(s), which is fine, until you run into the odd instruction that's been wrongly blocked.    For some reason, some of the more senior instructions are mapped into various 'core' instruction sets.     There's a few layers of  core instructions, but they're generally the most primitive operations. Things like math operations, comparisons, flow control etc.   

        This is not a huge drama for the VM, providing it can locate the instructions it needs, which it can.   But when we want to  export/translate the byte code, this can be quite a pain handling custom exceptions.   The PlayBASIC to DLL translator is built around the idea of mapping instruction sets into common tables.    Where the high level command sets all breaks down in a separate tables.  The low level operations don't, they must be manually resolved.    So the annoyance this creates is it's more work and ultimately more dependent than it need be.    PB2DLL can translate any known set of commands via one routine, regardless of the input/output fields.   But lower level stuff, has to be manually written.  Making the former easier in the long run,  but tedious in the short term ;(

         In terms of functionality difference to PB1.64P  VM, this makes virtually no difference at the moment.   The hope is to share some of the newer code between the two sides.   This should make execution under the VM faster (of those operations) and will strip sway some of the baby fat that's been introduced in the short term.

[kevin]

  PlayBASIC V1.64P Beta 24 - Instruction Remapping Continued - MidPoint, MinVal,MaxVal

    Still wading through the core operation functions trying to weed out any unnecessary byte code from ever being produced.    You might be aware that the PlayBASIC compiler supports pre-evaluation of  literal(constant) expressions.   This means that when PB notices an operator in your code being performed upon literals.  The operation is solved right there and then without producing any byte code at all.      So if you have line of code  Print 67*56 ,  the Multiply is solved during compilation and the output code is actually Print 3752 -  Which is really handy for the programmer and more efficient for the runtime.  


   The compile time evaluations don't just stop at simple math operators though, as a number of the internally bound functions are also able to be solved at compile time.  You can't solve everything, but the more of this stuff you trap then the less work a program has to be at runtime.   Which in term means, the less code being translated when it's exported to DLL for example.  

   The MidPoint function is one of those little operations that short cut some pretty basic logic, same goes for the Min/Max functions.   Which are also supported.   

PlayBASIC Code: [Select]

   print MinVal(100,200)
   print MaxVal(100,200)
   print MinVal#(100,200)
   print MaxVal#(100,200)

      ; test pre-solver for the mid point function
      print midpoint(100,200)
      print midpoint(100.0,200)
      print midpoint(100   ,200.0)
      print midpoint(100.0   ,200.0)

   



   

[kevin]

  PlayBASIC V1.64P Beta 26 / 27 - Testing Calling VM instructions from DLL interface

     When we build a DLL with PlayBASIC to DLL,that code hooks backs into the  PlayBASIC runtime to execute any commands you call.   The commands live in tables basically and the translator uses the table data to build calls for you.   The legacy VM uses a part table and part unrolled decisions to look up and call instructions.   What I've been thinking is the DLL tables could be used to help short cut that even more, at least for most of the main command sets.   This should reduce the calling overhead on the instruction in question.  Meaning less VM overhead and more time spent executing command set functions

     To test this, I've been working with the Bank Command set, writing a generic function caller for the DLL interface.  So the VM traps the command block and then just passes it to the generic caller.    My gut feeling was this might well add extra overhead to simpler higher level operations, which would even out in the end.   Any initial fears seems to be have been somewhat put to rest, with the experimental build (beta 27) being able to out preform beta 26.      

     On my 8 year old athlon system the code bellow runs each test in approximately 2 milliseconds per test using Beta26.  Beta27 reduce that to around 1.6/1.7 milliseconds per test.     Adding around 15 FPS to the test.

PlayBASIC Code: [Select]

   Max =10000

   Do
      cls

         frames++

         Bank=NewBank(Max+64)

         t=timer()
            for lp =0 to Max-1         
                  ThisByte=PeekBankByte(Bank,lp)
            next
         tt1#+=Timer()-t
         print tt1#/frames
         

         t=timer()
            for lp =0 to Max-1         
                  ThisByte=PeekBankWord(Bank,lp)
            next
         tt2#+=Timer()-t
         print tt2#/frames


         t=timer()
            for lp =0 to Max-1         
                  ThisByte=PeekBankInt(Bank,lp)
            next
         tt3#+=Timer()-t
         print tt3#/frames


         t=timer()
            for lp =0 to Max-1         
                  POkeBankByte Bank,lp,ThisByte
            next
         tt4#+=Timer()-t
         print tt4#/frames
         

         t=timer()
            for lp =0 to Max-1         
                  POkeBankWord Bank,lp,ThisByte
            next
         tt5#+=Timer()-t
         print tt5#/frames


         t=timer()
            for lp =0 to Max-1         
                  PokeBankInt Bank,lp,ThisByte
            next
         tt6#+=Timer()-t
         print tt6#/frames

;         pokebankstring Bank,10,"Hello World",0

;         s$=PeekBankString(BAnk,10,0)

         deletebank Bank

         print s$
         print fps()

      Sync
   loop

[kevin]

PlayBASIC V1.64P BETA #27 (Retail Compiler Only Beta) - (Avail for Registered Users ONLY)  (8th,Mar,2014)

     PlayBASIC V1.64P  Beta #27 continues with it's PlayBASIC to DLL alignment so many changes related around cleaning up byte code / fixes mainly.   But that's not the only thing this build includes,  Beta 27 is first built to share the DLL interface with the internal VM.   This means the VM and now call some commands directly without having to solve them.    So far only the BANKS, SOUND and MUSIC sets have been converted to this form, but the idea is to convert as many of possible.  

       The advantage of sharing the DLL interface with the VM, is we not only get faster function calling from the VM but it helps reduce the size of the VM.  Just converting 3 mid sized command sets pulls 16->20K from the runtime.  I suspect we'll be able to trim a lot more when some of the bigger sets are done.  At this point I just want to be sure it's all working as expected.    



Download

    Download PlayBASIC V1.64P Beta 27 (8th,Mar,2014)   (old file removed)

[kevin]

  PlayBASIC V1.64P Beta 28 -  Expanding Support For Calling VM instructions via the DLL interface

      The previous version (#27) includes the first few tastes of refreshed VM calling convention,  so today's objective was to extend the support across more of the core command sets,  as I write this, FONTS, RGB, 2D graphics General & SHAPES are using the new method.    Everything has progressed fairly easily as most of the hard work was done when building the internal DLL interfaces some months ago.    All I really have to do to hook these up, is strip out the old legacy opcode trapper for each command and replace it with the new one.   The only problem I ran into so far,  was some speed issues with DOT/FASTDot,  which initially perform  worse due to the change.   The overhead they experience is from the 'wrapped' nature of the command set, it should be possible to get trim some of that fat away, but for now i've reverted that change.   All the other commands in that library (2d drawing) are handled the new way and do perform better for it.

      So how fast is it ?  - Well, in the RGB benchmark bellow, beta 28 is around twice as fast as previous editions.  Not too bad for a change that's really a by-product of PB2DLL :)  

PlayBASIC Code: [Select]

   Max =10000

   Do
      cls
      
         frames++

         print "Rgb()"
         t=timer()
            for lp =0 to Max         
                  a=rgb(lp,lp,lp)
            next
         tt1#+=Timer()-t
         print tt1#/frames
         
         print "ARgb()"
         
         t=timer()
            for lp =0 to Max         
                  a=argb(lp,lp,lp,lp)
            next
         tt2#+=Timer()-t
         print tt2#/frames


         print "RgbA() RgbR() RgbG() RgbB()"
         t=timer()
            for lp =0 to Max         
                  a=rgba(lp)
                  a=rgbr(lp)
                  a=rgbg(lp)
                  a=rgbb(lp)
            next
         tt3#+=Timer()-t
         print tt3#/frames


         print "RgbFADE"
         t=timer()
            for lp =0 to Max         
                  a=rgbfade(lp,50)
            next
         tt4#+=Timer()-t
         print tt4#/frames
         

         print "RgbAlphaMult"
         t=timer()
            for lp =0 to Max         
                  a=rgbalphamult(lp,lp)
            next
         tt5#+=Timer()-t
         print tt5#/frames


         print "RgbAlphaAdd"
         t=timer()
            for lp =0 to Max         
                  a=rgbalphaadd(lp,lp)
            next
         tt6#+=Timer()-t
         print tt6#/frames


         print fps()

      Sync
   loop

       

[kevin]

PlayBASIC V1.64P BETA #28 (Retail Compiler Only Beta) - (Avail for Registered Users ONLY)  (10th,Mar,2014)

     PlayBASIC V1.64P  Beta #28 goes further with VM calling convention changes, moving the FONT, RGB, SCREEN, 2D Graphics (general) and Shape command set to the new form.     Generally everything has gained in terms of performance.  Some functions will benefit more than others, which is to be expected.   For example,  calling a colour function like RGB() turns out to be about 50% faster, where as calling a function like GetScreenWidth() might only be about 10->15%  faster.      

     You should expect a steady flow of betas as the transformation takes place.   It's best to test them incrementally, rather than waiting and trying to run the final on your code, as there are bound to be differences that have gone unnoticed in the DLL function interfaces.   Testing small steps lets us solves what works and what doesn't during the process.  



Download


    Download PlayBASIC V1.64P Beta 28  (10th,Mar,2014)   (Obsolete version removed)

[kevin]

  PlayBASIC V1.64P Beta 29/30 -  Expanding Support For Calling VM instructions via the DLL interface

     Today was something of a small victory, translating 5 command set banks to the new format.     Starting with the Math Intersections library, moving to the Camera commands/functions, onto the scene commands and finally through the World commands.     The progress was fairly painless, it's just making sure everything lines up in the tables.   When they do, things seem to work out of the box, if not, they don't..    Have found the odd command/function that does behave differently mostly due to the  wrappers having incorrect parameter types.    Nothing really big through, just little things.   There's bounf to be more of them though !

     One of the best things about converting the VM to use the internal DLL function interfaces for command sets, is it means they'll be functionality identical.   So calling CLS from the VM or from your DLL, means they're both running the exact same code.   In previous editions of the P upgrade  that was dependent upon the function, so they weren't always the same.   Moreover this has a flow on effect also, meaning less PB2DLL testing is required, since if it works in normal PB, they it's 99.9% likely it's going to work from an exported DLL too.

     So timing today's build 29/30 against 26 for the following and we win back 15->16 milliseconds across the test.

PlayBASIC Code: [Select]

   Max =10000
   
   Gosub MakeWorld

   Cam=NewCamera()

   Do
      cls
      
         frames++

         print "GetCameraX & Y()"
         t=timer()
            for lp =0 to Max         
                  x=getcamerax(Cam)
                  y=getcameray(Cam)
            next
         tt1#+=Timer()-t
         print tt1#/frames
         print x
         print y
         
         print "POsitionCamera()"
         t=timer()
            for lp =0 to Max         
                  positioncamera cam,100,200
            next
         tt2#+=Timer()-t
         print tt2#/frames


         print "MoveCamera()"
         t=timer()
            for lp =0 to Max         
                  Movecamera cam,1,1
            next
         tt3#+=Timer()-t
         print tt3#/frames


         print "Get Camera Width & Height"
         t=timer()
            for lp =0 to Max   
                  w=getcamerawidth(Cam)
                  h=getcameraheight(Cam)
            next
         tt4#+=Timer()-t
         print tt4#/frames
         

         print "World Info"
         t=timer()
            for lp =0 to Max         
                 result=GetWorldStatus(MyWorld)
                 result=GetWorldElements(MyWorld)
            next
         tt5#+=Timer()-t
         print tt5#/frames


         print "GetWordlClosestPOint()"
         t=timer()
            for lp =0 to Max         
                 result=GetWorldClosestPoint(MyWorld,mx#,my#,x1#,y1#,x2#,y2#)
            next
         tt6#+=Timer()-t
         print tt6#/frames



         print "Ray Intersect World()"
         t=timer()
            for lp =0 to Max/2         
                 result=RayintersectWorld(MyWorld,100,100,200,200)
            next
         tt7#+=Timer()-t
         print tt7#/frames
         print lp
         
   
         print fps()

      Sync
   loop
   
   
   
MakeWorld:
   
    
; ==============
; Part #1 - create a world to collide with
; ==============
  
; Get the Screen size and use it as the world size
  WorldWidth=GetScreenWidth()
  WorldHeight=GetScreenHeight()
  
; create a Camera
  MyCamera=NewCamera()
  
; Create world
  MyWorld=NewWorld()
  CaptureToWorld MyWorld
  
; draw a series of boarder line for this world
  Line 0,0,worldwidth,0
  Line worldwidth,0,worldwidth,worldheight
  Line worldwidth,worldheight,0,worldheight
  Line 0,worldheight,0,0
  
  
  randomize 1000
; draw a series of polygon shaped obejct into the world
  For lp=1 To 10
     xpos#=50+Rnd(worldwidth-100)
     zpos#=50+Rnd(worldheight-100)
     size=RndRange(30,100)
     angle=Rnd(359)
     Make_Convex(RndRange(3,20),xpos#,zpos#,Size,angle)
  Next lp
  
; Partition The world up into 32 by 32 cells
  PartitionWorld MyWorld,32
  
; Tell PB to return to Immediate drawing mode
  DrawGFXImmediate
  
  
  
  

return
  
  
; This function creates a convex polygon shape
  
Function Make_Convex(edges,xpos#,ypos#,Size,angle)
  sa#=360.0/edges
  c=RndRGB()
  For lp=0 To edges-1
     a#=angle+(lp*sa#)
     x1#=xpos#+CosRadius(a#,size)
     y1#=ypos#+SinRadius(a#,size)
     If lp<(edges-1)
        a#=angle+((lp+1)*sa#)
     Else
        a#=angle

Login required to view complete source code

[kevin]

PlayBASIC V1.64P BETA #30 (Retail Compiler Only Beta) - (Avail for Registered Users ONLY)  (13th,Mar,2014)

     Beta #30 continues with the VM calling convention changes. This version has most of the command sets converted, including the main ones like IMAGES, SPRITES, MAPS and so on.   Read the history for a detailed list of  VM changes.

     Be warned though, I've noticed a few gremlins in some examples and are expecting users to help find the differences !



Download


    Download PlayBASIC V1.64P Beta 30 (13th,Mar,2014)  - (Obsolete Version Removed)

[kevin]

 PlayBASIC V1.64P BETA #31 (Retail Compiler Only Beta) - (Avail for Registered Users ONLY)  (16th,Mar,2014)

     Beta #31 continues with the VM calling convention changes extending support the input commands  Mouse, KeyBoard, Joystick, File SYSTEM, File STREAM, File Name and ReadDir commands.

     It also includes a number fixes from the conversion,  there's still a few oddities here and there and probably a lot more than than that,  so get testing !



Download


    Download PlayBASIC V1.64P Beta 31  (16th,Mar,2014)   (Obsolete Version Removed)

[kevin]

  PlayBASIC V1.64P Beta 32 -  Testing Testing Testing

      Progress has been super slow this last week due to amount of testing required,  been able to trap a lot of issues with the DLL interface command sets, meaning those commands will function the same way internally and externally now, but there's still problems with some programs, like in 'For Foxes Sake' after the user picks up the paint brush the peeks/pokes to the map seem to go a little haywire.   Having not written it, i'm struggling to follow the logic to try and isolate where the issue originates form.    But that's about only the big demo I've run that misbehaves today, that i'm aware of :)

      Taking the axe to the VM has meant about a 200K reduction in the final runtime sizes.  So the current test runtimes for  PV1.64P are now smaller than the V1.64O release runtimes.    So it'll be smaller and faster..  can't complain about that !

[kevin]

  PlayBASIC V1.64P Beta 32 -  Testing Continued

     Today is really the last day i can afford to spend on testing, have found a few commands that weren't functioning, like SpritesInShape because the caller didn't understand array fields.   Actually cleaned the up the command somewhat also, just making sure it won't crash if passed an array that doesn't exist, or is the wrong type.   The VM is ambiguous when passing arrays and complex structures, so it's possible to pass commands structures of the wrong type, which need to weeded out at runtime.  Generally the type is uses as the reaction.   

     

[kevin]

 PlayBASIC V1.64P BETA #36 (Retail Compiler Only Beta) - (Avail for Registered Users ONLY)  (8th,Apr,2014)


     PlayBASIC V1.64P  Beta #36 completes the VM calling convention changes, as well as includes some bug fixes to the byte code libs.  Ran into a strange problem with the byte code libs where the exported byte code could be hundreds of megabytes in size, turn out to be the resizing routines being a tad over jealous when expanding the buffers.    

     This version also includes a subtle change to the compiler when returning errors.   Previously when the compiler found an error, the compile dialog would stop and wait for some input from the user,  but this is now gone in favor of just using the IDE for this.   The stop could be problematic in PB2DLL when an error occurs in the input source code.



Download


     Removed - Newer betas on next page