Could the 7800 reproduce the same number of enemy sprites as the arcade version of Gauntlet?

[+Pac-Lander]

Much is made of the 7800's strengths in handling a lot of sprites at once. But what's the limit? Could it theoretically pull off a near arcade version of Gauntlet, at least in regards to enemy sprite count?

 

For comparison/reference:

 

 

8-bit Sega Master System

The SMS version did a decent job of reproducing the arcade original, with some limited animation to help its cause. 

 

 

 

 

 

8-bit NES

Both Gauntlet I and II on the NES were fairly limited with their sprite count, but mostly avoided flicker. Gauntlet II was the more faithful to the arcade version, both in terms of artwork and gameplay. 

 

 

 

 

 

 

16-bit Sega Genesis

A definitive console port of the arcade original, Gauntlet 4 would be the target for sprite count if the 7800 could indeed exceed it's 8-bit counterparts above. 

 

 

 

Arcade

 

 

[+Defender_2600]

Why not?

 

 

 

 

Edited April 4, 2022 by Defender_2600

[+Pac-Lander]

42 minutes ago, Defender_2600 said:

Why not?

 

 

 

 

 

I thought about Robotron, but how much of it has to do with being against a black background?

 

Would a map of maze tiles occupying the same screen prevent this from being possible? Or would it have no effect?

[+Gemintronic]

The NES ports used tiles instead of sprites.  Not sure if you can use the same strategy on the 7800.

[+Defender_2600]

7 hours ago, aaron1677 said:

Would a map of maze tiles occupying the same screen prevent this from being possible? Or would it have no effect?

 

I don't know if the Dark Chambers engine is the most efficient solution and approach, but I'm curious to see how many sprites it can generate if the player isn't shooting ...

 

 

 

Edited April 4, 2022 by Defender_2600

[+Defender_2600]

6 hours ago, Gemintronic said:

The NES ports used tiles instead of sprites.  Not sure if you can use the same strategy on the 7800.

 

This also explains the reduced number of colors on screen since the NES can only use 4 palettes for tiles.

 

The equivalent mode on the 7800 is practically the reverse, so using sprites as tiles, the advantage is that you have all 8 palettes available for use.

 

[ZylonBane]

Midnight Mutants pretty well demonstrates the limits of the 7800 when drawing sprites against a scrolling background. It doesn't take a lot of monsters lined up in a row before they start flickering.

[+Defender_2600]

3 hours ago, ZylonBane said:

Midnight Mutants pretty well demonstrates the limits of the 7800 when drawing sprites against a scrolling background. It doesn't take a lot of monsters lined up in a row before they start flickering.

 

This looks much more efficient than Midnight Mutants:

 

 

Edited April 5, 2022 by Defender_2600

[+Defender_2600]

However, only if it is really useful and necessary to replicate the arcade experience, it is still possible to draw only the graphics of the walls and exclude the graphics of the floor, in order to have more sprites on screen (as the C64 and Amstrad CPC versions do).

Edited April 5, 2022 by Defender_2600

[ZylonBane]

Blank floors have nothing to do with sprites. The floors are blank in some Gauntlet ports because all the monsters are character/tile graphics, and they didn't have enough memory to bake each floor pattern into each enemy graphic.

[+Defender_2600]

In the comparison I intended to refer exclusively to the aesthetic result but thanks for having said it better.

[+Defender_2600]

Perhaps a better compromise, use sprites as tiles and only include the floor where the sprites are not placed, so without any overlapping sprites, as does the NES version which only uses tiles as sprites.

[ZylonBane]

Does anyone have any idea what he's trying to say?

[Traxx]

2 hours ago, ZylonBane said:

Does anyone have any idea what he's trying to say?

What do you mean?I'm sure a port of gauntlet can be done but just like all older consoles some compromises will have to be made.For Tron I'm using indirect sprites for the tanks,bike stages and direct sprites for the cone,spider stages.RevEng would know just how close a gauntlet port could be.

Edited April 8, 2022 by Traxx

[RevEng]

2 hours ago, ZylonBane said:

Does anyone have any idea what he's trying to say?

It's pretty plain to me, but you need to be up to speed with more advanced 7800 homebrew techniques. Instead of sticking with a 7800 tile background - which is either low color or has an overly high cost in terms of DMA - you create a grid of sprites (aka "sprites as tiles") and update the "index" of each of these sprite-tiles directly in the DL. It leans on the Maria's ability to throw a lot of sprites on the screen, and it also avoids Sally burning up all of her cycles on DL formatting and updating.

 

