News:

PlayBASIC2DLL V0.99 Revision I Commercial Edition released! - Convert PlayBASIC programs to super fast Machine Code. 

Main Menu

PlayBASIC V1.65 (Work In Progress) Gallery

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

Previous topic - Next topic

kevin

#60
  PlayBASIC V1.65 Beta 4 - RndRange() being skewed by caller


 Found an interesting difference between PlayBASIC V1.65 and PlayBASIC V1.64 last night with the RndRANGE() (integer version) being rounded slightly in the 1.65 runtimes..

 This one was only detected while looking through the JetPAK sources from Ian Price.  Some of the controller code in that demo used  an expression like this  Y=Y+RndRange(-1,1)*2  so those characters wouldn't move randomly UP / DOWN in PB1.65, only up,  as a result of 1 wasn't seem possible..  Seems to be fixed now in PB1.65 Beta4  so í'll throw that up on the server over the weekend.  

  Another change has been  made to legacy expression solver, NOT operations are now solved after AND/OR/XOR again..

kevin


PlayBASIC V1.65C BETA #4 (Retail Compiler Only Beta) - (Avail for Registered Users ONLY)  (6th Sep,2017)

      V1.65C Beta #4 continues with the V1.65 clean up.   While working through some old examples I noticed that JetPAK (after fixing it) ran different in V1.65 than older PB versions.    The main issues were the optimizer was breaking some expressions that contain NOT and there was some rounding sneaking into the integer version of RNDRANGE() function call

.     In JetPAK the game uses an expression such as Y = Y + RndRange(-1,1) * Speed to move some characters up / down randomly, when running the game in V1.65 they only would move up, where as in V1.64 they behave normally.  Took a bit of detective work, but we ended up having to wrap a separate version of RndRange in order for it behave like the older versions of PB..   Another issue that work differently in older versions of PB then  1.65 was the player collisions and gravity in the game.  There was an issue with the NOT opcode read/writing the incorrect variable/register as well the PB byte code optimizer could break those expressions by modifying the output expression incorrectly.   

      The only functionality change in this build is the precedence of NOT has been restored to being lower than the AND/OR/XOR operations.  So the NOT will occur at the end of the expression.   Which is how it used to work, but it seems to have changed at some point...


      Anyway, the byte code optimizer should now tweak these kind of expressions into the simpler forms that function  the same..

PlayBASIC Code: [Select]
      result= not  A=B

if not A=B

endif


if not A<>B

endif

if A=B

endif

if A<>b

endif









Bug Reporting


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


         

Download



   Download PlayBASIC V1.65C Beta4 (login required)  6th,Sep,2017)



kevin


  PlayBASIC V1.65 Beta 6 - Command Caller

    So last night I've finally managed to weed out the last dark corners of the legacy command callers from the new VM.   This means that all of the command set can now be considered external.  The problem I was having is that internal commands have some wacky parameter matching in them, which allowed for a bit less table data back in the day and pushed some of the work onto the VM, so those  commands have logic inside them to handle the different input types.  Some still do,  in particular commands that are considered part of the VM.  Arrays would be able of that.   

    For example, the classic PRINT statement, was defined as accepting Integer/Floats and String as parameter, then the VM caller would work out what to do when calling the print  oncode in the VM.  This is cool can all but in the new vm, were calling a function with a single pattern, so any differences need to be either be converted prior and our during the call, ideally without adding any overhead to the call.   What I ended up doing is the latter, is coming with a way of defining stuff that is simple to how it works already (coz i'm lazy) that can handle conversion of terms if need be.   So it should make the end functionality of the same how it already works,  but the caller operation is much leaner and meaner,  giving us faster execution.

   I know this all sounds like none -sense but splitting the VM some the command sets and having a generic caller means the VM doesn't need to be updated to add new commands and more importantly, we can change command sets....  Still have to sure up the caller and opcode generation stuff (it's just hacked in to get it working) then we can convert the command set tables.  Which I think I can write a parser to convert most if not all of them..  But for now I'll keep the test to a hand full of left over commands





kevin

#63
   PlayBASIC V1.65 Beta 7 - FastDot benchmark hits 60fps

     Yep, last nights build of PB1.65C pushed the FastDot bench from a new high of 22/23fps up to 60fps on Athlon test system.... (800*600 PIXELS IN 32BIT)

         :)      :)      :)      :)



   EDIT:
   




