Is there a way to draw directly in the "background"? I mean, the gfx used as background after each "showscreen".
Something like "usescreen", but perhaps "-3" :)
It would be good if:
usecreen 0-7 to draw in sprites (as is)
usescreen -1 to go back to backbuffer screen
usescreen -2 to draw directly in frontbuffer
usescreen -3 to draw directly in background image.
I said this because drawind a 480x320 sprite each frame is killing my app framerate :P
Not really. I think about adding CLEARSCREEN -1 to disable the clearing of the screen after a showscreen. That way you could draw the background sprite yourself w/o performance penalty.
In my case it would not work, as I have to draw also the falling snow, and I dont want it "sticked" to the background. :whistle: Another aprox could be to set a "createscreen -1" to access background... dont know. As I said, it is just a desiree, as to be able to write directly to the background could save (me) a lot of gpu processor time.
Not really related, but sometimes it would be usefull to draw the entire background with a color different to black, so maybe adding an rgb color to blackscreen...
stick means USEASBMP ?
If you dont clear the background, you can not draw moving sprites, just add statics ones.
Let see my game as example. I have a background and falling snow. Once the snow touch the floor, it does not move anymore.
Currently, I have 3 layers:
1.- background (480x320)
2.- non-moving snow (480x320)
3.- tons of snowflakes (5x5)
Any snowflake that touches the floor, is drawn in layer (sprite, full screen) 2 and deleted from memory.
If I could draw directly on the background, I only have 2 layers.
1.- background
2.- snowflakes
I do not need to draw the layer of the non-moving snow, as the snow falling into the floor would be drawn on the background. The benefict is not only "not drawing a layer", but "not drawing a BIG (full screen) layer (sprite)"
If you dont clean the background (which can be usefull in some cases), the layer of moving snow is on the background on next frame, so I will have a line of snowflakes.
Notice that non-cleaning the background is not usefull in my concrete case, but coould be useful in another cases (as has been in another project I did in BB3D).
why don't you merge layer 1 and 2 - the static ones with e.g. USEASBMP?
I have to call it each frame and it is slow. And horizontal.
you could draw to an offscreen sprite then, and draw/rotate that then. With the clearscreen -1 that might be almost without delay. (Not implemented, yet, though)
clearscreen -1
I wont it now !
IMHO ANY method of reducing the number of times that and entire "screenworth" of data gets coppied around would be an improvement.
Quote from: ampos on 2010-Oct-22
If you dont clear the background, you can not draw moving sprites, just add statics ones.
It may not work in your program, or could get too complex to actually save time, but a couple of methods have been used to address this in geenral. One has been to perform some math that negates the screen at a point to produce the dot - and then negate it again to remove that dot on the next path. The other general technique I've seen is to store the color under a dot before you place it, so you draw only the background dots that you have obliterated on the next pass around. Either of these basic ideas might be adaptable if "Don't clear the back buffer" is adopted.
Even if "don't clear the back buffer" doesn't fix this specific issue, it would be an important improvement to the screen handling capabilities of GLBasic. IMHO.
Quote from: ampos on 2010-Oct-22
usescreen -2 to draw directly in frontbuffer
If I am not entirely wrong, a direct draw to the front-buffer would generate flickering if the gpu isn't vsynced ?
But CLEARSCREEN -1 :good:
That one is VERY important imho.
It wold boost the speed in both our projects.
I am nit sure Burnett flicker effect is no more on LCD screens...
But if you have an option you can use it or not. But if you have not an option, you are limited to a single way, for the good or the bad.
Quote from: ampos on 2010-Oct-27
I am nit sure Burnett flicker effect is no more on LCD screens...
But if you have an option you can use it or not. But if you have not an option, you are limited to a single way, for the good or the bad.
You can certainly get a "tearscreen" effect :(
HOWEVER - I cannot agree more on flexibility. If you have 3 alternatives (say) then you have choice and can do what is best for your appv -vif you have only 1 way then there are no options. There are instances where each possible technique has its advantages.
If you would not clear / overpaint the screen when using CLEARSCREEN -1, you would get a flickering image. Basically because you have 2 screens where you draw on, and swap them fromt/back all the time. Now you draw to the other buffer on each flip. Anyway - the contents of the back buffer when using CLEARSCREEN -1 is *undefined*, because it may vary on other platforms.
Quote from: Kitty Hello on 2010-Oct-28
If you would not clear / overpaint the screen when using CLEARSCREEN -1, you would get a flickering image. Basically because you have 2 screens where you draw on, and swap them fromt/back all the time. Now you draw to the other buffer on each flip. Anyway - the contents of the back buffer when using CLEARSCREEN -1 is *undefined*, because it may vary on other platforms.
DOn't complain, just do it! And the -2 option fro frontbuffer, too! :whip:
:nana: :whistle: :nw:
I'm terribly confused about this thread. Could someone post some example code to display (and keep) a static background image, sprite or bmp file the most efficient way plzzzz!!!1!!11 :whip:.
Quote from: matchy on 2010-Oct-28
I'm terribly confused about this thread. Could someone post some example code to display (and keep) a static background image, sprite or bmp file the most efficient way plzzzz!!!1!!11 :whip:.
loadbpm "my static background.png"
:whistle:
Quote from: matchy on 2010-Oct-28
I'm terribly confused about this thread. Could someone post some example code to display (and keep) a static background image, sprite or bmp file the most efficient way plzzzz!!!1!!11 :whip:.
ampos's response is quite correct and most helpful, but I'd like to add "you're probably confused in part because this thread is NOT about the most efficient way of having a static background, but about making having a dynamic background more efficient".
For example, if we could time our Apps to the "screen refresh" pass, we could (in theory) time our screen drawing directly to the screen memory with no snow or tearing or anything.
Now, I don't know the exact internals for how screen handling works in GLB for every device, but there are several steps taken (copying from backbuffer to frontbuffer, then clearing the backbuffer, then potentially copying the static background to the backbuffer) which have a number of effects:
1. It keeps the "ACTUAL screen update" as fast as GLB can possibly manage, which should avoid all snow and/or tearing.
2. It adds processing to do all those jobs, which might not be necessary for some Apps*
3. It wipes the drawing "to date", which may actually mean the App coder has to redo masses of work, further slowing the App.
What we're looking for is to increase the performance of Apps which don't need - or want - the background clearing and rebuilding each and every frame. The "ultimate" of this would be to be able to draw on the screen directly, but in some instances this can cause screen tearing. So you can see why Gernot might be qnti this, as it could cause support issues for those who don't understand screen technology very well. A compromise situation is to not clear the backbuffer when it's copied to the frontbuffer. How Gernot achieves this would depend on the actual techniques used to "swap" and clear the buffers on each platform, but the theory is to reduce the CPU/GPU overhead on screen updates.
:D
Oh. I didn't realize that LOADBMP stays in the fore-buffer. :zzz:
Quote from: matchy on 2010-Oct-28
Oh. I didn't realize that LOADBMP stays in the fore-buffer. :zzz:
Well technically it probably replaces the background image buffer, in much the same way that "UseScreen" can redirect drawing to a sprite instead of the usual backbufffer:
QuoteLOADBMP bmp$
Loads the file bmp$ and changes the background image buffer to the image. As a result, it will form the background for your program's display from the next call to SHOWSCREEN.
(from http://www.glbasic.com/xmlhelp.php?lang=en&id=50&action=view)
Probably the key word there is "from". Often the implication of commands (in many language) hinge on the tiniest of words in the definition, and I usually miss them completely.
If no-one does so before I get home in a few days time, I might be tempted to draw up a few flowcharts of ways that GLBasic's screen updates might currently be happening - but they would be based heavily in conjecture (for example, when there is a background image, does Gernot bother clearing the backbuffer before copying the background screen over it? If the background image supports alpha/transparency then it probably needs a clear screen beforehand, if it doesn't then that step would seem to be not required). And so on.
Quote from: ampos on 2010-Oct-28
Quote from: matchy on 2010-Oct-28
I'm terribly confused about this thread. Could someone post some example code to display (and keep) a static background image, sprite or bmp file the most efficient way plzzzz!!!1!!11 :whip:.
loadbpm "my static background.png"
:whistle:
Actually, a simple test appeared to show that this is actually the least efficient way to display a background on my laptop. Using a standard sprite proved best for me.
I've included my test (.EXE and code). Maybe the test is flawed, but there's a significant difference between the four tests.
[attachment deleted by admin]
Quote from: Ian Price on 2010-Oct-28
Quote from: ampos on 2010-Oct-28
Quote from: matchy on 2010-Oct-28
I'm terribly confused about this thread. Could someone post some example code to display (and keep) a static background image, sprite or bmp file the most efficient way plzzzz!!!1!!11 :whip:.
loadbpm "my static background.png"
:whistle:
Actually, a simple test appeared to show that this is actually the least efficient way to display a background on my laptop. Using a standard sprite proved best for me.
I've included my test (.EXE and code). Maybe the test is flawed, but there's a significant difference between the four tests.
Good catch. On my PC, 1 & 2 (no background & drawsprite) are around 1300 and 3 & 4 (polyvector & loadbmp), 800.
I will compile tonite to iPhone to check if this is also true on iDevices.
PS: it seems we have been mislead (!) by Gernot, as the options that "should be faster" are the slower and viceversa.
[EDIT by Ian] Ampos: your reply was embedded in the quote. Sorted.
I get the same ampos - no background and sprite image seem to be twice as fast as POLYVECTOR and LOADBMP. This is surprising.
#1 - 3440
#2 - 3391
#3 - 1447
#4 - 1454
This is one reason that i am hesitant to produce any kind of flowchart that is anything but overly generic to show "how screen updates are done" becuase the fine details - which may be platform specific - could disagree in specific situations with a flowchart. Without being privvy to how and why some routines are slower than others it's a tough call on how and why different scenarios are faster or slower.
In theory a sprite SHOULD IMHO be faster than Polyvector, because a sprite that matches the background dimensions pixel-for-pixel should be a very swift, optimised copy that POLYVECTOR can't compete with because POLYVECTOR has to be able to cope with non-exact size and shape matches. BUT - this can be made "untrue" either by harnessing the GPU for POLYVECTOR and not sprites (so memory accesses are almost all on the graphics card, not having to cross busses to the CPU) for example, or by having sprite code simply being older and unoptimised than the POLYVECTOR code. Examples only of how, on some platforms, sprites could be faster or slower than polyvector.
Why or how the existing "background image" code could perform slower than using a sprite is a mystery to me, as one would have thought that the "background image" would have the most efficient code possible because it has the most certain direct 1:1 correlation, in size, between the background and the backbuffer. It FEELS as if, perhaps, sprite handling has been given some optimisation over the years that the background image copier hasn't. I'd have thought it possible for the background image to be AT LEAST as fast as a sprite (by reusing the same technique/code) if not faster (by optimising based on the background being held in memory as the same dimensions as the backbuffer) but that would require more dev time from Gernot (or perhaps an efficient method of cloning Gernot!)
The fact is that it opens a new entry way for my app to be faster on old iDevices :good:
QuoteWhy or how the existing "background image" code could perform slower than using a sprite is a mystery to me, as one would have thought that the "background image" would have the most efficient code possible because it has the most certain direct 1:1 correlation, in size, between the background and the backbuffer. It FEELS as if, perhaps, sprite handling has been given some optimisation over the years that the background image copier hasn't. I'd have thought it possible for the background image to be AT LEAST as fast as a sprite (by reusing the same technique/code) if not faster (by optimising based on the background being held in memory as the same dimensions as the backbuffer) but that would require more dev time from Gernot (or perhaps an efficient method of cloning Gernot!)
I totally agree. There are some interesting inconsistancies shown here. Whilst the test itself may be flawed, it is consistant.
POLYVECTOR usage will vary depending on number/size of images being shown (and the host machine's 3D graphic handling) and can be more efficient than using DRAWSPRITE.
No way to access the front buffer on all platforms.
Quote from: ampos on 2010-Oct-28
The fact is that it opens a new entry way for my app to be faster on old iDevices :good:
Possibly - at least it is the hope, but it depends somewhat how SHOWSCREEN actually WORKS as to whether there is significant room for improvement.
At it's simplest, I imagine SHOWSCREEN does something like the first flowchart here, although obviously the second flowchart would be more efficient when there is a static background image being used (even if that "static" background image is changed every frame by the App, as can be done).
HOWEVER, there is much that is left unclear in these flowcharts - each step could do with being better defined. For example, if the step "Swap BackBuffer and ForeBuffer" involves copying the contents of the BackBuffer to the ForeBuffer then the state of the BackBuffer afterwards is well known and potentially useful (and so having a way to NOT clear it would be great). If, however, the process involves assigning a "ForeBuffer" pointer to the BackBuffer and creating a new BackBuffer memory block, and pointing the BackBuffer pointer at this new memory block, then the contents of the Backbuffer is unknown and removing the "Clear BackBuffer" process from the procedure would not be as helpful as might otherwise be imagined.
Additionally it would be interesting to know if the FrontBuffer (oops I named it wrong above) is the actual display, or if it is indeed a buffer that is copied to the ACTUAL screen display at the termination of the SHOWSCREEN command. I get the impression that the FrontBuffer is the ACTUAL display memory, but I am not 100% positive.
[attachment deleted by admin]
It should be noted that my concern about whether there is ACTUALLY any significant time saving to come from what we've been asking for (the ClearScreen -1 request, anyway) is this text from the help file:
QuoteWhen SHOWSCREEN is called, the Back Buffer and Primary Surface are swapped. The now unusable Back Buffer will be replaced (cleaned) with the Offscreen Surface which is black when no bitmap is loaded.
...
If you don't see any result from your program, the first thing to check is whether you have forgotten to add the 'SHOWSCREEN' command to it.
Think of Double Buffering as two sheets of paper, one on top of the other where you draw on the bottom sheet. Once you're finished drawing, you swap the sheets and in the process erase the new bottom sheet. This hides the actual drawing of the sheet from the user and in the process eliminates screen flicker.
Now it CAN be dangerous to read too much from small words or even sentences, but there is an implication that the BackBuffer and FrontBuffer are somehow "swapped" rather than just copying the BackBuffer over the FrontBuffer. If indeed the BackBuffer is "simply" copied onto the FrontBuffer then there is much more room for a "ClearScreen -1" type command to save significant time for certain types of App. It would certainly help some aspects of code I have been writing, which is more vector-based than sprite-based, and would benefit from being able to display tiny single-triangle updates more quickly. Of course, being able to draw directly onto the FrontBuffer would be better still for MY code - but it seems this is not possible in GLBasic for multi-platform compatability reasons.
Here's an improved (more accurate) version of the earlier flowcharts. It should be noted, however, that the "Copy backImage over BackBuffer" process and the "Clear BackBuffer" process MIGHT actually be the same process, but "Clear BackBuffer" simply uses an all-black background image to perform the "clearing" operation (this seems fairly likely given some of the wording in the help file).
[attachment deleted by admin]
So, reading and re-reading the help file to try and deduce what's happening brings me down to a third iteration of my interpretation of the SHOWSCREEN command, as attached. This leads to three basic questions which I think fundamentally affect whether Gernot can significantly improve speed of screen updates for us across all platforms:
1) What does the "Swap BackBuffer and FrontBuffer" process/stage actually DO? Does it copy the BackBuffer to the FrontBuffer, or something else?
2) Can the "Copy BackImage over BackBuffer" process be optimised so that it does this in the FASTEST possible way, matching or beating similar processes that currently outpace using the BackImage?
3) If the current "Swap BackBuffer and FrontBuffer" process copies screen data in the same kind of way that the current "Copy BackImage over BackBuffer" process does, can it likewise benefit from some optimisation to improve the speed of every single SHOWSCREEN command?
[attachment deleted by admin]
As on old Amiga double buffer works, was that way: you have 2 memory zones or screens. The displayed one was a pointer. Then you were writing in the other memory/zone. When you finished painting just told the system to change the pointervto the other screen and the new gfx operations were performed on the new hidden one.
Think like having two pieces of paper, one in each hand. You show one and paint on the other. On showscreen just change your hands. So no copy was made from one buffer to the other. Jus the front becomes the back and the back the front.
Quote from: ampos on 2010-Oct-28
As on old Amiga double buffer works, was that way: you have 2 memory zones or screens. The displayed one was a pointer. Then you were writing in the other memory/zone. When you finished painting just told the system to change the pointervto the other screen and the new gfx operations were performed on the new hidden one.
Yup-and other old computers that predate the Amiga, too. The thing is, if it's pointers that are changed and not memory contents that are copied, then Clearscreen -1 might not save as much time as you may be hoping for - because there is no "old copy" of the screen to leave in place. Optimising "ClearScreen" and "UseAsBMP" to be faster might be a better option, if possible. Although ClearScreen -1 should always save SOME time if one is going to redraw the entire screen each frame (as in from a sprite or "Usescreen", for example).
And here is the "undefined" parameter.
On OpenGL (Win32, Linux, Mac, iPhone) I actually swap as you did on the Amiga.
Same for GP2X.
On the Wiz I have to "copy" to the framebuffer (could not get the swap registers working).
On WindowsCE it totally depends on the device drivers if I swap or copy.
But the question is why is slower the things that should be faster... :S
But when you swap the buffers, the new "back" has the contents of the old frame drawn. Thus, I had to glClear(GL_COLOR_BUFFER) it.
Quote from: Kitty Hello on 2010-Oct-28And here is the "undefined" parameter.
Paraphrased: Sometimes it's a pointer swap, sometimes it's the whole screen copied, depending on the platform.
I had a horrible feeling you were going to say that. So on some devices we could be looking at a modest speed improvement :( (though many a mickle makes a muckle/every little bit helps).
Could I ask which technique is used on the various iDevices, especially the older ones?
Quote from: ampos on 2010-Oct-28
But the question is why is slower the things that should be faster... :S
Indeed - or to rephrase "can GLBasic use the best speed techniquesfor the commonest functions please".
Quote from: Kitty Hello on 2010-Oct-28
But when you swap the buffers, the new "back" has the contents of the old frame drawn. Thus, I had to glClear(GL_COLOR_BUFFER) it.
So the BackBuffer would not contain the most recent screen image, but the frame before it? If this is consistent, and you can find a way to document it such that App authors can grok it easily enough, this still could be more useful left intact - saving some overhead in reproducing the screen contents to that point - in some cases, rather than always wiping it. A ClearScreen -1 would leave us with two new choices:
1. Paint the whole screen from scratch -as we might need to do even with the screen being cleared.
2. Rebuild the screen changes for the last frame then add the next frame's changes.
For certain types of App either of these MIGHT be a benefit over the current scenario - though I am a little concerned that in some situations glClear(GL_COLOR_BUFFER) might be so efficiently performed by a seperate GPU that it will be hard to see any improvement in speed for many apps :(
It would still be "nice" if the Backimage copy were at least as fast as using a Sprite to achieve the same ends, unless there's a specific reason that it is slower?
many games overdraw the whole background with animated stuff. Here, a glClear is not needed. I use the flip on iDevices, and try the fastest output possible on all devices. Test it, GLBasic really is fast. Often faster than SDL. Especially blitting.
Do not rely on what's on the back buffer after a flip. It also depends on what the driver does. There's no definite way of telling.
But way is faster to draw a full screen sprite than loadbmp?
no. Loadbmp does exaclty that. But! When you draw an animated background, you don't want the clear.
Well ... why not start with an implementation of CLEARSCREEN -1 ?
Quote from: Kitty Hello on 2010-Oct-29many games overdraw the whole background with animated stuff. Here, a glClear is not needed.
Agreed. A CLEARSCREEN -1 capability would be nice for these situations :)
Quote from: Kitty Hello on 2010-Oct-29I use the flip on iDevices
A shame. While it seems unlikely, it would always be nice to discover that a small change might result in a large speed improvement ;(
Quote from: Kitty Hello on 2010-Oct-29and try the fastest output possible on all devices. Test it, GLBasic really is fast. Often faster than SDL. Especially blitting.
No doubt - indeed, many of my posts in this vein have been warnings that due to this or that, we might not get the speed improvements that SEEM "obvious", because it seemed likely to me that you would have fairly optimised code, and that "obvious" solutions might not, in the end, provide such improvements :(
Quote from: Kitty Hello on 2010-Oct-29Do not rely on what's on the back buffer after a flip. It also depends on what the driver does. There's no definite way of telling.
This is the saddest thing :(
Quote from: ampos on 2010-Oct-29
But way is faster to draw a full screen sprite than loadbmp?
Quote from: Kitty Hello on 2010-Oct-29
no. Loadbmp does exaclty that. But! When you draw an animated background, you don't want the clear.
Ian has done tests which suggest otherwise:
Quote from: Ian Price on 2010-Oct-28
Quote from: ampos on 2010-Oct-28
loadbpm "my static background.png"
Actually, a simple test appeared to show that this is actually the least efficient way to display a background on my laptop. Using a standard sprite proved best for me.
I've included my test (.EXE and code). Maybe the test is flawed, but there's a significant difference between the four tests.
Perhaps there is some flaw in Ian's testing (perhaps you could check his tests):
http://www.glbasic.com/forum/index.php?action=dlattach;topic=5258.0;attach=2496
but otherwise there seem to be some odd differences in speed between certain methods, and a sprite appears to be faster than using a background image :( We'd love to know why/have background images sped up :D
TEST @ iPhone 3G
A.- without "clearscreen -1"
1: 60 no background
2: 43 drawsprite
3: 43 polyvector
4: 60 loadbmp
B.- with "clearscreen -1"
1: 60 no background
2: 38 drawsprite
3: 38 polyvector
4: 60 loadbmp
Very strange results... will change my program "sandscape" to clearscreen -1 and/or drawsprite to check fps...
Upd:
1.- my program loses 1-3 fps if using drawsprite instead of loadbmp.
2.- clearscreen -1 wins 1-2 fps on loadbmp and lose 4-5 in drawsprite vs loadbmp.
Very strange, again.