PDA

View Full Version : SimpleGameFramework


TomorrowPlusX
2006.11.17, 04:40 PM
So, now and then a few people have asked for my gui code -- which is pretty flattering to be honest.

So, I'm offering it up. The trouble -- or the advantage depending on your viewpoint -- is it comes with a buncha buncha burning other stuff. The whole framework is called SimpleGameFramework, or SGF for short. It's all the malarky which I found myself copying and pasting into different opengl projects and wishing I had as a single basecode.

First, attributions where they belong:

1) The Cocoa toolkit is based off of OneSadCookie's GameShell. It's not 100% GameShell, by any margin, but that's what I started with.

2) It uses a number of open source 3rd party stuff. SlotSig for signal slot event dispatching, GLEW for opengl extensions checking. And libPNG, since I couldn't find libPNG in /usr/lib or wherever and so I had to statically link it in. Oh, and boost, for their smart pointers.

Second, the stuff SGF offers:

1) A basic GLUT like approach, but for C++ -- e.g., subclass sgf::Application and override display() and step(), and other methods for input, or whatever. You can specify at bootstrap time whether you want it to run in "GameMode" or "ApplicationMode" -- the only real difference is that game mode captures full screen when going fullscreen, and lets you use an emulated mouse ( where SGF draws the mouse ). ApplicationMode is more desktop friendly, and lets you integrate cocoa controls ( you basically treat it as a nib-based Cocoa app ).

2) Some useful basic math/geometry stuff, like vec2, vec3, vec4, mat4, quaternion. An AABB class for bounds, and a frustum class which can check to see if AABBs would be visible. A camera class which generates frustums, and can be easily positioned, change FOV, etc.

3) Texture loading, texture management, as well as FBOs -- you'll note that sgf::FrameBufferObject and sgf::Texture derive from sgf::TextureInterface -- which is pretty convenient.

4) Path management. Look up stuff in the app itself, or in packaged bundles, etc. Useful.

5) the sgf::glsl::Program class which makes it easy to load programs from file or string, including macro substitution before compiling. the sgf::glsl::Uniform<T> class which makes it stupid easy to manage uniforms. And the sgf::glsl::Attribute class which makes it stupid easy to manage vertex attributes. I also have convolution mechanisms whereby you can dynamically gaussian blur a texture on the GPU at runtime. I do this with the reflection in my water demo. This makes me happy.

6) a FilterStack API which makes it easy to run full-screen postprocessing filters using glsl.

7) a classloading mechanism for C++. Works for classes compiled into the executable, as well as classes compiled into bundled frameworks and plugins. You can see its usefulness in the Filters demo app, which uses classloading to load filters from SGF.framework, from a packaged bundle DemoFilters.bundle, and from Filters.app/Contents/MacOS/Filters executable directly.

8) An xml-like-but-simpler file format reader/writer with SAX and DOM access. I modeled the DOM access off of TinyXML's approach where it's really easy to lookup the value of a deeply nested child without needing to check each branch. Very easy to use, and the file format is very easily human readable/writable. There's not much likelyhood you'll use this, but I like it.

9) Simple timers. Easy to use, and whic huse signals to register timeouts.

10) A reasonably useful GUI api. With layout management, basic widgets, and primitive themeing. Well, not really. You can swizzle colors, border/background styles, & fonts, but if you really want to change appearance you have to subclass widgets. Plus, I have a render-to-texture hud subclass which lets you mount a fully functional GUI on a surface in your game world. See the WorldHud demo for how to do this.

11) And bugs! Almost certainly. But writing the demo apps helped me track a lot down. I'm porting my "WorldEngine" to use SGF ( SGF came from WorldEngine's toolkit ) and so far it's smooth. I know of one big bug only -- antialiasing only appears to work on my ATI x1600, this is due to my FilterStack system, which makes a lot of use of glCopyTexSubImage, and apparently that doesn't play well with most gl cards/drivers.

12) Doxygen documentation. I'm no master documenter, and I don't know doxygen's ins and outs, but the documentation is good enough that I keep it open all the time while I use SGF to write apps.

You can download it here: http://zakariya.net/shamyl/etc/SGF.zip

