PlayBASIC V1.64O (Work In Progress) Gallery

[monkeybot]

that sounds handy.i hope to actually get round to using it soon.

[kevin]

PlayBASIC V1.64O  Beta 5- Resource Manager

       Since DLL binding is working in the test, but there needs to be a system where the compiler/runtimes can attach/fetch linkdll resources as need be.  To do this, I've got to build a resource manager with searching facilities into the core.    Like most things, this turns out to be a little more work than i'd like, but the current incarnation seems to run pretty well (given limited testing).    Each resource has it's own name (string), rather than hard pointer, allowing high level services to query the resource buffer for media by name, before continuing on an loading the thing off disc if it's not present.    So in theory, pretty much anything could be attached and bundled in the same manner.

       Managing the resources at runtime is one part of the problem, but the resource buffers also need to be included the byte code hunk.  This is the point i'm at this afternoon, tentatively trying to solve some of the logic problems.   But i think we'll get there in some way, shape or form, even if the first solution isn't as clean as I'd like.       

[kevin]

   PlayBASIC V1.64O  Beta 5- Dll Resource Binding is a Go

         To paraphrase Murphy's law, anything that can go wrong, will go wrong..  and generally all at once.  So yesterday, we had some dramas with the server,  right while I was 1/2 way through sticking all the binding stuff together.    But eventually all the little dramas have been resolved.  

         Today's (well last nights) build of Beta 5, has binding up and running.  Allowing 3rd party dll's to be packed into EXE modules, and loaded/ initialized from  memory during compile and execution time also.     To do this, the programmer simply adds an asterix character to the start of the LInkDLL declaration and PB does the rest.  

        ie

PlayBASIC Code: [Select]

  ;  PlayBASIC expects to load this DLL from disc.  
linkdll "Test.dll"
 
    Myfunction() alias "NameInDll" 
endlinkdll

    ; This tells PlayBASIC to import this dll as a resource
linkdll "*Test.dll"
    Myfunction() alias "NameInDll" 

endlinkdll

     The only thing that I can see that's left to do, is try and drop some error messages in place of some of the little debug messages that can occur when somethings wrong.   Namely if the DLL you try and bind can't be found.  



  PlayBASIC V1.64O  Beta 5- Download

  Download   Removed, newer builds bellow



     

[kevin]

   More Testers Required !

    Just a reminder  that  we need more people upgrading to run the beta builds.  Currently only one person has bothered to download Beta 5 ( thanks for that), but really it defeats the purpose of having pubic beta testing.

[kevin]

   PlayBASIC V1.64O  Beta 6 - Replace$ Issue ?

        Everything has pretty much ground to a halt at the moment, as while testing the Amos To PlayBASIC conversion tool,  seem to be have uncovered a situation where Replace$ can fail.  At least that's what it seems like on the surface.  I'm more than a bit tentative pinning the blame on it as yet, after all, this is not my first rodeo and yesterday  I'd traced the same issue back to the split to array function.  These kind of issues are hard to track down and  I'm tentative because the functions might turn out to be ok, but the strings it's passing in could be damaged.   Which would definitely hang it, as the string engine assumes the VM always gives it are legal strings..   Either way something is looking fishy somewhere. 

        Another possible cause might be from man handling the arrays, the parser builds a tokenized view of the converted source code in nested types.  Where there's the program parent type, which in turn allocates it's own line buffer, where each line is a typed array.   Which not only means you can have as many programs in memory as need (I only actually need one),  but each line of code is a separate 1D typed array.  This removes the impact of moving lines and code fragments around.   Now when the convert routines parses the tokenize code, the routine skim through looking for the Tagged Tokens. if there's a match if runs the reaction function to the token.

         When changes need to be made to a line of code, it peeks into the array directly.    This allows the program to move stuff without every really knowing what it's moving and without having to copy the string fragments directly.   The thing is, when you start peeking and poke into an arrays memory, there's no "i think that'll work", it has to work correctly.  Otherwise you run the risk of either leaking the string/type resource your moving, or your function corrupts the array data in some way.   A leak would just have some information that was there, vanish so easy to track down (in most cases), but corruption can be bit more difficult.    If types were being leaked, then we've see parts of the output code would vanish from final code, but it's unlikely to cause some other function down the line to die.  Provided the bad routine that leaked that data, didn't insert a none existent thing into the line array.  If this occurs now we've a lottery, as the bad data might actually make sense in some causes,  but make it blow up in unexpected ways in others. 

         Anyway, while on the hunt have a found a few tidbits that were worth tweaking, but no smoking gun as yet.. well see.. 

