OpenPowder: The Powder Toy Remake

[ss2man44]

I see that you're using both SDL and C++. You know that SDL is a bit outdated to be using with C++, right? I personally prefer SFML, not only because it's faster, but because it's easier and object oriented. Try not to include stdout.txt in the binary release or include the dist directory in the SVN. Also, if you need help, I'll be glad to seeing as I need the practice with C++ and graphical programming.

EDIT: Oh God... which is newer, lagger1 or src? And what kind of name is "misc.h" for a header file?

[Zcool31]

Thanks for the suggestion. SFML seems like a decent library to use, and perhaps sometime in the future I might even consider switching the game over to it from SDL. The way it's written now, it shouldn't even be so difficult, except for changing the names of a few function calls.
On the other hand, the reason SDL hasn't changed for a good amount of time is because it doesn't need to. Why fix what's not broken? And I already know how to use SDL, and the window interface isn't even close to the top of my list of issues to fix. I'd first like to get the game stable, believable, and optimized.

Having looked at some SFML source code, I get the impression that it tries to do too much for me. For example, when I try to draw text, I must specify the scale and position in the function call. Then SFML stores essentialyl the entire OpenGL state, transforms/scales the view based on the parameters I passed, draws the object, and then restores my OpenGL state.
In theory, this is pretty nice. In practice, it's a great big waste of time for my processor. Generally, when I want to draw text, I do the OpenGL transformations myself before I make the function call, which I expect to simply render the text without modifying my OpenGL state.
All of the SFML primitive drawing functions are simply wrappers around OpenGL functions that basically do the same thing. The containers for polygon data seem nice. But If I want to draw something, I can just use OpenGL myself.

The one big reason I've been using SDL all this time is because it doesn't try to do too much. It's one goal is to provide a simple, completely portable interface to platform-specific stuff. They say themselves that for most platforms, SDL is just a wrapper around that platform's API. This is exactly what I need. This is the only thing I need.

The #1 goal of Openpowder is to make an awesome Powder Toy Clone that is open source, moddable, and extensible.
The #2 goal is to learn. I won't learn too much by having things done for me. SDL only does the bare minimum. In fact, many commercial games use SDL (Quake 4 used it for keyboard input). This is just fine, it's exactly what I need. And lots of people use it. That's good enough for me.

[ss2man44]

Ah, well then I respect your decision, but I will point out that SFML can be interfaced with OpenGL. I'm not much of an OpenGL person so I really don't know how important that is, really. But I know it can do it!

All your other points are valid, too, but I still want to know which of the two folders is newer.

[akuryo]

Originally Posted by ss2man44

I see that you're using both SDL and C++. You know that SDL is a bit outdated to be using with C++, right? I personally prefer SFML, not only because it's faster, but because it's easier and object oriented. Try not to include stdout.txt in the binary release or include the dist directory in the SVN. Also, if you need help, I'll be glad to seeing as I need the practice with C++ and graphical programming.

EDIT: Oh God... which is newer, lagger1 or src? And what kind of name is "misc.h" for a header file?

I second this.

