Snake game finished - check it out

[ultifinitus]

I'm not a super huge fan of SFML. I've done quite a bit in it, and I've also done quite a bit in SDL. It really truly doesn't matter what you use, both serve essentially the same purpose. I just dislike how much SFML does for you vs. the relative flexible feel of SDL.

Also, I recommend going straight into OpenGL. Using textures you can do the exact same thing with more power and speed that you can in either lib.

[chrisname]

I like how much SFML does for you, but the main reason I prefer it is that it I think it's better designed than SDL. I don't like how SDL's extension libraries work. I would probably use SDL with OpenGL instead of SFML, though, because I have a feeling SDL is more lightweight.

[Disch]

I just dislike how much SFML does for you vs. the relative flexible feel of SDL.

What makes SDL more flexible than SFML? I can't think of a single thing SDL can do out of the box that SFML can't, whereas I can think of quite a few SFML can do.

Using textures you can do the exact same thing with more power and speed that you can in either lib.

SFML2 is in the process of undergoing a major API change to address the "too much overhead over OpenGL" issue. Although I agree that using OpenGL directly is a more "power user" approach.

And really, the graphic interface with SDL is so bad you pretty much have to use OpenGL directly with it. Not to knock on SDL, but the graphic API is just crazy dated (blitting? dirty rects? really? Is this 1997?).

SDL also has other extremely crippling issues. I haven't used it in a while so I don't know how many have been fixed, but when I last used it:

1) It demanded to be the owner of the window. Which doesn't play nice with other libs. Ever tried to make a program with uses both SDL and a widget lib like wx? I have for an emulator I was working on. It wasn't pretty.

SFML on the other hand has ties to Qt and wxWidgets, so you can easily have a high performance game window with all the bells and whistles alongside a widgetry lib.


2) One and only one window. Again this is probably due to SDL just being crazy dated.


3) You can't toggle between fullscreen and windowed without trashing your entire GL context. Which means reloading all textures, etc.

I have a feeling SDL is more lightweight.

Lightweight as in better performance? I haven't experienced this.




EDIT:

Regarding use-the-lib-with-OpenGL, SFML makes this easier as a whole. One point in particular is that you can load images to textures directly and bind them with SFML's API. With SDL_image, iirc, you have to load them to a surface, pull the pixel data out of the surface, send it to OpenGL, then destroy the surface. Not really a big deal, but it's a more involved process. And I guess it's a performance issue (since you guys seem to be squabbling about that ;P)

Also regarding the Audio API. I'm not sure how SDL_mixer works, but if it uses SDL's audio API, then it's crap. SDL's audio API forces you to do all mixing in software (again partially due to the "one and only one" audio device it allows). Not the case in SFML.

[chrisname]

Disch wrote:

SFML on the other hand has ties to Qt and wxWidgets, so you can easily have a high performance game window with all the bells and whistles alongside a widgetry lib.

Yay :) I thought I'd have to be writing my own widget library, now I don't need to bother.

Disch wrote:

Lightweight as in better performance? I haven't experienced this.

