I don't really need anything I'm just brainstorming :)
I just thought it would be cool if it came with some sort of "generic" tile engine that could be used for various kinds of games (platform, RTS, etc).
When I said layers I meant layers like in Jazz Rabbit, for background. I don't remember the english word for that right now :P
Wishlist for 2D SDL/OpenGL library?
Quote:Original post by PnP Bios
having a depth buffer is really pushing it. It is way better to leave depth out of it when working with 2d. doing it by your self offers much more control.
i dont know... i think having OpenGL "sort" your objects makes it much more flexible and easier to use. you can basically have thousands of different layers and easily stick objects at whatever layer you want by giving them a Z value... its easier to do then manually making a layered effect, you just use glVertex3f instead of glVertex2f . also its faster to render say a screen full of tiles in one single pass then in multiple passes. he could even encapsulate the whole thing, and make the user think hes only working in 2 dimensions by offering a blitting function which received a "layer" as a parameter. this layer could be between -10 and 10 and internally it would just be the Z value that the object was rendered to. this would give the user all the layers he could ever work and is something thats very convenient and that no other 2d API probably offers. didnt the SNES have a system like this? i think it would be very sweet.
Quote:Original post by graveyard fillaQuote:Original post by PnP Bios
having a depth buffer is really pushing it. It is way better to leave depth out of it when working with 2d. doing it by your self offers much more control.
i dont know... i think having OpenGL "sort" your objects makes it much more flexible and easier to use. you can basically have thousands of different layers and easily stick objects at whatever layer you want by giving them a Z value... its easier to do then manually making a layered effect, you just use glVertex3f instead of glVertex2f . also its faster to render say a screen full of tiles in one single pass then in multiple passes. he could even encapsulate the whole thing, and make the user think hes only working in 2 dimensions by offering a blitting function which received a "layer" as a parameter. this layer could be between -10 and 10 and internally it would just be the Z value that the object was rendered to. this would give the user all the layers he could ever work and is something thats very convenient and that no other 2d API probably offers. didnt the SNES have a system like this? i think it would be very sweet.
the biggest problem is what happens when one object is drawn over another on the same layer. The triangles/rectangles clash with each other for rendering superiority. that's not an issue if you don't have a depth buffer.
Quote:Original post by PnP Bios
the biggest problem is what happens when one object is drawn over another on the same layer. The triangles/rectangles clash with each other for rendering superiority. that's not an issue if you don't have a depth buffer.
i dont understand.. what do you mean "they class with each other for rendering superiority"???
if 2 objects have the same Z value, and are drawn one on top of the other, then they will show up in the order in which they were drawn, IE the last guy drawn will be on top. this is the same effect that happends without a depth buffer... no?
As best I can tell, everything you want to do can already be done by SDL, except for rotation. I assume (corrrect me if I'm wrong) that your intention is to insulate users from needing to know OpenGL to do simple 2D graphics (for which I applaud your efforts).
Instead of building a seperate library on top of SDL/OpenGL, why not build a new renderer under SDL? Complement the existing Windows DirectDraw/GDI renderer with a new, hardware accelerated OpenGL one. I believe some work has been done in this direction already, but I can't find any evidence of it.
The downside (of course) is that you're restricted to the existing SDL interface (unless you add some special extensions, a la SDL_gfx) and anyone who wants to use it would need a special build of SDL - unless you can get it accepted into the mainline.
I don't know what might be involved - depending on the state of the SDL code, a seperate library might just be simpler and easier. The SDL20 branch hasn't been updated beyond the initial commit 18 months ago, and much of SDL12 is three years old.
Instead of building a seperate library on top of SDL/OpenGL, why not build a new renderer under SDL? Complement the existing Windows DirectDraw/GDI renderer with a new, hardware accelerated OpenGL one. I believe some work has been done in this direction already, but I can't find any evidence of it.
Quote:Original post by KylotanWhat could be simpler than the existing SDL library interface, especially if people already know SDL?
The emphasis will be on making usage as simple as normal SDL, portable, and requiring no or little OpenGL specific knowledge.
The downside (of course) is that you're restricted to the existing SDL interface (unless you add some special extensions, a la SDL_gfx) and anyone who wants to use it would need a special build of SDL - unless you can get it accepted into the mainline.
I don't know what might be involved - depending on the state of the SDL code, a seperate library might just be simpler and easier. The SDL20 branch hasn't been updated beyond the initial commit 18 months ago, and much of SDL12 is three years old.
Quote:Original post by jdhardy
As best I can tell, everything you want to do can already be done by SDL, except for rotation. I assume (corrrect me if I'm wrong) that your intention is to insulate users from needing to know OpenGL to do simple 2D graphics (for which I applaud your efforts).
Yes. The reason here is not really to provide anything new but to provide good performance. SDL for Windows is based on DirectDraw 5 or 6, which is slow by modern standards. I find myself with frame rates of between 30 and 50 when I'm barely doing anything except fill the screen with tiles. Try using any SDL alpha blitting and it gets unusable.
When people post here about this speed problem, the answer is often to 'use OpenGL'. Sadly this is generally quite daunting to someone who's just used to 2D. Using OpenGL for 2D does actually seem quite simple when you know how, but it's the knowing-how that's the problem.
Oh, and I do think rotation is a very useful thing, not to be written off as a mere bonus feature. It's great to not have to create and load 4 or 8 times the artwork, or to have to worry about the anti-aliasing of the edges. It's also good to not be limited to a discrete number of angles.
Quote:Instead of building a seperate library on top of SDL/OpenGL, why not build a new renderer under SDL?
Because that would be an ambitious project, and I don't want an ambitious project. As you say, that has already begun, about 2 years ago now, and as far as I know is not finished yet.
Quote:The SDL20 branch hasn't been updated beyond the initial commit 18 months ago, and much of SDL12 is three years old.
I'm very unhappy with the stagnation in SDL development, to say the least. Maybe one day they'll do all this stuff natively, as they should have a long time ago, but for now I hope I can write something useful to somebody.
Quote:Original post by Kylotan
I'm very unhappy with the stagnation in SDL development, to say the least. Maybe one day they'll do all this stuff natively, as they should have a long time ago, but for now I hope I can write something useful to somebody.
yea the fact that SDL hasn't been updated in so long irks me continuously
Anyways, this is real cool of you Kylotan. I've been procrastinating for so long switching my rendering from straight up SDL to OpenGL. One of those things where I know once I learn it it'll be easy, but I just haven't taken the time to learn it yet :P I've managed to squeeze out decent framerates using bare SDL, but OGL support would be sooo much better.
How's it coming? I'd be happy to help too if you need it, tho it sounds like a pretty straightforward project
There's glSDL which replaces SDL's blitting functions with OpenGL stuff. http://olofson.net/mixed.html
Hardware accelerated alpha blending.
Ability to render tens of thousands of sprites at high frame rates. For examples of where this might lead game designwise, please see the results of Indie Game Jam 0.
Once you start worrying about 10K..100K sprites on the screen at once, you start worrying about 2 things:
- how am I going to keep all those sprites from simply overlapping each other?
- how the hell am I going to control all of those sprites?
For instance, several of the games in the Indie Game Jam 0 could just have easily been implemented with 1 great big sprite for some monsters, rather than tons and tons of little ones. As it stands, you often couldn't tell if you were being approached by a horde of 20 sprites or 20K sprites.
Ability to render tens of thousands of sprites at high frame rates. For examples of where this might lead game designwise, please see the results of Indie Game Jam 0.
Once you start worrying about 10K..100K sprites on the screen at once, you start worrying about 2 things:
- how am I going to keep all those sprites from simply overlapping each other?
- how the hell am I going to control all of those sprites?
For instance, several of the games in the Indie Game Jam 0 could just have easily been implemented with 1 great big sprite for some monsters, rather than tons and tons of little ones. As it stands, you often couldn't tell if you were being approached by a horde of 20 sprites or 20K sprites.
Rendering to sprites / modifying sprite pixels can be done easily if you keep a copy of them in system memory and you upload this to the video memory (which is fast). So when creating a surface/sprite/etc. specify a flag which makes the API keep a copy in system memory.
Once you have a setpixel function you can draw lines, circles, rectangles. If you chose to do this in your own api, you can keep it simple by using just these basic primitives.
The other way of doing it would be to preprocess sprites that need modification before rendering the screen: render the sprite onscreen in a viewport with its size, then render queued primitives using opengl, then copy from the backbuffer to the sprite's memory range (glCopyTexImage2D i think).
Another thing that would be great, but a little harder to implement: non power of two sprites / surfaces. You can do these by dividing the surfaces into power of two subsurfaces and where these extend beyond the original surface's size, fill with alpha = 0 making them transparent. To render to these you could use either of the two techniques above just make sure you copy only the pixels within the orignal surface (non pow 2).
Also, don't use floating point colors for the SetPixel function, it will just slow things down as you have to convert to RGBA, use bytes.
Once you have a setpixel function you can draw lines, circles, rectangles. If you chose to do this in your own api, you can keep it simple by using just these basic primitives.
The other way of doing it would be to preprocess sprites that need modification before rendering the screen: render the sprite onscreen in a viewport with its size, then render queued primitives using opengl, then copy from the backbuffer to the sprite's memory range (glCopyTexImage2D i think).
Another thing that would be great, but a little harder to implement: non power of two sprites / surfaces. You can do these by dividing the surfaces into power of two subsurfaces and where these extend beyond the original surface's size, fill with alpha = 0 making them transparent. To render to these you could use either of the two techniques above just make sure you copy only the pixels within the orignal surface (non pow 2).
Also, don't use floating point colors for the SetPixel function, it will just slow things down as you have to convert to RGBA, use bytes.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
