UnderwareDesign
April 28, 2017, 07:19:05 AM *
News: PlayBASIC V1.64P4 (Revision 4) Released  (24th,Mar,2016)
   Home    
Pages: 1 2 3 [4]
 
Author Topic: PlayBASIC V1.65 (Work In Progress) Gallery  (Read 5559 times)
Member
Development Team


WWW
« Reply #45 on: January 10, 2017, 06:59:56 AM »


   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 Smiley

   
Logged

Member
Development Team


WWW
« Reply #46 on: January 27, 2017, 02:24:16 AM »

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)


 
Logged

Member
Development Team


WWW
« Reply #47 on: January 29, 2017, 01:34:05 AM »

   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:
     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:
      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:
    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




  
Logged

Member
Development Team


WWW
« Reply #48 on: February 03, 2017, 06:25:43 PM »

 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

Logged

Member
Development Team


WWW
« Reply #49 on: February 08, 2017, 12:51:32 AM »

 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

   Get PlayBASIC V1.65B Beta7 (login required)  (8th,Feb,2017)


Logged

Member
Development Team


WWW
« Reply #50 on: February 12, 2017, 07:43:17 AM »

  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 !




Logged

Member
Development Team


WWW
« Reply #51 on: February 24, 2017, 06:34:44 AM »

   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:
    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:
   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.. 

 

 
Logged

Member
Development Team


WWW
« Reply #52 on: March 25, 2017, 08:00:23 PM »

 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

   Get PlayBASIC V1.65B Beta7 (login required)  (26th,Mar,2017)


Logged

Pages: 1 2 3 [4]
 
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.13 | SMF © 2006-2009, Simple Machines LLC | Privacy Policy Valid XHTML 1.0! Valid CSS!