[kevin]

   PlayBASIC V1.64O  Beta 6- Download

    Seem to have tracked the issue with replace$ down to the common string fragment searcher used in Replace/SplitToArray and possible other commands.  The problem was the matching could overflow the it's local stack,  Leading to all types of fun and games..    


  Download   removed, newer builds follow.

[kevin]

  PlayBASIC V1.64O  Beta 7 - Boot Issues Resource Binding

    While the resource binding stuff was added a few revisions ago now, but it's not really been tested in the wild.  So wasn't that surprised to find some dependance dramas with attached dll's, in fact was expecting it.   The issued turned out to be the order in which the hunks are loaded.   If the function declarations are loaded before any bound Dlll they depend upon, then the address resolution will fail.. So the VM will exit when it runs into any function with a null address in user code.    Another issue could occur if default command bindings and the user bindings both had  resource hunks.  

    Been testing today's build Beta 7  with Amos-To-PlayBASIC and found another compiler dependency in the boot process on my 64bit Win7 system.   Turned out to be an easy fix, runs as normal now.   Not sure when that started but suspect the V1.64N revisions would have similar dramas in them but  haven't tested them.  No point now anyway.



 

[kevin]

 PlayBASIC V1.64O  Beta 9 - Tweaks & Things

        Been picking through the map level collision functions looking for an issue with RectHitLevel, initially seemed the query function was pulling the wrong 'spans' from level data, but after some head scratching it turns out the routine pop's a true on any block that has been classified as solid, regardless of if they overlap or not, as they may not.    Can't be sure, but are willing to bet there's some similar assumptions with other methods also.    Wouldn't mind updating the Mapping stuff again actually, not a huge fan of 'pixel level operations', as masks would be better.   Just not sure i can be bothered though.
 
       
       Edit:  Found another query problem with SpriteHitLevel when the sprites collision mode was set to mode 0.    

[kevin]

  PlayBASIC V1.64O  Beta 9b - Adding Errors

      By now you should realize that entire arrays can be passed around like candy, which allows us to do pretty wacky things.  However when we start doing this, the onus is largely put upon our shoulders, us that what we're writing into an Array, is actually a legal array, as it might not be.

      Ie.

PlayBASIC Code: [Select]

    Dim Stuff(100)

    ; assign Stuff() array to some none existent array
     Stuff() = 2000

     While PB would already precheck that the incoming value (on the right hand of the assignment) was actually an array container for us,  it would also ignore writes that weren't legal.   Making it harder to track down where the data corruption might be coming from.
 

PlayBASIC Code: [Select]

   Limbs=10

   Dim Tree(Limbs)
   MakeArray Branch()
   
   ; create an array to place them in the tree() array.
   ; so each cell is now conpetually a 1D array
   For lp =0 to Limbs
      
      ; The MakeBranchfunction exports the 'bank/container' of the array
      ; as an integer.  We can assign then anywhere.  There's nothing special
      ; about them.  
      
      
      Tree(lp)=MakeBranch(rndrange(5,20))   
   next

   ; Display the tree
   
   for lp=0 to limbs
      if Tree(lp)
   
         ; Copy the Branch array container into our redirection/pointer array
         ; so we now use the redirection arrays to look at the array data
         ; When PB writes the right handy value into Branch() array it check
         ; if this value does represent a legal array.  if it doesn't it'll error
         Branch()=Tree(lp)

         ; Parse the values into a string      
         Row$="Branch["+digits$(lp,2)+"] = "
         For b=0 to getarrayelements(branch())
            row$+=str$(Branch(b))+","            
         next
         
         ; print it out
         print trimright$(row$,",")
               
      
      endif
   
   next
   

   
   Sync
   waitkey



Function MakeBranch(Size)
   Dim ThisBranch(size)   
   For lp =0 to size
         ThisBranch(lp)=rnd(1000)
   next
EndFunction ThisBranch()

       

[kevin]

 PlayBASIC V1.64O  Beta 9b - Download

  removed, newer beta downloads follow.

