Comparison of 4th generation ("8/16-bit") system hardware

[Kamahl]

You forgot the 5-layer demo, right? Two of the layers were software scrolled. Because simply scrolling a 32×32 pixel area wasn't enough, so I've put a layer inside your layer so you can scroll while you scroll [/yodawg] :v

No I didn't forget, I misunderstood what you meant by 4x4 tiles (I thought you meant replacing 1/4 of a tile to scroll, kinda like you'd replace a full 8x8 tile).

I wonder how much VRAM would something like this eat up ;P

Depending on the size of the background, less than 10% (if it's "static", just 6%). You can also just use half the trick to get vertical scrolling, and make the horizontal scrolling dynamic tiles. It's flexible .

You'd need that in any devkit anyways.

Yeah but I mean a rather complex encoder just for this algorithm.

I don't think programmers would be happy with 15×15 blocks. 16×16 would be nicer since 16 is a power of two.

16x16 works too, it's just extra pixels that need to be read per 8x8 tile.

Also, analyzing your idea... You've just replicated what Traveller Tales did for the 1bpp FMVs in Sonic 3D =/ (Sega logo and Game Over screen, those two use palette trickeries to store four frames into a single image)

You mean I came up with an algorithm used by such gods? (And yeah, the idea is to store a crap ton of frames on a single image )

[Sik]

No I didn't forget, I misunderstood what you meant by 4x4 tiles (I thought you meant replacing 1/4 of a tile to scroll, kinda like you'd replace a full 8x8 tile).

Nah, I meant rendering the tiles from scratch. I still find it fun how it turned out to be easier to optimize if you left it in tile format instead of bitmap format. Sometimes I come up with optimizations even I don't understand o_O;

