PlayBasic V1.64L Work In Progress Gallery

[kevin]

PlayBASIC V1.64L (Work In Progress) Gallery

    This thread documents the changes being made for the PlayBASIC 1.64 revision L.  


    For newer upgrade work in progress see,

     See  PlayBASIC V1.64P (login required)   -     Convert PlayBASIC To Machine Code Dll's

    See  PlayBASIC V1.64O (login required)

    See  PlayBASIC V1.64N2 / V1.64N3

    See  PlayBASIC V1.64N

    See  PlayBASIC V1.64M

    See  PlayBASIC V1.64L Learning Edition History (Building learning Edition Thread)



    For Older upgrade work in progress see,

    See  PlayBASIC V1.64K







PlayBasic V1.64L  Beta 1-3

     Minor bug fixes



PlayBasic V1.64L  Beta 4

     Spent the last day restructuring the inner drawing routines so some threading support can be added.   Thus far the progress has been pretty slow.  Most of the change are to ensure that the routines are going to be safe.    The most annoying change is how the GFX lib handles current surface.  Which was  hard  coded into the library.    Changing isn't difficult to do, it's just the amount of mundane changes that need to be made... what fun..

     The first goal is to get the Blit Image routines threaded.   If this work anything like the prototypes do, then we should see some very handy performance benefits from the changes.  Without you having to lift a finger.   But that's just speculation today,  but we'll know for sure in a few days :)

[kevin]

  PlayBASIC V1.64L  Beta 6 -  Re-factoring the GFX engine ='s Crawling Towards Threading

    Those reading my private blog (if you're not then you should be! - You'll learn a lot more about PB than anywhere else !) would be aware that I've stated my desire to implement threading (MultiCore) support to this revision of PlayBASIC, among other things.    

    Threading support, in a nut shell will allow your PlayBASIC programs to take advantage of the Multi-Core systems.   The goal is to provide completely scalable support, so the more CPU cores the host machine has, the more render horse power available to your program.    While this is not currently available in PB obviously,  we've already prototyped the method with some fantastic results, not only on Multi-Core systems, but it works very well single core systems also!  -   So even if the PB implementation only works half as well, it should have some serious bite !

     All of my most recent work on the GFX engine has been splitting up the engine into clearer/better modules (since this code base is to be used in PBFX also).  One of the issues with adding threading, is that engine needs to be made thread safe,  to do this means change how the current surface works throughout the GFX library,  so it's not quite as simple as a re-compile and hey presto.   But all the pain will be worth it in the end.  

     
    MoreInfo -> See Blog  ->  PlayBasic And The Threaded Monster (login required)

[kevin]

 PlayBASIC V1.64L  Beta 6 -  Threaded Blit Image

  Today I've been actually implementing some threading into the Blit Image routines deep the graphics engine.  While it works, the results (speed wise) are virtually the opposite of those found in the last set of tech demos.  Why ? - I've No Idea !    

  This image is drawn in threaded segments, the segments have visible splits so I can see which thread is rendering what section.  
 

[kevin]

PlayBASIC V1.64L  Beta 7 -  More On Threading

   Still working away on the testing the threading in the graphics engine, as such i've limited the testing to one filling routine,  which is the post alpha mult routine deep inside the blitimage library.    This just lets me focus upon a small area of code before trying to branch this out.   As one things for sure,  the momemt you introduce threading, it become increasingly easy to make it all go belly up if your careful.

   In yesterdays tests, the results on my single cpu give the same as the previous tests (from 2008/2009) do, that being they're a fraction slower for each thread you add.   After careful consideration,  my best reasoning for why this behavior occurs,  is because the PB app run's at higher priority than it does in the GDI threading tech demo's.  So the APP's own execution is in fact getting in the way of the threads.  Which makes sense.  This shouldn't however be an issue with true multi-core ( or Hyper Threaded possibly) systems though, so the filler will run in true parallel. 

   Single core CPU's  are going to present a bit of issue in PB as it stands,   obviously if the thread pritorities are going to get in the way, then another solution would be to  asynchronously execute render jobs in the background, so they're interleaved against / while game logic is being processed..  After testing this in PB again though, it basically breaks the implementation objective set out in the blog, as it places all of the onus upon the programmer to launch and synoncrionize renderings tasks.  Get it wrong and your app goes belly up...

   The real issue is though, is that while i can happly get asynchronously rendering  working, it's no quicker due to the dependency.  Meaning that even if we shift rendering from out of the current thread to another one,  at some point we have to sync up and see if it's completed it's work.    It'd work much better in situations where the results aren't dependent upon previous results. 
   

