OpenGL output for software
Moderator: InsideQC Admins
2 posts
• Page 1 of 1
OpenGL output for software
I wanna do that for Engoo. but how!
I think SDL can do it, DOSBox has exactly the approach i'd want to do, plus GLSL shaders (for silly things like scale3x, lanczos, maybe even a crt filter)
you know, like separating game res w/ screen res, so you could 360x480 to a desktop-sized window, or have that over the screen. the game would still look classic and 8bit paletted, just hardwarefied in the output for modern machines with minimal actual screen resolution switchery, vid_mode would follow the old dos resolutions, fullscreen only available by alt enter or some vid_fullscreen cvar (1 stretches to host res, 2 is actually changing your res, in planned theory)
NO THIS IDEA IS NOT GLQUAKE THIS IS JUST SOFTWARE QUAKE RENDERED TO OPENGL TEXTURE
why? Windows Vista, shut up THATS WHY. I love palettes, but I DON'T LOVE WHAT NT 6/6.1 DO TO THEM.
I think SDL can do it, DOSBox has exactly the approach i'd want to do, plus GLSL shaders (for silly things like scale3x, lanczos, maybe even a crt filter)
you know, like separating game res w/ screen res, so you could 360x480 to a desktop-sized window, or have that over the screen. the game would still look classic and 8bit paletted, just hardwarefied in the output for modern machines with minimal actual screen resolution switchery, vid_mode would follow the old dos resolutions, fullscreen only available by alt enter or some vid_fullscreen cvar (1 stretches to host res, 2 is actually changing your res, in planned theory)
NO THIS IDEA IS NOT GLQUAKE THIS IS JUST SOFTWARE QUAKE RENDERED TO OPENGL TEXTURE
why? Windows Vista, shut up THATS WHY. I love palettes, but I DON'T LOVE WHAT NT 6/6.1 DO TO THEM.
i should not be here
- leileilol
- Posts: 2783
- Joined: Fri Oct 15, 2004 3:23 am
I want to implement software Quake's surface caching using dynamically updated textures.
Otherwise though here how you'd do this:
You might get better using a PBO than the final 32bpp pointer, or you might do the same trick using D3D (I also did that) which lets you lock a texture rectangle directly and with no messing with memory pointers or PBOs (you could even use D3DPRESENTFLAG_LOCKABLE_BACKBUFFER when creating the device and write to the backbuffer directly - but you'd need to mod the regular drawing functions to output 32bpp data - I've also done that for the C versions - it's slow).
Otherwise though here how you'd do this:
- Create a texture sized at the resolution you want to render.
- Set up the vid.buffer, vid.conbuffer, vid.rowbytes, vid.conrowbytes stuff sized to this texture.
- Set up a memory pointer the same size.
- Run the software renderer as normal into this memory pointer.
- Expand it out to a 32bpp memory pointer when finished rendering.
- glTexSubImage2D it and draw as a fullscreen quad.
You might get better using a PBO than the final 32bpp pointer, or you might do the same trick using D3D (I also did that) which lets you lock a texture rectangle directly and with no messing with memory pointers or PBOs (you could even use D3DPRESENTFLAG_LOCKABLE_BACKBUFFER when creating the device and write to the backbuffer directly - but you'd need to mod the regular drawing functions to output 32bpp data - I've also done that for the C versions - it's slow).
We had the power, we had the space, we had a sense of time and place
We knew the words, we knew the score, we knew what we were fighting for
We knew the words, we knew the score, we knew what we were fighting for
-

mh - Posts: 2292
- Joined: Sat Jan 12, 2008 1:38 am
2 posts
• Page 1 of 1
Who is online
Users browsing this forum: No registered users and 1 guest