I was just sort of guessing, since SDL does less. To me, that means it contains less code (although I guess it's a similar fallacy to "it's more expensive so it must be better"). SFML is better IMO, though.

[helios]

The problem is the SDL audio system isn't so much the API as the overall design it uses. Compared to something like OpenAL, it's really inflexible about what you can do or how you can do it. Double buffering is also rather crappy compared to a buffer queue. Too big and there's too much delay; too small and the sound becomes choppy.
SDL_mixer is alright as long as you don't try to get too creative. If you do, you'll find it crippling.

[ultifinitus]

What makes SDL more flexible than SFML? I can't think of a single thing SDL can do out of the box that SFML can't, whereas I can think of quite a few SFML can do.

Well for one thing I'm not required to use a class to display images. When you derive a class from sf::Sprite they declared their instance variables they declared them private. So you have to use it's methods for setting it's variables. No biggie, just inconvenient.

And really, the graphic interface with SDL is so bad you pretty much have to use OpenGL directly with it. Not to knock on SDL, but the graphic API is just crazy dated (blitting? dirty rects? really? Is this 1997?).

Yes, it is indeed dated. And while I haven't looked at the source of either library, I love the amount of example programs and tutorials available for SDL(none of which have I read, so the point is really moot) Though I definitely prefer SFML's documentation. which is fantastic.

With SDL, I feel it's more "flexible" which perhaps wasn't the correct word, because you are essentially creating everything from the ground up yourself. I love that- and as a programmer that's one of my highs. I felt like SFML's class system just did too much for me. But that's just personal preference.

SDL_mixer is alright as long as you don't try to get too creative. If you do, you'll find it crippling.

SDL fails for audio. SFML's audio library is much better. but overall I prefer other libraries for my audio anyways.

In all I'm crazy, and I like reinventing the wheel.

[Disch]

Well for one thing I'm not required to use a class to display images

Eh? Aren't you splitting hairs, here? I mean SDL just uses structs instead of classes.

When you derive a class from sf::Sprite

But why would you do that? I never understood why people did that. Sprite is a class to use, not derive from.

you are essentially creating everything from the ground up yourself. I love that- and as a programmer that's one of my highs. I felt like SFML's class system just did too much for me.

SFML does very little more than SDL in terms of "under the hood" stuff. It just uses more updated techniques. In fact SFML is basically a very thin wrapper around OpenGL to make it easier to use for common 2D tasks.

Just like SDL's SDL_Surface structure is a thin wrapper around DirectDraw surfaces... SFML's Sprite class is a thin wrapper around OpenGL transformations. All it really does when you draw a sprite is pass a bunch of vertexes to OpenGL and set up the world view matrix to match the given position/scale/rotation/etc stuff you supplied.

That's it. It's just taking the 3D OpenGL interface and wrapping it inside a 2D interface. It's not that it's "doing more", it's just that it's doing it smarter.

Besides if you want to do everything yourself, you can. You can ignore SFML's interface completely and just use straight OpenGL to render your scene (like you pretty much have to do on SDL anyway). In this scenario, SFML still trumps SDL because it does a better job of managing the OpenGL context(s), window management, and audio.

But that's just personal preference.

I guess that's true. Although I just can't help but see it as an opinion formed on false assumptions. =P

And while I haven't looked at the source of either library, I love the amount of example programs and tutorials available for SDL

Yes, that's about the only thing SDL has up on SFML. It's been around longer and therefore is more well known. I can't debate this point.

SFML's audio library is much better. but overall I prefer other libraries for my audio anyways.

Such as? I'm curious as to what other audio libs are available and how they compare to SFML. About the only one I know of is FMod, and it is crazy complicated (although very, very sophisticated).

In all I'm crazy, and I like reinventing the wheel.

Then why do you use any library at all? ;P Why not go straight to the source: DX / OpenGL.

[ultifinitus]

false assumptions

No assumptions were made. (sorry, I don't mean to be argumentative)

Then why do you use any library at all? ;P Why not go straight to the source: DX / OpenGL.

Sadly, I am. (going straight to the source, that is)

[Disch]

No assumptions were made

Then I guess I was the one making assumptions!

lol

[ultifinitus]

Ahh well, you're awesome regardless of our differences Disch.

Agree to disagree?

[Disch]

Right back at ya. That sounds good to me. =)

[chrisname]

I love the SFML documentation. SDL's documentation is ok, but I don't like the format as much.

As for OpenGL, I've been having a hard time learning it. I can't find any decent tutorials. The ones on nehe.gamedev.net are Windows-only and I don't want to use the Windows API. Also that guy uses loads of global variables unnecessarily and I don't like it. I think I've ranted about this before...

[ultifinitus]

As for OpenGL, I've been having a hard time learning it. I can't find any decent tutorials. The ones on nehe.gamedev.net are Windows-only and I don't want to use the Windows API. Also that guy uses loads of global variables unnecessarily and I don't like it. I think I've ranted about this before...

I felt the same way, NEHE is less than ideal. I actually think there are much better guides available. But I would recommend starting with 2d.

Here're the things you need to learn.

OpenGL is a state machine. I didn't truly understand what a state machine was before I used it.

A vertex is a point in space, (x,y,r) essentially when you make something in OpenGL you are using a collection of vertices to make the edges, and it will fill in the center (by interpolation)
-On this note:
to describe a square you'd say something like

Immediate Mode:

     glBegin(GL_QUADS);    //As a state machine, opengl will be drawing quads until you tell it to stop
        glVertex3f(x, y, 0);
        glVertex3f(x+sx, y, 0);

        glColor3f(r,g,b);  //The following vertices will be in the rgb color, and 
                           //everything after will be until we tell opengl something else

        glVertex3f(x+sx, y+sy, 0);
        glVertex3f(x, y+sy, 0);
      glEnd();

Essentially OpenGL is awesome, it's actually quite easy, and with a few resources you can learn really quickly. Here's my favorite link:

http://arcsynthesis.org/gltut/

This link teaches good Modern techniques, whereas NEHE is quite dated.

[chrisname]

Thanks :)
I've done the SFML OpenGL example and I managed to get it to draw two rotating cubes, but I couldn't really get any further than that. I'll look at your link when I have some free time (in a few weeks, I'll have a week off school).

