FUSION OpenGL Framework

FUSION
Unregistered
 
Post: #1
I came across this site a couple of months ago while looking for something. It looks like a great site for Mac game developers!

I've been making desktop applications for the Mac since the Mac Plus days, but recently decided to take a look at OpenGL programming. I've just finished an OpenGL application framework for the Mac that I call FUSION. Based on posts I've seen on this site, I believe others may like to use it as well, for both game development, and perhaps as a teaching aid.

I would like to clarify, I know very little about OpenGL. The knowledge required to write a framework depends more on the Mac O.S. then OpenGL.

Projects are included for Xcode and Metrowerks CodeWarrior, and can build targets for Classic pre-Carbon, Carbon, and Universal Binaries that will run on Intel and PPC processors. The framework is written entirely in C. At the basic level, the developer of a FUSION based application or game need only fill in the blanks for function handlers to calculate and draw frames, process events, etc. No knowledge of the Mac O.S. is required. Please refer to the included Read Me files for more information.

I hope this proves useful to some people!

Cheers!

FUSION 1.0

P.S. Hi OneSadCookie! From the few times I've been to this site, you've stood out as someone who seems very knowledgeable and helpful, so I just wanted to say greets! Grin
Quote this message in a reply
FUSION
Unregistered
 
Post: #2
Hello?..... Hmmmm........ This thing on?

It's been two days since I posted my FUSION framework, and I am just wondering if anybody has looked at it. A lot of work went into it and I assure you it is quite well written, as long as you desire, or are willing, to work in Carbon.

