better keyboard input and blitting..

[ultralazor]

-Have a managed buffer or whatever for keyboard so input doesn't die when you hold down a key
-Have optional inner blitting for supported videocards. Full screen blitting even with simple text drawing is bad performance wise. Most newer cards OpenGL&DX9+ support this.

I just got to mess with 4.51 from a game developer perspective tonight, and these two things killed a project I was thinking of working on.

EDIT:I don't see a solution in help file for either of these..all there is, is StartDrawing(ScreenOutput()) A.K.A. FS-Buffer+OpenWindowedScreen+KeyboardInkey+FlipBuffers

[Thorium]

-Have optional inner blitting for supported videocards. Full screen blitting even with simple text drawing is bad performance wise. Most newer cards OpenGL&DX9+ support this.

What exactly do you mean with that?
I thought blitting directly to the screen is pretty much outdated since 20 years or so. Or do you mean something else?
On a video card not older than 10 years you will not notice any performance hit on clipping the whole screen every frame.

[djes]

Post some code, and I'm sure we'll be able to help you.

[ultralazor]

The keyboard problem seems to be fixed by using KeyboardPushed and manually handling everything including timing..

I don't have any code cause PB doesn't support it..Allegro for C does as do most other engines. It's the ability to flip buffers to the screen based on memory bitmaps instead of one whole flip for the entire screen causing a performance impact and excess drawing operations. You have to flip the buffer for the entire backbuffer to get changes to a bitmap that was previously drawn to show, instead of just flipping for that bitmap and having it show.

[Thorium]

Ah, i think i understand now.
You want to save performance by cutting out rendering of stuff that hasnt changed since the last frame.
That sounds actualy very complex as you would have to track what has changed and whats it's overlapping. I believe it could save some performance but not on all games. Most scolling games would not benefit from it.

However can that not just done by not clearing the buffer after the flip and just render the changed stuff to it? The flip itself dont cost less if you blitt only changed stuff. So that would be pretty much the same as your screen blitting.

Or use some kind of tribble buffering.

[ultralazor]

Ah, i think i understand now.
You want to save performance by cutting out rendering of stuff that hasnt changed since the last frame.
That sounds actualy very complex as you would have to track what has changed and whats it's overlapping. I believe it could save some performance but not on all games. Most scolling games would not benefit from it.

However can that not just done by not clearing the buffer after the flip and just render the changed stuff to it? The flip itself dont cost less if you blitt only changed stuff. So that would be pretty much the same as your screen blitting.

Or use some kind of tribble buffering.

DrawImage and FlipBuffer seem efficient enough right now, but I haven't really done but maybe 1/3 of the draw operations I plan on doing. I'll find out later.

[djes]

Don't you test our lethal judgment games? I'm sure you'll never have much objects on screen!