PlayBASIC V1.65 (Work In Progress) Gallery

[kevin]

PlayBASIC V1.65C Beta 40 - VROOM VROOM - Start Up Process is working

    Some awesome news today as the initial properties have made there was into the APP format and seems to be working well albe it from the limited testing here this morning.    I've had to keep the way the start up sequence  much the same as the original for the time being, but it will be necessary to move the startup procedure into the platform bindings.   The bindings are just some  pre compiled Playbasic code which  user code is compiled after, which is pretty standard fair in programming languages.  The problem with the current design is that the startup sequence is initializing the screen state and libraries, which makes the startup dependent upon the command sets, so they can't be switched out easily.   Ideally what we need is all the library and screen set up code moved into the bindings,  so it's not attached to the VM.     But that can be done during the next phase I think.

[kevin]

 PlayBASIC V1.65C BETA #41 (Retail Compiler Only Beta) - (Avail for Registered Users ONLY)  (29th July,2018)

     V1.65C Beta #41 includes support for building EXE's - thus it includes the release and debug runtimes in the BIN folder.   So in order to test, you copy the files into your PLayBASIC folder, so that they replace your existing files.   You might not want to break your 'official retail install, so what I generally go is just make a clone of my PlayBASIC folder somewhere and then drop the beta files into it.   This allows me to play without ever worrying about damaging my retail install.  

     Anyway, have fun..


Bug Reporting

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


       
Download

  Download PlayBASIC V1.65C Beta 41 (With runtimes) (login required)  29th,July,2018)


Blog

   

[kevin]

PlayBASIC Blog - PlayBASIC V165C Beta 43 and Debugger Chat  (2018-08-20 )


 

[kevin]

PlayBASIC V165C Beta 44 and Debugger (2018-08-27 )

      Dropped a couple of new features into the old debugger such as some auto generated file names & some limited  Font & colour controls and few optimizations and clean ups,  that's about it for now

[kevin]

 PlayBASIC V1.65C BETA #44 (Retail Compiler Only Beta) - (Avail for Registered Users ONLY)  (9th Sep,2018)

     V1.65C Beta #44 includes support for building EXE's and a bunch of bug fixes and debugger tweaks.   The tweaks include some abilities to change the Fonts  & Colours in some of the debugger dialogs.   apart from that I think the core is basically the same as beta #41.    



     Anyway, have fun..


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



       
Download


     Obsolete, newer builds bellow

[kevin]

 Just a quick note that while testing PBV165 Beta 46 i've found some missing features, namely support for loading dll's form memory, which just leads to a crash in the current builds. Hopefully I'll be able to get this sorted ASAP and get the release out soon..