[kevin]

   PlayBASIC V1.64L  Beta 7 -  Download


  Retail users can download this beta from here (login required)




  TestCode for the Multi Core users


  Here's an example that uses the BlitImage post mult function to transfer the screen from the FX buffer to video memory.    It'd be very useful to get some idea of impact of threading from MULTI CORE users...

Code Select Expand




#include "blitimage"


Screen=NewFxIMage(GetScreenWidth(),GetSCreenHeight())

Colour=RndRGB()


Do
RendertoImage Screen
Baseangle#=wrapangle(Baseangle#,1)

scx=GetScreenWidth()/2
scy=GetScreenHeight()/2
inkmode 1+32
Offset=0
for lp=0 to 360 step 5
a#=Baseangle#+lp
x#=scx+cosradius(a#,100+lp)
y#=scy+sinradius(a#,100-lp)
circlec x#,y#,32+Offset,true,Colour
Offset++
next
inkmode 1

rendertoimage 0
t=timer()
BlitImageAlphaPostMultColour(Screen,0,0,Colour)
tt#+=Timer()-t
setcursor 0,0
frames++
print "FPS:"+str$(Fps())
print "Ticks:"+Str$(TT#/frames)


Threads=GetBlitFXThreads()
if LeftKey()
If Threads>1
Threads--
endif
BlitFXThreads(Threads)
Flushkeys
endif

if RightKey()
If Threads<32
Threads++
endif
  BlitFXThreads(Threads)
Flushkeys
endif
Text GetScreenWidth()-100,getScreenHeight()-30,"Threads:"+Str$(Threads)

Sync
loop esckey()=true




[kevin]

erm, anybody test it ???????

[BlinkOk]

error below

[kevin]

So what version are you running prior to the install beta 1.64L  ?   

 

[Big C.]

runs fine here...

I got the best result at 2 threads (use a AMD Athlon II X2 250)

[BlinkOk]

i think it was 1.64k

[kevin]

   That function was added to the blitimage library around PB V1.64J - However, I suspect you've installed a version of FX over PB at some time since the release of PB1.64k/PB1.64K2.  This would overwrite the PB SLIBS, with PBFX SLIBS.   So if you copy the PB 1.64L beta files (which don't include Slibs) over a PBFX install though, you'll get a version of PB mixed with FX.  Since FX and PB don't share common interfaces,  the slibs aren't interchangeable.    

 PB V1.64k2 (login required)
 

[kevin]

runs fine here...
I got the best result at 2 threads (use a AMD Athlon II X2 250)

So this is dual core or quad core ?

[stevmjon]

my computer is a pc, core 2, quad core, Q6600  2.4Ghz

PlayBasic v1.64L b7 BETA 'thread test'

fps = @ 330
ticks = 0.932
threads = 1

fps = @ 310
ticks = 0.960
threads = 2

fps = @ 290
ticks = 0.995
threads = 3

fps = @ 280
ticks = 1.014
threads = 4

fps = @ 240
ticks = 0.947
threads = 5

fps = @ 230
ticks = 0.970
threads = 6

fps = @ 230
ticks = 1.054
threads = 7

fps = @ 220
ticks = 1.092
threads = 8

hope this helps, stevmjon

[kevin]

      Interesting results,  I'm not too surprised really.  The task being threaded in your case, is already running inside a millisecond.   Launching a new thread(s) has OS over head in it, so it's unlikely to be able to launch a new thread, and get it's work done inside the original millisecond.    Given that thread execution is at the mercy of WinBlows here.    However what I suspect, if the task was doing more work (like the sprite scene demo), then the call overhead would be a complete none issue.   

[ATLUS]

phenom II x3 720
fps =  107
ticks = 3.006
threads = 32