Jump to content
IGNORED

Couple of animated Ninja Gaiden mockups and a couple noob questions...


Fragmare
 Share

Recommended Posts

Hey, everybody. I'm brand new here. I'm a pixel artist and chiptuner. I usually hang out over on the PC-Engine forums, but I've always had a soft spot for the 7800 too. I've made a couple of quick 7800 mockups of a the Ryu sprite from Ninja Gaiden, just out of my own curiosity more than anything. They seemed to turn out rather nice, so I thought I'd share them here.

 

First image using 160x4 mode. Second image is 160x2. Both use the NTSC Base palette.

 

UmF98JC.gifXHrUknU.gif

 

 

I also had a couple questions about proper 160x4 mode, which enables up to 12 colors per "sprite"...

 

I've noticed almost everything uses 160x2 mode, with 2-bit (3 color + transparent) objects/characters. If I'm understanding the docs correctly, the MARIA chip doesn't -really- distinguish between sprites and background tiles. It basically just understands "stuff that moves" and "stuff that doesn't move" within the DLLs, so it knows how to draw the scanlines. So, in that regard, whether something is a "bg tile" or a "sprite" depends entirely upon how the programmer is using the graphic data, but to the MARIA, it's all more or less the same. Would that be fairly accurate? Or am i completely wrong?

 

I'm also guessing the 160x4 mode is more rarely used because it costs more CPU time due to the doubled bitplanes, and increased time to process the DLLs (due to said extra bitplanes)?

 

If I'm drawing graphic data for use with 160x4 mode, are there any special restrictions I would need to pay attention to, other than sticking to the 7800 palette and keeping it 12 colors or under?

 

I've got a lot of experience doing pixel art and game dev for the PC-Engine, so I've got a fairly good understanding 8-bit hardware in general and working under restrictions, but I also know that an intimate knowledge of the graphical hardware is essential to making good art for a system. So I'm trying to get a better understanding of precisely how the 7800 works, in terms of restrictions. At least, restrictions, as it pertains to drawing pixel/game art for the 7800.

 

Any help and/or advice would be greatly appreciated! :)

Edited by Fragmare
  • Like 4
Link to comment
Share on other sites

Welcome! Those are some cool mockups. :)

 

I've noticed almost everything uses 160x2 mode, with 2-bit (3 color + transparent) objects/characters. If I'm understanding the docs correctly, the MARIA chip doesn't -really- distinguish between sprites and background tiles. It basically just understands "stuff that moves" and "stuff that doesn't move" within the DLLs, so it knows how to draw the scanlines. So, in that regard, whether something is a "bg tile" or a "sprite" depends entirely upon how the programmer is using the graphic data, but to the MARIA, it's all more or less the same. Would that be fairly accurate? Or am i completely wrong?

I'm not sure I'd put it like you did, but I think you have the essential character of it right. Maria renders everything down to a bitmap scanline in the end, and how the graphics get baked-in (sprite vs tile) doesn't affect the visible character of the graphics. Of course, some things are easier for Maria to bake-in than others, which affects how many things Maria can bake-in overall; characters/tiles eat up more of Maria's scanline rendering time than sprites. (aka DMA time) Using 160x4 objects takes a bit less than twice the amount of DMA time than 160x2 objects. So, for example, using 160x4 tiles everywhere will cut down a fair bit on the number of sprites you can display.

 

That doesn't mean the game background needs to be restricted to 3 colors. You can break up a screen into different 160x2 areas, with each area having different DL entries using different palettes. This complicates scrolling code a bit, but otherwise it's relatively easy to do.

 

It may not have been clear from your reading of the docs, but you can display 160B (160x4) graphics along with 160A (160x2) graphics. (there are similar pairings with 320A+C and 320B+D). So, for example, you can use 160B on a hero sprite, but use 160A enemy sprites to get more of them on the screen.

 

You can also use DL interrupts to change palettes on the fly, so it's possible to do change color between DLs for horizon sky/land changes, etc. Smooth gradients like those in your mockup background are possible, but they waste a lot more CPU time, which is usually the 7800's most precious resource.

 

Sprites are exactly 1 DL high, so far as Maria is concerned. Taller sprites are just a bunch of stacked sprites - that means you can also use 160A graphics, but use different palettes for each DL-height chunk. This sort of color variation is pretty much free.

 

 

 

I'm also guessing the 160x4 mode is more rarely used because it costs more CPU time due to the doubled bitplanes, and increased time to process the DLLs (due to said extra bitplanes)?

That's accurate. A 160x4 object takes a bit less than twice the DMA time for an equivalent 160x2 object. Since 160x4 uses the colors from all 7800 palettes combined, it also means you need to plan your palette with more care, and may restrict changing palettes on the fly.

  • Like 2
Link to comment
Share on other sites

