@SDL users, use OpenGL
Author
Don't get me wrong. SDL is wonderfull for 2d graphics, to a point. But, there are just some things that can't be ignored.
1) Software rendering in many cases is faster than hardware rendering. Does this seem wrong to anybody else?
2) No stretch blitting, No blending other than alpha, and no rotation. A super nintendo has hardware level support for this, so why not PC's? Oh, wait, they do...
3) It is slow. No matter how you look at it, speed is always going to be an issue. What can't be done in hardware has to be done in software, and sometimes, there isn't even support for hardware level functions at all. Last time I looked, Direct Draw, heck, even the GDI had support for stretched blitting. There is a soft stretch function, but I had to dig deep into the source to find it.
Ok, now you are all mad because I exposed the flaws. But don't be. Doing 2d in OpenGL requires a bit more setup at first, but the rewards are worth the effort. Some of you are aware of a library I have been working on. Drew and Wryzy have helped me a ton working on it. I have called it hxRender.
Now, there are 2 ways you can use this. As I have included all the source, you can use that as a tutorial to build your own framework, or you can use the libraries I have provided. As of right now, there is no documentation, and there are no samples. I am writing a sample program right now to demonstrate the capabilities of this library.
In theory, it is almost identical to SDL's built in rendering package, except where I have added functionality. There are 3 libraries, hxRender, which handles all of the OpenGL rendering. hxSDL, which provides an interface to integrate with SDL for window setup, and hxUtility, which fills the gaps of whatever else doesn't fit.
I built almost all of it from scratch, I have given credit where it is due for the stuff I couldn't do on my own, as much as I can remember anyways.. If you feel you deserve credit for someting, PM me and let me know so I can give it where it is due. If you have any questions, feel free to ask them here, PM me, or send me an email. Thanks.
Here it is for download.
hxRender version 0.7 (18.3KB)
If anybody wants to port to linux, that would be great.
[Edited by - PnP Bios on January 9, 2005 1:43:46 PM]
Of course, may I ask whether it supports resolution-independent sprite rendering and what sort of calls you are making to OpenGL? May I also ask if you have to be worried about texture switching to get good performance? The thing about SDL is that you don't have to worry about the number of surfaces or the size of the surfaces.
I, like many SDL users, are just starting out.
sure 50 fps may suck, but its not like speed is super critical for a tetris clone =P
I do plan to use OpenGL eventually, but right now I'm worried about making a box for string input. So I'll just stick with the easy to use SDL.
sure 50 fps may suck, but its not like speed is super critical for a tetris clone =P
I do plan to use OpenGL eventually, but right now I'm worried about making a box for string input. So I'll just stick with the easy to use SDL.
Quote:Original post by Lazy Foohis library looks almost exactly like SDL, so, it won't be any harder(read his post)
I, like many SDL users, are just starting out.
sure 50 fps may suck, but its not like speed is super critical for a tetris clone =P
I do plan to use OpenGL eventually, but right now I'm worried about making a box for string input. So I'll just stick with the easy to use SDL.
Author
Quote:Original post by Boder
Of course, may I ask whether it supports resolution-independent sprite rendering and what sort of calls you are making to OpenGL? May I also ask if you have to be worried about texture switching to get good performance? The thing about SDL is that you don't have to worry about the number of surfaces or the size of the surfaces.
Resolution independence is a big factor. All of the image data is stored as RGBA regardless of the resolution. Currently, the library supports up to 256 independenant textures. My library even handles non-power-of-two images. I have sacrificed using the depth buffer and lighting as a trade off for using different textures.
No good programmer would need more than 64 megs of ram for texture data at any given time for a 2d game.
Quote:Original post by PnP Bios
Here it is for download.
hxRender version 0.7 (18.3KB)
If anybody wants to port to linux, that would be great.
Why don't you set up a simple website for this lib? Sourceforge maybe? Write down a list of tasks people can be assigned to. I would like to get involved in a project like this in my spare time... But I don't want to start porting your library and then come back here and see someone else beated me to it.
EDIT:
Quote:No good programmer would need more than 64 megs of ram for texture data at any given time for a 2d game.
Generalizations are dangerous...
Thanks a bunch, Joel. Although I think SDL is a wonderful thing for beginners to use, I have to agree that once you're done with it and are confident enough, moving onto a something different is necessary.
Nice job, PnP, and keep it up.
After going through the source, I would like to make a suggestion. After doing some unit testing, I have found that calling glBegin() glEnd() too many times slows things down. Since this engine is directed towards 2D users, I would assume some people would use it for a Tile-Based Game. Often in tile-based games, you'll draw the same texture quite a few times per frame, so I would suggest incorporating a function that would set the texture and then allow users to draw with the current texture.
(Note: If you think this makes things too complicated, you may want to leave it out)
Maybe something like:
//////////////////
hxSetActiveTexture( hxSurface* s ) { glBindTexture( GL_TEXTURE_2D, hxTexList[s->texID] ); glBegin(GL_QUADS); }
/////////////////
hxBlitWithActiveTexture( hxBlitRect sRect, hxBlitRect dRect )
{
float sx = 0.0;
float sy = 0.0;
float sw = 0.0;
float sh = 0.0;
sx = (float)sRect.x/(float)source->wPad;
sy = (float)sRect.y/(float)source->hPad;
sw = (float)(sRect.x+sRect.w)/(float)(source->wPad);
sh = (float)(sRect.y+sRect.h)/(float)(source->hPad);
glTexCoord2f(sx, sy); glVertex2i(dRect.x, dRect.y);
glTexCoord2f(sw, sy); glVertex2i(dRect.x + dRect.w, dRect.y);
glTexCoord2f(sw, sh); glVertex2i(dRect.x + dRect.w, dRect.y + dRect.h);
glTexCoord2f(sx, sh); glVertex2i(dRect.x, dRect.y + dRect.h);
}
/////////////////
hxFinishedWithActiveTexture() { glEnd(); }
////////////////
Its just a thought, but it would probably really increase the speed of drawing if you were doing a tile-based game and drawing like 200 ground tiles, 400 sky tiles, 7 tiles that were the same enemy ....
After going through the source, I would like to make a suggestion. After doing some unit testing, I have found that calling glBegin() glEnd() too many times slows things down. Since this engine is directed towards 2D users, I would assume some people would use it for a Tile-Based Game. Often in tile-based games, you'll draw the same texture quite a few times per frame, so I would suggest incorporating a function that would set the texture and then allow users to draw with the current texture.
(Note: If you think this makes things too complicated, you may want to leave it out)
Maybe something like:
//////////////////
hxSetActiveTexture( hxSurface* s ) { glBindTexture( GL_TEXTURE_2D, hxTexList[s->texID] ); glBegin(GL_QUADS); }
/////////////////
hxBlitWithActiveTexture( hxBlitRect sRect, hxBlitRect dRect )
{
float sx = 0.0;
float sy = 0.0;
float sw = 0.0;
float sh = 0.0;
sx = (float)sRect.x/(float)source->wPad;
sy = (float)sRect.y/(float)source->hPad;
sw = (float)(sRect.x+sRect.w)/(float)(source->wPad);
sh = (float)(sRect.y+sRect.h)/(float)(source->hPad);
glTexCoord2f(sx, sy); glVertex2i(dRect.x, dRect.y);
glTexCoord2f(sw, sy); glVertex2i(dRect.x + dRect.w, dRect.y);
glTexCoord2f(sw, sh); glVertex2i(dRect.x + dRect.w, dRect.y + dRect.h);
glTexCoord2f(sx, sh); glVertex2i(dRect.x, dRect.y + dRect.h);
}
/////////////////
hxFinishedWithActiveTexture() { glEnd(); }
////////////////
Its just a thought, but it would probably really increase the speed of drawing if you were doing a tile-based game and drawing like 200 ground tiles, 400 sky tiles, 7 tiles that were the same enemy ....
Author
Wryzy, With your example with the tile map, I would be assuming that they would be pulling all the tiles off of the same texture anyways. But, you guys are right, assumptions are dangerous. The goal of this is to make OpenGL as transparent to the user as possible. The way I would handle it, would be to see if the texture being used this call was the same one used last call. So, yeah, I see your point.
Ok, this is what I need done, as far as I can tell. I need a web site, that much is a given. I also want to be able to export these as DLL's. So if we do make significant gains in speed, it won't be a pain for the user to upgrade. I also need documentation. I have played around with doxygen, but... That's just not what I want. Perhaps a WIKI would be approriate for this.
*nix people... What should we do for you guys? same for you mac people. I'm fine with it being win32, but if more people can use it, that's great too.
This is going to be giftware, I have decided. If you are going to use it, give me credit if you want to, otherwise I can't enforce it. Do whatever you want with it.
Ok, this is what I need done, as far as I can tell. I need a web site, that much is a given. I also want to be able to export these as DLL's. So if we do make significant gains in speed, it won't be a pain for the user to upgrade. I also need documentation. I have played around with doxygen, but... That's just not what I want. Perhaps a WIKI would be approriate for this.
*nix people... What should we do for you guys? same for you mac people. I'm fine with it being win32, but if more people can use it, that's great too.
This is going to be giftware, I have decided. If you are going to use it, give me credit if you want to, otherwise I can't enforce it. Do whatever you want with it.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