[kevin]

  PlayBASIC V1.64O  Beta 9c - CRF tweaks

    Been looking into the CRF libraries the last few sessions.  The tweaks started out looking at the loading process, but have progressed to cleaning up the communication protocol between libraries and the legacy VM, plus a few more optimizations.  The clean up is a compromise really between the new and the old, but it removes some of the annoying set up work when sharing common resources between the VM with other libraries.   But I'll get more into that in some future blog.

    CRF formatted fonts have a couple of different flavors, namely 2, 8 or 32 bit.   Font's created using the interval commands will be 32bit if your converting a bitmap font,or mostly likely 8bit it's it's a GDI conversion.   While picking through some of the routines you can see's these a bit of generic meat on the bones so have trimmed a health slab of that fat out of some render combinations.    The one that's showing the biggest benefit would be the 8bit mode when blending to colour.   The previous edition seemed to be performing the blend every time a span was drawn.   Depending upon the situation, this is generally unnecessary, so can be pre computed.

    The result of the changes gives about 20-30% higher through put, which is more than handy.

PlayBASIC Code: [Select]

   size=48
   LoadFont "Verdana",2,size,0,8

   FontBlendColour 2,$00ff00

   ; Set output to pre blend pixels with FontBlendColour
   fontdrawmode 2,2

Do
      cls 255

      frames++
      startinterval(0)
      Page_Of_Text(2,$ffff0000)
      tt#+=Endinterval(0)
      
      print tt#/frames
   
   
      Sync
   loop   



Function Page_Of_Text(ThisFont,C)

   oldrgb=getink()
   OldFont =GetCurrentFont()
   SetFont ThisFont

   ink c
   
   For lp=asc("a") to asc("z")
      s$+=chr$(lp)
   next
   s$+=s$   ;+s$+s$

   lockbuffer
   For ylp=0 to GetScreenHeight() step 10
      text xpos,ylp,s$
   next
   unlockbuffer

   SetFont OldFont
   ink OldRgb
   
EndFunction

      Testing blend with colour in different depth surfaces

PlayBASIC Code: [Select]

   size=48
   LoadFont "Verdana",2,size,0,8

   FontBlendColour 2,$00ff00
   
   Screen=1   
   CreateFXimageEx Screen,800,600,32

   ; Set output to pre blend pixels with FontBlendColour
   fontdrawmode 2,2

   ; ------------------------------------------------------------------
   Do
   ; ------------------------------------------------------------------
         rendertoimage Screen
         cls 255

         frames++

         startinterval(0)
            Page_Of_Text(2,$ffff0000)
         tt#+=Endinterval(0)
      
         rendertoscreen
         drawimage Screen,0,0,false
         setcursor 0,0
         print tt#/frames
         print GetImageDepth(Screen)
   
         Sync
   loop   



Function Page_Of_Text(ThisFont,C)

   oldrgb=getink()
   OldFont =GetCurrentFont()
   SetFont ThisFont

   ink c
   
   For lp=asc("a") to asc("z")
      s$+=chr$(lp)
   next
   s$+=s$   ;+s$+s$

   lockbuffer
   For ylp=0 to GetScreenHeight() step 10
      text xpos,ylp,s$
   next
   unlockbuffer

   SetFont OldFont
   ink OldRgb
   
EndFunction

[kevin]

  PlayBASIC V1.64O  Beta 11 - Loading CRF's directly from memory

        While looking through the CRF library I've added a way to load the font from memory rather than disc.   The following snippet loads a GDI font and saves it out into CRF format.  The program then  loads this file into a memory bank, then loads the font from the memory bank using the amended loadFont command.   Allowing font data to be stored in pack files, encrypted, crunched etc.     Ideally what i'd like to do, is implement some method where 'media' in general can be compiled into the exe's resource bindings.  Which is only partially possible legacy PB editions.  

PlayBASIC Code: [Select]

   Filename$="D:\TestCrf.crf"

   // Load a true type and convert it to CRF
   LoadFont  "verdana",20,75,0,8
   SaveFont Filename$,20
   deletefont 20
   
   
   // Load the file into a bank
   fh=ReadNewFile(filename$)
      size=filesize(filename$)
      Thisbank=NewBank(size)
      ptr=GetBankptr(thisBank)
      ReadMemory fh,Ptr,Size
   closefile fh
   

   // Load the front from memory.   Here instead of passing the load command
   // the filename with path, we give it the address of the resource in memory
   // in string form.  
   LoadFont "&"+str$(ptr),30,0   


   // This bank is no longer of any use, so delete it
   DeleteBank ThisBank
   
   
   // set and draw some text with the font loaded from memory
   setfont 30
   Print "Hello World"
   
   Sync
   waitkey

 

