Comix Zone: most technically impressive "16 bit" game?

You can talk about almost anything that you want to on this board.

Moderator: Moderators

psycopathicteen
Posts: 3140
Joined: Wed May 19, 2010 6:12 pm

Re: Comix Zone: most technically impressive "16 bit" game?

Post by psycopathicteen »

One thing that is frustrating me with the SNES lately is the lack of good hardware multiplication and division. I'm still up in the air over which would be my preferred method.
User avatar
TOUKO
Posts: 306
Joined: Mon Mar 30, 2015 10:14 am
Location: FRANCE

Re: Comix Zone: most technically impressive "16 bit" game?

Post by TOUKO »

'm not talking about 8-pixel sprites. I'm talking about slivers, which are single-line tile slices.
Ah ok, it was in the sprites caracteristics, this is why i misunderstood,because for me it's obvious that a tiles based system, can fill the entire screen width with tiles,and i did not see the point in specifying it.
Same with the SNES. You can't hit the 34-sliver limit with 8x8 sprites because you can only render 32 of them. But with 16x16 or larger, you hit the sliver limit first.
Yes, but in practice it's not really the same to put 32 8x8 sprites and 20,and if we take in account the resolution, it's 32 vs 16 in H32 :wink:
The snes can fill an entire line with his 8x8 sprites before reaching the limit,and the Md cannot,but the Md has a more flexible sprites engine .
93143
Posts: 1717
Joined: Fri Jul 04, 2014 9:31 pm

Re: Comix Zone: most technically impressive "16 bit" game?

Post by 93143 »

Just FYI, I changed the description. Somehow I managed to proofread it several times without noticing that I had claimed the tile data for SNES sprites was in ROM. To be clear: the two 8 KB tile data tables used to render sprites on the SNES are in VRAM, not ROM.

Unlike the NES PPU, the S-PPU in the SNES can't access the cartridge, so obviously the sprite system doesn't care how the tile data is stored there...
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Comix Zone: most technically impressive "16 bit" game?

Post by tepples »

On the other hand, different tile compression methods are applicable to packed pixels (on the Genesis and GBA) vs. bit planes (on the SMS, TG16, and Super NES). With 2bpp tiles on NES and Game Boy, for example, I've had success with RLE based on a byte from previous row of the same bit plane.
User avatar
Fisher
Posts: 1249
Joined: Sat Jul 04, 2015 9:58 am
Location: -29.794229 -55.795374

Re: Comix Zone: most technically impressive "16 bit" game?

Post by Fisher »

Ah, the Megadrive!!

I was really impressed when I saw El Viento's opening back in the day.
Strider impressed me too, It looked awesome.
Both consoles have their ins and outs, and even today I can't decide wich one (MD/SNES) is my favourite. I like many games on each console.

The best voice clips that I remember were from Strider 2 and Justice League Task Force.
Both are not great games, Strider 2 had great between stages voice clips, Justice League is barelly playable, but the Apocalypse's voice on the opening was very cool!

Didn't Comix Zone had a PC version?
I think I remember to have played it with general midi music, wich on my old AWE32 sounded awesome.
Unfortunatelly, I only played the MD version on emulators, it's a very nice game!!
93143
Posts: 1717
Joined: Fri Jul 04, 2014 9:31 pm

Re: Comix Zone: most technically impressive "16 bit" game?

Post by 93143 »

tepples wrote:On the other hand, different tile compression methods are applicable to packed pixels (on the Genesis and GBA) vs. bit planes (on the SMS, TG16, and Super NES). With 2bpp tiles on NES and Game Boy, for example, I've had success with RLE based on a byte from previous row of the same bit plane.
Okay, but that's only relevant to the S-CPU, and/or any special chip assisting with graphics decompression and/or rendering. The S-PPU's sprite handling circuits (which is what I meant by "sprite system") couldn't care less how the tiles got into VRAM, as long as they're there.
User avatar
Drew Sebastino
Formerly Espozo
Posts: 3496
Joined: Mon Sep 15, 2014 4:35 pm
Location: Richmond, Virginia

Re: Comix Zone: most technically impressive "16 bit" game?

Post by Drew Sebastino »

Fisher wrote:Strider impressed me too, It looked awesome.
Easily one of the best looking home ports of the time, imo. You can really tell it was made by Sega and not Capcom, because there's no way they would have done close to as good of a job... I actually prefer the music in this version of the game; it sounds a lot scarier, imo.
Fisher wrote:Didn't Comix Zone had a PC version?
I think I remember to have played it with general midi music, wich on my old AWE32 sounded awesome.
Correct; it was the first in the line of Sega PC games.You can tell any screenshot of it apart from the console version because they recolored the health bar blue, for whatever reason.

I have no idea what the midis sound like, but I'm not sure if they can touch this: https://www.youtube.com/watch?v=o1QAKVfRFas&app=desktop Probably my favorite Genesis music, particularly the final boss; so awesome...
93143 wrote:Okay, but that's only relevant to the S-CPU, and/or any special chip assisting with graphics decompression and/or rendering
Since you were talking about it, I wonder how badly the SNES's graphics format would affect rendering the variable width font generation in the game.
93143
Posts: 1717
Joined: Fri Jul 04, 2014 9:31 pm

Re: Comix Zone: most technically impressive "16 bit" game?

Post by 93143 »

I imagine you could render them into WRAM beforehand, if they didn't fit in the desired size of ROM. There's not that much text; this isn't an RPG script.