What fun ! :(



Update: Fixed 8th Oct 2018 .. the resource loader wasn't pulling a pointer to the resource and the order was out of sequence, so the function initialize wasn't returning function pointers

[kevin]

   PlayBASIC V1.65C BETA #47  - Updating the Doc's


    The current build is up and running with the old bigger code bases  such as app's like the Amos2playBASIC conversion tool.  Which works, but there's the odd assumption still left in the code where it's reading types that don't exist, which creates the odd runtime error.  Most on the one's look like this where it's querying an array and then reading from the index beyond the current one without a safety check.

PlayBASIC Code: [Select]

    if Token(Index)  

        ;  Here is where it'd trip runtime if the type beyond the current one which is known to exists, is then attempting read from the structure.. which 
        ; would throw a runtime in V1.65
        if token(Index+1).field
             

        endif
    endif    

      So in your code you should expect 1.65 to bark at you if you have code like this..    

      Beyond that I've been starting to update the doc's in order to build it all up into a release build for you.  


   

[kevin]

PlayBASIC V1.65C _Retail Upgrade_ Now Available (21st, Oct, 2018)

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

   The V1.65C includes third major release of the next generation of the PlayBASIC virtual machine.  In this build 100% of the commands now executed on the new VM side, giving much higher execution performance than V1.64 and previous legacy builds.   The main objective of V1.65C revision was to catch the last remaining problems or missing functionality from the previous V1.65 releases, which I thing we've about covered now.    There's still some features missing from the V1.64 era of the runtime that are not in v1.65c such as sequential type access optimizations, but that will reappear in the later build.        


   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.65C development story read the PlayBASIC V1.65 blogs here and for V1.65 related errors, post them in the V1.65 bug reporting thread (login required).  


Blogs

      none



Downloads

  Download Download PlayBASIC V1.65C Retail Upgrade (login required)  (21st,Oct,2018)  

[kevin]

  PlayBASIC V1.65C2 BETA (2019-03-16)  - CallDLL crashes

   Been chasing my tail this past week looking for the reason behind some strange crashes in one of the compo games.   Like most these issues you assume it'd be easy to find the smoking gun, which in this case is some CallDLL's in the code to some external library.  These should work as the back end code is the same as previous builds of PB, so the new fault must be in the new VM wrapper or possibly the expression is being optimized when it shouldn't be.   Dunno at this point..  it's annoying to run into a fault when I wanted to get it on the server.   If the issue does appear soon that's what i'll probably do as it includes a number of other fixes.


  The only other known problem that was found, appears in the VB6 to Flexi demo which has a mysterious deletion of one of the structures at runtime.   Finding that one might take some real debugging, as those types of problems tend to be found in tiny changes that are generally hidden in smaller problems,  as that's one of the longer PB programs.  

[kevin]

  PlayBASIC V1.65C2 BETA (2019-03-21)  - CallDLL crashes follow up

       Been looking at the JetPAK source for most of the week ( when time permits) as it uses a 3rd party Joystick dll that is crashing.   The project seems to work in old versions of PB, so therefore it must be a problem with modern PB runtimes right ??  nope..  trawling through the code and there's no obvious issues at all , apart from those commands not returning runtime errors.   So hmmm... strange

       Last night i changed tact and started to look into the DLL itself,  unfortunately it's really old and doesn't seem to be available anymore.   so the only code I've got on the dev box is JetPAK, so you'd think that code would be correct right ... hmmm .. more testing  on it's own and erm.. maybe not..    Fired up the disassembler to take a look at some of the function headers in the joystick DLL,  as  I was starting to wonder what parameters these functions take and that's one way you can work what the code is expecting to be passed upon call.    This is where it gets strange as it appears   the DLL functions are exported as cdecl  but the jetpak code us using stdcall to call the functions.    That seems like a crash waiting to happen, as they have different responsibility to clean up the stack.   

      So what happens if you set the joystick DLL to use  cdecl calling covention ???   well it works as normal.        So we're been chasing our tails looking for something that used to broken in old versions of PB as it would seem they befault to using cdecl rather than stdcall..    Which is why it works in old versions.


      Moving on and while looking at that library at least I can hook up the errors to the runtime.    Ideally i'll be able to get that done tonight and get a build out the next day or day after..   



     

[kevin]

 PlayBASIC V1.65C2 BETA #12 (Retail Compiler Only Beta) - (Avail for Registered Users ONLY)  (23rd March,2019)

      V1.65C2 Beta #12 is the current build of the compiler and runtimes.   Includes CallDLL fixes and some DATA fixes.



Bug Reporting

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


         
Download


   Download PlayBASIC V1.65C2 Beta12 (login required)  17th,Dec,2018)

[kevin]

PlayBASIC V1.65C2 BETA #14 (Retail Compiler Only Beta) - (Avail for Registered Users ONLY)  (5th March,2020)

      V1.65C2 Beta #14 is the current build of the compiler and runtimes.   Mostly small bug and tweak fixes as far as i can tell


      Anyway, have fun..


Bug Reporting

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


         
Download


   Download PlayBASIC V1.65C2 Beta14 (login required)  5th,March,2020)

[kevin]

PlayBASIC Live -  Finding RunTime Bug in 165C2 (16th June 2020)