[kevin]

  PlayBASIC V1.64O  Beta 11b - Loading PNG images directly from memory

      So in keeping with yesterdays updating of the CRF loader, here we have a variation of the PNG loader.  Just like the CRF stuff we pass the LoadImage (or any of it's variants) the address as a string with the & prefix.    The only difference is that this time, the buffered image data needs a 4 header with the size of the image data in it.   I'm not too keen on it, but it seems unavoidable.

      Today's built only supports PNG's, since that loader was just fetching the data into memory to begin with, the other formats are a little more 'attached' to the disc interface.

PlayBASIC Code: [Select]

   Filename$="D:\PlayBAsicSig2.png"
   
   // Load the image file into a bank.  The picture data needs the size (of the image) 
   // appended to the header of the structure for this work.   
   fh=ReadNewFile(filename$)
      size=filesize(filename$)
      Thisbank=NewBank(size+4)
      ptr=GetBankptr(thisBank)
   
      ; poke the size into the first 4 bytes
      pokebankint ThisBank,0,size

      ; read the data in after the size.  
      ReadMemory fh,Ptr+4,Size
   closefile fh
   

   // Load the image from memory. 
   // Just like the LoadFont tests, here we pass the loadIMage command
   // the address of the buffer in memory.   
   LoadImage "&"+str$(ptr),100,8

   // This bank is no longer of any use, so delete it
   DeleteBank ThisBank
   
   cls 255
   drawimage 100,100,100,true
      
   Sync
   waitkey
 

  Loading Map Blocks directly from memory

       Since the Map library uses the image library to load media these days we're able to expose the functionality to loading blocks also.

PlayBASIC Code: [Select]

  Filename$="D:\PlayBasicSig2.png"
   
   // Load the image file into a bank.  The picture data needs the size (of the image) 
   // appended to the header of the structure for this work.   

   fh=ReadNewFile(filename$)
      size=filesize(filename$)
      Thisbank=NewBank(size+4)
      ptr=GetBankptr(thisBank)
   
      ; poke the size into the first 4 bytes
      pokebankint ThisBank,0,size

      ; read the data in after the size.  
      ReadMemory fh,Ptr+4,Size
   closefile fh



   // Load the image from memory. 
   // Just like the LoadFont tests, here we pass the loadIMage command
   // the address of the buffer in memory.   
      t=timer()
      LoadafxImage "&"+str$(ptr),100
   

      

      BlockWidth=32
      BlockHeight=32

      Map=NewMap(10)
      Level=NewLevel(Map,20,10)

      LoadMapGFX  "&"+str$(ptr),Map,BlockWidth,BlockHeight,-1,4
   
      Tile=0
      For ylp =0 to GetImageHeight(100) step BlockHeight
         For xlp =0 to GetImageWidth(100) step BlockWidth
               PokeLevelTile Map,Level,xlp/BlockWidth,ylp/BlockHeight,Tile
               Tile++
         next   
      next
         
      leveldrawmode map,level,2
      
      cls 255
      drawimage 100,100,100,true
         
      drawmap Map,level,100,300      
      
      
      DeleteBank ThisBank
      
   Sync
   waitkey
 

[kevin]

  PlayBASIC V1.64O  Beta 11 - Download

   This revision includes the initial support of the LOAD MEDIA FROM MEMORY functionality.   The support thus far limits the user to loading PNG image files and CRF (Compressed raster Font) files from memory  (JPG/BMP/TGA are NOT supported).

   Come and get it..
     

    Download  removed, newer builds follow.

[kevin]

  PlayBASIC V1.64O  Beta 12 - Loading BMP/TGA images directly from memory

       So tonight's little coding session adds load from memory support for BMP and TGA image formats.  From the limited testing it's had tonight, it all seems to be working pretty well.    When picking through the loader,  the easy solution just seemed to be replace the 'file' fetching commands with an ambiguous interface.   Which meant rolling a bit of extra set up code, but once that was done the decode logic is identical in both modes.

       Just like loading PNGs from  memory, the loader needs the size of the resource (in bytes) poked into the data header.    This is really in an effort to trap some load possible errors up front, but existing loaders don't really bother with errors too much.  Some formats will require it, others not so much.

       Anyway, what all this now allows you to do, is create custom pack files with at least the image media in them.