The sample work to do justice to the music would probably take a fair bit of space. The graphics might be more compact, since the resolution is slightly lower...
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Comix Zone: most technically impressive "16 bit" game?

Post by tepples »

Drew Sebastino wrote:Since you were talking about it, I wonder how badly the SNES's graphics format would affect rendering the variable width font generation in the game.
Does the VWF implementation in the NES or Game Boy port of 240p Test Suite feel laggy to you?
Oziphantom
Posts: 1565
Joined: Tue Feb 07, 2017 2:03 am

Re: Comix Zone: most technically impressive "16 bit" game?

Post by Oziphantom »

Proportional font rendering doesn't lag on the C64(in a text box case), and it has the same tile based "bitmap", having 3.58x the Mhz and 816 - not a problem.
psycopathicteen
Posts: 3140
Joined: Wed May 19, 2010 6:12 pm

Re: Comix Zone: most technically impressive "16 bit" game?

Post by psycopathicteen »

tepples wrote:On the other hand, different tile compression methods are applicable to packed pixels (on the Genesis and GBA) vs. bit planes (on the SMS, TG16, and Super NES). With 2bpp tiles on NES and Game Boy, for example, I've had success with RLE based on a byte from previous row of the same bit plane.
viewtopic.php?f=12&t=19098

This might be able to come in handy, although it's still not fast enough to convert an entire 256x224 screen from packed to planar in a single frame.
turboxray
Posts: 348
Joined: Thu Oct 31, 2019 12:56 am

Re: Comix Zone: most technically impressive "16 bit" game?

Post by turboxray »

The SNES, in general cases, has the worse sprite setup of the SNES, TG16, Genesis. Genesis is clearly superior to both (H40 mode). Have you guys actually played Genesis games?!

In order for the SNES to compete with the Genesis, you'd have to use 8x8 paired with 16x16 mode. And you'd burn through that 128 OAM entries pretty quickly. And still have the disadvantages of 16k, and in banked format. With that 8/16 paired mode, you only get a maximum screen coverage 32k pixels (and all entries would have to be 16x16 sized sprites) using all 128 entries. A 256x224 size screen (no blocked off HUDs) is 57k pixels. And because of the 16k vram limit for sprites, you can only get 32k of unique screen detail regardless of the sprite sizes you use. That's a little more than half the screen. If you're trying to make meta sprites as optimal as possible for scanline limit, then you're meta sprite has chunks of 8x8 paired with 16x16. That's also going to burn through your sprite table, with even less screen sprite realstate. Genesis can cover its 71k pixels of 320x224 with just 70 entries at 32x32, and still have options for 24x, 16x, and 8x - and that entire 71k sprite screen coverage can be unique.

Not to mention the cpu overhead on the SNES side for all the meta decoding into 8/16 pair. So unless you have a shmup or game with small sprites and lots of 8x8 objects all around, the snes 8/16 paired mod is just a super edge case scenario. Once the snes moves into a more usable 16x16/32x32, it loses a LOT to both Genesis and PCE/TG. It's a shame, because the large OAM and 32 sprite per scanline limit (and 272 pixel limit) would have been great if you could choose sizes in multiple of 8x8 cells going all the way up to 32x32. Though it'd still have the 16k limitation.
Last edited by turboxray on Sat Nov 02, 2019 7:38 am, edited 1 time in total.
User avatar
Fisher
Posts: 1249
Joined: Sat Jul 04, 2015 9:58 am
Location: -29.794229 -55.795374

Re: Comix Zone: most technically impressive "16 bit" game?

Post by Fisher »

I think the SNES can DMA tiles to VRAM to "amenise" this problem, not sure when or on what frequency.
Is it correct?
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Comix Zone: most technically impressive "16 bit" game?

Post by tepples »

Super NES DMA can copy data to video memory during vertical blanking or forced blanking. How many tiles depends on how long rendering is turned off. You get eight channels and 165.5 bytes per line for (261 - display height) lines, where display height is 224 lines unless you're extending vblank. (Figures are for NTSC: PAL provides an additional 60 lines of vblank or 9930 bytes per frame.)

DMA capacity based on display height:
  • 224 lines (default): 6123 bytes
  • 208 lines: 8771 bytes
  • 192 lines: 11419 bytes
  • 176 lines: 14067 bytes
Sizes of things commonly copied using DMA:
  • OAM: 544 bytes and one channel
  • CGRAM: 512 bytes (partial updates are shorter) and one channel
  • Each run of consecutive tiles: 32 bytes and one channel
  • Changing the destination address in VRAM: 2 bytes and one channel
  • Nametable row: 32 to 64 bytes and one or three channels
  • Nametable column: 32 bytes and three channels
Channels can be reused at the cost of bytes of DMA time.
93143
Posts: 1717
Joined: Fri Jul 04, 2014 9:31 pm

Re: Comix Zone: most technically impressive "16 bit" game?

Post by 93143 »

Yeah, both SNES and MD can update almost the exact same fraction of the screen worth of tiles via DMA during VBlank (which console can do more depends on how much of OAM/SAT and CGRAM/CRAM need updating, as they are different sizes). Mega Drive can keep going during active display using the FIFO, but it's horribly slow, completely stalls the CPU, and can cause visible artifacting if you update something while it's being displayed, so you probably don't want to do too much of that under normal circumstances.
Post Reply