[zwA4jE8b]

Fixed memory leak

HDC hDC = GetDC(hWnd);

	MSG msg;

	_game.game_getvars(hDC, hWnd);
	_game.game_setstate('i');

was...

HDC hDC;

	MSG msg;

	_game.game_getvars(hDC, hWnd);
	_game.game_setstate('i');

for some reason when I initialized the level without getting the HDC of my games HWND it caused a mem leak.

[Disch]

But then doesn't that reintroduce the jitteriness problem?

It's like with new/delete. Every GetDC must have a matching ReleaseDC. What's more, you should minimize the time between GetDC and ReleaseDC so the DC is "gotten" for the smallest time possible.

Really, you probably shouldn't be passing the DC around like that. Just pass the HWND around and when you need to draw, THEN GetDC(), quickly draw, and immediately ReleaseDC.


Or you could doublebuffer all your drawing and pass around an offscreen DC, then blit the entire thing to the screen every frame. This would also [mostly] solve the "#5" bug I mentioned earlier.

[Albatross]

I know I'm sort of reviving the SFML topic, but I'm a little bit worried how they haven't officially released a major version since July 2010. That's making me a little bit hesitant to use it for any projects, while SDL I believe is still under active development. Version 1.3 of SDL in the works right now.

-Albatross

[zwA4jE8b]

Thank you so much Disch for all the useful info.

I changed the code so only the hWnd is passed around. if a function needs to draw, it gets the HDC then releases it at the end of that function.

This should be good for now. I am interested in double buffering but do not yet know how to do it. I understand the concept though.

Updated media fire.

Oh and one bug that no one else noticed, you can change your direction while paused.

[zwA4jE8b]

@Disch
I was reading your post at http://www.cplusplus.com/forum/windows/35484/ and would like to know how I can implement this.

As you know there are a couple functions that draw. I am starting to think that because all the visible objects are RECT's I can make one drawing function and just send it the RECT and Brush to use.

//  TO ALLOCATE
// we'll make an 800x600 24-bit offscreen DC
HDC mdc = CreateCompatibleDC(NULL);
HBITMAP mbmp =  CreateBitmap(800,600,1,24,NULL); // width, height, 1, bit_depth, NULL
HBITMAP moldbmp = (HBITMAP)SelectObject(mdc,mbmp);


//  - now you can draw to/from mdc -
//Right here would I just do my FillRect(mdc, &someRECT, BlueBrush);