If you find bugs, please let me know. If you find it useful, please let me know!

Finally, you'll need to install boost to compile any of this. The projects look for boost in /usr/local/include/boost. SGF doesn't link against it, but needs the headers.

Some screenshots:

AppMode ( Cocoa GUI )
http://zakariya.net/shamyl/etc/SGF_AppMode.png

Filters ( Loading filters via classloader from various sources )
http://zakariya.net/shamyl/etc/SGF_Filters.png

Text display ( displaying entire Matrix FAQ, yet is Teh Snappy, link because it's wide )
http://zakariya.net/shamyl/etc/SGF_Text.png

Water ( lots of GLSL lovin, as well as real-time gaussian blur of reflection )
http://zakariya.net/shamyl/etc/SGF_Water.png

Interactive GUI displayed on a surface on the world -- same app as "AppMode" above, but in GameMode and with a glow filter.
http://zakariya.net/shamyl/etc/SGF_WorldHud.png

AnotherJake
2006.11.17, 05:18 PM
Cool man! It is super awesome that you finally let the cat out of the bag. :D

Malarkey
2006.11.17, 05:25 PM
SimpleGameFramework, or SGF for short. It's all the malarky which I found myself copying and pasting into different opengl projects and


Eh? Did someone call? :) Sorry, I just had to say it. Also, I'm glad to see you release this project. I've done two UI engines for my work so far, and I'm looking at adapting the second one I did into yet a third one (the second one was for hand-held gaming devices) so this will certainly give me something to look at.

TomorrowPlusX
2006.11.17, 05:34 PM
One thing I forgot to add: This isn't a game engine, it's just my basecode for windowing, input, and other stuff. I'm posting it because people have asked about my GUI code, and I'm happy as a clam to share.

aarku
2006.11.17, 08:18 PM
This looks awesome! Thanks for sharing. What is the license on it? (Obviously the licenses for the 3rd party stuff you use are known)

Cheers,
-Jon

TomorrowPlusX
2006.11.18, 11:15 AM
The license is the "Do whatever you want with it" license.

The only addendum to the license is that if you make good use of it, please reference me in your about box; or if you're ever in Washington DC, you can buy me a beer.

Duane
2006.11.18, 01:10 PM
you are my hero. You just made my day that much brighter.

Nick
2006.11.24, 01:11 AM
I'm going to try and use the UI code from SGF (I compiled the framework and am just including <SDG/UI.h>). Is it possible? Am I going to run into any big set-backs? Eventually I hope to go through and just include your UI into my project (with credits of course) so I don't have to use the whole framework (6.6MB and all I'm using is the UI code), but for now I figured this way was easier.

PowerMacX
2006.11.24, 10:30 PM
Ahh! New toys! :D So little time to play... :cry:

I hope I can do some experiments with this before the next big contest comes up!

TomorrowPlusX
2006.11.25, 12:48 PM
I'm going to try and use the UI code from SGF (I compiled the framework and am just including <SDG/UI.h>). Is it possible? Am I going to run into any big set-backs? Eventually I hope to go through and just include your UI into my project (with credits of course) so I don't have to use the whole framework (6.6MB and all I'm using is the UI code), but for now I figured this way was easier.

If you want to use just the UI, you'll have to build a custom framework -- or, more easily, compile a static library. Then Xcode will only link in what parts you're actually using. Mush easier.

Off the top of my head, the UI code requires everything in /core... so you'll need all that. You can separate ui::Hud from Application, but you'll need to manually feed it input events.

Good luck!

Duane
2006.11.25, 09:52 PM
why don't you just include the headers to boost? :p

TomorrowPlusX
2006.11.27, 10:22 AM
why don't you just include the headers to boost? :p

I'm of the opinion that if you do C++ programming, you should already have boost installed :sneaky:

Frank C.
2006.11.27, 01:42 PM
I'm of the opinion that if you do C++ programming, you should already have boost installed :sneaky:

Some of us don't do much C++ but would still like to check this out - how 'bout some pre-built binaries :D

Personally if I download an Xcode project and it doesn't build immediately (or requires installing crap into the system) I usually don't bother with it. At the very least you should stick a little readme in there that lists the dependencies. I don't want to diminish your contribution - this looks very cool, and I like open source stuff, but I like it more when it works out of the box ;)

TomorrowPlusX
2006.11.28, 09:24 AM
Some of us don't do much C++ but would still like to check this out - how 'bout some pre-built binaries :D

Personally if I download an Xcode project and it doesn't build immediately (or requires installing crap into the system) I usually don't bother with it. At the very least you should stick a little readme in there that lists the dependencies. I don't want to diminish your contribution - this looks very cool, and I like open source stuff, but I like it more when it works out of the box ;)

Well, that's fair.

I did some major work on it over the weekend, after discovering boost::enable_shared_from_this<T>, which allowed me to rewrite my gui api and my manifest parser to use boost::shared_ptr ( and weak_ptr ) for everything. Which is great, because it allows for much more robust memory management. So, here's what I'll do when I get to work ( and have a fast internet connection ):

1) I'll include the boost smart_ptr headers, and I'll tweak the build in that package to use the bundled headers.

2) I'll include pre-built universal frameworks and demos.