The only real drawbacks are that it is Mac only, and that it makes use of some deprecated functions, which is unavoidable since it can create OS 9 builds as well. Perhaps I will make an OS X only version in the future that will eliminate the use of deprecated functions, and greatly simplify the code. (I've programmed on the Mac for over 20 years from system 6 to system 9 and can't help but write code to still work for it. Wacko I've won 3 Eddy Awards for my work back during System 7 days, one for an animation program, and two for a multimedia presentation program.)

The reason I wrote FUSION, is that when I first decided to venture into OpenGL, the first thing I looked at is GLUT, and I was quite disappointed with it. I found it more difficult to use then it needed to be, and that it wasn't as flexible or as fully functional as it could have been. FUSION is designed to be as easy as possible to use for new programmers, and programmers that are new to the Mac. At the basic level, they need only fill in blank handlers in the file Game.c to handle drawing, events, etc., and need no Mac know-how at all beyond opening a project in Xcode.

FUSION allows you to open multiple contexts in windowed and/or full screen mode at once, and will produce the most accurate, and fastest, frame rates possible. This comes at the cost of being a CPU hog, but allows even the most intensive games to run at their full potential.

Anyway, sorry for all the babble. Smile I just wouldn't mind some feedback is all. If you download it, try building and running the Tester application that comes with it. Open multiple instances of it (via File/New), experiment with the menu options, left-click to add more sharks, right-click to remove them, play with the scroll wheel, type on the keyboard, press modifier keys, and you can see how FUSION handles things. Any context can go full screen by pressing cmd-f, and you can even set multiple contexts to full screen mode at once if you have more then one monitor.

Hoping to here some feedback,

Cheers!
Quote this message in a reply
DoG
Moderator
Posts: 869
Joined: 2003.01
Post: #3
Don't expect to be rushed with praise immediately. These things need time to sink in. Smile

Now, it seems like your app is running, but: The cursor is just a white square, is that intentional? Also, you have a bunch of resolutions hard coded which are practically useless.

To be frank, I appreciate the mac-likeness, but i am not too thrilled with what things look like under the hood. A good starting point, it is, but not much more. It not being cross platform also severely limits its usefulness. If you want easy UI on the Mac, you can just code with Cocoa, no need for another wrapper around the OS.
Quote this message in a reply
FUSION
Unregistered
 
Post: #4
Hi DoG! Thanx for some feedback! Smile

One of the context flags is to hide the cursor while in the context's content. Tester has a menu option to turn this off and on. The white square following it is simply to test mouse tracking.

The base framework comes with a simple rotating square and some sample menu items, including the Resolution menu. The sample menu items can be turned off in the code. FUSION includes an API to add your own custom menu items, and the Resolution menu (and some others) was added this way. With sample menu items turned off, the only menu option hardcoded to be in all applications is About, Quit, and Full Screen.

Although nobody minds a little praise, I was just hoping for a little feedback. Hoping things worked for others et al. Smile

I did find one minor bug since I posted it. In Tester, if you select a menu option that requires a new window to be created for the context, the framework forgets the current context (menu items related to the current context are disabled) until you click in one again.

Thanx again!
Quote this message in a reply
Member
Posts: 204
Joined: 2002.09
Post: #5
General feedback:

As DoG said, there's simply not much under the hood here. It seems to be a nice application wrapper to get something quick up in OpenGL. This puts it in the realm of helping beginners to OpenGL on the Mac, which puts it in competition with GLUT. As noted, FUSION is not cross-platform (although my little looking internally it seems like it could be made cross-platform in the future), so it loses ground to GLUT on that point. However, there's a lot lesss code in FUSION than GLUT, so for people looking to build their own wrapper FUSION might be a good place to start.

With that said, FUSION is most likely to appeal to beginners (anyone else has already faced these issues and have them sorted out by now) who want to start building their own "engine". This is a very small target base, which is probably why you have't received much feedback.

What can you do to improve FUSION? Cross-platform is a possibility, although for me that's not a big issue. You might want to start incorporating things like physics (ie, ODE), CoreVideo/CoreAudio, etc. This will get you out of the realm of competing with solely GLUT, and provide a little more meat to your burger.


Specific feedback:

Your demo eats up 80% of my cpu when not-FPS capped (garnering 200-400 fps). However, when FPS capped at 30fps, it still eats up 80% of the cpu. One would assume that if you're doing 1/8 the amount of work, it should use 1/8 the amount of system resources.
Quote this message in a reply
FUSION
Unregistered
 
Post: #6
Hi KittyMac! (Cute name! Wink )

Being a beginner to OpenGL myself, FUSION is mainly aimed at beginners, eliminating the need for Mac know-how. It is in fact meant to be a replacement for GLUT, for those who don't like GLUT, or who want something that's easier to use and more flexible in many ways then GLUT. GLUT is the only thing I was aiming to compete with. I will never make FUSION cross-platform, because if aren't using a Mac, you're using the wrong computer! Smile Kidding aside, I simply have no interest in any platform other then the Mac, so if you wish to be multi-platform, FUSION may not be for you.

FUSION is a framework only, not an engine. It does however allow a person to create their own engine without worrying about the Mac specific overhead. FUSION by itself will never include engine features such as those you suggested.

Yes it is a CPU hog, in order to allow more power and flexibility. FUSION requests as much CPU time as possible regardless of frame rate or how much is being drawn. Frames are handled in two steps: calculate frame, and draw frame. If a game overtaxes the system, and it can't keep up, multiple frames can be calculated before a new one is drawn. This way, a game will never fall behind timing wise. For example, if a game was set to 60 frame per second, but was taking 1/30th of a second to draw, a one step method would actually take 2 seconds to handle 60 frames. With my method, all 60 frames will be calculated in one second, but only 30 of them would draw. Think of it this way: drawing frames is something that is only performed when time allows. Technically, no drawing need ever take place and the game would run just fine, although the user may have a tough go figuring out what to do! Smile

Another thing, FUSION will calculate the next frame right after one frame is brought to the screen, then request a draw (time allowing) which will draw into the offscreen buffer. This way, when the time comes to actually bring the next frame to the screen, it is already prepared and can happen instantly. This allows for very accurate timing.

I could allow Timer Events to perform the timing, thus freeing up CPU time, but then I could not do all the things I've mentioned. For small simple games this would probably be preferred, but even though FUSION is aimed at beginners, it was designed with the thought in mind of running a single context in full screen mode and being able to tax the system to it's fullest potential.

I really should remove all OS 9 support though, which would greatly simplify the code (especially when it comes to full screen support. I wish CoreGraphics was around in the OS 9 days. Wink ), eliminate the need for use of deprecated functions, and replace the few resources it uses with nibs. Perhaps then I'll add an option to perform one step frame handling and use TImer Events to perform the timing, for use with small games that this would be satisfactory for.

Thank you kindly for the feedback!
Quote this message in a reply
Member
Posts: 204
Joined: 2002.09
Post: #7
FUSION Wrote:Yes it is a CPU hog, [snip everything in the middle] With my method, all 60 frames will be calculated in one second, but only 30 of them would draw....

I looked in your code, and you have support for time-based animation (although your tester demo doesn't use it). The advantage of time-based animation is that you can do one big update before each drawn frame. For simple games without networking or "other things to do which might not wait", this makes perfect sense. Why waste CPU time calculating frames which the user never sees? More importantly, why waste the battery life of your laptop using customers on frames they never see?

Quote:I could allow Timer Events to perform the timing, thus freeing up CPU time, but then I could not do all the things I've mentioned.

That is a falicy... you can do everything you want and still use timers. Even "big" games use timers :-p
Quote this message in a reply
FUSION
Unregistered
 
Post: #8
FUSION was actually designed with time based animation in mind. The sharks in Tester were intentional frame based, which is stated in the Tester Read Me file.

FUSION does use timer events btw, it just that it specifies a timing of kEventDurationMicrosecond, then performs its own timing from there.

You are absolutely correct; a properly written game would look at how much time has actually passed, then update accordingly. I suppose I over-killed things by removing the need for the programmer to worry about this, although I still prefer the idea of separating frame calculation from frame drawing. FUSION does allow you to do it in one step if you prefer, by specifying a frame rate of 0, and then you can handle things according to the current time, which is supplied to you.

But I definitely agree with you, and will change FUSION to let timer events do the timing. Thank for the helpful feedback!

BTW, I just noticed the Big Bang Board Games link in your sig. I've been playing them between between posts! Wink
Quote this message in a reply
DoG
Moderator
Posts: 869
Joined: 2003.01
Post: #9
Note that if you use a busy loop, the scheduler will lower your process's priority because it hogs the CPU, which might lead to worse performance than using timing and a sane framerate.
Quote this message in a reply
Post Reply 

Possibly Related Threads...
Thread: Author Replies: Views: Last Post
  Multimedia Fusion 2 and iOS Export Module Jeff_CT 0 4,448 Aug 24, 2011 08:26 PM
Last Post: Jeff_CT
  FUSION 1.1 OpenGL Framework FUSION 0 2,606 Mar 18, 2006 12:47 PM
Last Post: FUSION