🔒 Locked

@SDL users, use OpenGL

Started by PnP Bios Jan 6, 2005 at 10:57 PM 91 replies 20.7k views

Original Post

Jan 6, 2005 at 10:57 PM

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]

Boder

Jan 6, 2005 at 11:11 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.

Lazy Foo

Jan 6, 2005 at 11:13 PM

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.

Roboguy

Jan 6, 2005 at 11:15 PM

[imwithstupid] forgot to login

PnP Bios

Jan 6, 2005 at 11:19 PM

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.

owl

Jan 6, 2005 at 11:23 PM

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...

Rob Loach

Jan 7, 2005 at 8:06 AM

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.

wyrzy

Jan 7, 2005 at 8:20 AM

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 ....

PnP Bios

Jan 7, 2005 at 9:04 AM

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.

Pipo DeClown

Jan 7, 2005 at 9:07 AM

- Very, if not most, important part of a coding library is it's documentation. Many people make their choice based on that.
- There is basically no point in making a wrapper that doesn't add any functionality. Although it's a good personal exercise.

Anyway, I look forward to more of your tutorials, if you're planning on making those.

owl

Jan 7, 2005 at 9:58 AM

Quote:
Original post by PnP Bios
*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.

I'll try to port it to linux as soon as I get my monitor back (or I buy a new one). If you know someone else already doing it, drop me a line, so I won't expend that time doing redundant work.

wyrzy

Jan 7, 2005 at 10:03 AM

Quote:
Original post by PnP Bios
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.

I would take the recommendation of owl and look into source forge. They seem to offer space for almost any open source project. You may be able to find a free Wiki off Google but I don't know of any off hand. I think source forge is reliable and it would probably be a good idea to go with them. What are you looking for in documentation? Doxygen is pretty nice, IMO, and it tells you which function you need for what.

As far as exporting as .dll's, if you don't know how to do that I would just open up one of your SDL header files. Its not really complicated, but it just looked "cryptic" the first time I saw it. You may already know what you need to do.

PnP Bios

Jan 7, 2005 at 11:07 AM

Owl, port away.
Wryzy, I will look into source forge later today, as well as a doc wiki. What I don't like about doxygen is getting it to work with my editor. Dreamweaver, yum.

johnhattan

Jan 7, 2005 at 11:25 AM

Quote:
Original post by PnP Bios

. . .snip. . .

If anybody wants to port to linux, that would be great.

SDL already works on Linux, as well as BSD, OSX, and MacOS classic. It also works on platforms that don't support OpenGL, like PocketPC and Symbian.

If you want to trumpet your own library, let it live on its own merits. Don't start out by pointing out the inadequacies of the competition unless your solution can win on all fronts. . .which would then make cutting down the competition unnecessary.

pTymN

Jan 7, 2005 at 11:29 AM

Clanlib. Who needs SDL?

owl

Jan 7, 2005 at 11:41 AM

Quote:
Original post by johnhattan
Quote:
Original post by PnP Bios

. . .snip. . .

If anybody wants to port to linux, that would be great.

SDL already works on Linux, as well as BSD, OSX, and MacOS classic. It also works on platforms that don't support OpenGL, like PocketPC and Symbian.

If you want to trumpet your own library, let it live on its own merits. Don't start out by pointing out the inadequacies of the competition unless your solution can win on all fronts. . .which would then make cutting down the competition unnecessary.

That's fair enough. Anyway I think OP meant OpenGL being better than SDL in the terms of OpenGL having hardware acceleration support. Beyond that and neededles to say, I don't expect his 8-header-files-long library to be more complete or more crossplatform than SDL and it's agregates.

EDIT: @PnP Bios, if you want people to help you out with your project you better show them it is under the GPL license. Otherwise they would be working for free and wouldn't have the right to own a copy if you or anybody else copyrights the source code.

PnP Bios

Jan 7, 2005 at 11:54 AM

I registered it under LGPL with source forge. I hope that is good enough.

I don't know jack shit about licensing, software law, or anything like that. You want it GPL, sure, I don't care. Just show me what to do.

Khaosifix

Jan 7, 2005 at 12:10 PM

I do agree that it would be a great idea to use OpenGL over SDL for graphics but think about the people just starting out. Some of the things in OpenGL wouldn't make any sense to them at all. Examples of this include setting a orthogonal projection, alternating between matrix modes, etc.

SDL is super simple that is why it doesn't support some of the advance features, like stretch-blitting, that DirectDraw so proudly supports.

PnP Bios

Jan 7, 2005 at 12:26 PM

Quote:
Original post by Khaosifix
I do agree that it would be a great idea to use OpenGL over SDL for graphics but think about the people just starting out. Some of the things in OpenGL wouldn't make any sense to them at all. Examples of this include setting a orthogonal projection, alternating between matrix modes, etc.

SDL is super simple that is why it doesn't support some of the advance features, like stretch-blitting, that DirectDraw so proudly supports.

Anybody using my library wouldn't even know that they are using OpenGL. Did you even look through the source?

Khaosifix

Jan 7, 2005 at 12:40 PM

Quote:
Original post by PnP Bios
Quote:
Original post by Khaosifix
I do agree that it would be a great idea to use OpenGL over SDL for graphics but think about the people just starting out. Some of the things in OpenGL wouldn't make any sense to them at all. Examples of this include setting a orthogonal projection, alternating between matrix modes, etc.

SDL is super simple that is why it doesn't support some of the advance features, like stretch-blitting, that DirectDraw so proudly supports.

Anybody using my library wouldn't even know that they are using OpenGL. Did you even look through the source?

No I don't need to. I'm comfortable with OpenGL. Thank you.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.