3) That's it, actually. But if you want to actually write an app using SGF, you'll have to use those boost headers.

A final note: I understand the whole "I don't want to install some extraneous crap" bit, but frankly, boost is to C++ what Foundation.framework is to ObjC. If you're doing C++, you really ought to have it, and it takes all of 10 minutes to install. It's a few more steps than a ./configure && make && make install, but not much more. If you have fink or darwinports it's probably a one-liner.

Final, final note: I installed subversion on my machine a couple weeks ago. It's wonderful to manage my code this way. I'm very content.

PowerMacX
2006.11.28, 10:00 AM
A final note: I understand the whole "I don't want to install some extraneous crap" bit, but frankly, boost is to C++ what Foundation.framework is to ObjC. If you're doing C++, you really ought to have it, and it takes all of 10 minutes to install.

Particularly considering that many of boost features will be made a standard part of C++ 09 (maybe):
http://www.devsource.com/article2/0,1895,2061094,00.asp

TomorrowPlusX
2006.11.28, 02:53 PM
OK, I updated SGF to include the boost headers, and it comes with a pre-built universal SGF.framework and all the demo apps ( again, universal) . The download is quite a bit bigger, now ( ~42 mb ) as opposed to 10 before.

As I mentioned above, I made a few changes to the GUI code to use boost::shared_ptr extensively. It ought to be significantly more robust now than before. This results in small changes to how you write the GUI code but it's easy enough to look at the demo code to see the difference.

So you know, the difference is minor. Before, you'd create a widget more or less like so:


Button *foo = new Button( parentWidget, "Foo" );


Now, since shared_ptr cannot point to 'this' in a constructor, the code above now looks like so:


ButtonRef foo = Button::create( parentWidget, "Foo" );


Basically, that's all that's different. The constructors for the various GUI tidbits are all private now and instead you use a static factory method. The tradeoff is better ( essentially automatic ) memory management.

Frank C.
2006.11.29, 01:53 PM
Much better :)

The UI stuff is very cool indeed - I'm sure the other stuff is cool too, but my aging Mac can't handle FBOs.

TomorrowPlusX
2006.11.29, 04:49 PM
Much better :)

The UI stuff is very cool indeed - I'm sure the other stuff is cool too, but my aging Mac can't handle FBOs.

If it helps you out, I've done what I intended to do :p

I probably ought to add a flat-out disabling of the filter effects for older machines. Right now, even if you have no filters running, it still captures the backbuffer each frame, so that when you call sgf::app->pause() it bypasses normal rendering and just displays the last rendered frame.

ootoovak
2006.12.14, 03:11 PM
Wow TomorrowPlusX,

I must say that is really well done. I can't believe the water looks so realistic, and it's done in real time ... on my crappy machine! Also the HUD is very well designed, looks quite professional. I hope you or others find some very interesting things to do with this framework.

Sam

Duane
2007.08.16, 05:11 PM
Sorry, don't mean to bring this thread up again, but I'm going to port the gui stuff-JUST the gui stuff-to objective-c for the inkubator stuff.