PlayBASIC V1.64N3 / V1.64N3b / V1.64N3c & V1.64N3d _Retail Upgrades_ Now Available (11th, Dec, 2012)
The
PlayBASIC V1.64N3 packages include updates of PlayBASIC Compiler, Release / Debug Runtimes, SLIBS, DOCS & IDE V1.17b.
The V1.64N3 upgrade was slated as a bug fix, hence the version number, as after releasing V1.64N2 a few fairly major issues were discovered in the mapping command sets. While those issues have been addressed, we've taken this opportunity to apply another round of bug the optimizations to the package. There's even some completely new functionality in way of multi core support with the addition of the threading support being added to the Blit Image library functions.
Bug Fixes Bug wise, the main changes would be the improved block classification routines in when importing blocks in the maps, as well as localizing the sprite to map collisions and tweaking the ray to map intersection commands, which would only work on the first level. But really the biggest issue that's been addressed, would be the legacy issues with recursive function calls. Where it seems older versions from the PB run time had some logic issues with how the stack was being managed in certain situations. After much research, it was decided that the best way to remedy the situation, would be to replace the how the run time uses the stack. While more work that i'd like for a quick upgrade, the results speak for themselves, by not only fixing the issues, but it uses less memory and is quicker at runtime.
New Feature: Multi Core / Threading The addition is multi core support or threading support is big one. This features allows the programmer to push big blit image rendering tasks off your current cpu core onto a second cpu core on your system. The idea being, that you can
get your program doing two things at once. The threading commands in this version I consider to be prototypes. Meaning the function names and parameter many well change in future releases. But rather than hold this feature back, you can use it today !
Threading is disabled by default, so your programs will run entirely on the same cpu-core that started upon. The current implementation of the threading only allows a single 'function' to the pushed onto the second core at once. So it's doesn't support queuing up render tasks.. Yes, that's exactly what i've in mind, hence why the commands may change.. The only commands that support threading are the BiltIMage functions. The reason being they're generally big job functions, where if we can interleave our code, we'll get the best performance improvement. In other words, if you can work out a way to set up an effect where you can use a blitimage function to perform some action in the background, then that's an ideal situation.
Current Multi Core/ Threading Commands (WIP) BlitFXThreadMode State (1= Threading on, 0 = Threading Off immediate mode rendering)
GetBlitFXThreadMode() ; Get the current thread mode
BlitFXThreadPriority ThreadPriority ; Set the priority of this threading request. Range between 1 to 15. 1 being lowest, 15 being highest (critical)
ThreadPriority=
GetBlitFXThreadPriority() ; Get the current thread OS level thread priority that threaded rendering is using.
WaitOnBlitFX() ; This thread waits until our drawing process is complete.
How Not To Use Threading Threading is only of any value, if you design your program to perform the required tasks in parallel with the main program. Linear thinking and threading don't mix.
For example , If I enable threading and call a blitimage function say
BlitImageClear, then this task is going to be offloaded from the primary program onto a second CPU core.
; start the blitting the from buffer to the PB screen
rendertoscreen
; When thread mode is enabled, this BlitFX function will be pushed onto a
; second thread.
BlitIMageClear Screens(FrontBuffer),0,0,$304050
; wait until the other thread completes it;s task..
WaitOnBlitFX()
OK.. so here we see a program that's gaining absolutely nothing from threading at all, why ? The reason for this, is the main program is being forced to sit and wait until the secondary rendering thread (on some other cpu core) completes it's task. What we should be doing, is getting the main program to perform some other none related task while the rendering takes place in the background. And only wait for the blit function to complete, when we actually need to use the result of that rendering.
In the main example bellow, we're starting the second thread doing the BlitImageClear, then rather than waiting for it complete, we're rendering our batch of circles to a secondary FX screen. In a dual/quad core system the two tasks are being performed in unison. Generally the blitimage function will finish long before main program is done drawing the batch of circles, so we're not really gain much, other than offloading one screen copy onto the second core.
Swarming Parallel Rendering When threading was last on the radar, the approach was entirely based around using a swarm of threads spread across the host system to perform common tasks in unison. This allows the program to use as may threads as the programmer wants (within reason), meaning a computer problem can be broken up into small jobs and distributed across many CPU's at once. Today we don't have this, the new implementation is queue based. Where we push a job from our main program onto a secondary thread. All these jobs run on a separate core to main program (if you have multi core system), but only on the one core. There's advantages and disadvantages to both.
Anyway you can share rendering of blitImage functions between two cores, by first setting the Viewport of the destination surface, then call the render function. This will push the job off to core #2, core #1 will continue on. Where we'd set the viewport to the other half of the screen and then call the same blit image function we wanted again. So we're doing is splitting the job between the two cores. So core 2 is drawing the top half of the screen and core 1 the bottom.
#include "blitimage"
Screen=NewImage(800,600,2)
Do
rendertoimage Screen
inkmode 1+64
circlec mousex(),mousey(),50,true, $304050
inkmode 1
rendertoscreen
; this first request is pushed onto core #2
ScreenViewport 0,0,800,300
; turn blitimage threading on
BlitFXThreadMode ON
; Calling this function pushes the task off onto core #2
BlitImageAlphaPostMultColour(Screen,0,0,$e0a0b0)
; while Core#2 performs the blitimage function on the top half
; turn blitimage threading on
BlitFXThreadMode OFF
; we now change the viewport to the lower half.. So core #1
;will render this now
; this first request is pushed onto core #2
ScreenViewport 0,300,800,600
BlitImageAlphaPostMultColour(Screen,0,0,$e0a0b0)
; restore the viewport
ScreenViewport 0,0,800,600
; better wait for the core #2, it may not have complete it's job
WaitOnBlitFX()
Sync
loop
The
PlayBASIC V1.64N3b package includes updates of PlayBASIC Compiler only. To install, you download it, unzip and copy the included files over the V1.64N3 files.
This update includes a fix for some issues with some built in constants (like
PBCompileMode) not responding to the compiler settings. Beyond that, it also includes a number of mostly small tweaks to the variable/constants and literal searching routines. These tweaks improve the compile times by around 30% in programs that make heavy usage of lots of unique variables / constants or literals. Routinely getting a compile performance of
10,000 lines a second on 7 year old single core AMD system.
The
PlayBASIC V1.64N3c + V1.64N3d packages includes updates of PlayBASIC Compiler only. To install, you download it, unzip and copy the included files over the V1.64N3 files.
These includes a number of minor tweaks to the compilers keyword scanning (for even faster compiling) code generation ( optimizer), allowing them screen out many more redundant move operations from reading types and various redundant math operations between variables.
As always we
highly recommend reading through the
V1.64N2->V1.64N3 WORK IN PROGRESS GALLERY for some more insight in what new additions are hidden away in this release.
Don't have a retail version of PlayBASIC ? and want to find out more information about PlayBASIC programming > please visit the
www.PlayBasic.com and download the free learning edition.
Download Download PlayBASIC 1.64N3 / V1.64N3b / V1.64N3c & V1.64N3d Retail Upgrades (login required)
