PlayBasic V1.64L Work In Progress Gallery

[kevin]

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

[kevin]

 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.  

Code Select Expand



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

[ATLUS]

so how to do good fontsize? i chouse 16

[Big C.]

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

[stevmjon]

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.

[kevin]

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

[kevin]

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.


     

[kevin]

  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.

[ATLUS]

so sad  :(

[kevin]

  Could be worse, we could discontinue PlayBasic completely !

[ATLUS]

  Could be worse, we could discontinue PlayBasic completely !

this really could happen?

[kevin]

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

[ATLUS]

and PlayBasic 1.7 too?

[Big C.]

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

[kevin]

 

and 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.. Here For Example (login required)