Figured out how to optimize the SDL_compat path and simplify writing framebuffer drivers
--HG-- extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%402581
This commit is contained in:
parent
fee28b42b4
commit
22170d41cd
1 changed files with 10 additions and 0 deletions
10
NOTES
10
NOTES
|
@ -150,3 +150,13 @@ IRC - Mon Aug 6 23:50:44 PDT 2007
|
|||
[12:01am] slouken: If it were software only I could just say, write your own and register it here, but you'd have to maintain parity with the OpenGL and Direct3D renderers as well.
|
||||
[12:01am] slouken: At that point you might as well be working in surfaces and uploading to texture.
|
||||
[12:02am] icculus: yeah
|
||||
|
||||
TODO
|
||||
----
|
||||
Change textures to static/streaming. Static textures are not lockable,
|
||||
streaming textures are lockable and may have system memory pixels available.
|
||||
SDL_compat will use a streaming video texture, and will never be HWSURFACE,
|
||||
but may be PREALLOC, if system memory pixels are available.
|
||||
|
||||
The software renderer will be abstracted so the surface management can be
|
||||
used by any renderer that provides functions to copy surfaces to the window.
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue