Suggestion - single buffering

[flet]

Hi,

I started a small app for Windows Mobile. Part of it is a basic tool to hand-write on the screen.
Due to double-buffering, it simply craaaaaaaaawls. Each and every single time the stylus is moved, the app has to go through the whole redraw process. It'd be way faster to simply draw to the screen buffer without swaping buffers every time.

A suggestion : it'd be GREAT to have a feature for sending graphic commands  both to the back buffer and to the screen right away (smth such as USEASBMP + SHOWSCREEN performed after each graphic command, but it would not have to swap buffers, and it should be way faster). Or better yet : have a selector to chose if graphic commands would write to the back buffer, the front of both.

Also the suggestion of adding a parameter to DRAWLINE : the line thickness (currently it's only one pixel)

Thanks

- Flet

[PeeJay]

Or better yet : have a selector to chose if graphic commands would write to the back buffer, the front of both

Gernot - if you are thinking of implementing this, may I also suggest being able to write to an image buffer (ie a sprite)?

For example:

USEBACKBUFFER       <- default setting

USEFRONTBUFFER

USESPRITEBUFFER (spritenumber)

[Kitty Hello]

CREATESCREEN / USESCREEN.

[Ian Price]

Here's a quick drawing utility using CreateScreen and UseScreen.

Code (glbasic) Select Expand

SETSCREEN 320,240,0

LIMITFPS 60

SYSTEMPOINTER TRUE

CREATESCREEN 1,1,320,240

USESCREEN 1

DRAWRECT 0,0,320,240,RGB(255,255,255)

main()

END


// Main
FUNCTION main:
WHILE TRUE

MOUSESTATE mx,my,b1,b2

USESCREEN 1

IF b1=1
 IF oldx=0 AND oldy=0
  oldx=mx
  oldy=my
 ENDIF
 
 IF mx<>oldmx OR my<>oldmy THEN DRAWLINE mx,my,oldx,oldy,RGB(0,0,0)
 oldx=mx
 oldy=my
ENDIF

IF b1=0
 oldx=0
 oldy=0
ENDIF

USESCREEN -1

DRAWSPRITE 1,0,0

SHOWSCREEN

WEND

ENDFUNCTION

[PeeJay]

Thanks guys - my bad (can't you tell I'm still feeling my way around the language?!?)

[flet]

Here's a quick drawing utility using CreateScreen and UseScreen.

The problem is, it is sloooooow - I mean, on a Windows Mobile PDA (could be OK on a 3 GHz dual core PC, but it is not the target platform).

I can tell  that the double buffer mechanism is the issue here - because I set up some optimizations, which reduce the number of calls to SHOWSCREEN (at the expense of redraw rate) and the handwriting is captured much more smoothly.

Still, I'll try the USESCREEN option and see if it helps....
Thanks for the hint.

[Ian Price]

Well, my pc is far from a 3Ghz mega beastie, and my code ran like a rocket. In all honesty if that code didn't work at a decent speed for you, I very much doubt that anything more advanced will either - there isn't really a lot happening in it. However, PDAs are not my forte and someone with some experience may well provide a better solution - if not, then I'm afraid you're stuck.

Is there no dedicated PDA software that'll do what you want it to?

[flet]

All right so...
I tried the USESCREEN version, and it's acceptable in terms of speed (not lightning fast, but... well)
The thing is: it's allright if the CREATESCREEN has the same size as the physical screen. If bigger (and then a clipping has to be done when refreshing screen), performance is adversely impacted.

Still wouldn't mind a feature for drawing to the front buffer

[Kitty Hello]

The problem with PocketPCs is, that when you move the pen or hold down a button, the device gets slow.
Just do a simple program that just shows the FPS, then hold the stylus down. Framerate drops to 50%. It's a design flaw the GP2X does not have. I think they are polling the touchscreen a few times and interpolate the result to get very accurate positions. But it's slow.

[flet]

The problem with PocketPCs is, that when you move the pen or hold down a button, the device gets slow.
Just do a simple program that just shows the FPS, then hold the stylus down. Framerate drops to 50%. It's a design flaw the GP2X does not have. I think they are polling the touchscreen a few times and interpolate the result to get very accurate positions. But it's slow.

Hmmm... The thing is, I don't know how to clock the FPS (in GLBasic) without using the SHOWSCREEN feature.

What I know is, some apps are provided w/ the PDA, or by third parties, which let one use the stylus at a very decent speed.

[flet]

OK, not much traffic on this topic, but I'm still stuck with my slooooow application :-(

Another suggestion that may be more generic & easier to implement:

Adding x, y, w, h parameters (optional) to SHOWSCREEN

SHOWSCREEN x, y, w, h   would only redraw the subsection of the screen which intersects the (x, y, w, h) rectangle

[AndyH]

I've just tested Ian's game on the Pocket PC.  It uses the mouse throughout.  In this game, it looks like it is always one click behind in the wrong place.

For example, I click on a block.  Nothing happens.  I click on a second block, the first one highlights instead.  I click on a third block, the second one highlights.  I click on the third one again and (in Ian's game) it selects again and gives me an option to move it.

I've not got the source code to Ian's game so I can't see what is happening behind the scenes, so I'll make a simple test application to see if I can replicate it and post the code.  Maybe it's a bug in the game, or maybe a bug in GLB?

I wonder if this is anything to do with your pen responsive problems?  Will let you know what I find out.

[Ian Price]

On a pc the mouse control is not a problem at all (checked on at least 6 pcs and one laptop, with no mention of problems), however the game was written for pc and GP2X. Perhaps the ppc works in a different way with regard to mouse/touchscreen presses?

[AndyH]

Sorry, don't mean to imply your code is buggy - just there's something weird going on when it runs in PPC so there's going to be a problem somewhere.  As you can't test on a PPC it's going to be hard to anticipate or debug problems.  I hope we have some very verbose GP2X testing volunteers willing and waiting  BTW - Very nice game Ian.

Anyway, I'll post what I found in a new thread, so not to hijack Flet's any more