Depending on the size of the background, less than 10% (if it's "static", just 6%). You can also just use half the trick to get vertical scrolling, and make the horizontal scrolling dynamic tiles. It's flexible .

Filling the entire screen with completely unique tiles would eat up about as much VRAM as storing a full-screen bitmap. Unless I'm misunderstanding something? Not all the screen is covered by those tiles?

Yeah but I mean a rather complex encoder just for this algorithm.

Dunno, not sure if this would be really that complex. It's not like you're making a lossy FMV encoder or something, where sudden of all you're forced to implement crazy heuristics and such to get the best compression ratio sanely possible.

16x16 works too, it's just extra pixels that need to be read per 8x8 tile.

And probably would be faster, since optimizing powers of two is much easier (binary operations can be performed on them - e.g. bit shifting to replace multiplication and division, and the AND operation to replace modulo). You need to read more stuff, but that'd be outweighted for the extra optimization.

You mean I came up with an algorithm used by such gods? (And yeah, the idea is to store a crap ton of frames on a single image )

Yes, lol =P They use this trick to get extra framerate (since they need to load less tiles into VRAM so transfer bandwidth becomes less of an issue).

EDIT: to give you an idea of how it works:

• Palette for frame #1: 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1
• Palette for frame #2: 0 0 1 1 0 0 1 1 0 0 1 1 0 0 1 1
• Palette for frame #3: 0 0 0 0 1 1 1 1 0 0 0 0 1 1 1 1
• Palette for frame #4: 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1

So essentially they store one frame for every bit of the pixel. Since the format is 4bpp, they can store up to four frames into a single image.

[Kamahl]

Filling the entire screen with completely unique tiles would eat up about as much VRAM as storing a full-screen bitmap. Unless I'm misunderstanding something? Not all the screen is covered by those tiles?

I got the calculations wrong, stupid windows calculator made a division twice .

The PC Engine has 64kB of VRAM.
A tile occupies 32 bytes
You need 896 tiles to fill a 256x224 screen
So 28kB of VRAM, which is a lot (not that bad for the PCE since it can update a ton of crap per frame)

However there's actually no need for the image to be completely different horizontally or vertically -_-, it can be a pattern.
It works perfectly for smaller images... I don't really understand why I didn't see that *facepalm*.
Just repeating the background once horizontally cuts the VRAM requirement in half.

I'm now trying to come up with a way to get line-scrolling, and even better, the possibility to use tiles (almost) freely.

EDIT: Super easy way to get linescrolling
- Only allow a differently scrolling block to use around 28 something different actual colors (this includes repeated colors, so in reality you'll end up with like 8 colors tops ).
- Leave a scanline between scrolling blocks.
- Update colors during scanline.

Success

Dunno, not sure if this would be really that complex. It's not like you're making a lossy FMV encoder or something, where sudden of all you're forced to implement crazy heuristics and such to get the best compression ratio sanely possible.

It's complex to me . Me dumb.

And probably would be faster, since optimizing powers of two is much easier (binary operations can be performed on them - e.g. bit shifting to replace multiplication and division, and the AND operation to replace modulo). You need to read more stuff, but that'd be outweighted for the extra optimization.

The freaking encoder doesn't need to be fast my good man .

Yes, lol =P They use this trick to get extra framerate (since they need to load less tiles into VRAM so transfer bandwidth becomes less of an issue).

EDIT: to give you an idea of how it works:

• Palette for frame #1: 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1
• Palette for frame #2: 0 0 1 1 0 0 1 1 0 0 1 1 0 0 1 1
• Palette for frame #3: 0 0 0 0 1 1 1 1 0 0 0 0 1 1 1 1
• Palette for frame #4: 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1

So essentially they store one frame for every bit of the pixel. Since the format is 4bpp, they can store up to four frames into a single image.

Pretty darn clever.

[kool kitty89]

If they did that then this game is an even bigger fail. If you can scroll freely why limit yourself to a pattern like that?
Specially considering just how few locations there are in the game.

Yup, I checked the game out in mednafen debugger as well as a tile editor. It's a 128x128 pixel image in 8x8 tiles. There are 8 frames total, which is all that's needed since it doesn't scroll vertically (at a different speed).



Well, since they already used dynamic tiles for that - they could have added some additional foreground layer detail/scroll in conjunction with it.

Why bother using dynamic tiles at all though? It's almost no foreground overlapping with the BG, just a few lines and with sparse enough foreground that sprites should have worked fine. (perhaps with moderate flicker with many enemies on-screen in the few cases where a large chunk of foreground was actually present)

Given the memory and overhead wasted for such a limited effect, I don't really see the point to just avoiding a bit of sprite flicker. (especially since using dynamic tiles also limits color and/or leads to attribute clash issues)

[Kamahl]

Why bother using dynamic tiles at all though? It's almost no foreground overlapping with the BG, just a few lines and with sparse enough foreground that sprites should have worked fine. (perhaps with moderate flicker with many enemies on-screen in the few cases where a large chunk of foreground was actually present)

Given the memory and overhead wasted for such a limited effect, I don't really see the point to just avoiding a bit of sprite flicker. (especially since using dynamic tiles also limits color and/or leads to attribute clash issues)

Hey, they at least put some parallax on the game, pretty good looking parallax too for such a simple effect. It was probably all they could think of doing.

[Sik]

The freaking encoder doesn't need to be fast my good man

Don't you need to deal with this block PCE-side at some point though? *confused*

[Kamahl]

Don't you need to deal with this block PCE-side at some point though? *confused*

No, the encoder outputs a bunch of tiles, palettes and a color replacement table - [original, below, left]
All the decoder does is go through each color in the palettes (8-12 palettes so the foreground can look somewhat acceptable ), and replace it with the corresponding new color on the table (below if it scrolled vertically, left if it scrolled horizontally), and/or edit the tilemap if there was an 8 pixel scroll.

For every pixel scrolled it needs to "move" in the colors, which can get a bit expensive (max 7+7 = 14 operations per color).
Best usage would be a maximum of 1 pixel scrolling, then it's no problem.

Everything else is only setup at the start of each level.

[kool kitty89]

Hey, they at least put some parallax on the game, pretty good looking parallax too for such a simple effect. It was probably all they could think of doing.

??? Why would they opt for a more complex/difficult/limited effect when sprites+linescroll alone could be used to similar (or better) effect?

Using linescroll and sprites for parallax were the primary options on the PCE . . . dynamic tiles were more complex, "extra" effects that were possible.

Similar to Stef's comments:

Are you sure about the dynamic tiles ?
What i see is a simple background plan + some sprites used on the first plan when it overloads the tree part. It's much more simpler to do this way.

Indeed, barely noticeable but we can see it if we watch carefully. That explains the so tiled background...
Anyway it's quite surprising they used that method since sprites would have be sufficient to fake the foreground.

[Sik]

??? Why would they opt for a more complex/difficult/limited effect when sprites+linescroll alone could be used to similar (or better) effect?

Not sure if it was actually more complex (especially given other levels were already doing this, so it was just a matter of reusing already existent code). Remember, they'd have needed to first make all the level foreground, then make sprites exclusively for it, then program every single piece of scenery as new objects. Not to mention it would have been harder to tweak, and that we don't know if they were making room in case they wanted to do anything more complex. Considering that, maybe it was faster to just do parallax with dynamic tiles.

[tomaitheous]

Using linescroll and sprites for parallax were the primary options on the PCE . . . dynamic tiles were more complex, "extra" effects that were possible.

Dynamic tiles are much more the norm than sprites for doing multilayered scrolling on the PCE. For level/area being discussed, you'd have to change enemy behavior or make some sort of exception code for when you reach the tomb entrance part. Maybe they didn't want to limit the game design in that way.

[Kamahl]

Not sure if it was actually more complex (especially given other levels were already doing this, so it was just a matter of reusing already existent code). Remember, they'd have needed to first make all the level foreground, then make sprites exclusively for it, then program every single piece of scenery as new objects. Not to mention it would have been harder to tweak, and that we don't know if they were making room in case they wanted to do anything more complex. Considering that, maybe it was faster to just do parallax with dynamic tiles.

^

[kool kitty89]

Dynamic tiles are much more the norm than sprites for doing multilayered scrolling on the PCE. For level/area being discussed, you'd have to change enemy behavior or make some sort of exception code for when you reach the tomb entrance part. Maybe they didn't want to limit the game design in that way.

With dynamic tiles used, they could have added a lot more than the limited overlapping sections . . . albeit that would then take more animation, so I guess the large sections of linescroll (with no overlap effects) make sense too.

On that note though, you shouldn't have to limit enemy behavior or such if sprites were used for the foreground . . . just support flicker on enemies when sprite overloading occurs. (granted, that adds complexity too -as does the need to manage additional sprite objects for the foreground in general)

[Kamahl]

Well, at least this thread has resulted in 2 full parallax tricks (sprite foreground and color encoding) for the PCE. Still disappointed by the lack of flaming/trolling.

[Sik]

With dynamic tiles used, they could have added a lot more than the limited overlapping sections . . . albeit that would then take more animation, so I guess the large sections of linescroll (with no overlap effects) make sense too.

Just because you can make more doesn't mean you have to make more. Especially if that means added development time.

On that note though, you shouldn't have to limit enemy behavior or such if sprites were used for the foreground . . . just support flicker on enemies when sprite overloading occurs. (granted, that adds complexity too -as does the need to manage additional sprite objects for the foreground in general)

Actually, that wouldn't work, because the sprites that would be missing are always those at the bottommost depth, so the end result is that the level foreground would go missing, not the enemies. Flickering is always implemented by swapping the order in which sprites are drawn, but this means that overlapping sprites will flicker as their drawing order is always swapped every frame.

[kool kitty89]

Shifting gears a bit, there's been some ongoing discussions (mainly between Crazyace and me) on the Flare/Konix Slipsteam/Multisystem design and Atari Panther in this thread:
http://www.sega-16.com/forum/showthr...p?17275/page11
But it really doesn't fit in the "32/64-bit" console thread.


Crazyace, where did you find detailed information/documentation on the Panther? (all I've seen is the limited files from Atarimuseum -with the sample code and such, but no manual or such)

From what I gather, the Panther object processor worked rather like MARIA (in that it was a list processor building the display a line at a time, loading "sprite" graphics into an on-chip double buffered scanline buffer). MARIA worked mainly with graphics in ROM and RAM used mainly for the lists and CPU data variables, but was the Panther intended to rely on that too, or use RAM more heavily for graphical storage. (32k isn't much to load into, along with the lists and 68k data -assuming most code and read-only data was read from ROM)

If it was reading from ROM, that would also imply the use of fairly fast ROMs on a wide (32-bit) bus . . . or a serious bottleneck for slow and/or 16-bit ROM. Using fast and wide ROMs (and the larger PCB connector needed for a 32-bit bus) would seriously compromise the cost effectiveness of the system, so that really wouldn't make sense at all for what they were aiming at. (a cheap base system with expensive to make software -or games limited to comparably small ROM sizes- doesn't make sense)
On top of that, reading straight from ROM would mean all graphics would need to be uncompressed, further exacerbating cost effectiveness. (ie either having very costly games or very small/limited games)

So in that context, it would have made far more sense to retain a small chunk of SRAM for fast list reading (and possibly select graphics) and a larger buffer of cheap DRAM to decompress/buffer into (allowing slow/narrow/cheap ROM to be used, and allowing compression to improve cost effectiveness even more) . . . even without FPM support, DRAM of the time should have allowed ~187 ns accesses (ie 3 16 MHz cycles) or even at 250 ns it would be much better than cheap/slow ROM of the time (especially with DRAM at 32-bits vs cheap ROM at 16-bits). Such DRAM could also have been used as 68k work RAM with few/no wait states (vs many waits in slow ROM and very limited use of SRAM).
. . . But then you could compare SRAM to DRAM in general and the Panther would still have roughly 2/3 the speed for accesses of DRAM vs the 125 ns SRAM access, let alone if it had been designed around optimal use of FPM access (especially since it's already designed around serial bus sharing between CPU and OPL, packed pixels, and reading into internal lime buffers, so a fair amount of fetching should cater to FPM anyway) which would have allowed even closer to the same bandwidth as SRAM (125 ns FPM accesses, plus additional waits for page breaks and refresh) . . . and using only a single bank of DRAM with no SRAM at all would be even more cost effective. (and more realistically allow more RAM to be used -256k DRAM would have been pretty cheap around 1990, let alone later on, and that's also a good size as 2 64kx16-bit DRAMs could be used with relatively limited board space/traces)


Also, the panther has 32 CRAM entries, but a range of color depths per-object of 1, 2, or 4-bits, right? (I assume there's not 8bpp 32 color support . . . though the extra 3 bits could have gone to use too -even with the 32 entry CRAM limit, you could have things like halfbright/shadow/hilight or direct 1-1-1 RGB control)
Is that set up as segments in CRAM (ie 4-bits would have 2 15 color palettes to choose from) or is an offset used to allow more flexible use of the colors. (ie 4-bit could use any 15 consecutive colors starting at 0 to 17 and ending at 14 to 31 for 18 different "palettes" to choose from -assuming 1 object color was always mapped as transparent; thus a 1-bit object could be any 1 of the 32 colors, or a 2-bit object could be any 3 consecutive colors)





I was also thinking on the slipstream again in the context of 4bpp rendering. Single-pixel precision overwriting/masking in 4-bit mode requires a read before each write, but does that have to be an 8-bit read/write (for only 1 or 2 pixels at a time), or could it be a 16-bit read/write? (even with the byte-addressable RAM limitation, it would be really useful if the blitter could read 4 4-bit pixels from a sprite/texture, then read a 4-pixel word from the destination in the framebuffer, and write a full 4 pixels to the framebuffer) That sort of operation would be far more competitive with the 8bpp modes, or potentially faster (per pixel) than 8bpp rendering since you'd need 3 accesses to blit 4 pixels rather than 2 accesses to blit 2 pixels. (or, aside from CPU/VDC overhead, 8 Mmix/s vs 6 Mpix/s -and an even wider gap with VDC overhead included since 4-bit lowres mode takes 1/2 the bandwidth to display)

Of course, even drawing like that (assuming you could), you'd only approach peak bandwdith for sprites/textures of multiples of 4 pixels wide and if blitted on byte allignment rather than nybble allignment. (so an object could be positioned to a 128x200 grid of a 256x200 screen, but actual blitting/overwriting would be done with transparent pixels on 4-bit pixel-precise boundaries; rendering with actual 256x200 precision for positioning would mean more loss in bandwidth as you'd often be handling less than 4 pixels at a time)