can the background be drawn?

[ampos]

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 

[Kitty Hello]

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.

[ampos]

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

[Kitty Hello]

stick means USEASBMP ?

[ampos]

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

[Kitty Hello]

why don't you merge layer 1 and 2 - the static ones with e.g. USEASBMP?

[ampos]

I have to call it each frame and it is slow. And horizontal.

[Kitty Hello]

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)

[mull]

clearscreen -1

I wont it now !

[Cliff3D]

IMHO ANY method of reducing the number of times that and entire "screenworth" of data gets coppied around would be an improvement.

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.

[ketil]

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 

That one is VERY important imho.

It wold boost the speed in both our projects.

[ampos]

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.

[Cliff3D]

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.

[Kitty Hello]

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.

[ampos]

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!