Jump to content
  • Advertisement
  • entries
  • comments
  • views

Fire Track

Sign in to follow this  


When people ask, in the future, what the greatest feature of Fire Track is, they will not say the graphics. Nor the gameplay. In fact, they will... well, see for yourself. (Sorry, it's a bit quiet). [smile]
There is one more attack pattern. I have redesigned the attack system so that the enemies do NOT have their clocks auto-incremented (though they can call a function in their update code to do so if they really need it). This is so I can use the clock to store states instead. The new attackers slide in from the top-right, move down until they are level with the player then slide right again.
One peculiarity of gameplay in Fire Track is that you are permanently firing. You can never let go of the fire button. Also, the enemy ships do not fire at you - they just try to crash in to you.
I ran out of room. The game refused to compile. So, with a bit of tweaking in the map editor and a rewritten scrolling routine, I have doubled the amount of free space (without the music, about 10000 bytes are free). I'm using RLE compression on each 20 bytes of the level. If I get even tighter for space, I could probably pack the 8 bit level bytes into 6 bits.

Here's an awful sprite of an explosion. It looks really ropey, but it's as close as I can get to the authentic Fire Track (ship) explosions. I don't know how good it'll look in action!

Sign in to follow this  


Recommended Comments

Lack of ending levels, lack of scoring, only 3 enemies, lack of explosion effects... Yes, there's a lot to do. [grin]

Share this comment

Link to comment
looks great and the music rocks ;)
one thing i would like to ask is do you care about framerate indipendent movement? or does it run stable enough at all times so you dont need this?

since i started coding games i always wanted to know hot this is managed on consoles, and now that i want to start a bit coding on the TI-92 plus it might be usefull to know that too ;)

Share this comment

Link to comment
Regarding framerate independant movement;
On the Game Gear, this is very simple. You don't. [wink]
The reason is quite simple - the VDP (Video Display Processor) on the Game Gear has some internal storage (VRAM) which holds all the 8x8 tiles that make up the sprites and background, a large table that is your "map" for the background, a table to hold all the coordinates of your sprites, a palette and so on. As it produces a video output signal by scanning down the screen it needs to access these areas of memory, and therefore changing anything or accessing any of the VRAM during this sweep will cause nasty things to happen.
How, then, does one write to the display?
There are two ways - firstly, disable the screen. This stops the VDP from outputting anything, so it doesn't need to access any VRAM so you can read/write all you like.
However, disabling/reenabling the display causes the output to flash, so it's only really any good for loading large chunks of data at the start of a level.
The other way is to wait for the vertical retrace (which can be accessed through port hardware $7E) to hit the bottom edge of the display, write to the VRAM like crazy whilst it's not currently scanning the active part of the screen (and so the VDP isn't accessing the VRAM) and hope that you don't have too many writes so that you're still writing when it reaches the top of the display again. As such, everything is tied to the vertical retrace count, (which scans at a constant rate) so you're always operating at the framerate of the display.
For something like a calculator; well, I only know this from the TI-83 Plus.
The display controller on the TI-83 Plus is very different to that of an SMS/Game Gear, because it is not designed to be constantly retracing a CRT. With that, you set (x,y) write and just output values which are sent to the LCD. In this manner, you can build up a screen in RAM taking as long as you like then send it all to the LCD in one go without any problems. However, the longer it takes to build up your image, the slower the framerate of your game - and how do you handle this? I've come up with a number of solutions;
  • Ignore it. Let the framerate drop slightly when drawing lots of stuff to the screen. (Fire Track II for the TI-83 plus does this, there is some slowdown when there are lots of explosions on screen.
  • Make most of your graphics routines take up a large portion of time in relation to the rest. This is why FT2's slowdown isn't too bad - I went over the top with smooth-scrolling backgrounds and a parallax scrolling background, which take up most of the time in comparison to a few extra sprites.
  • Perform dummy operations when you know something is going to be slow. For example, in your inner loop, just increment a counter. When it is finished, for faster operations you'll have a low count, so do something else until that counter is the same as when processing a lot of data (so artifically slow down the faster cases).
  • The TI-83 Plus Z80 can be switched into a useful IM2 mode, which calls an interrupt routine approximately 200 times a second (based on current battery level - the TI-83 Plus CPU is sloppily timed with a RC circuit, not a crystal). Use this to increment a "tick count", and use that for frame-time based movement. This is much more horrible to code for, though.

Share this comment

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!