// TO CLEAN UP / DESTROY
SelectObject(mdc,moldbmp);
DeleteObject(mbmp);
DeleteDC(mdc);

And I saw this on another example

BitBlt(hDC, 0, 0, iWidth, iHeight, memDC, 0, 0, SRCCOPY);

Also I am thinking that the functions that currently draw should just fill _maingrid[][] and in the render function I should just redraw _maingrid, is that too much? or the correct way?

Or pass mdc around to the functions, draw to it, then draw it in the render function!

[Disch]

CreativeMFS wrote:

Also I am thinking that the functions that currently draw should just fill _maingrid[][] and in the render function I should just redraw _maingrid, is that too much? or the correct way?

This would be the correct way with most graphic APIs (SFML/OpenGL/D3D) because in those APIs you pretty much need to completely redraw the screen every frame.

However for WinGDI that isn't necessary. And in fact it would be slower than the alternative. You could do it that way. And your game isn't very demanding so it probably wouldn't slow it down. So if you want to do it that way, go ahead.

But, what I would do is this:

1) Create that offscreen DC like you're doing in your post (first 3 lines)

2) Keep that DC alive for the life of your program. Create it once at startup and destroy it once at shutdown. Don't keep creating/destroying it for every draw.

3) The drawing code you have now you can keep, just draw it to your offscreen DC instead of to the screen.

4) When all drawing is complete, get the screen DC, blit the offscreen DC to it, release the screen DC. This would be done once per frame.



Now you can break #4 up into smaller steps and only redraw the "dirty" portions of the screen, but that's more work than it's worth.

Also because WinAPI is extra-fun, there's actually multiple ways to get the screen DC. Which you use depends on what you're doing. For your per-frame drawing, you would want GetDC/ReleaseDC as you're doing now.


But if you want to fix the #5 bug, that's something else...

Whenever a window passes over yours, or whenever something else happens that causes the window contents to be disrupted, Windows will tell your program that it needs to redraw itself by sending it a WM_PAINT message. To fix the #5 bug, you'll need to catch the WM_PAINT message in your message handler and redraw the window.

This is pretty easy if you're using an offscreen DC, since you can just blit over the contents to the display. Easy peasy.

The goofy thing is, you can't (or rather, shouldn't) use GetDC to get the screen DC in WM_PAINT messages. If you do, it will still draw correctly, but it'll have other consequences...

In WM_PAINT, you should use the BeginPaint and EndPaint functions to get/release the DC. The reason for this is twofold:

1) Windows clips the DC it gives you so that you'll only draw the portions of the window that need to be drawn.

2) Using these functions effectively tells Windows "okay, I redrew the window. Everything is OK now". If you don't use these functions, Windows will keep thinking the window is dirty and will send you a never-ending stream of WM_PAINT messages -- causing your program to draw the same thing over and over and over again.

But of course BeginPaint/EndPaint should only be used in response to a WM_PAINT message. So for other drawing to the window outside of WM_PAINT, you would want to use GetDC/ReleaseDC instead.

-----------------------------------

Albatross wrote:

I know I'm sort of reviving the SFML topic, but I'm a little bit worried how they haven't officially released a major version since July 2010. That's making me a little bit hesitant to use it for any projects, while SDL I believe is still under active development. Version 1.3 of SDL in the works right now.

SFML is heavily in active development. SFML 2.0 is actively in the works and you can get the latest version of it from the website. It's updated maybe once every week or two. It's stable and works great -- the only reason it hasn't been an official release is because he's still making changes to the API, so if you use the WIP version and then update it, it might break code that uses earlier versions.

I'm a semi-regular on the SFML forums, and from the looks of it, he's working out the details for the new graphic API, but once that's done and the code is complete, SFML 2.0 will effectively be done and released. IIRC it was projected to be another month or two.


On the other hand... SDL has been at version 1.2 since I used it last, which would have been at least 5 or 6 years ago. (Actually -- checking the timestamp on the SDL download page, it looks like the last update was 2001, so make that 10 years ago)