In reply to a post about Cannon FodderReal hardware sounds better too.
Also oh god I found a serious contender for the "GBC game that looks like GBA" place
Toki Tori
Sik wrote:
Real hardware sounds better too.
Also oh god I found a serious contender for the "GBC game that looks like GBA" place
https://youtu.be/KTzRpHrXS_w?t=27Ah, good old Toki Tori. The separate far background is an impressive trick. I've only seen it done in this game and Shantae, as far as retail GBC games are concerned.
Shonumi wrote:
The separate far background
Could be wrong but I think that's called parallax scrolling. (The GBC can do it of all handhelds, who knew?)
Parallax scrolling is when there are multiple layers scrolling at different speeds to simulate depth, but this effect in particular is special because it has overlapping layers in a system that only has 1 background layer. When the layers don't have overlapping details, parallax scrolling is just a cheap effect that can be achieved with a simple mid-screen scroll change, but with overlapping details you have to manipulate the patterns according to the movement of the camera. There's nothing revolutionary about this trick being used in a GBC game though, seeing as several NES games used it, including
Battletoads.
It's a lot easier on the GBC than on the NES or original Game Boy because the GBC has
CHR HDMA, which copies 16 bytes to video memory in every hblank.
Was looking closer (including other levels) and the parallax layer seems to be 64×64 (Shantae's is just 8×8, people!). How the heck did they pull off that? Only thing that comes to my mind is to have 8 copies (for each of the possible pixel-level tile rotations) and then do several DMAs, and that'd require 8KB of ROM space (assuming it's uncompressed), although only 1KB of CHR-RAM. That may have been feasible, though...
Still, yikes.
EDIT: oh, and just to put it into context: on the Mega Drive I can pull off 32×32 software scrolling in about 34 scanlines (out of 262). That's with a 68000 manipulating an entire 32-pixel row at once (when I do crazy stuff I take it to the extreme :v). Here it's a Z80 (admittedly a sorta fast one) handling four times as many pixels, and on a planar system. So huh yeah, some clever trickery is going on. The method I mentioned is pretty much the first one that came to my mind that seems feasible (and it wastes space, but I guess 8KB by that time wasn't much of a problem, and there's only a handful of different backgrounds).
So yeah, it's actually kind of revolutionary just because of the sheer size of the parallax. Now to figure out how Prehistorik Man does it (since the parallax is infinitely tall), but that one may be cheating more heavily, especially since it's only 32px wide, and a huge chunk seems to be either blank or horizontal stripes (only a tiny portion is an actual bitmap).
The GBC has no problem doing a 1K DMA transfer. Transfer speed is 1 byte per CPU cycle. It can either transfer 16 bytes during HBLANK time for 144 scanlines (up to 2304 bytes), or transfer more during vblank. Vblank period is about 9000 cycles long.
The issue is more the ROM space usage just for that =P (how big were GBC games in general, anyway? also this is a late GBC game too, being from 2001)
Sik wrote:
The issue is more the ROM space usage just for that
In some cases it makes more sense to rotate the pattern in RAM at run time rather than store all the rotations in ROM.
But that'd be too slow, unless you mean rotating at load time and keeping the rotated versions cached in RAM. How much RAM does the GBC have, anyway? (I know it's more than the GB, that's for sure)
Sik wrote:
But that'd be too slow
Yes, but it's not like the gameplay in Toki Tori is incredibly complex... I bet they have the CPU time to do the rotation at run time.
Quote:
unless you mean rotating at load time and keeping the rotated versions cached in RAM
I don't. A 64x64-pixel area has 4096 possible rotations, times 1KB for the 64 tiles equals 4MB of RAM.
Quote:
How much RAM does the GBC have, anyway? (I know it's more than the GB, that's for sure)
I think it's 32KB.
tokumaru wrote:
I don't. A 64x64-pixel area has 4096 possible rotations, times 1KB for the 64 tiles equals 4MB of RAM.
Or you could split it into 16 DMAs and only have to keep 8 rotations, for a grand total of 8KB.
But now that I think about it though the GBC's DMA is aligned to 16 byte addresses, right? So that ruins the fine vertical scrolling part... (that'd still be way more feasible to rotate with the Z80 than doing the full scrolling, because it's just moving bytes around instead of manipulating them - bit rotations are slow since they happen one bit at a time only).
GBC games of this era were huge, like 2MB minimum.
Toki Tori in particular is 1MB.
Dwedit wrote:
GBC games of this era were huge, like 2MB minimum.
And anybody who wanted to make a smaller game had to pad it out with GIFs and stuff.
The Adventures of Elmo in Grouchland is 2 Mbit (256 KiB), the same size as
Battletoads, but according to
its TCRF article, Nintendo wouldn't manufacture anything smaller than 8 Mbit (1 MiB) anymore.
For chr-ram parallax scrolling, vertical positioning is free because you just change which byte offset you copy from. Horizontal positioning is free every 8th increment, because again, you just change which byte offset you copy from. From here, you have two choices. One choice is to store 8 versions of the original background, each offset horizontally by one pixel, and the other is to shift the pixels in software. For a 64x64 pixel graphic, the worst case scenario is to shift 4 pixels (Instead of shifting 5 pixels, you move to the next byte (effectively shifting 8 pixels) and shift 3 pixels in the opposite direction), which would equate to 4 (shifts) * 8 (bytes per row) * 8 (rows per tile) * 8 (rows of tiles) * 2 (bits per pixel) = 4096 shifts.
A compromise between shift and CPU effort is to store two copies of the 64x64 graphic, with one copy offset by 4 pixels. Here, the worst case scenario is 2 shifts (for 3 shifts, you move to the other table (effectively shifting 4 pixels) and shift once in the opposite direction). Instead of 8 copies of the 64x64 graphic, you only have 2, and instead of a maximum shift of 4 pixels, it's now a max of 2.
I'm not sure how comfortable I'd personally be with a subroutine that burns a variable amount of operations between 0 and 2048 depending on the screen's scroll position, but if it can be proven to not negatively impact the game, then this would be a feasible solution.
Try this: Store half the pattern offset by 4 pixels (or by 2 in the compromise version). Then the number of shift operations is constant no matter what the offset is: 0+4, 1+3, or 2+2.
I'm about to split the discussion of Toki Tori's scrolling.
Drag wrote:
For chr-ram parallax scrolling, vertical positioning is free because you just change which byte offset you copy from.
This is what I thought at first, but then I remembered that the DMA addresses (both source and destination) have to be aligned to 16 bytes (the size of a tile). So the vertical granurality is as bad as the horizontal one (i.e. steps of 8 pixels).
Still, worst case would be 64 different copies, i.e. 64KB. Given the ROM size being mentioned before, that doesn't sound as bad as it may seem at first.