Sega Master System / Mark III / Game Gear|
SG-1000 / SC-3000 / SF-7000 / OMV
Home - Forums - Games - Scans - Maps - Cheats - Credits
Music - Videos - Development - Hacks - Translations - Homebrew
Game ProgrammingPosted: Wed Jul 21, 1999 2:39 am
Alright, when a game is running, I understand that it plays it music and sound effects by going to sound
sub-routines and updating the sound each game loop. The same goes for graphics as well. But this
has been puzzling me for weeks. How does it keep track of what is supposed to be played? Cause
if you simply write a huge list of music commands during a game loop and you call that function
to play the music or sound effect, the entire game is going to freeze until the music commands
are finished. And, if you simply place a return instruction after each note, it's going to only play
the first note of the song, go back to the game loop, go back to the music function, play the
first note, and loop over and over again because it uses a return statement. How do I know
all of this? I tried it in Qbasic as well as Visual Basic.
Also, how does a video game detect certain kinds of collisions and such? Like, take a platform
game like Wizards & Warriors. The view is sort of slanted downward, giving it a sort of "3D"
effect besides the basic Mario Bros/Donkey Kong genre. Same thing goes for the Ninja
Gaiden games, Friday the 13th, Battletoads, and A Nightmare on Elm Street. How does
it know when the character is standing on solid ground, when the character is falling, when
the character has been hit by something. I don't get it. How does it know how high to
make the character jump? How does it know when the character has touched the ceiling
or top of the screen?
I know many of you out there may already have a full grasp of game programming but this
is like a whole new world of programming for me. It's like, a game is a true work of
art. The way it plays sound, the way it displays graphics, the way it accepts controller
input, the way it makes the screen scroll, man. Where did these programmers come
up with these ideas? Their so smart.
||Posted: Wed Jul 21, 1999 9:17 am|
Hmm... I may not be a programmer, but I beleive that I have the right ideas... (feel free to correct me if I'm wrong)
I think that this is done by programming in a 'clip' area where the character can move around freely (the ground) and a 'noclip' area where the character can fall through. (Doom, anyone?)
I believe that this is done by setting limits during the various debugging stages. Like say the jump limit = (button press time)÷ (max. jump height).
Or something like that. Maybe not.
Did that just confuse you more?
|Posted: Wed Jul 21, 1999 3:13 pm|
Well lots of console and arcade machine have two microprocessors. Most of a time a 68000 and either
a z80 or a 6502. The 68000 is the main microprocessor, it controls the game, it is much like the Pentium,
K6, or whatever of your PC. The secondary processor, in our case the z80 or the 6502 issue commands to
the sound hardware either psg or fm synthetizer. So the 68000 ask the secondary processor to control the
But on our mighty PC, stuff are a little bit different, for example the timer clock can issue an interrupt,
say every 0.02 second (50Hz), the processor (Pentium for instance), is interrupted and it can be "vectored"
to an interrupt service routine which issues music commands to the soundcard.
The way it's done on our PC is, I think, the good way, waste a z80 for music is not worth, except if you make
the z80 do some dsp stuff, but I've never heard of an arcade or console game doing so. Well the perfect
way would be PC + a soundcard with DSP (a 56k dsp like those turtle bitch cards).
Well using qbasic and visual basic is not the easiest way to program game. Maybe you should switch to
Visual C, so you can take advantage of DirectX.
|Posted: Wed Jul 21, 1999 3:59 pm|
Here's how I would write game music for something like the SMS:
First I would use a main game loop. The loop would be synchronized with the VBlank interrupt. Somwhere in ROM would be a large data table. Each "element" in the table would consist of two bytes of data, a freqency and a duration measured in VBlank cycles. The main game loop would contain a counter and a pointer into the data table. At the beginning the pointer points to the beginning of the data table, and the counter is 0. The frequency value is loaded from the table, and the PSG is programmed to produce that pitch, then the counter is loaded with the duration value. That's it for the first iteration of the game loop. Each iteration after, the counter is decremented and compared to 0. If the counter is 0, the pointer is incremented to point to the next data pair, the PSG is programmed and the counter is re-loaded. When the pointer gets to the end of the data table, it is reset back to the beginning (thus repeating the song). Each track in the music would have it's own data table, pointer and counter. One disadvantage of this approach is that the longest duration is only 255 VBlanks, or a little more than 4 seconds on NTSC systems. However, I don't think this is to big a problem. The duration could be made longer (by using 16-bits to represent duartion) at the expense of making the data table larger. I have not actually implemented the above, but I believe the approach is valid.
Also, one really crude way of doing collision detection is by checking the color of surrounding pixels. For example, if only the enemies on the screen use color X, then you know your character has hit an enemy if any pixels next to your character are color X.
||Posted: Fri Jul 23, 1999 5:08 am|
Actually taking the NES or C-64 as an example, the music routine IS ran in the vblank. This isn't as bad as it sounds. For example if the machine has 4 channels, you may update 16 registers, and that would be assuming every voice changed at the same time. You could probably slow your music down to run at 1/2 the rate of the interrupt and update 2 voices on each vblank.
And, if you simply place a return instruction after each note, it's going to only play
Well the vbalnk routine has access to normal memory (not taking into account banking), so you store the counters and stuff, and update them each vblank.
Elm Street. How does
I can't remeber (or have never seen) the games you've mentioned, but a common method of doing stuff with tiles is to give a tile attributes, and then use the atteribute to determine behavior on tile. For example sloped tiles are given a FLAG of 'TILE_SLOPE45'
or 'TILE_SLOPE60' and the character is moved across the tile based on the slope. (The TILE_SLOPEx would have to be defined in your program). Or the tile can be given a 'TILE_SOLID' or TILE_PASSTHROUGH' flag to represent solid or passable tiles. Handling of tile attributes is handled strictly by the game code (and isn't a hardware function).