kevin


  PlayBASIC V1.65 Beta 14 - Kissing Vm2 Goodbye

       Early this morning PB sprang back to life after being dead for the best of last week,  as outlined in the last video blog, I moved directly pass the function caller updates onto separating VM3/4 from legacy VM2.  Cutting the umbilical chord and making it sink or swim on it's own, of course initially it sunk :)  -  However after some pretty boring detective work, I've been able to track down why an where the crashes appear.  Some obvious and some not so...  So it's been sort of sorta of running for days, but wouldn't run anything big, now after this morning repairs it's actually starting to run bigger stuff again..  Still unstable, but working !!

   



kevin


  PlayBASIC V1.65 Beta 15 - Hooking the debugger

     So some good news today as work ticks along with the transition to the VM3 focusing on the debugger hooks, which has meant rewriting and patching the old debugger and new runtime together,  as of today we're down to two instructions left to fix, which relate to step and trace.    Once those are in place it should be all working, of course with whatever quirks...

kevin

 PlayBASIC V1.65C BETA #20 (Retail Compiler Only Beta) - (Avail for Registered Users ONLY)  (29th Dec,2017)

     V1.65C Beta #20 virtually concludes the V1.65 clean up.  In this build we are running on the new VM only.   Which means all new instruction set and all new inner workings of PlayBASIC...  In this last build we're reconnected the Vm with the legayc debugger,  which was previously rigidly hooked to the legacy VM making it break in later builds.   In this version is almost back to normal, I say almost as the old interfaces are still there and there many be some routines still using them, but I'll tackle  that in the clean up when building a release version in the new year.

     The new runtime brings us more number crunching performance, standard instruction set and is now separate from most of the command sets (some are built into the VM.. like strings or array commands)  the generally command sets could be swapped without needing to constantly update the runtime.   There's some features of V1.64P that are NOT in the new VM, which are mainly some of the compiler optimizations that it would make to user byte code, one that comes to mind is the serialization of the Type / Structure accesses..  Which can give a massive performance benefit in code that focuses it's accessed on one structure of data..  I'm going to include this in V1.65, but wanted to get it working first.. then we can add some of my list of tricks :)


     Anyway, have fun.. there's bound to be some DEBUG  messages etc in this.. but it's the future !



Bug Reporting


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


       

Download



Take me to  Download PlayBASIC V1.65C Beta20 (login required)  29th,Dec,2017)



kevin


  PlayBASIC V1.65C BETA #21

     So a few issues have been found and release 20 so putting together a beta 21 (well build 21) , this one fixes  SetFPS, strips from double reading from text drawing , fixes CopyRect and it's brothers (the command table was short :) ) and has some tweaks in it for the the release build..   All of which isn't on this system anymore, whcih means dragging it over from the devlopment box to put it online, which is always pretty tedious.

     I did notice there's one command that's become homeless and that's one of the Mesh commands using in the old 2D in 3D demos as well as various terrain demos in the example packs...    I think I might put together a mesh library,  or at least make provision for one in the command sets.   

     Anyway, we'll try and get it together tonight..     


kevin

#68
 PlayBASIC V1.65C BETA #22 (Retail Compiler Only Beta) - (Avail for Registered Users ONLY)  (17th Jan,2018)

     V1.65C Beta #22 addresses various missing or broken issues with beta 20,  things like the SetFPS command was broken, because SYNC is now actually a command and not a VM process,  Text drawing had some extra String processing it in and some commands we're defined in the table and would crash at runtime, such as CopyRECT for example.

     Anyway, have fun.. there's bound to be some DEBUG  messages etc in this.. but it's the future !


       

Download


   Take me to  Download PlayBASIC V1.65C Beta22 (login required)  (17th,Jan,2018)





kevin

#69
   PlayBASIC V1.65C BETA #24  - Mesh Command Set

       The last couple of very short coding sessions have been to find homes for a couple of commands that had become orphaned through out the 1.65C process.  Thankfully these tent to be the legacy 'test' commands used in the some of the more obscure demos  and even some that are in the demo packs even like the, like the 2D in 3D platformer and Terrain demos.

       Here's a link to the 2D platformer in 3D blog/ thread from back in 2006..
       
     



kevin

#70
 PlayBASIC V1.65C BETA #24 (Retail Compiler Only Beta) - (Avail for Registered Users ONLY)  (7th Feb,2018)

     V1.65C Beta #24 includes some obscure commands that were missing from the previous builds, fixed an issues with constant declared within functions/psubs and includes a few clean ups in the low level mesh command commands.  

     That constant declaration bug was stopping a few old demos from working as they constant strings declared inside functions, at first this wasn't even on my radar thinking the problem was with the TranslateMeshToScene command, which was a test command from about 10 years ago.. But once they're in you can't really just remove them, well you prolly could but some of the funkier old demos use them..    Like the Terrain demo in the example pack.    None the less, i spent more than few nights thinking that was faulty command, but of course what i should have been doing was putting in some break points and checking if the data passed into the command was good to begin with, it wasn't !


    The problem turned out to be in a function that created a cube. The function used a string which I was then parsing out for the faces, a bit like bellow..