Welcome! Those are some cool mockups. :)

 

 

I'm not sure I'd put it like you did, but I think you have the essential character of it right. Maria renders everything down to a bitmap scanline in the end, and how the graphics get baked-in (sprite vs tile) doesn't affect the visible character of the graphics. Of course, some things are easier for Maria to bake-in than others, which affects how many things Maria can bake-in overall; characters/tiles eat up more of Maria's scanline rendering time than sprites. (aka DMA time) Using 160x4 objects takes a bit less than twice the amount of DMA time than 160x2 objects. So, for example, using 160x4 tiles everywhere will cut down a fair bit on the number of sprites you can display.

 

That doesn't mean the game background needs to be restricted to 3 colors. You can break up a screen into different 160x2 areas, with each area having different DL entries using different palettes. This complicates scrolling code a bit, but otherwise it's relatively easy to do.

 

It may not have been clear from your reading of the docs, but you can display 160B (160x4) graphics along with 160A (160x2) graphics. (there are similar pairings with 320A+C and 320B+D). So, for example, you can use 160B on a hero sprite, but use 160A enemy sprites to get more of them on the screen.

 

You can also use DL interrupts to change palettes on the fly, so it's possible to do change color between DLs for horizon sky/land changes, etc. Smooth gradients like those in your mockup background are possible, but they waste a lot more CPU time, which is usually the 7800's most precious resource.

 

Sprites are exactly 1 DL high, so far as Maria is concerned. Taller sprites are just a bunch of stacked sprites - that means you can also use 160A graphics, but use different palettes for each DL-height chunk. This sort of color variation is pretty much free.

 

 

Thank you, and thank you for replying! :) I think that helps clarify things a bit. When you refer to "baked-in", do you essentially mean the programmer setting up some kind of software environment using the DLs along with the other game code during vblank that tells the MARIA chip how to output each scanline for the upcoming display period? What sprites have moved, where they have moved to, what tiles have scrolled a pixel or so, how many pixels and in what direction, etc. You know, all the important stuff

 

It's strange, to me, that the 7800 can push around so many sprites so well, particularly 160A sprites, but it has a harder time with scrolling bg tiles. I'm guessing static, non-scrolling background graphics are generally super easy and it's the scrolling background stuff that kills it, in particular, because it has to be done more or less by hand, in the code, by wrapping/bumping the graphic data using various DLs and MARIAs char/tile mode... which is expensive on the 6502. I.e., it's not something that is "accelerated", as they say, though it is supported and simplified somewhat via the char/tile or "indirect" mode.

 

Yes! I was going to ask about mixing graphic modes and such. So having a 160b sprite mixed in with other 160a NPC sprites is ok? That's some nice flexibility!

 

I figured having different areas of the screen, specifically horizontal lines/layers, using different graphic modes and/or palettes might be ok. I think I've seen similar in 7800 games and just assumed it was using some ye olde horizontal interrupt trick. The background image in my mockup I just kind of threw in there last minute, but it's good to know the 7800 can do super smooth gradients like that!

 

Woah, so let me get this straight... you can "cheat", and build a higher color 160a sprite by stacking 160a DLs vertically? That's both clever and awesome! :D

Edited by Fragmare
Link to comment
Share on other sites

when I referred to "baked-in", I was referring to the process of Maria traversing the DLL+DL memory structures, pulling out sprite and tile info, and drawing them on it's internal linebuffer.

 

 

It's strange, to me, that the 7800 can push around so many sprites so well, particularly 160A sprites, but it has a harder time with scrolling bg tiles. I'm guessing static, non-scrolling background graphics are generally super easy and it's the scrolling background stuff that kills it, in particular, because it has to be done more or less by hand, in the code, by wrapping/bumping the graphic data using various DLs and MARIAs char/tile mode... which is expensive on the 6502. I.e., it's not something that is "accelerated", as they say, though it is supported and simplified somewhat via the char/tile or "indirect" mode.

That's pretty accurate. The reason why I earlier said that 6502 cycles are usually the most precious resource, is because a good chunk of the time the 6502 is building-up or modifying display list structures.

 

But tiles are extra expensive compared to sprites simply because Maria has to do more work to get to the graphics, compared to sprites. In the case of sprites, the DLL points to the location of the sprite bitmap. In the case of tiles, the DLL points to the character/tile buffer. Then Maria has to look up each character value in the buffer, and add them to the character set graphic location.

 

 

Yes! I was going to ask about mixing graphic modes and such. So having a 160b sprite mixed in with other 160a NPC sprites is ok? That's some nice flexibility!

Yep. Each mode can be mixed with it's alternate mode anywhere on the screen.

 

 

Woah, so let me get this straight... you can "cheat", and build a higher color 160a sprite by stacking 160a DLs vertically? That's both clever and awesome! :D

