PlayBasic V1.64k WIP Gallery

[kevin]

 PlayBASIC V1.64k  Beta 15 - Yet Another Asteroid Clone.

    Been busy today with other real world stuff,  so tonight I thought i'd knock up a  demo rather than tinker with parser/compiler.    This one is yet another asteroids demo,  it's really just the first thing that came to mind (that didn't require artwork :) ) .  The Interesting thing is, that Asteroids is a game that's often discussed (ie. a common question I get) but I don't really recall seeing too many people get a demo up and running.  So I knocked this up.

    The demo doesn't actually use anything new in terms of rendering, it's just some alpha additive shapes on depreciated buffer (image blurring).   The only thing that makes it a 1.64K program  is in the code.    Which just uses some of the new features here and there.   It could be made to run it in V1.64I/V1.63LE but then there's no point posting it here.. :)

     So far the demo features player controls, basic asteroids and player firing, collisions and some particles.   Looks ok when running...


   YAAC - (Yet Another Asteroids Clone) Blog




 

[kevin]

 PlayBASIC V1.64k  Beta 16 - Exporting Pointers from PSubs.

   Functions and Psubs might look very similar on the surface, but internally they're very different.   Originally PlayBasic was only ever designed to be support the three basic data types,  Integer,Floats & Strings.    So a lot of PB runtime internals we're built around this assumption.   However, later on during development, Pointer support was added internally, then later (partly) exposed to the user.    Of course, when we tack new functionality in, this has  habit of creating some potential issues with older parts of the core parser & code generation.  

  One such omission  was that even though PSUB declarations allow pointer fields to be declared,  internally the code generator couldn't meaningfully resolve such operations.    So the generator would spit out opcodes that didn't make sense to the runtime, resulting  in a Unknown  Opcode error upon execution.    While here we're focusing upon export pointers, importing them and also cause similar issues.

  So resolving these situation is the my current focus.  So far,  basic pointers can be exported with 'type mismatching' applied.

PlayBASIC Code: [Select]

   explicit true

   Dim Cool as integer
   
   Cool =Test_Sub_PointerReturns()


   Dim MyPtr as pointer
   
   MyPtr =Test_Sub_PointerReturns()

   print Cool
   print Int(MyPtr)

   Sync
   waitkey
   




Psub Test_Sub_PointerInputs(A as integer pointer)
      print int(a)   

EndPsub


Psub Test_Sub_PointerReturns()

      a=45554
      print int(a)   

EndPsub A as integer pointer

[kevin]

 PlayBASIC V1.64k  Beta 16 - Pointer & Buffer support from PSubs.

    Today's update continues on from the last update.  These changes allow pointers to be passed into Psubs.  Beyond that that support for importing and exports type and array buffers has been added.

PlayBASIC Code: [Select]

   Type Vector2D
         x#,y#
   EndType

   Dim Cool as Vector2D
   
   Cool.x#=11.22
   Cool.y#=22.33
   

   Dim Buffer1(50)
   Dim Buffer2(50)


   print "return array from sub"
      for lp=0 to 1000
         buffer1()=TestArrayReturnFromSub(100)
      next
      

   print "return array from function"
      for lp=0 to 1000
         buffer2()=TestArrayReturnFromFunction(200)
      next
   
   
    TestUDFPassToFunction(cool)
    
    TestUDFPassToSub(cool,9999)
   
   Sync
   waitkey
      



Function TestArrayReturnFromFunction(size as integer)

   Dim MyArray(size)
   Dim lp as integer
   for lp=0 to size
      MyArray(lp)=1000+lp
   next

EndFunction  MyArray()



psub TestArrayReturnFromSub(size as integer)

   Dim MyArray(size)
   Dim lp as integer
   for lp=0 to size
      MyArray(lp)=1000+lp
   next

EndPsub  MyArray()




function TestUDFPassToFunction(this as vector2d)

   print "Passed UDT buffer into function"
   print THis.x
   print THis.x
;
EndFunction

Psub TestUDFPassToSub(this as vector2d,qqqq as integer)

   print "Passed UDT buffer into sub"
   print THis.x
   print THis.x
   print qqqq

EndPsub

 Download BETA

 Get PlayBasic V1.64k Beta 16 (login required)

[kevin]

 PlayBASIC V1.64k  - Debugger Syntax Highlighting Tech Test

     While this is currently not a built in feature,  Here I'm just prototyping a new approach for doing 'Syntax Highlighting', with the hope that it'll make it's way into PB in the not too distant future.  The prototype is actually written in PlayBasic V1.64k beta 16.

     The goal of this test, is to see how fast I can get the parsing and rendering in pure PlayBasic.   The current results are very pleasing,  with the loader being able to process over 5000 lines of source in around 250 milliseconds.    And the render being able  to render basic page of text as between 200->300 FPS, and in some cases even higher.  

     I don't imagine it'll stay this quick as I introduce more features, but this is light years ahead of the previous approach.  Although it's nowhere near as refined atm..  :)


     

[kevin]

PlayBASIC V1.64k  - Debugger Syntax Highlighting Tech Test (continued)

      Worked pretty much through the night and most of the day trying to get the tech demo to a point where it incorporates all the main features found in the IDE without costing the earth.    So this version pays more attention to the formatting and support multi line comment segments, which the original tech didn't.   

     Performance wise it's really no slower than it was,  at yet as least.  Obviously the more aware it is, the more work it has to do at runtime.  And by aware I mean it's knowledge of what the code actially is.    Ideally an IDE version could be aware of the data type of things you type and help you as you enter code.   Much like the current IDE does, but just taking that to a higher lever.   But I digress,  at the moment what i'm looking at first is building a version that could used in the debugger view.   Hopefully with some type of 'hover' support.  So you can see the contents of variables, just by hovered over them... But, lets not get too far ahead of ourselves.   

      Anyway, here's the second piccy of the bare bone tech demo running in PB1.64k.   This time i've doubled the size of the test source to over 10000 lines.. Which as expected doubles the parse time to around 525 milliseconds, but it's still running in the 200->300fps range. (approximately 3 to 5 millisecond refresh)),  which is nothing compared to some of these tools..

[kevin]

 PlayBASIC V1.64k  Beta 17 - Fixes Array Passing Inside With PSUBS.

   It seems that with the updated condensed function compiler in Beta #16 (and prior I think), there's been an omission with the importing array buffers into PSUB's.    But this has been fixed in beta #17.

PlayBASIC Code: [Select]

   Type That
            x,y,z
   EndType

   Dim Dude as That
   Dim DudeArray(0) as That

   Dude.x=666
   DudeArray(0).x=7777

   print dude.x
   Test1(11,Dude())
   Test1(11,DudeArray())

   Dim IntArray(100)
   Dim FloatArray#(100)
   Dim StringArray$(100)
   IntArray(0)=44
   FloatArray#(0)=11.22
   StringArray$(0)="CCOOL"


    TestInteger(a,IntArray())
    TestFlt(a,FloatArray#())
    TestStr(a,StringArray$())

   Sync
   waitkey



Psub Test1(a,This.That)
      print "Exists"
      print This.x
EndPsub



Psub TestInteger(a,This())
      print "Exists"
      print This(0)
EndPsub

Psub TestFlt(a,This#())
      print "Exists"
      print This#(0)
EndPsub

Psub TestStr(a,This$())
      print "Exists"
      print This$(0)
EndPsub

 

    it's good to see this was picking up by all the diligent beta testers out there ..  :)

[kevin]

  PlayBASIC V1.64k  Beta 18 - Tweaks For Geeks

     Starting work on this revision a couple of days back,  the objective is to bring some environmental functions into the user command set.   So ideally you'll be able query the runtime (VM) environment (about your  programs state), which in turns means being able to write routines that are more generic.    This presents a few problems I hadn't bargained for.    From the how these things will appear to the user and the core implementation.   So rather than progressing at a steady pace, work has been revolved around following the instruction set chain down the rabbit hole.   Which has uncovered a few issues that need to be altered in order to progress. 

     Long story short,  so rather than focusing on what i'd intended upon doing, i've been revisiting some of the core instructions trying to wedge in the needed functionality.   This can presents some bigger than expected problems.  Generally if you add more instructions , this often adds more weight to the execution.    It's not as cut and dry and one operation does one thing.  As the general purpose opcodes are used throughout the language. So adding a bit of weight to this hardly used operation (or so you assumed), can end effecting something you didn't really expect.. 

     To counter this i've been trying to reduce the instruction set, but without removing functionality.   This means quickly rethinking the implementation of a number of embedded core operations.  What i've been looking for is effectively ways to remove/short cut some existing opcodes, to make space for needed additions.  Unfortunately, this sounds easy in principal, but getting it working, just isn't going  smoothly.  So far, all i've succeeded in doing in either making it much slower,  or making it die in bizarre ways.     
 
    erm.. what fun...

[kevin]

 PlayBASIC V1.64k  Beta 18 - Tweaks For Geeks (Cont.)

    Had a rather lovely evening of tweaking/removing/rewriting some 5 or 6 year old code fragments.   The good news is that Beta 18 is working again, but i'm not too sure I can fit what I actually need into the instruction set without making some really major changes :( .

   Given we're talking about working  on VM#1 here,  i'm really not too fond of the idea of giving a major overhaul now,  given the VM2 runtime makes it completely obsolete..   While my objective at start of the 1.64K upgrade was to give PB1.64K as much functionality as possible,  but there are limits to how far i'm willing to go with it.. 

   The changes thus far have given Beta 18 a little more bite for you buck though.   A good example of this can be seen when running the Debugger Syntax Highlight prototype in Beta 18, as compared with Beta 17.    Beta 18 can load & parse the 20000 plus lines of source 200 milliseconds faster than beta 17...  Same program, but only difference is the revisited runtime.     

   

[kevin]

 PlayBASIC V1.64k  Beta 18 - CallFunction (Dynamic Function Calling)

     All of the recent work has been edging towards adding more operations that allow greater freedoms in user code.   What CallFunction  does, is it allows you to call  a function in your code by name.   While it's early days as yet (i've only just got a simplified version working in fact)  this functionality will hopefully allow users to write routines that can dynamically call other routines, without the user having to explicitly code it.  

     This type of functionality tends to pop up when we need to write code that's going to be used between many projects,  while still remaining generic.  A good example that comes to mind, would be a GUI library.   Where the GUI could be written to call a particular user defined action(s).   For example, if the GUI detected a button click, the GUI could check if the  button has an associated function (something the designer could to do at design time).  This function be the code that react to this button click.  So the programmer wouldn't have to explicitly add code to react to the button click

      Another situation could be in collision detection.   If each object had a user associated 'destroy function', then the collision code could be simplified into a more generic version.  This would allow the programmer to add more object types and destroy methods, without having to patch them into all the collision routines.     So basically it's going to be used a call back mechanism.  

      Anyway, so far all that's working is calling simple subs without and parameters or returns..   In the example bellow it's calling Psubs,  in the future I hope to be able to support user defined functions/psubs and bound functions.    But first things first...

       This example randomly calls either the functions bellow by name.

PlayBASIC Code: [Select]

   Print "Dynamic Function Calling"
   
   Dim FunctionNames$(1)

   
   FunctionNames$(0)="Test"
   FunctionNames$(1)="ThisOtherTest"


   Do
      Cls 0
         for lp=0 to 10   
            Index=Rnd(1)   
            CallFunction FunctionNames$(Index)
         next
      Sync
   loop
   


Psub Test()
   Print "Callled Test Sub"

EndPsub


Psub ThisOtherTest()

   Print "Called The Other Test Sub"

EndPsub

[kevin]

 PlayBASIC V1.64k  Beta 18 - CallFunction (Dynamic Function Calling) (cont.)

    While it's only a few hours later, but the implementation has progressed a bit further already.   The current version supports user defined functions and Psubs.   Moreover function calls support basic parameter passing.  I suspect that only Integer/Float & strings will work (at this point), but I haven't actually tested anything else.  Arrays certainly won't work, but pointers and individuals types may work.      It doesn't returns though.

    Given the function is called by NAME,  this means function name has to be resolved back to it's internal pointer.    This process was pretty slow in the initial version.  With the following benchmark (bellow) taking some 750 milliseconds to execute 10,000 times.    However, with a bit of a rethink i've been able to trim this back to a much more respectable 22.8 milliseconds for 10,000 calls.  
 
    In the final you'll be able to call functions by name, or by index, which gets rids of the need to search for the function by name.  So that'll be a fair be quicker I'd imagine.

PlayBASIC Code: [Select]

   Print "Dynamic Function Calling"
   
   Dim FunctionNames$(3)

   
   FunctionNames$(0)="Test"
   FunctionNames$(1)="ThisOtherTest"
   FunctionNames$(2)="Test"
   FunctionNames$(3)="ThisOtherTest"

   MaxTests=10000

   Do
      Cls 0
      
         frames++

         t=timer()
            for lp=0 to MaxTests
               CallFunction FunctionNames$(lp &3)
            next
         tt1#+=(timer()-t)
         print tt1#/frames

         CallFunction "Yeah",45
         
      Sync
   loop
   





Psub Test()
;   Print "Callled Test Sub"

EndPsub


Psub ThisOtherTest()

;   Print "Called The Other Test Sub"

EndPsub


Function  Dude()
;   ink $ff0000
;   Print "Called The Other Test Sub"
;   ink $ffffff

EndFunction


Function  Yeah(x)

   ink $ff0000
   print "Running Function"
   Print x
   ink $ffffff
EndFunction

    Quickly tested calling via Function Index..  And it'll execute the equivalent loop in about 3.8 milliseconds.  So clearly, if via index will be the best of the options, If speed is a concern.   CallFunction will always be slower than native function call though.  
 

[kevin]

PlayBASIC V1.64k  Beta 18 - CallFunction (Calling Bound DLLs)

    Still working on getting this feature to work as robustly as possible.   Which means being able to call the all thenative function types, those being Psubs, Functions and bound (via linkDll) functions.

    There's a few big issues that need error trapping, in particular with calling bound (dll) functions.  Namely the issues resolve around there being no way to really screen the CallFunction parameters at compile time.  So this stuff can get lightly sanitized at run time. So if you try and shovel the wrong parameters types into a function call, then there's not too much I can do about it.  So in this case you should expect it die...   There's some type matching but that's about it.

    The other drama is managing whats returned from the various types of function calls.  Which of course all work differently and return data differently also.   Which is further compounded by not actually knowing the return type of the function.   Since this can't be resolve during compliation.. Which is turning out to be a tricky one.   My gut feeling is that it'll only returning Integer/Floats and Strings though, unless something magical happens. 

[kevin]

 PlayBASIC V1.64k  Beta 19 - CallFunction (Dynamic Function Calling)

   As of BETA 19, the call function command works with User defined Functions, User Defined Psubs and Linking DLL's -   However the implementation in this version can only pass basic  parameters (Integers/Floats & Strings), and can not return anything from the called function.      

   Here's a basic example..  

PlayBASIC Code: [Select]

   Print "Dynamic Function Calling"
   
   Dim FunctionNames$(3)

   FunctionNames$(0)="Yeah"
   FunctionNames$(1)="SubYeah"

   

   Do
      Cls 0
      
   
            for lp=0 to 1
               Name$=FunctionNames$(lp)
               CallFunction Name$,Rnd(100),rnd#(200),Name$
            next
         
      Sync
   loop
   




Function  Yeah(x,y#,Name$)
   ink $ff0000
   print "Running Function ["+Name$+"]"
   Print x
   Print y#
   ink $ffffff
EndFunction



Psub  SubYeah(x,y#,Name$)
   ink $00ff00
   print "Running Psub ["+Name$+"]"
   Print x
   Print y#
   ink $ffffff
EndPsub

[kevin]

 PlayBASIC V1.64k  Beta 20 - FunctionExist /FunctionIndex

   These couple of functions are just to round off the CallFunction operation above.  I'd hope hope what they do is pretty self explanatory, but just in case...    FunctionExist allows us to check if a Function Name exists,  FunctionIndex lets us pre-calc the internal index of the function.   The latter is so that you can store the index to the function rather than it's name.  

   Calling by name is fine if you're only calling the function a small amount, but the 'name searching' overhead sure adds up with you call them lot (1000's of times).    So in those situations it'd better to pre-calc the functions index, then call it using the index,rather than it's name..

PlayBASIC Code: [Select]

   print "function Exist"
   print FunctionExist("Yeah")
   print FunctionIndex("Yeah")
        CallFunction FunctionIndex("Yeah"),222,333.44,"This is working"
         

        Sync
        Waitkey


Function  Yeah(x,y#,z$)

   ink $ff0000
   print "Running Function"
   Print x
   Print y#
   Print z$
   ink $ffffff
EndFunction

 

[kevin]

  PlayBASIC V1.64k  Beta 20 - limited Optional Parameter Support For Command Calls

   Optional parameter support is one of those features that's been on the design doc for what seems like years, so it's long overdue.  This feature, allows us to drop from the trailing parameter(s) from certain internal commands calls.  When you drop the parameter, the command uses the 'internal default' for this parameter.  These will be the mostly settings for a command.  

   At this point, it only supports commands and not internal functions.   But obviously that'll come after i've weeded the bumps out.     The main issue with adding it is how the internal parameter matching and moreover how the parameter passing works in vm.   So it's a little messy getting it work and there are a number limitations, but it should be ok for the most part.  

    Bellow is a tiny example of new change.  Spot the difference ?  - it's pretty subtle.. Notice the CLS commands parameter is now optional.   If left out, the command defaults to BLACK (rgb(0,0,0))..   Which reminds a very long winded discussion we had with somebody about what the 'default' colour of Cls should be.   But anyway..

PlayBASIC Code: [Select]

   Do   

      Cls 

      print "Optional CLS "
   
      box 100,100,200,200,true
   
      Sync
   loop

[kevin]

  PlayBASIC V1.64k  Beta 20 - limited Optional Parameter Support For Command Set Function Calls

    Continuing on from where the last post left off,  now we have optional parameter support in both internal commands and internal functions.   So far there's only one function with a optional and that's the MID$() function.     The Length parameter is now optional in this function,  if you leave it out it'll default to a length of 1.

     So it's like the MID() function (they are different !) except MID$(String$,pos) returns a single character as a string.  Where MID(String,pos) returns the single character (it's ASCII value)  as an integer.    So MID() is the  equivalent of asc(mid$(String$,pos,1)) in old school BASIC.  

PlayBASIC Code: [Select]

   Do   

      Cls 

      print "Optional Parameters in Commands"
      
      box 100,100,200,200
   
      circle 400,400,50
      
      

      print "Optional Parameters in Functions"
      a$="Hello"

      for lp=1 to len(a$)
            print mid$(a$,lp)         ; notice the length is missing, it defaults to one now
      next
      
      Sync
   loop

 

 

 Benchmark

  Does dropping an optional parameter wins us some speed ?  -   Well, lets check...  

PlayBASIC Code: [Select]

   MaxTests=10000


   a$="      Hello        "

   Do

         Cls 0
         frames++

         t=timer()
            for lp=0 to MaxTests
               b$=trim$(a$," "+chr$(9))
            next
         tt1#+=(timer()-t)
         print tt1#/frames


         t=timer()
            for lp=0 to MaxTests
               b$=trim$(a$)
            next
         tt2#+=(timer()-t)
         print tt2#/frames

      Sync
   loop

   
    Both loops execute at virtually identical speeds.  So no...  Why ? -  Well,  just because the parameter is optional, this doesn't mean nothings being passed into the function.    While you may not have explicitly sent anything in, behind the scenes the compiler is outputting the code to pass the 'default' parameter for you.  So the operation is the same in the output code.