SFML is a lot more complete(graphics, sound, threads, sockets...etc) and faster(from what i've heard).

Now, you do not like when things are easy, and wrapped in nice little shiny packets you just have to use. Well i'm totally with you, but SFML is not about that.
But ss2man4 is right, it is interfaced with openGL, and you do not even imagine how fun it is to make 3D using pure openGL, but still has that little support that lets you use fonts(writing things on the screen with pure openGL is hard... really).

Also, no i didn't have the time to look at the code, but i'll do soon, the fact that it's using SDL doesn't help, i haven't use sdl for years(since i switched to sfml).

If i've got some time i'll maybe try to rewrite it on sfml, i think this will really helps you to learn how to use it pretty quickly.

Also, you talked about multithreading for the game. Yeah, if the project goes serious, threads will be necessary, because it's a great push for any multicore computer(which is the majority today). Now i don't know about SDL, but SFML is really great with it. It's a lot like using windows threads, but since it's designed to be crossplatform, well, you don't have to worry about those other platform, or not as much.

It's early, i didn't sleep well, my english is probably at it's suxiest.

edit : I think SDL is openGL based too actually, just don't know if it's as easy to use in the same time.

[Zcool31]

It was never an issue that SFML wasn't OpenGL based, I know that it is. In fact it uses OpenGL for pretty much all of its graphics functions. SDL is also really easy to integrate with OpenGL, except that it it hands you the control stick the moment you have a window and a framebuffer. It's up to you to set up the viewport and the projection matrix.

I see that you took a look at the folder structure. I know it isn't very well organized. Within SDL_APP/ there are three folders.
/dist is old and outdated. It shouldn't even be there. I thought at one point I might be using that to have an up-to-the-minute binary available to anyone with an SVN client, but it doesn't work too well when I try to do a commit on the changes that my partner tries to do (none at all).
/lagger1 is a really old and broken experiment. Don't even bother looking at it. I've done at least 2 major recodes since then, and I don't ever intend to use it again.
/src is where it's at right now. This folder contains the latest source code.

Now, if you want to look at how the game works, you'll need to look at PowderGame.cpp. That's where all the action is at. Don't worry about SDL because you won't see a single SDL function call in that file. IO_Manager is a separate class in a separate file that handles all the SDL stuffs.
"misc.h" contains all the miscellaneous stuff that doesn't have anything to do with one particular class. It's full of things that my entire program uses. It's where I keep my vector class (not the collection, the coordinates).

[Lazers]

Ze question worth asking is, should you switch to this SFML magic now, while this project is relatively simple, and save yourself the bother of switching a larger program across later? Or, you could just stick with SDL and do exactly that. Stick. Like a Stick. In the mud.

[ss2man44]

You know, you'd still benefit from switching to SFML at this point because if you do want its object-oriented-ness and faster drawing than SDL (Yeah, benchmarks show that SFML is somewhere in the thousands percent faster than SDL at drawing), it's right there for you to use it.

You can still do all that fancy OpenGL stuff without SFML getting in the way because you can use it as just an event manager like you seem to be using SDL as.

[Abolish666]

Mac version? ):

[samysam]

Originally Posted by Abolish666

Mac version? ):

Just no.
not now atleast

Back to the smart talk
I find it an interesting read

[flyboy95]

Originally Posted by Abolish666

Mac version? ):

It's open source. Learn to compile.

[Lazers]

Well, I'm for this project to be switched to SFML. All we gotta do is convince the developer dude. Zcool?

[Zcool31]

If any of you have actually bothered to look at my code, you'd see that the actual game doesn't make a single SDL function call. This is left to be taken care of by another object dedicated to window management and SDL stuff. So switching this to SFML means that I just have to change the implementation of my SDL handler object. The interface to the game code (the stuff that handles physics) will remain exactly the same.
So at this point, and further down the line, it is equally easy for me to switch from SDL to any other OS interface. I could, right this second, switch to Win32 API, and it would be no more difficult than switching to SFML. I say this because the game itself doesn't change, only the interface. And the only difficulty with doing this is learning the new interface.

Next, what gave you the idea that SDL is slow at drawing? An OpenGL function call using SDL is no different from an OpenGL function call using SFML, or Win32 API, or GTK, or whatever Mac uses. That's the beauty of using OpenGL: it's just you and your graphics card. As long as your platform has good drivers, it doesn't matter what your code is compiled for, or what interface you use.
What you probably mean is the default SDL drawing functions. If you did, then you're right. The default SDL_draw function calls access the framebuffer directly. They're pure software, no hardware acceleration at all. So basically, they are painfully slow. That's why I don't use them.

The thing is, once you get past the superficial interface differences, SFML is really nothing more than a shiny OOP wrapper around what's basically SDL. Sure, you have your fancy classes that use inheritance and polymorphism, and you have your custom types in their pretty little namespaces. But I look at the actual function list, and except for built in text support, I don't see any real benefit.

On the other hand, in the future I might offer two versions of the game, one SDL and one SFML. You could run them side by side and see how they're absolutely identical.

[akuryo]

Hmm, i don't know how to explain that...

Of course openGL is really pure, and that's what makes me love it so much(and you too apparently), but it IS possible to make it faster than how you would normally use it.
For example, just random : threads. Imagine if SFML used directly threads in it's graphic "wrapping". Well, it WOULD be faster. Faster than basic use.

Now i don't think it actually does use multithreading directly in that, but it probably optimize the whole things in many other way.

if you use pure openGL(and by that, i mean that you could run the game WITHOUT including any SDL .dlls) then ok, great.

