|
Note: You must be registered in order to post a reply.
|
| loonycoder |
Posted - Dec 27 2004 : 4:14:44 PM
Just your basic space shoot-em-up. Kill minibosses for powerups to help destroy the ever increasing numbers of enemies. It starts off easy but after a few minutes things start zipping about the screen. It's somewhat dynamic, the bad guys get more powerful and shoot more as you get more power ups, they'll shoot less if you tend to die alot. Has end of level bosses, various space scenery, lots of explosions, alien bad guys and big guns.
homepage (sorry bout the banner ads)
http://www.angelfire.com/pq2/loonycoder/
This is the first game i've released and am interested in feedback/comments/bug reports.
Thanks!
|
| 2dcoder |
Posted - Jan 06 2005 : 12:51:16 PM
"#5. You can implement frameskipping without resorting to time movement calculations. Playstation (and other consoles) emulators do this. The emulators do not mess up with the movement values by factoring time delta (it's the emulated processor's thing), yet they can skip frames if your PC cannot handle the frame."
One of the options I've learned to implement in my code is timebased movement combined with fps limiting. This way if a game is running on an older cpu or crappy card, the user can configure it run at a constant 15,20,30,60 fps, or refresh rate, while the internal calculations are still timebased. For 3D games, it's ok to jump around the frame rate because the object/world movements are usually based on a real world clock running 1000 times per second. For 2D apps a stutter or hiccup is very noticeable and your characters can seem to jump/move a very far distance if using time based movement. That's why even with a locked frame rate & time based movement, you still want to make sure the distance to update per frame never gets too far, that's where limiting comes into play. When limiting is in effect the movement will not get any greater, the frame rate will slow down.
I use time base movement for everything, but in pixel terms and capped frame rates, this is my general approach to limiting:
Game loop is running at 60fps so time_delta=1.
Loop drops to 30fps so time_delta=2.
Loop drops to 15fps so time_delta=4.
Loop drops <15fps but keep time_delta=4 because we don't want the objects to move too great a distance per loop. Otherwise objects could miss collisions, go through tiles, etc. The end result is slow motion for a while until the frame rate speeds up. :) I'm fairly sure this is how alot of 2d games on consoles are coded. Remember all those shooters a while back that had the dreaded "slowdown"? :) LOL... |
| hotrodx |
Posted - Jan 06 2005 : 12:41:16 AM
Time-based movement computations without any form of VSync or framecapping leads to excessive framerates that are best left to benchmarking. Even without VSync, Quake still tries to sync it's framerate to the monitor's refresh rate. It won't go to gazillion FPS unless you are benchmarking.
"a game that runs at 60 FPS for 80 percent of the time but sometimes drops to 15 FPS during certain situations is worse than a game that runs at 20 FPS for 80 percent of the time"
A lot of 3D games are actually like the former, Quake included. When you get to places where there are more detail or more enemies, the framerate drops. The high-profile game I've seen that forces framecapping would be HALO for the PC. If you turn off the framecap, it'll behave like the latter.
But say, HALO has framecaps still ON at 30FPS, but there is still too much detail in a particular scene (or you really have a crappy vidcard) that it still drops at 15FPS, it is unecessary to force the whole game to run at 15FPS just so you can have a *consistent* framerate when certain other scenes can run relatively faster.
|
| Eric Coleman |
Posted - Jan 05 2005 : 10:45:40 PM
Have you ever tried to play "retro" games on a modern computer? Games such as "avoid the noid" or whatever it was called run too damn fast to play. There are situations where all of frame limiters, vsync, and time based movement would have been great. Time based movement, as oposed to pixel based, is designed for faster computers, not slower. For example, Quake's models are designed for 30 frames per second. However, if you have a fast enough computer it can fill in missing frames and create a smother game for you.
There are situations where frame limiting and vsync compliment each other very nicely. Vsync generally operates on certain harmonics, 60, 30, 20, 15, etc. Frame limiting, assuming your game is played on very fast comptuers, can help maintain accuracy (especially for multiplayer games) on monitors with a very high refresh rate.
The best solution is to be able to sustain a consitent frame rate, and that generally requires a combination of techniques. Frame rates that flucuate are more noticable than sustaining a low frame rate. As an example (can't you tell by now I love giving examples?, lol) a game that runs at 60 FPS for 80 percent of the time but sometimes drops to 15 FPS during certain situations is worse than a game that runs at 20 FPS for 80 percent of the time.
The optimal solution is to do some sort of speed test to see what kind of frame rate a video card can handle and then use that as a basis for other calculations. |
| hotrodx |
Posted - Jan 05 2005 : 04:09:22 AM
I really don't want to turn this thread into a "VSYNC or NO VSYNC" topic, but what the hell...
My 2 centimos (to *no one* in particular):
#1. You can have 60FPS even with VSYNC off if you have a frame limiter.
#2. Frame limiters do not waste system resources. They actually return unused resources back to the system.
#3. Certain jerkiness can still be seen even with VSYNC on when the monitor refresh rate does not match the frame rate.
#4. Having more the 60 cycles does not create any perceivable difference on multiplayer games. Exceeding cycle rates only unecessarilly sends more data packets which slower (other connected) computers cannot process. You are only sapping the bandwidth. What matters is latency, packet size and planning.
#5. You can implement frameskipping without resorting to time movement calculations. Playstation (and other consoles) emulators do this. The emulators do not mess up with the movement values by factoring time delta (it's the emulated processor's thing), yet they can skip frames if your PC cannot handle the frame.
Anyway, the idea behind frameskippers or Time-based movement is to allow slower computers to run games designed for faster PCs. Unfortunately, this is only an IDEAL condition, designed mainly to broaden the target PC demographic. No matter what you implement, you cannot make DOOM 3 run on a slow PC, even with frameskipping and/or time-based movement on.
On the flipside, Time-based movement is not designed to make 300fps games. You are just wasting resources. You are just wasting time (pun intended). It's just like the SUV mentality.
Going back to the game...
To loonycoder,
Keep up the good work. Anyway, the game didn't run on an S3 Trio3D-equipped PC. It turned out that the card does not support D3D on Windows 2000 (I wonder what the "3D" in "Trio3D" meant). I *am* assuming the game uses Direct3D with all that rotation stuff.
Anyway, if Mission Demolition is an indication of the quality of your future games, then they're really something to look forward to. Good luck. |
| 2dcoder |
Posted - Jan 02 2005 : 01:34:49 AM
"Vsync should not always turned on. While ina game such as this one, it makes no difference, in a complicated 3D game, things can be processed at fatser than VSync. It is much more natural for the input to be handled more than 60 times per second."
uh..this is wrong information frankly. Don't mean to sound like a pompus know it all, but for any video game that draws to a backbuffer, page flips, etc, vsync should be turned on to keep things from as I described tearing. Actually, other than testing how fast the logic is cranking, there never should be a need to turn Vsync off.
Ofcourse you can get input faster than 60 times a second. Almost all PC monitors refresh at 75hz or better now days. TV and console games have vsync on and refresh at 60hz.
This is where time based movement comes into play. In modern pc games, you never worry about what the refresh rate is because you are moving things in ms per second, not pixels per frame. You think "how far is my object going to move in 1 second" compared to "how many pixels my object is going to move per frame". This way your main loop is cranking as fast as the cpu can go and your object updating is based on real time.
Even in a 2D shooter like this game, time based movement would allow the objects to move silky smooth on fast cpu's and slightly more coarse on slower cpu's or those with crappy video cards.
In modern PC games (2D and 3D) it's fun to turn vsync off and see how fast the frames are updating, but keep in mind, the objects on screen are not moving any faster, they are just moving smoother. |
| loonycoder |
Posted - Dec 30 2004 : 2:55:25 PM
Just to clarify... In the game itself V-sync is enabled. I never had a reason to disable it/make it a toggle option. It's the video card (hardware) vsync option on my older puter and old geforce card that makes the game a tiny bit skippy, might be drivers, might be the old monitor it's connected to that does 50hertz at 640x480, I never bothered looking too closely, I normally have vsync hardware turned off and have no problems.
I have also just added a 'hard mode'. It makes the bad guys come in greater numbers and faster from the start, you start with a speed and firepower upgrade at the start in this mode too. Should help for those people finding the game slow at the start.
|
| Sr. Guapo |
Posted - Dec 30 2004 : 12:06:48 AM
Vsync should not always turned on. While ina game such as this one, it makes no difference, in a complicated 3D game, things can be processed at fatser than VSync. It is much more natural for the input to be handled more than 60 times per second. Also, it helps any data packets to be sent as often as possible in multiplayer mode for a smoother and less bumpy multiplayer.
One solution to the tearing is to add triple bufferering to your game. Another is to use multiple threads and only set the render thread to 60 times per second. This solution is a bit more difficult to set up and debug, and it also has a bit of an overhead on single processor (and non-hyperthreading) systems. |
| Lachlan87 |
Posted - Dec 29 2004 : 10:23:09 PM
Better yet, make there be an option to turn it off and on. |
| 2dcoder |
Posted - Dec 29 2004 : 4:31:39 PM
VSYNC should 100% always be active on final releases. What VSYNC does is force the vertical blank to occur, which means the frame rate will never exceed the monitor's refresh rate. Sure it's fun to see a FPS of 200 or more, but this should only be used to see how fast your game "could run". Turning vsync off creates "tears" in the graphics which means you're updating the graphics faster than the video card is updating the screen, causing graphics to be drawn ontop of each other. (This is the tearing.) |
| loonycoder |
Posted - Dec 29 2004 : 3:50:07 PM
The things you dont notice when you play your own games, i've updated the banking speed, should be more on par with the ship movement now. |
| Sr. Guapo |
Posted - Dec 29 2004 : 2:40:22 PM
Nice game - the only thing I would change is the banking thing when you turn. It is really lagging behind the actual turn... The game also seems to be pretty slow. Otherwise it is a great game: Decent graphics, fun gameplay, fairly original enemies (not like every vertical scrolling space shooter). |
| loonycoder |
Posted - Dec 29 2004 : 1:22:28 PM
I have 2 puters, a coding box, Amd 1666, ATI9550 card and a smaller test box, pentium2-550, geforce2 card. On both machines with the hardware directx v-sync turned on it makes the game skip a little, not sure why. Turning it off in advanced video options makes the game run smoother for me, not sure why, just posted an observation.  The game itself will just try and run as fast as it can, could be why.
|
| 2dcoder |
Posted - Dec 29 2004 : 12:37:17 PM
Good stuff! But if you think removing vsync from your main loop makes the game run smoother then you really need to research what vsync does. |
| loonycoder |
Posted - Dec 28 2004 : 11:25:04 AM
Revision 1.0.1 ready to download, added exciting stuff like an icon! (wheee) and some extra graphics. |
| Walrus |
Posted - Dec 28 2004 : 05:22:17 AM
Nice! I wanted to ask you if you were going to enter the x-mas contest, but then I saw you already did! 
|
|
|
| VBGamer |
© |
 |
|
|
|
