SDL Game Engine (SGE)

[chrisname]

Update: It can now load and blit images: http://i.imgur.com/LPDoX.png. The next step is to handle animated sprites. I'm not sure quite how I'm going to do this yet. I'm probably just going to have them as GIFs.

[NGen]

Please don't encourage your users to blit images :<

[BHX]

Please don't encourage your users to blit images :<

Isn't that what most things encourage?

[hanst99]

I don't know, "blitting" makes it sound kinda 80's/early 90's. "Block Image Transfer" (or bit block transfer, I won't think less of you for it), is pretty far away from the truth no? Unless you're actually trying to do that chris, in which case, shame on you :P

No but seriously, don't use GIF's for animations. Load them either from different parts of the same image, or from different images. I'd say go for the latter one, with the option to identify sub images as individual images (though explicitly allowing the first option would be better performance-wise).

[NGen]

Isn't that what most things encourage?

Most SDL tutorials make use of blitting because they're SDL-only, and configuration of OpenGL wouldn't be appropriate for such a tutorial. But in a game engine, it's the opposite. Linear transformations aren't fun to use ore implement when all you can do is blit, I can tell you that.

[chrisname]

Alright, I won't blit surfaces together. As for sprites, the other thing I was thinking of was having a wrapper around a simple image format like TGA which would store the offset of each frame of the sprite, so it'd look something like

typedef struct __sgeSprite__ {
	Uint32		Width;
	Uint32		Height;
	SDL_Surface*	Image;
} sgeSprite;

Then to draw frame 'n', you just draw Image from (Width * (n - 1), Height * (n - 1)) to (Width + (Width * (n - 1)), Height + (Height * (n - 1))).

[xander333]

If you want a nice and clean implementation of animations, you can check out the AnimatedSprite and Animation class in my engine. It's very flexible and easy to implement.

http://code.google.com/p/sfgengine/

[chrisname]

I'll take a look, thanks.

[chrisname]

I've made blitting optional, there is now a function to specify whether to use blitting or OpenGL for surfaces (OpenGL is the default).

However, the OpenGL rendering function doesn't work entirely. White boxes seem to appear randomly, and sometimes parts of the screen are rendered that shouldn't be (e.g., stuff from other windows; sometimes the image is repeated as well).
OpenGL initialisation code: http://pastebin.com/19XFvLGc
Surface->texture & texture drawing code: http://pastebin.com/ddDQL00R

[hanst99]

So, you're using OpenGL 1.x? Sorry, can't help you there :O

[chrisname]

I don't even know at this point. I'm just sort of experimenting.

[hanst99]

Well, intermediate mode is slow-ish. I don't think it matters a lot as long as you're just drawing quads, but... And vbo's are supported by pretty much any graphic chip that anyone still uses.

[chrisname]

I haven't learned how to use retained mode or GLSL yet, but I'm going to be learning them along the way (which is the main point of this project).

[NGen]

Does your texture have dimensions with a power of 2? Otherwise, I'm not seeing anything in particular - could you provide a running executable sample? (Preferably for Windows, since Ubuntu isn't liking me right now)

[hanst99]

Was having dimensions of powers of 2 a hard requirement? I was under the impression that using textures that don't "fit" would only lead to a speed break.

[NGen]

It depends on the drivers and graphics hardware - I know that when developing for iOS, I spent MUCH more time than I should have debugging a rendering system and practically rebuilding it from the ground up. My texture was 340x120, and OpenGL ES never gave me any errors. That was 2 weeks well spent.

At the least, it's something to consider for the bug.

[chrisname]

@NGen,
The dimensions are 320x200. Here is a screenshot showing the texture rendered correctly and in the correct place, but with some graphics and text from this site and a picture of a guy with a guitar (I have no idea where that came from; I don't think I've ever seen it before).

http://imgur.com/3ZQeD

[NGen]

It looks like the renderbuffer was never cleared, but you definitely call glClear in your initialization function. I might suggest adding a secondary call to glClear in your __render_gl function, right before you call glBegin just to make sure.

What sort of graphics hardware are you running?

[chrisname]

@NGen,
I'll try that, thanks for the suggestion. I've got an NVIDIA GeForce 9500 GT (planning to upgrade to a GTX 560 Ti), which supports OpenGL up to 3.3 (core profile, I assume).

Edit: Putting glClear() in the ClearScreen function worked.