Agreed. :)

Link to comment
Share on other sites

The 7800 GPU uses several data structures to generate graphics. The screen is first broken into zones which are 1-16 lines high. The graphics for each zone are generated based on a display list (which is very different from the A8 display list). The display list contains a series of entries which describe either a sprite or a series of characters (i.e. tiles).

 

Each display list entry contains the following:

1. horizontal position of the leftmost pixel (-96 to 159)

2. 16 bit address of either a list of characters or the graphics data for the last row in the zone

3. 3 palette bits

4. number of bytes of graphics or characters

5. an optional bit to change the bits per pixel

 

For indirect (character/tile) mode, the characters are used as the LSB of the address of one or two bytes of graphics data for the last row in the zone.

 

So on the 7800 scrolling the background or a sprite horizontally is relatively easy - just update the horizontal position of the appropriate display list entries. Vertical scrolling backgrounds are trickier as you need to fiddle with the height of the first and last zone and the CHARBASE register for the last zone. For sprites, vertical motion means adding the sprite to multiple zones and updating the MSB of the address. (See https://sites.google.com/site/atari7800wiki/graphics-programming/vertical-motion)

Link to comment
Share on other sites

Those animations are great! Imagine NG on the 7800! I like the 1st animation the best. But seriously people don't even think the 7800 can scroll horizontally except us. I remember the Zelda demo was cool here that did it flawlessly better than that junkyard kid game even.

Link to comment
Share on other sites

Those animations are great! Imagine NG on the 7800! I like the 1st animation the best. But seriously people don't even think the 7800 can scroll horizontally except us.

 

A lot of people misinterpret what technical people say.

 

An engineer says, "it's more work to get a nice smooth scrolling display on the MARIA than the NES" and it inevitably shows up somewhere as "I hear the 7800 can't scroll".

 

Usually I end up shaking my head, going, "Have you actually played more than two or three titles in the 7800's library?"

  • Like 2
Link to comment
Share on other sites

when I referred to "baked-in", I was referring to the process of Maria traversing the DLL+DL memory structures, pulling out sprite and tile info, and drawing them on it's internal linebuffer.

 

 

 

That's pretty accurate. The reason why I earlier said that 6502 cycles are usually the most precious resource, is because a good chunk of the time the 6502 is building-up or modifying display list structures.

 

But tiles are extra expensive compared to sprites simply because Maria has to do more work to get to the graphics, compared to sprites. In the case of sprites, the DLL points to the location of the sprite bitmap. In the case of tiles, the DLL points to the character/tile buffer. Then Maria has to look up each character value in the buffer, and add them to the character set graphic location.

 

 

 

Yep. Each mode can be mixed with it's alternate mode anywhere on the screen.

 

 

 

Agreed. :)

 

 

The 7800 GPU uses several data structures to generate graphics. The screen is first broken into zones which are 1-16 lines high. The graphics for each zone are generated based on a display list (which is very different from the A8 display list). The display list contains a series of entries which describe either a sprite or a series of characters (i.e. tiles).

 

Each display list entry contains the following:

1. horizontal position of the leftmost pixel (-96 to 159)

2. 16 bit address of either a list of characters or the graphics data for the last row in the zone

3. 3 palette bits

4. number of bytes of graphics or characters

5. an optional bit to change the bits per pixel

 

For indirect (character/tile) mode, the characters are used as the LSB of the address of one or two bytes of graphics data for the last row in the zone.

 

So on the 7800 scrolling the background or a sprite horizontally is relatively easy - just update the horizontal position of the appropriate display list entries. Vertical scrolling backgrounds are trickier as you need to fiddle with the height of the first and last zone and the CHARBASE register for the last zone. For sprites, vertical motion means adding the sprite to multiple zones and updating the MSB of the address. (See https://sites.google.com/site/atari7800wiki/graphics-programming/vertical-motion)

 

 

Awesome, thanks for the help, folks! I think I have enough info to do some proper 7800 pixel/game art now. :)

 

 

 

Those animations are great! Imagine NG on the 7800! I like the 1st animation the best. But seriously people don't even think the 7800 can scroll horizontally except us. I remember the Zelda demo was cool here that did it flawlessly better than that junkyard kid game even.

 

Thanks! And I think it would have been great! :) I knew the 7800 had a lot more juice than its game library lets on. I just wanted to get some clarification on what and how it does what it does.

 

Incidentally, I'm also looking into the sound hardware, as well. I started familiarizing myself with RMT the other day and came up with a POKEY cover of a NES Ninja Gaiden tune, which I posted in the RMT thread > http://atariage.com/forums/topic/264684-pokey-rmt-by-eckhard/page-2?do=findComment&comment=3749709

Edited by Fragmare
  • Like 1
Link to comment
Share on other sites

  • 3 months later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...