PlayBASIC V1.65 (Work In Progress) Gallery

Started by kevin, April 03, 2016, 12:01:41 AM

Previous topic - Next topic

kevin

#45
   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

#46
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

#47
   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

#48
 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

#49
 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

#50
  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

#51
   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

#52
 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


  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

#54
 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


  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

#56
 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

#57




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


    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

#59
 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)