Help With A Prototype

Apprentice
Posts: 13
Joined: 2006.09
Post: #1
Hey All,

I have a game application that I just got up and running thanks to help from people on these forums. It is an OpenGL application. It is only a prototype at the moment, because I am not really using any specific objects to get things done. It is more of a test bed to make things work. Once I have a better understanding of how things work in OpenGL and Cocoa I will then start working on a foundation of classes that all items/entities will be based on in the game.

So, while in the process of working on this I have noticed a few issues that I need to get ironed out.

Here is a list of issues/questions I have in regard to my application:

  1. My animation seems to flicker and/or appear grainy. How can this be fixed? This might be caused by the images I am using for my sprites. They are .png files.
  2. My animation slows when another window is placed over my application window. What would cause that and how can it be fixed?
  3. Sometimes while firing bullets, some animations seem like they skip or slow for a split second. How can this be fixed?
  4. Using OneSadCookie's "Creating Mac Games" HTML book I was able to make my application display an image of the window while minimized in the Dock. But I want to be able to keep the animation going while minimized in the Dock and display it, not just display a static image. Think playing QuickTime window minimized in the Dock. How would I do that?


On to the application:
Instructions:
Right Arrow = move right
Left Arrow = move left
Spacebar = fire
P = pause

Known Issues:
Fullscreen mode (cmd-opt-f) does not work.

Please download the application, run it and give me any feedback you can. It is located on my iDisk public folder. The application is named "DisplayImageGL". The .sit file it is contained in is "DisplayImageGL-iDevGames.sit".

LOL! Yes, the graphics were highjacked from the web! Shock

NOTE: This application requires Mac OS X 10.4.

Here is a link to my iDisk Public folder:
http://homepage.mac.com/gdaniels/iDisk/

Here is a link to OneSadCookie's book:
http://onesadcookie.com/CreatingMacGames...ames.xhtml

Gerry

Quote:There is a name for people who are not excited about their work--unemployed.
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Apprentice
Posts: 13
Joined: 2006.09
Post: #3
OneSadCookie Wrote:http://sacredsoftware.net/tutorials/Anim...tion.xhtml

Ok, I have a question here, in regard to the information below:

Code:
while (updateIterations > UPDATE_INTERVAL) {
    updateIterations -= UPDATE_INTERVAL;

    updateGame(); /* Update game state a variable number of times */
}

http://sacredsoftware.net/ Wrote:The while loop runs a variable number of times, determined by the value of updateIterations. In your updateGame function, you should perform the necessary actions to update the state of your game world by one iteration.

So, if the player is issuing commands to the game (keystrokes), do I need to store these keystrokes up in a queue/stack and perform them in my updateGame() function, one keystroke command per interation? Once one keystroke is performed remove it from the queue or pop it off the stack?

I can understand the natural movements of other things in the game. I am just trying to figure how to handle user interaction in relation to this technique. Thanks.

Gerry

Quote:There is a name for people who are not excited about their work--unemployed.
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #4
Generally, you'll track key downs and key ups, and treat the key as being down for all updates between receiving a key down and a key up.* If you have event timestamps you can potentially do something more accurate than that, but I've never seen the need.
Quote this message in a reply
Moderator
Posts: 1,560
Joined: 2003.10
Post: #5
Xenos Wrote:So, if the player is issuing commands to the game (keystrokes), do I need to store these keystrokes up in a queue/stack and perform them in my updateGame() function, one keystroke command per interation? Once one keystroke is performed remove it from the queue or pop it off the stack?
Not necessarily. The usual approach is to set a variable to something in your keyDown handler, act on it in your main loop, and reset it in keyUp. There's typically not much benefit to trying to make it possible for a user to interact with your application at a finer resolution than the graphics are displaying, since they won't be able to see what they're doing. It should be fine to just use whatever state the input is in at the beginning of your run loop through all of its iterations.
Quote this message in a reply
Apprentice
Posts: 13
Joined: 2006.09
Post: #6
Thanks for the input guys. I will try this stuff and see how it works.

On another note, have any of you actually ran my app? I was wondering why OneSadCookie posted that initial web link. Did you see my app acting a certain way that prompted you to think that the technique outlined there would help?

I am running a PowerMac G5 Dual 2.0 GHz machine with 2.5 GB of RAM. The only thing that could possibly be a bottleneck would be my GPU, which is a nVidia GeForce 6600. But factoring in the things I am moving around on the screen, 2 ships and max 10 bullets on the screen at any one time over a black background, so I don't think I am having any performance issue. The only noticeable slow down of animation comes when I place another window over my app window. It could be just partially over the window. I am not sure if "Fixed interval time-based animation" will help that, but I am willing to try.

Before I posted a link to the executable, I knew that people probably would not download it. So I tried to find some way to make a movie from it but I did not find anything that did the job effectively enough to show the issues I mentioned in my first post.

Again, thanks for the input.

Gerry

Quote:There is a name for people who are not excited about their work--unemployed.
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #7
You said that your game runs at different speeds under different circumstances. That means that you're not using time-based animation. That's why we suggested doing it.

Your game's frame-rate *will* vary; there's nothing you can do about that. Putting another window over the top seems a perfectly reasonable catalyst (the window server has to do a lot more work compositing).
Quote this message in a reply
Apprentice
Posts: 13
Joined: 2006.09
Post: #8
OneSadCookie Wrote:Your game's frame-rate *will* vary; there's nothing you can do about that. Putting another window over the top seems a perfectly reasonable catalyst (the window server has to do a lot more work compositing).

