UnderwareDESIGN

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


    For newer upgrade work in progress see,

     See  [plink]PlayBASIC V1.64P (http://www.underwaredesign.com/forums/index.php?topic=4089.0)[/plink]   -     Convert PlayBASIC To Machine Code Dll's (http://www.underwaredesign.com/?l=PlayBASIC-To-DLL-Development-Blog)

    See  [plink]PlayBASIC V1.64O (http://www.underwaredesign.com/forums/index.php?topic=3988.0)[/plink]

    See  PlayBASIC V1.64N2 / V1.64N3  (http://www.underwaredesign.com/forums/index.php?topic=3833.0)

    See  PlayBASIC V1.64N (http://www.underwaredesign.com/forums/index.php?topic=3651.0)

    See  PlayBASIC V1.64M (http://www.underwaredesign.com/forums/index.php?topic=3440.0)

    See  PlayBASIC V1.64L Learning Edition History (http://www.underwaredesign.com/forums/index.php?topic=3405.0) (Building learning Edition Thread)



    For Older upgrade work in progress see,

    See  PlayBASIC V1.64K (http://www.underwaredesign.com/forums/index.php?topic=3216.0)

---

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

  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  ->  [plink]PlayBasic And The Threaded Monster (http://www.underwaredesign.com/forums/index.php?topic=338.msg21858#msg21858)[/plink]

 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.  
 

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. 
   

   PlayBASIC V1.64L  Beta 7 -  Download


  [plink]Retail users can download this beta from here (http://www.underwaredesign.com/forums/index.php?topic=1150.msg22317#msg22317)[/plink]




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






#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




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

error below

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

 

runs fine here...

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

i think it was 1.64k

   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.    

 [plink]PB V1.64k2 (http://www.underwaredesign.com/forums/index.php?topic=1182.msg21942#msg21942)[/plink]
 

Quote from: Big C. on March 15, 2010, 03:41:50 PM
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 ?

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

      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.   

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

    Perhaps that means something to you, but it doesn't mean anything to me without the base line performance.   In other words, without knowing how it runs in one thread, how can we see the benefit (if any) of threading on your system. Currently there's not enough information see the trend up or down.

    Also, running more threads, than you have CPU cores, will be slower.. 

 Standard BlitImage Threading Test

   Bellow is the code we'll use to query the actual performance/effect of threading BlitImage on each machine.   Simply cut and paste the code to the IDE and run it (F5).

  The test may  take a few minutes to complete, but when it does, it'll show you a results screen.     Capture this screen, to do so press ALT - PrintScreen key, to capture the PB window, then paste this captured image into your favourite paint program.  Save the image out in some compressed form JPG/PNG etc...  

  In the results, the program will highlight the best performing combination for each effect.  





#include "blitimage"

openscreen 1000,720,32,1
centerscreen
titlescreen playbasic$

CenterText GetScreenWidth()/2,GetScreenHeight()*0.45,"Warning, This test may take a few minutes to complete!"
Sync
wait 1000 ; DO NOT REMOVE !
wait 1000 ; DO NOT REMOVE !
wait 1000 ; DO NOT REMOVE !


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

Colour=RndRGB()

MaxThreads=8

Pass=1
MaxPasses=6

Type tThreadTest
name$
Frames
TT#
EndType
Dim Thread(MaxThreads,MaxPasses) as tThreadTest



Threads=1
BlitFxThreads Threads

Frames=0

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()
Select Pass
case 1
name$="BlitImageClear"
BlitImageClear(Screen,0,0,$ff)
case 2
name$="BlitImageAlpha50Colour"
BlitImageAlpha50Colour(Screen,0,0,$ff0000)

case 3
name$="BlitImageAlphaSub"
BlitImageAlphaSubColour(Screen,0,0,$080808)


case 4
name$="BlitImageAlphaAdd"
BlitImageAlphaAddColour(Screen,0,0,$010101)

case 5
name$="BlitImageAlphaMultColour"
BlitImageAlphaMultColour(Screen,0,0,$ffffff)

case 6
name$="BlitImageAlphaPostMultColour"
BlitImageAlphaPostMultColour(Screen,0,0,$ffffff)
EndSelect


Thread(Threads,pass).tt#+=Timer()-t

frames++
Thread(Threads,pass).frames++
Thread(Threads,pass).name=name$

if frames=250
Threads++
if Threads>MaxThreads
Threads=1
Inc Pass
If Pass>MaxPasses
ExitDo
endif
endif
BlitFxThreads Threads
Frames=0
endif

setcursor 0,0
ink $30ff40
s$="Thread Count:"+Str$(Threads)+" Pass "+Str$(Pass)+" of "+str$(MAxPasses)
text 0,0,Name$
Text GetScreenWidth()-(GetTextWidth(s$)+20),getScreenHeight()-20,s$

Sync
loop

setfps 60
Do
SetCursor 0,0
for pass=1 to maxpasses

BestIndeX=1
BestAverage#=10000
For lp=1 to MaxThreads
tt#=Thread(lp,Pass).tt#/Thread(lp,Pass).Frames
if TT#<BestAverage#
BestIndex=lp
BestAverage#=tt#
endif
next


For lp=1 to MaxThreads
Ypos=GetCursory()

ink $ffffff
if lp=BestIndex
ink $ff0000
endif

name$=Thread(lp,Pass).name$

text 10,Ypos,Name$
text 250,Ypos,"Threads:"+Str$(Lp)

tt#=Thread(lp,Pass).tt#
frames=Thread(lp,Pass).Frames

text 350,Ypos," Average Ticks:"+str$(tt#/Frames)
text 520,Ypos," Frames:"+digits$(Frames,4)


print ""
next
print ""
next
Sync
loop






  Bellow are the results from my AMD FX 64 3000  (single Core)

so how to do good fontsize? i chouse 16

my result by using AMD Athlon II X2 250 (Dual-Core)..

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

PlayBasic v1.64L b7 BETA 'thread test'

   stevmjon

p.s.  woo hoo. this is post 100. only taken me 5 years. can't rush these things.

  Map Culling Test

     Adding threading presents a lot of little awkward headaches,  one of which is the rendering of maps through the scene buffer (among other things).      Threads create dramas because the individual threads have access to common data,  reading is ok, but anything that writes can break the bank.    So the scene buffer content has to be piped into  the appropriate data sets for each threaded pass.   In other words breaking the stuff up, so there's no common writing over the source structure.   Which would be  bad, very bad !  

     So since the map data is going to be preprocessed, then this opens the door for some potential background culling.    So backdrop map layers could have their data reduced if the backdrop layer is being covered by some foreground map layers, providing the foreground contains solid sections.    What this does, is the reduces the level of overdraw.  This is really simply and fundamental program principal,   Less overdraw, means the computer is potentially doing less work to draw the same scene.   So it stands to reason that if we can drawn the same scene with less work, then it's going to be faster not only our own machine, but faster on slower systems also.    

     Now implementing specialized culling is not terribly difficult to accomplish and has been demonstrated in the 2d parallax demo (http://www.underwaredesign.com/forums/index.php?topic=2906.0) for example, however coming up with a general solution isn't quite as clear cut.     The current tech demo (written purely in PlayBASIC) simulates how the scene buffer code will handle  map caching, tile culling and then batches them out for drawing.      While the implementation is ok, it's not the prettiest code at the ball that's for sure.    Even though it's currently done in some sloppy PB code,  the simulation generally performs about the same or a little better than native rendering.    Obviously implementing it within the PB engine would give the best bang for the buck.  The problem is going to implementing some way for the user to control culling.   ermm....yeah        

    Anyway, here's a few pictures so you can get an idea what we're talking about..   The first two shots are of a two layer scene.  The first shot is what the player see's, the second is what part of the background layer is being drawn.  The last shot is a four layer scene with full culling.  

Map Culling Cont.

     Put a bit more work into this today,  while the previous version prototypes the potential implementation,  the routines we're pretty straight forward, so i wanted to improve them to reduce as much of the work load as possible.   The theorty being that If it's fast in PB code to have a positive effect, then it can only get better if it's added to the scene rendering code.  The only problem is for some reason the sped up version slowly falls out of sync, so the backdrop is be culling by a displaced version of the foreground.   Not to sure why this occurs, but it's bound to be something simple.  Always is.


     

  PlayBasic V1.64L  - Canceled !      

          Well, unfortunately the lack community interest in the V1.64L upgrade means this upgrade has been canceled, well, postponed.    Producing a new version of the Learning Edition is far more important at this time.

so sad  :(

  Could be worse, we could discontinue PlayBasic completely !

Quote from: kevin on March 25, 2010, 10:38:45 AM

  Could be worse, we could discontinue PlayBasic completely !

this really could happen?

 of course, we won't be supporting this forever...

and PlayBasic 1.7 too?

That would be a pity. Play Basic has potential and is quite basically an easy to learn language. For me personally, but no thread is visible. From my perspective, there are currently 3 versions, which, it seems, must be maintained independently. Is this efficient? You want to put the focus on the limited version. Why is this not a limited version with little effort variant of the retail version 1? Version 1 should come to an end, but also contain a minimum of basic language elements, such as animated sprites as built-in commands and not as Libary. Version 2 would be the next stage of development. Build finished and making it independent of version 2 with eg real 3d art, 64-bit capability, open to multiple platforms or consoles, and possibly a new, free editor. I personally have multiple licenses for several Basic languages, such as BlitzMax, GLBasic, PureBasic and Game Maker ... All have advantages and disadvantages ... Depending on what I need, I can make my choice ... But honestly, I am a regular for 4 years followers of Basic Play and try to as often as possible to make my contribution to the (poor) community.

I would like to contribute more to the community, eg hovers around me for a long time, a new contemporary editor in my head, because it seems that Empty has turned his back to the community. Any attempt on my part to come in contact with him suggested to fail now. Unfortunately, I lack the experience, how to begin and where do I ... I have so far not found any tutorials that have given me only rudimentary first steps for such a project.

Please understand not wrong, this is only my opinion ...

 

Quoteand PlayBasic 1.7 too?

   If we decided to discontinue ALL PlayBASIC support, this would indeed include PBFX.    

   However, this shouldn't come as any great surprise to anybody reading the blog.. [plink] Here For Example (http://www.underwaredesign.com/forums/index.php?topic=338.msg22214#msg22214)[/plink]

QuoteFrom my perspective, there are currently 3 versions, which, it seems, must be maintained independently. Is this efficient?

     No, there's only one version of PlayBASIC.

     LE editions are built directly from the PB retail sources.  

     PBFX is completely different project.  

QuoteYou want to put the focus on the limited version. Why is this not a limited version with little effort variant of the retail version 1?

     You've got that backwards! -  Building the Learning Edition is as easy as running the (newly updated) VM builder.  The bulk of the work is in going over the example packs & documentation etc.       While refreshing the LE is fair bit of work,  it's nothing comparing the work load & hardware testing that's required to get a threaded retail V1.64L to a release state.  

     As outline in the blog [plink](here for example) (http://www.underwaredesign.com/forums/index.php?topic=338.msg22168#msg22168)[/plink]  The LE release is some 2 years (or more) behind.    We could delay the LE release another few months (more like 4 or 5), but without a fresh new update there's no traffic.. No traffic ='s no sales.. etc.  No sales ='s no more upgrades.  

QuoteVersion 1 should come to an end, but also contain a minimum of basic language elements, such as animated sprites as built-in commands and not
as Libary.

   How many times do I have to say it,  All commands sets in the future will come as library's

QuoteVersion 2 would be the next stage of development. Build finished and making it independent of version 2 with eg real 3d art, 64-bit capability, open to multiple platforms or consoles, and possibly a new, free editor.

   You're talking about 1000's of man hours to develop it, so who's paying for it ?

when something appears 2d Engine PlayBasic for C++ ?

So your asking when will there be a SDK version of the PB engine for C++  ?

Quote from: kevin on March 27, 2010, 01:31:44 PM

So your asking when will there be a SDK version of the PB engine for C++  ?

yes, I think after much expanded community

Never !