Articles tagged “Game Gear”
Game Gear LCD Scaling
The Game Gear's hardware is very similar indeed to the Master System's - so similar that you can play Master System games on a Game Gear via a special adapter. Some Game Gear games were just the Master System ROMs in a Game Gear cartridge. That said, the Game Gear's LCD is only 160×144, and the Master System has a resolution of 256×192 (or 256×224 or 256×240, but those modes were very rarely used). In Game Gear mode, this resolution is simply cropped. In Master System mode something more interesting has to be done to scale this down to fit the LCD.
TI Emulation, Functions in Brass and Gemini on the Sega Game Gear
This post got me wondering about a TI emulator. I'd rather finish the SMS one first, but so as to provide some pictures for this journal I wrote a T6A04 emulator (to you and me, that's the LCD display driver chip in the TI-82/83 series calculators). In all, it's less than a hundred lines of code. The problem with TI emulation is that one needs to emulate the TIOS to be able to do anything meaningful. Alas, I had zero documentation on the memory layout of the TI calculators, and couldn't really shoe-horn the ROM dump into a 64KB RAM, so left it out entirely.
Patch files
I added Emukon patch file export to Brass - Brass will export all the labels, variables and breakpoints from the source and Emukon can then load them in. It makes debugging much simpler... Click for legible In my Game Gear-related fiddling, I optimised the tween demo code significantly, but then slowed it back down again by adding 4 more points, extending the rotation code to using 16.16 rather than 16.8 fixed-point and using a proper linear tween. It's still a bit smoother, though:
Video: 00'58" WMV [1007KB]
Scripted attacks
Attack patterns can now be simply scripted as a list of 4-byte chunks, covering which enemy to use, the delay between adding them, how many of them to add, the delay between them and a delay after adding the last one. For example, this:
.db $04,16,8,100
...would add 8 enemies of type $04, adding one every 16 game ticks and then pausing for 100 game ticks after adding the last one then progressing to the next scripted enemy. To support this, I've added some new per-level parameters, covering:
Attack type (random or 'scripted') with delay between enemies or a pointer to script to follow.Speed of enemies.Speed of landscape scrolling (used very little - bonus levels with no enemies/mines scroll past extra-quickly).Maximum number of mines.
Enemies Galore
I completely rewrote every single attack pattern from scratch (pretty much - the precalculated paths were left intact) last night. The result of having the ability to start any enemy attack pattern at any time (within reason - I only provide 8 enemy slots!) results in nothing short of sheer mayhem. Yes, collision detection was disabled for the video. I'm looking at you, evolutional... Is that enough enemies, do you think? [AVI/MPEG-4/1.62MB]
The small blobs that drift towards me are the aforementioned mines.
ARGH!
Fire Track (on the BBC Micro) is probably the fastest, hardest, most adrenaline-packed space shooter I've ever played! I'm playing my way through the extended version to try and work out the game mechanics a bit more. I've been using an ancient "infinite lives" cheat disk with it, but even so... whew, this game is tough. I have saved state images for Levels 1 to 22, though, at last. My nerves are shot to pieces, in any case! It appears that I have to rethink the way enemies are handled. Currently, I store a list of 8 enemies and assume they all follow the same pattern.
Fading
I spent a while last night on a reusable routine to fade between two different palettes. → → →
It just happens to be one of the muckiest pieces of code written so far. You can see it in action in a video I've knocked together here (262KB). [I haven't put together a video for a while, so any old excuse, eh?]
I rejigged a few bits of the code, including neatening up the core sprite routines (so they are now much faster, huzzah!)
I ran a test on what it would look like if I added 8 "mines" (sprite limit and all that).
Scoring
Fixed drunk pilots. New algorithm is about 20 lines shorter, 10 times faster, 5 times simpler. Reason for drunk pilots: drunk coder.Implemented scoring, including:
Variable points for shooting enemies.Variable points for shooting objects on the ground.Display of score at top of screen. Updated pause screen, all sprites now remain on-screen, background is less wavy.Trimming of enemy attack times so they follow on from eachother nice and quickly.Numerous minor bugfixes and tweaks. The score might look nice there, but it really needs to be stuck on a background - any sprites trying to come in are cut off and look really odd popping into existance 8 pixels down from the top of the screen (8 sprite limit, and I have 8 digits in my score).
It works!
Fire Track II for TI-83 Plus: 31 source files. Fire Track for the Sega Game Gear: 42 source files. Based on this information alone, you can deduce that FTGG will be vastly superior. I just gave FT2 a try in VTI (I don't have any batteries in my calculator) and good grief it's slow. FTGG is much much faster... (though you should see it go when I set the enemy speed to two... I need more accurate control of speed, 1 being medium-ish easy, 2 being nightmarishly impossible!)
This makes me happy. Things to notice about the above screenshot:
Near pixel-perfect parallax star background (you can see some through the bullet holes!)Not one single poorly timed VDP write.
Parallax
Here's a nice little graphical enhancement... ...and here's the video for it! (I disabled collision detection for that video, so no silly comments, alright? )
Now, there's a little problem with this system - well, a number of problems. The worst is this:
Oh dear. I'm now writing to the sprite table when the display is active, which (understandably) it does not like. On the Game Gear hardware, you can see this in the vertical bar of flickering stars towards the left hand side of the screen. I am not sure how I shall fix this, but I'm hoping that altering the sprite drawing routines to write to a RAM shadow then dumping the entire RAM shadow in the frame is faster than my current method which is to manually draw the sprites in a number of different routines.
Title screen goodness
I spent some time yesterday doing some 'fun' work on Fire Track - that's not to say that the other stuff is not fun, but I find the graphics work less head-hurting than the programming work. Hence the spiffy title screen above! It was fun trying to fit that into 16 colours and able to be broken down into 256 tiles, but with a bit of shuffling around it's a mere 254 tiles and the GIF exporter in Photoshop has done a great job dropping down the colours. The display on the Game Gear blends adjacent pixels together very nicely - on hardware, the title looks pretty flash.
Minor progress
I've spent the last few days up North for a cousin's wedding, so not much has gone on regarding Fire Track. A few things have been added, though! The sound is now "mixed" (for want of a better word) much better. It's still not perfect, and I'd like to see how it sounds when favouring amplitude over priority. That'll be my next tweak! I have added the cheat screen (also useful for testing sound!) which will appear if you hold down certain keys as the game starts. There are a new set of enemies... They just drift towards you - and you can't shoot them (they block bullets, though).
Bloop-bleep, it's the 80s!
Sound! I am still musicless, but never fear, for sound effects will fill the gap. Screenshots are pretty poor for sound , so here's the MP3. Simple as it sounds, that takes a mere 163 lines of ASM code to work, and even then it's a fairly crap effect! Each sound is stored as a series of "fades". Each fade contains the following data:
Starting period of the wave.Starting amplitude of the wave.Length of the wave in frames.Amount to add to volume each frame.Amount to add to period each frame. Using these simple fades and joining them together you can very easily produce a fairly complex sound.
Old projects and ugly XP icons
This is going to be a very boring update, I'm afraid. I wasn't feeling too good so haven't got much done. First of all, Latenite updates. With the project thingummy, I thought it would be nicest if it displayed the proper Windows icons for file types rather than the ones I had hardcoded in. Here is a function I wrote to take a filename and return an icon (in the form of a .NET Bitmap) based on it and whether you requested a large or small icon. It works by going into the registry and looking up the ".ext" key.
On the merits of Excel and running out of space
Latest video. [2.29MB AVI]
You chaps probably don't know what a major headache it is trying to get clear, non-wobbly video... I gave up in the end and went for the "propped-up against a wall with camera on stack of books" approach. The reason I cannot, therefore, appear to play the game very well is because I cannot see the screen. All I can see is a faint, inverted glow and have to guess where I am. Not fun. Here are the major updates since last time:
Removed Blackadder theme Altered colour contrast on title screen, added wipe to clear it in imitation of original, restructured code for better fades, changed timing, added sound.
Fire Track
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). 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.
Enemies!
They claim a picture says a thousand words. In this case, with these two pictures and one video [549 frames] I estimate that I have saved myself from having to write over half a million words in this journal entry. There is, of course, the usual shonkily shot video footage to watch: 416KB AVI. The collision rectangles need a little bit of fine-tuning and something better than just vanishing sprites needs to be implemented, but the modular and simple system is there. Each level contains a pointer to an "attacks" table.
Finished the levels! Wahey!
...and here is level 6. This, however, worries me:
Hopefully I can cram in all the rest of the code, tables, graphics and music into 5K. Failing that, I might have to start compressing my levels... I don't believe I've introduced you to my enemies yet? Here's the complete sprite table - don't worry, the letters P, A, U, S, E and D do not feature as enemy craft! I spent some time adding a new command systen to QuadPlayer, so you can now set a song to loop back X times (or infinitely) to a particular spot.