Makes sense. I just thought that with the limited amount of pixels I am moving around the screen that there would not be any performance hit at all for one window on top of another.

Gerry

Quote:There is a name for people who are not excited about their work--unemployed.
Quote this message in a reply
Moderator
Posts: 3,570
Joined: 2003.06
Post: #9
Xenos Wrote:Makes sense. I just thought that with the limited amount of pixels I am moving around the screen that there would not be any performance hit at all for one window on top of another.
It's not that there is any appreciable performance hit at all (although complex compositing might incur *some* penalty, that has not been what I have observed), rather that there is a scheduling conflict, where the window manager is trying to prioritize when a given window needs to be redrawn. I have noticed that system UIs like to draw at the screen refresh rate, which makes infinite amounts of sense, and might force the underlying window to lock to the refresh as well, which would be aproximately 60 Hz on an LCD. So while it looks like it is drawing a lot less frames than say the 400 per second you might have been doing so far (of which only 60 are actually shown BTW), the machine's ability to draw at any given speed or push any given amount of pixels didn't change, just the scheduling changed. This is why you must use time-based animation. Fixed rate time-based is even better. ThemsAllTook's article on it is very difficult to grasp if you hadn't thought about it at length before. I had to go through it several times and rewrite the code in several different ways to finally pick up on it, which is sad because it is an extremely simple algorithm! I would suggest a better way to explain it except that I can't think of any. Rasp
Quote this message in a reply
Member
Posts: 26
Joined: 2006.09
Post: #10
I have been using the idea from this article for years now:

http://jare.planet-d.net/docs/FixLoop.htm

The basic idea is the same as in the article described earlier, but in addition it calculates a variable which allows you to interpolate the results from two different game states.

I usually calculate the game logic at 30Hz, but without the interpolation the player would not notice smoother animation at higher framerate. So each time I update the game state I store the previous value, and while rendering I interpolate between the two values. For position it would be something like: renderPos = prevPos + (pos - prevPos)*t. So if the game is run at 120fps, the update will be called every 4th frame, but I get smooth animation by interpolating in the frames between.

Some people really like to build their stuff to use variable timestep (use the time passed between frames to update the system) and some like fixed timestep (make sure the system is update x times persecond, assume always same delta time). I think there is no right solution, but I personally prefer the fixed timestep.
Quote this message in a reply
Moderator
Posts: 1,560
Joined: 2003.10
Post: #11
AnotherJake Wrote:ThemsAllTook's article on it is very difficult to grasp if you hadn't thought about it at length before. I had to go through it several times and rewrite the code in several different ways to finally pick up on it, which is sad because it is an extremely simple algorithm! I would suggest a better way to explain it except that I can't think of any. Rasp
If you come up with anything that could make it easier to understand, I'd like to hear it so I can update the article. It's the one I always get the most questions about, and I usually have to work with people to get their implementation right.
Quote this message in a reply
Moderator
Posts: 3,570
Joined: 2003.06
Post: #12
ThemsAllToo Wrote:If you come up with anything that could make it easier to understand, I'd like to hear it so I can update the article. It's the one I always get the most questions about, and I usually have to work with people to get their implementation right.
It's a super simple concept that just happens to be hard to describe, I think. I'll try to look at it a different way and see if I can come up with something, but... I dunno, you did a pretty good job with it.Smile
memon Wrote:The basic idea is the same as in the article described earlier, but in addition it calculates a variable which allows you to interpolate the results from two different game states.
Well, you can pass in delta time (which is the interpolation variable) anyway, so it's the same either way:

myGuysPosition + myVelocity * deltaTime

The bonus to the way ThemsAllTook's article does it is that it guarantees that there will be a requisite amount of calls to the game update so as not to have huge (or tiny) deltaTime values (to a certain point of course). The built-in side effect to this is that deltaTime winds up being the same every frame, which just happens to be a perfect condition for stable physics integration.
Quote this message in a reply
Member
Posts: 254
Joined: 2005.10
Post: #13
ThemsAllTook Wrote:If you come up with anything that could make it easier to understand, I'd like to hear it so I can update the article. It's the one I always get the most questions about, and I usually have to work with people to get their implementation right.
I think the confusion is due to your explaining the updates per second in terms of the frame rate.
Sacred Software Wrote:update the state of your game world a variable number of times per frame, but at a fixed timestep interval.
Whew, what a mouthful. Perhaps it would be easier to explain that the updates happen at the same rate no matter how many frames are displayed. That is, the update rate is constant while the frame rate is variable. When you are drawing a complex scene the update rate shouldn't change (or the game will be unplayable) while the frame rate will slow down. OTH if you aren't drawing anything complex the frame rate should increase, but again the update rate should not change.

At least, that's how I understand it.
Quote this message in a reply
Member
Posts: 49
Joined: 2006.07
Post: #14
Are you double buffering?
Quote this message in a reply
Apprentice
Posts: 13
Joined: 2006.09
Post: #15
ia3n_g Wrote:Are you double buffering?

No I am not. My view is setup as a double buffer view, but I am still learning how to implement this technique. I did look at Apple's TextureRange, but there is a whole lot of other stuff going on there that makes the concept cloudy to me. I need to find an OpenGL example whose sole purpose is to explain how to implement double buffering to make it easy for me to absorb the subject. Any suggestions?

Gerry

Quote:There is a name for people who are not excited about their work--unemployed.
Quote this message in a reply
Post Reply