While developing a simple video animation tool to do privacy masking / blurring I ran into a weird runtime bug in PlayBASIC V1.65C2 and decided to make a video about it...

  Did we find the bug ??  (Spoiler yes, but it wasn't what i expected.. never is )



Video:

Credits:


      Video By:
   Kevin Picone
   http://PlayBASIC.com 
   https://underwaredesign.com


   Video Cast:
   Sox and Sophie
   Ava and Kevin Picone
 

   Music:
  Spirit of Fire by  Jesse Gallagher



PlayBASIC LIVE PLAYLIST
https://www.youtube.com/playlist?list=PL_dvm0gvzzIVGlAhx34N6z2ce0ffMMOZ8

PlayBASIC BLOG PLAYLIST
https://www.youtube.com/playlist?list=PL_dvm0gvzzIU0Hnr6veV5UvwkSapHCo1J

PlayBASIC on FACEBOOK
http://www.facebook.com/pages/PlayBasic/127905400584274   (Facebook Page)

PlayBASIC on TWITTER
https://twitter.com/PlayBasic


#playbasic #debugging #sourcecode

[kevin]

 PlayBASIC V1.65C2 - Beta 15 -  expanding IF expression support to include strings / arrays


        I've ran into a few runtime stopping issues this last week, starting some missing error trapping or execution support in CMPBNE instructions of the runtime.   The CMP Branch not equal opcodes and the byte code behind such user statements as IF statements.  Somewhere around the 1.65 rebuild the compiler parsing and byte code generation trimmed out some of screening logic that would trap the acceptable input parameters for the opcode.   Hence there's nothing to trap expressions like IF A$ Then , even though that might be a valid thing to do...  


        So i've build in support for strings in IF expressions.  This acts as way to detect if the string is empty.   Internally what happens is the parser inserts a LEN() operation  then compares if the length is none zero.

       

PlayBASIC Code: [Select]

    gosub State

    a$=""
    gosub State

   a$+="A"
    gosub State

     sync
     waitkey
    end

State:
      if a$ 
              print "a$ is Defined"
      else
              print "a$ is UNDefined (EMPTY/NULL STRING)"
      endif
      return

         Might extend this to ARRAY HANDLES, so you could do something like  IF Array() then Do stuff.  This would wrap the handle with GetArrayStatus() call, but it's a little cleaner the programmer.   

[kevin]

   PlayBASIC V1.65C2 - Beta 15 -  IF Array() supported and the NEW operator can create types from Indexs again


   Just like the recent String support added to the IF expression which boils down to a compare not equal instruction in the runtime, this has been expanded to support Array handles (ie.   If Array() then Do something)   So you can check if an array has been allocated (Dimmed) just but going IF Array(), rather than typing IF GetarrayStatus(Array())  

   Now be aware that what actually happens is the compiler inserts the GetArrayStatus() function call around an Array() handles it sees.   So it's a shortcut in typing only, performance wise it's the same speed as the long hand expression.  

   
   NEW

    There was a bug uncovered in the code generation of the NEW operator.    NEW allocates structure of TYPE, where you tell it the NAME of the TYPE.    ie.  NEW Alien.     What of course happens is that Name is really an index into  the type definition structure in the runtime.     But what I suspect nobody knew is that you can use an Integer with NEW also, and it'll just assume that value of that integer is a valid Index into the internal definition table.   But if you did that in V165 it'd break as the code generation was missed support for it.   So that would parse but wpuld break at runtime.

PlayBASIC Code: [Select]

    Type tPrivacyKeyFrames
           frame
           X#
           y#
           Size#   
           Image
      EndType
     

      Dim Mask(1000) as tPrivacyKeyFrames


      // allocate a type of tPrivacyKeyFrames and write it's handle into index 1 of within the MASK array
         Mask(1)                = new tPrivacyKeyFrames


      //  Now let's do the same thing, from a variable

      // Get the INDEX of a TYPE name

         Index  = tPrivacyKeyFrames + 0  ; (NOTE THE ADDITION)

         Mask(2)                = new INDEX

      sync
      waitkey
      waitnokey

    The original concept of allowing users to select the type from an index was only via an addition with the TYPE NAME.   So you could select the child types of a parent type as they'd be sequentially stored in the type definition table, without worrying about makes mistakes with the indexes (Think about it ).     A by product of allow this means you that providing  you can complete the index of the TYPE NAME you want, you can use a variable for the type.   You have to careful not to rearrange yur definitions though, but I you could compute them up front and store them in an array. and just pull the actually value  from the array.   


    Thinking back on it now, it probably should have been wrapped into the INT()  function. That is to say that INT() could compute the integer value of the type name and thus be used anywhere within reason.    I'm sure we'd find a way to exploit it and create unwanted situations tho..   but isn't that fun ?