PlayBASIC Code: [Select]
Function NewCube(Size)

constant FaceList$="|1,2,3,4|1,2,3,4... blah"

For lp =0 to 5
Vertex1= mid(FaceList$,POs)-asc("0")
Vertex2= mid(FaceList$,POs+2)-asc("0")
Vertex3= mid(FaceList$,POs+4)-asc("0")
Vertex3= mid(FaceList$,POs+6)-asc("0")

SetFace(Vertex1,Vertex2,Vertex3,Vertex4)
Pos+=8
next


EndFunction ObjectIndex





      The code was generated correctly, but the scope initial which is executed for each new scope when it's called was killing the FaceLIst$ constant thinking it was a string variable...  

      I should point, While declaring constants inside function works, they are defined GLOBALLY BTW...  yeah.. yeah It's already on the TO DO list :)


     Anyway, have fun..



Bug Reporting


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


       

Download


  Download PlayBASIC V1.65C Beta24 (login required)  7th,Feb,2018)


kevin


PlayBASIC V1.65C BETA #28 (Retail Compiler Only Beta) - (Avail for Registered Users ONLY)  (4th Mar,2018)

      V1.65C Beta #28 includes support for FASTCALC expression stacks as well as a including a few compiler/parser level optimizations.  The parser can detect and upgrade Sin/Cos(Angle)*Radius and upgrade it to Sin/CosRadius(Angle,Radius)  as well as detecting a void usage of INT when occurring in an IF block.     


      Anyway, have fun..


     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



   Download PlayBASIC V1.65C Beta28 (login required)  4th,Mar,2018)





kevin

#72
  PlayBASIC V1.65C BETA #34  - Rescue Me from the land of legacy code

   After a bit of coding hiatus i've been sticking nose under the hood of the latest 165 builds with the thought of issues it as another 'as is ' retail build.  So set up the runtime builder, but quickly ran into a bunch of issues with the generated code, namely like it doesn't work/build..   So that's annoying as I distinctly remember doing that ...  obviously didn't :)  

   Since we're running the new VM with it's own program format,  then it stands to reason it needs it's own support code for not only generation but startup the runtime, which I had wanted to hold off until a D revision of V1.65..  So I can get the boring stuff done and let you have something new to play with, but I don't think that's going to happen, might be forced into doing all this crap now..  Even then, we'll still another revision that deals with the command sets as it turns out there's about a 1000 commands parameter patterns that need to redefined, but that i should be able to most of that via code.  

   The internal command defines isn't at all important for users, this actually all about passing generated code through to 3rd part conversion tools.  Since the tool need to be able to work out what  command / function the code is calling.  It works in old programs like pb2DLL because that tool contains a version of the instruction set that V1.64 uses and assumes it knows that commands from the fixed offsets.  I could do that again, but then it doesn't detached the exported code from the compiler, in other words the conversion tool needs to know what compiler / version it was created with, which is exactly what I don't want...  The solution will be ugly, but should work fine.  A command set is defined by name and then functions/command names are offsets into that name set buy search out the parent, which is kind of how DLL's actually work..

   Anyway, better go get something done.




kevin

#73
PlayBASIC V1.65C BETA #36  - Reloc and DLL binding is a go

   Just wanted to say that I've finally overcome the crashing at startup problem  found in the most recent beta ( mentioned in the latest blog (login required)),  which turned out to be just sloppy pointer handling, where the base structure pointer wasn't looking at the Reloc / DLL Binding chunks in the APP at all, but it was offset..   Which is annoying as I must have checked that code about 50 times for such an issue without noticing it.   Turned out the brackets around the compute expression where wrong.. LOVELY...



kevin

#74
PlayBASIC V1.65C Beta 39 - It LIVES

Just wanted to say that this morning the new build process finally sprang to life, after a number of trouble shooting sessions. This means that the current build includes the ironed out new APP format (localized) and it's new startup sequence. Long story short, this mean the runtime can be built into the release and debug editions and thus exe's can be  built, but they work.

There's still some missing things from the APP format such as a replacement of the initial properties, which were a binary hunk in the original byte code, but could be replaced with either a text version or default startup function appended to the user code. Something like the latter will need to done at some point, but I'm in no rush with that.

Now what ? Well, it means we head into a clean up phase in order to build a release build from the V1.65C code bases, stuff like cleaning out legacy code & debug code from the runtimes. It'll need some testing in the wild that's for sure and there's some compiler features that are not present in v1.65 at all, but it's working and that's all I care about today...Tomorrow is another day!

Have fun !