[edit] So he's saying use that, and drive the display like the NES Gauntlet does. i.e. not with independent sprites floating over tiles, but with enemies drawn with the tiles. (albeit with "sprites as tiles", and not native tiles.)

 

[Traxx]

When in doubt what the 7800 can do ask the resident master of 7800 RevEng

[+Defender_2600]

19 minutes ago, Traxx said:

When in doubt what the 7800 can do ask the resident master of 7800 RevEng

 

In truth, for a few decades, the 7800 itself was unaware of having hidden special abilities, until one day RevEng taught him how to do some awesome new things...

 

[RevEng]

I'll say "thanks" and take that all in the intended spirit. I'll just add that we have luckily have an amazing abundance of developers pushing various 7800 boundaries, and I'm no more master than they are. I'm just happy to stand with them.

[+Defender_2600]

Absolutely right, a huge thank you to all the talented developers. And again, allow me to thank those who provided the powerful development tools, also because on some occasions, surely for mere forgetfulness, it was not mentioned. Just give to Caesar what is Caesar's .... wait, I meant, give to Mike what is Mike's.

 

Edited April 8, 2022 by Defender_2600

[+Pat Brady]

5 hours ago, RevEng said:

It's pretty plain to me, but you need to be up to speed with more advanced 7800 homebrew techniques. Instead of sticking with 7800 tile background, which are either low color or have an overly high cost in terms of DMA - you create a grid of sprites (aka sprites as tiles) and update the "index" of each of these tiles directly in the DL. It leans on the Maria's ability to throw a lot of sprites on the screen, and it also avoids Sally burning up all of her cycles on DL formatting and updating.

 

 

Well, "Sprites as tiles" has been mentioned in several threads but AFAIK is not defined anywhere.

 

If I understand correctly, the idea is to use direct mode with one object per grid location ("tile") that combines both background (floor) and foreground (player/enemy/generator/treasure/food) into a single bitmap for that tile. The downside I see is that it requires a lot of graphics data, so it should fit well with SOUPER or bankset.

 

I've given some thought to Gauntlet, and this is what I've come up with:

1. The playfield objects need to use 160B with each tile being 8 pixels wide.
2. Shots probably need to be in separate (direct mode) objects, otherwise the number of bitmaps would explode.
3. For the status bar, most obvious approach is 160A indirect mode.
4. Per-line DMA time is 8+4*3=20 cycles per tile (plus 2 cycles for the first column since 5-byte header is necessary to toggle write mode) for the playfield and 10+10*6=70 cycles for the status bar.
5. One option is 15 playfield tiles (same as arcade), and 10 status characters (1 less than arcade, probably fine), but there can be only 2 shots per zone before running out of DMA time, and 2 shots per zone is definitely not enough.
6. More programming work (and CPU cycles and RAM), but I think the status bar can be done in a single direct mode object with the bitmap in RAM, saving enough DMA time to add 2 shots per zone for a total of 4.
7. That's still not enough (on levels with demons or lobbers) but where to go from there is a matter of opinion. I'd be inclined to flicker shots instead of shrinking the playfield.
8. Vertically, 15 zones of 13 pixels each would make the playfield nice and square (both overall and per tile), the same grid size as the arcade, and works out to 195 lines, a good number; score/health digits would be 3x5 which is also good.

So to answer the original question, I think it is possible, but of course you never know for sure until you try. CPU cycles will be precious, and 8x13 sprites might be a challenge for the artist.

 

3 hours ago, RevEng said:

I'll say "thanks" and take that all in the intended spirit. I'll just add that we have luckily have an amazing abundance of developers pushing various 7800 boundaries, and I'm no more master than they are. I'm just happy to stand with them.

 

I agree with this, but the work you've put into a7800 and documentation is a huge reason why that's the case.

[+Defender_2600]

Just a few quick thoughts, all the graphics in 160B would be gorgeous but if that took too many cycles I think 160A is enough for the graphics of the walls, floor and some enemies, plus I quite like the graphics of Atari 8 bit, C64 and Amstrad versions.

 

Sprites / tiles may fit 8 * 16 or 8 * 14 but I would recommend avoiding 8 * 13 because odd numbers can be a complication if you want to smooth the speed of horizontal and vertical scrolling. 320A mode could be used for the letters and numbers of the status.

Edited April 9, 2022 by Defender_2600

[+Defender_2600]

I always thought Kevin Bulmer did an excellent job converting sprites to 8 * 16, plus the multicolored ones, of the Amstrad CPC version, really look like they were designed for 160B mode. There would still be enough cycles available to make the walls and the floor in 160A mode.

 

https://www.spriters-resource.com/amstrad_cpc/gauntlet/