D.C.
Member
- Joined
- Dec 26, 2005
- Messages
- 235
Book/tutorial On Sprite Engines
- Thread starter D.C.
- Start date
Exophase
Nothing good will ever come of Exophase.
D.C. said:
Tell us more. What kind of display are you connected to? What resolution and color depth is your framebuffer, and how much RAM do you have? What clock speed is the AVR at? What refresh rate are you hoping to achieve?
You probably won't have peripherals to help you blit images, so you'll probably be stuck rendering completely in software. This is in stark contrast to old consoles and some computers, which had video hardware that could be used to scroll backgrounds and blit sprites. For consoles those backgrounds were usually tiled as well, and by the 16-bit era you got multiple background layers. The CPU didn't have to draw any of this stuff, so they could get away with slow processors. If you have to draw each pixel each frame then the story is very different, and an AVR is going to be very limited in how fast it can pump out pixels. If this is the case then you may end up limited to doing a game with no scrolling and a limited number of small sprites, so that you only have to redraw the sprites.
Last edited by a moderator:
D.C.
Member
- Joined
- Dec 26, 2005
- Messages
- 235
Maybe you heard of it, it's called an Uzebox. It combines my interest in getting into embedded development and classic 8-bit games. As I said, I'm very interested in the actual mechanics behind 8-bit games, so I hoped there would be some resource that described the general techniques used in those games. As you point out, most consoles did use custom hardware for video/audio, whereas the uzebox uses a kernel that performs those tasks in software. I've already gotten some good advice from the guys at the uzebox community, but considering this place houses some great developers (like yourself 
), any advice is welcome.
), any advice is welcome.Exophase
Nothing good will ever come of Exophase.
I haven't heard of it before but am looking at it now. I'm quite surprised the kernels are capable of rendering as much as they can, the atmega644 at 28MHz must be pretty capable indeed, when paired with zero wait-state RAM. Still, it does look pretty limiting. I'm not really sure how there can be much variation in amount of cycles left when you have to generate the video signals - squeezing non-video work during the scanlines is going to be almost impossible. In that regard it's very reminiscent of Atari 2600. Maybe it's going by scanline count, since less scanlines means longer vblank, except most of the modes are 224 lines.
Even then, the chip is much faster than any of the ones in old 8-bit consoles, and will even be much faster than 16-bit or better ones in most older consoles like SNES and Genesis. So even if you only get 1- (224 / 262) = 14.5% full CPU time in the usual modes, that's still 4.148MHz and for a mostly single-cycle RISC chip that's a ton better than what you'll get on say, a PC-Engine.
So if you're okay with the video modes you should have plenty left to do a good game. But I think they're very limiting, especially the tiny amount of VRAM. Probably the worst facet of the system is the very limited sprite capability - all of them are far worse than NES. Expect to have a lot of flickering if you want anything more than simple displays.
But I've been side-stepping your original inquiries. Let me ask you one more major question.. what kind of game do you want to make? This will drive a tremendous amount of the design work behind it. We'll probably be able to give you more useful advice once we know this.
Here are some general things I can say:
- Since the work is already done for you for graphics, start by doing some simple things to interface with the graphical setup. This will probably mean creating tiles, creating a tile map, and setting some RAM values to determine screen parameters. If you use the proper libraries/headers/whatever then it looks like you'll get C variables for these things, including arrays of structs for sprites. Start simple, with a static background, then one you can scroll with the background, then some sprites you can move around.
- That'll also involve some stuff with interfacing the controller, which is probably really simple.
- No matter what game you do, you'll want to time everything around one unit: the 60Hz frame rate. That means that once per frame (in vblank, after the kernel is done drawing things) you'll want to increment the game logic one "cycle" for every element in your game. Don't shoot for anything more or less than this. You'll have to get used to time-slicing everything around this.
Even then, the chip is much faster than any of the ones in old 8-bit consoles, and will even be much faster than 16-bit or better ones in most older consoles like SNES and Genesis. So even if you only get 1- (224 / 262) = 14.5% full CPU time in the usual modes, that's still 4.148MHz and for a mostly single-cycle RISC chip that's a ton better than what you'll get on say, a PC-Engine.
So if you're okay with the video modes you should have plenty left to do a good game. But I think they're very limiting, especially the tiny amount of VRAM. Probably the worst facet of the system is the very limited sprite capability - all of them are far worse than NES. Expect to have a lot of flickering if you want anything more than simple displays.
But I've been side-stepping your original inquiries. Let me ask you one more major question.. what kind of game do you want to make? This will drive a tremendous amount of the design work behind it. We'll probably be able to give you more useful advice once we know this.
Here are some general things I can say:
- Since the work is already done for you for graphics, start by doing some simple things to interface with the graphical setup. This will probably mean creating tiles, creating a tile map, and setting some RAM values to determine screen parameters. If you use the proper libraries/headers/whatever then it looks like you'll get C variables for these things, including arrays of structs for sprites. Start simple, with a static background, then one you can scroll with the background, then some sprites you can move around.
- That'll also involve some stuff with interfacing the controller, which is probably really simple.
- No matter what game you do, you'll want to time everything around one unit: the 60Hz frame rate. That means that once per frame (in vblank, after the kernel is done drawing things) you'll want to increment the game logic one "cycle" for every element in your game. Don't shoot for anything more or less than this. You'll have to get used to time-slicing everything around this.
D.C.
Member
- Joined
- Dec 26, 2005
- Messages
- 235
Thanks for such a comprehensive reply.
To answer your question about what kind of game I would like to make. My long-term goal might be a rpg game in the style of Earthbound or something like Zelda. For a short-term goal, I was thinking about a a simple side-scroller. However as you stated, I will need to start with the very basics, especially as I don't have any experience in writing games (or graphics for that matter).
Also I'm unclear how far the platform can be pushed graphically. The tetris clone looks quite nice and this super mario world demo looks promising, although it's buggy and slow. Do you have any idea how far the graphics could be pushed (Atari 2600/NES/SNES)?
Now please forgive my ignorance, as I said I'm new to game development . This is how I understand it so far: the TV (NTSC) uses a frequency of 60 Hz to update the screen. That means a frame rate of ~30 (2 fields interlaced). Each field is composed of 262 number of horizontal scan lines.
The total time to draw one field consists of the time needed to draw each scan line and the hblank of each line times the number of lines used, plus the vblank (including non used scan lines).
So you have the hblank and the vblank times to do everything else. This includes game logic (collision detection, input processing), audio generation and other things.
Now I'm not really clear on video modes. The atmega644 runs at ~28Mhz, which means 28M cycles for 60 fields. This means you have 28M/60 cycles for each field. How much of these cycles you'll need for displaying graphics depends on how complex your calculations are going to be. And this is then somehow (certain "operations" needed for certain types of games?) divided in video modes I guess. As you pointed out, most video modes don't use all the scan lines, thus freeing cycles for other calculations.
Sorry for the long rant, hope any of this makes sense .
To answer your question about what kind of game I would like to make. My long-term goal might be a rpg game in the style of Earthbound or something like Zelda. For a short-term goal, I was thinking about a a simple side-scroller. However as you stated, I will need to start with the very basics, especially as I don't have any experience in writing games (or graphics for that matter).
Also I'm unclear how far the platform can be pushed graphically. The tetris clone looks quite nice and this super mario world demo looks promising, although it's buggy and slow. Do you have any idea how far the graphics could be pushed (Atari 2600/NES/SNES)?
Now please forgive my ignorance, as I said I'm new to game development
. This is how I understand it so far: the TV (NTSC) uses a frequency of 60 Hz to update the screen. That means a frame rate of ~30 (2 fields interlaced). Each field is composed of 262 number of horizontal scan lines. The total time to draw one field consists of the time needed to draw each scan line and the hblank of each line times the number of lines used, plus the vblank (including non used scan lines).
So you have the hblank and the vblank times to do everything else. This includes game logic (collision detection, input processing), audio generation and other things.
Now I'm not really clear on video modes. The atmega644 runs at ~28Mhz, which means 28M cycles for 60 fields. This means you have 28M/60 cycles for each field. How much of these cycles you'll need for displaying graphics depends on how complex your calculations are going to be. And this is then somehow (certain "operations" needed for certain types of games?) divided in video modes I guess. As you pointed out, most video modes don't use all the scan lines, thus freeing cycles for other calculations.
Sorry for the long rant, hope any of this makes sense
.
Last edited by a moderator:
