Jump to content
  • Advertisement
Sign in to follow this  
Kylotan

Wishlist for 2D SDL/OpenGL library?

This topic is 5086 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Since I'm usually too lazy and uninspired to make complete games, I thought I might have a go at throwing together a tiny library for high-speed 2D rendering using OpenGL and SDL. It would be solely concerned with initialising video, loading sprites, drawing them, buffer flipping, and graceful shutdown. The emphasis will be on making usage as simple as normal SDL, portable, and requiring no or little OpenGL specific knowledge. Assuming this is a reasonable project - and I'm guessing it might be, considering how many people still ask about this despite relevant snippets being posted in the past - what features would you like to see in it?

Share this post


Link to post
Share on other sites
Advertisement
I've been waiting for something like this for a while.
Here is my wishlist.
-ability to manipulate RGBA values with out having to respect the surface. (No more damned SDL_MAPRBGA!)
-write to the surfaces w/out having to lock unlock the memory, and make all of the surfaces 32bit to begin with!
-color keying
-rotation about an arbitrarty point of the sprite.
-scaling.
-render to buffer. good for staging effects like shaking and transitions.
-straight up C implimentation, or minimialistic classes.

Kylotan, if you are serious about doing this, I could write up a tutorial and some documentation for it.

Share this post


Link to post
Share on other sites
it would be really cool, if you had the rendering aspect of it be slightly "independent". basically, have it so it uses SDL for blitting if theres no hardware available, and OpenGL if there is hardware available. this would be very nice, it would be compatible with almost all systems, and super fast on most systems. you could even disable rotations/alpha blending/scaling on software only mode.

a font system would be really nice.
a gui system would be even nicer.

i realize those last 2 are more suited for add on lib's, but i thought id try for the hell of it.

oh, oh!!! and a high resolution, cross platform timer. god, i would kill for one of these [smile].

Share this post


Link to post
Share on other sites
Pretty much what PnP Bios said but with a few modifications.

- scaling
- rotation
- color keying
- alpha blending
- use simple rects for blitting and hide all of the vertex crap
for 2d stuff but make it accessable for 3d uses.

I think that is it. Pretty much, I want to remain a 2d programmer without having to learn about verticies and planes and polygons if I don't have to but be able to use the hardware acceleration for alpha blending and rotation. Is this really too much to ask? :) Thanks Kylotan for taking the step video card manufacturers skipped (if this project gets underway that is).

Share this post


Link to post
Share on other sites
Regarding pixel manipulation, I wouldn't want to go too deeply into this since it's usually slow no matter what system you use, but some sort of SetPixel(r,g,b,a as floats from 0.0...1.0) might be on the cards.

Not sure about locking surfaces before writes - I believe it may only be DirectX that requires this on SDL so it might not be an issue, but I'd have to look more closely at it under OpenGL.

Colour keying - definitely going in. I had just planned on converting the keyed colour in the sprite to having 0.0 opacity at the start. Is there any common use case requiring an alternative approach, or can I safely use that in all cases?

Rotation, certainly. About an arbitrary point... I don't see why not as that would just involve a translation before the rotation.

Scaling is already done, since I saw a snippet for that here once before.

Render to buffer, I will have to research. Any links appreciated.

C implementation... I was considering a C implementation with some thin wrapper classes for C++ fans. I'll be writing a Python wrapper for it if all goes well, so the simpler the better.

SDL rendering fallback if no hardware was available would be nice but it's a little beyond the scope of what I want to do, since the idea here is to provide a lib that makes it practical to use full alpha-blending, scaling, rotation, bilinear filtering, and so on in your simple 2D apps.

Font library... I would like to implement very simple text support using sdl_ttf as the backbone. So basically, if you want font support, you'd need that library installed, but it would be used behind the scenes. Similarly for sdl_image - if you have it installed then the system can load more file formats but its use is largely transparent.

Alpha blending - yeah. I already have support for an opacity value from 0.0 (transparent) to 1.0 (opaque) with all values in between. I also want to include a utility function that blends 2 sprites together from one side to the other, or one corner to the other, to make tile transitions simple.

Share this post


Link to post
Share on other sites
what about window resizing / resolution changing? could you somehow make that so easy that there wouldnt be any work involved in allowing it to happen? that would be very nice (hard to do in a cross platform way).

Share this post


Link to post
Share on other sites
Since it would come with support for sprites, support for tiles and layers would be cool too.

Share this post


Link to post
Share on other sites
Not sure about dynamic resizing and resolution changes. I'll see how difficult it is once other things are implemented.

Owl, what do you mean by tiles and layers? I think everyone might have different thoughts when they say that, so I'd like to know what you would need.

So far, I have the following implemented:
- Window opening in fullscreen or windowed mode at chosen resolution
- Sprite loading using SDL_LoadBMP or IMG_Load (from sdl_image), for power-of-two sized sprites
- Basic sprite rendering
- Scaled sprite rendering
- Rotated sprite rendering (currently around centre of sprite only)
- Translucent sprite rendering (from fully opaque to fully translucent)
- Alpha channel sprite rendering (from PNG)
- Coloured quad rendering with arbitrary opacity (useful if you need to darken or lighten part of the screen, for instance)

Next up I hope to handle the colour keying aspect, which will edit the alpha channel based on the specified key. Once that's done, I'll clean up the code and give out a test release for people.

Share this post


Link to post
Share on other sites
what about the Z axis? you should provide a blitting function which lets you specify the Z value, or something. that way it will be very easy to add layers to a game, by just specyfing the Z value (this is VERY nice).

be carefull, though. theres that screwy thing with geometry disapearing (failing the depth test) when 2 transaprent objects are rendered on top of one another with varying Z values. if you could get this to work though, it would be very very sweet. theres a GL state which says "throw away any pixels which are completely transparent", which should solve half the battle. then you just have to sort semi-transparent objects... (if you figure out a good way to do this, please let me know...)

also, will you library allow access to OpenGL and SDL directly, or will we have to go through your API only?

Share this post


Link to post
Share on other sites
Quote:
Original post by graveyard filla
what about the Z axis? you should provide a blitting function which lets you specify the Z value, or something. that way it will be very easy to add layers to a game, by just specyfing the Z value (this is VERY nice).

be carefull, though. theres that screwy thing with geometry disapearing (failing the depth test) when 2 transaprent objects are rendered on top of one another with varying Z values. if you could get this to work though, it would be very very sweet. theres a GL state which says "throw away any pixels which are completely transparent", which should solve half the battle. then you just have to sort semi-transparent objects... (if you figure out a good way to do this, please let me know...)

also, will you library allow access to OpenGL and SDL directly, or will we have to go through your API only?


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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!