Date   : Sun, 25 Jan 2004 16:04:08 -0000
From   : tom@...
Subject: Re: Graphics Rendering in BeebEm

DirectDraw is recommended. It's nice and fast, and everyone seems to 
have it. (At least, model-b requires it, and noone has complained :)

model-b has an internal buffer which is what the emulator draws to. 
(It's nothing special, just a std::vector containing palettized 
data.) This buffer is then expanded onto an offscreen video memory 
DirectDraw surface of the same size, which is then blitted, possibly 
with stretching, onto the primary surface into the window's client 
area. The expansion takes quite a while (about 25-30% of the running 
time), but the stretched blitting is very quick.

(A few people have complained about poor windowed performance; I've 
put this down to cards that don't do accelerated blits, because their 
problems go away in full screen mode. I take it that most people have 
no problem at all.)

In full screen mode, the internal buffer is copied straight to the 
front buffer. I don't wait for vsync or use page flipping, but I 
probably should, as you can sometimes see a bit of tearing.

Another thing to try is not using WM_PAINT. Each time a new frame is 
ready, blit it to the screen and validate the window rect straight 
away. The improved response (you're not limited by how often you do 
your GetMessage loop) makes the display look more like a real Beeb. 
You'll now get WM_PAINT messages only (I think) if you're moving or 
resizing the window. You can handle them as before, or ignore them 
and pass them to DefWindowProc, if you don't mind the display looking 
a bit messy sometimes.

Hope that's at least of some help. 

--Tom

On 25 Jan 2004 at 14:59, Richard Gellman wrote:

> Hi
> 
> I'd like to collate opinion on dropping the old GDI interface for the 
> graphics rendering of BeebEm. The problem is this:
> 
> The current BeebEm model involves a windows bitmap in memory, which 
> realizes a pallette of 8 BBC Colours (Black, red, green, yelow, blue, 
> magenta, cyan, white) and roughly 6 or so Windows colours used to 
> display things like the FDC plugin in use, speed/FPS display, keyboard 
> and disc LEDs, etc.At screen update time, this is stretch-blitted either 
> directlt to the screen in non-directdraw mode, or into a DirectDraw 
> surface representing the screen.
> 
> This is not only slow, but also results in a judder effect as the eye 
> catches the screen in mid-update (no *FX 112/3 tricks for us). The 
> better option (and the one favored by most DirectDraw users) is to use 
> page flipping (A%=113:CALL &FFF4...). The DirectDraw subsystem takes 
> care of keeping pointers in check, but stretch-blitting into the 
> backbuffer is hideously slow. A direct blit speeds things up slightly, 
> but results in an _interesting_ display...
> 
> To summarise all this, the ideal DirectDraw model interferes with the 
> ideal GDI model. I would like to remove GDI (non-directdraw) support 
> from BeebEm, and move to a more pure model, implementing a BBC Screen 
> buffer (sans windows bitmap objet headers) and a custom-made blitter to 
> get the data into a 32-bit backbuffer.
> 
> All of this does not affect the ability to do windowed mode, this 
> feature would not be dropped.
> 
> So, after all this great long explanation, whats the general opinion on 
> dropping GDI support?
> 
> -- Richard Gellman
>