Talk:Plan for new graphics rendering

The Mad Cacti 04:47, 13 June 2011 (PDT): Hmmm, I have very few complaints about this proposal. One thing I can think of: SDL requires that you lock a hardware surface before reading or writing it. I'm not totally clear why, but apparently this may cause a portion of main memory to be mapped to video memory. However, I guess the data pointer in a Surface probably should not actually be a pointer to the backend's low level surface (and an extra layer of copying between them shouldn't be too significant), so all the locking and unlocking would happen in gfx_UpdateSurface...

Oh, we need an optional way to blit 8 bit graphics without colour-key transparency, because some graphics (layer 0 tiles and backdrops) aren't transparent.

If we add a special-case function in rasterizer.cpp for simple rotated+scaled quads, wouldn't we want a gfx_* function corresponding to it?

Hieran Del8 08:01, 13 June 2011 (PDT):

SDL requires that you lock a hardware surface before reading or writing it

So do DirectX and OpenGL, so that'll be fine.

we need an optional way to blit 8 bit graphics without colour-key transparency, because some graphics (layer 0 tiles and backdrops) aren't transparent.

Ah. I'll adjust that now.

If we add a special-case function in rasterizer.cpp for simple rotated+scaled quads, wouldn't we want a gfx_* function corresponding to it?

Yes, but how would a rotation+scaling be different from the arbitrary transform?