But please, take some minutes(yeah, it's not much really) to learn how to use SFML graphics instead of SDL.

Better for you, better for the players(speed) and better for us, little developpers avid of juicy sources.

[wakkydude]

I had no idea on what was going on. So I quit.

[Zcool31]

Ok, I'll stop flaming SFML now.

Here's what I'll do. Right now, and probably on the near future, I'll focus on the game simulation. I need to get the physics to be more stable and less bugged. I'll also re-organize my code into objects to make it as modular as possible. Once the underlying game engine is at least reasonably usable, I'll port to SFML. After that, I'll make a nice, shiny GUI, and start planning scripting support.

Now, I'll be working on the game engine this weekend, and a good bit next week. I'm not going for too many features, but stability and un-bugged-ness is my #1 priority right now. So chances are high that by this time next week I will have already ported to SFML.

I'm sorry that I haven't been able to release a new binary lately, but I haven't had too much free time with "exam hell", at least one exam per week throughout April and May. But you can expect one really soon. Check http://code.google.com/p/openpowder/ for updates, and I'll try to keep the first post up to date as well.

[Eavan]

I am absolutely compelled to say, that SFML is a hell of a lot faster than SDL.

Here are some pretty significant benchmarks to back me up. There is a single benchmark that supports SDL's speed, but all the others show that SFML is crazy fast compared to SDL.

[Zcool31]

I'd love to have a look at the source code for those benchmarks. I hope you all know that by default, SDL doesn't use OpenGL, but rather it uses pure software and changes the framebuffer directly. SFML uses OpenGL by default. So if you just use the default, built-in drawing functions then yes, default SFML is as much faster than SDL as is pure OpenGL. Though I can argue that pure OpenGL is a small amount faster than SFML because you don't have any overhead at all.

[zamadatix]

http://sfml.sourceforge.net/temp/bench-sdl-sfml.zip for the source of those but if you are drawing the minimum you need with opengl i cant see how it would matter if you used one or the other.

[ss2man44]

You know, I would have already ported the IO_Manager class to SFML, but I can't get any of the program to compile. It's giving me endless errors with both MinGW and Visual C++ 2008.

It could be SDL-related entirely, so I might just go ahead and replace all the SDL code with SFML and see if it compiles then.

EDIT: I'm also on Mac right now so I should see if I can compile it for Mac while I'm at it.

[Zcool31]

Oh, you just have to link your project with mingw32.a, opengl32.a, SDLdll.a, and freetype2.a. Just go to project properties -> c++ -> linker -> libraries and add those library files to the list. For me they're in C:\Mingw\lib\.

[ss2man44]

Didn't your mother teach you about whitespace? This is painful to read. I'm about to scrap the IO_Manager class as a whole and rewrite it.

[Another CPP Programmer]
[ACPPP]: Tell him another cpp programmer
[ACPPP]: wants to slap him for his painful use of templates

... yeah.

On the plus side, I never would have figured out how to do the particle physics. That's the main reason I wanted to look at the source in the first place. Good job on everything but the code quality.

[Zcool31]

Hahahah lol. IO_Manager was meant to work as sort of like a mini-window-manager. But that's too far off. What about my painful use of templates? Which class might you be talking about?

What's whitespace? To me it's just space in my code that doesn't do anything. Just a waste of memory (in my brain).

Actually, the particle physics are one of the things that are actually pretty broken right now. The fluids, on the other hand, I am quite proud of. In any case, I'm in the process of a re-code. It won't affect the Game<->IO_Manager interface at all, so as long as the same functions do the same thing, feel free to change it up as much as you like. Send me the code, and if it's nice, you're getting permissions for the project to commit code.

[ss2man44]

Originally Posted by Zcool31

Hahahah lol. IO_Manager was meant to work as sort of like a mini-window-manager. But that's too far off. What about my painful use of templates? Which class might you be talking about?

What's whitespace? To me it's just space in my code that doesn't do anything. Just a waste of memory.

She was looking at your misc.cpp and misc.h.

By whitespace, I mean empty lines separating relevant groups of code. It's important for readability, and readability is a useful thing to have when you're working in a team. Plus, what's one byte for a newline character?

[Zcool31]

Originally Posted by ss2man44

She was looking at your misc.cpp and misc.h.

By whitespace, I mean empty lines separating relevant groups of code. It's important for readability, and readability is a useful thing to have when you're working in a team. Plus, what's one byte for a newline character?

I'm not talking about memory, I'm talking about screen real-estate. When your code goes above 500 lines per file, you want to save as much space as possible. I'm considering writing entire functions on one line. You see that I already do that when the functions are short.

[ss2man44]

Originally Posted by Zcool31

feel free to change it up as much as you like. Send me the code, and if it's nice, you're getting permissions for the project to commit code.

Okay, but this might take a while. I'm not the fastest worker, plus I have school to focus on.