5 ms·

It's crazy to remember that the GBC lacked even Mode 7, of which something comparable wouldn't come to Nintendo handhelds until the Game Boy Advance. A full ray

It's crazy to remember that the GBC lacked even Mode 7, of which something comparable wouldn't come to Nintendo handhelds until the Game Boy Advance. A full raycaster running on the Color, at a high frame rate no less, is a very strange sight. I wonder just how wildly impractical it would have been to build such outboard hardware acceleration into a cartridge in 1998.

CoolGuySteve 10y ago
The SNES had Doom running with a SuperFX 2 coprocessor in 1995. https://www.youtube.com/watch?v=n18tcF4nbqE https://www.youtube.com/watch?v=n18tcF4nbqE The Gameboy had several address banks which allowed for whatever coprocessor you wished to put in, you just DMA out of the address space. I suspect the unit volumes just weren't there to justify the enigineering expense in the Gameboy's case. Coincidentally, the Gameboy game X from 1992 ( https://www.youtube.com/watch?v=AyjU4MtonZM https://www.youtube.com/watch?v=AyjU4MtonZM )was developed by Dylan Cuthbert, who later went on to work on Star Fox and the Super FX chip.
- digi_owl 10y ago
  That Doom music. :D
vanderZwan 10y ago
Someone managed to make this for the TI-83+, which only had a Z80 chip and nothing else: https://www.youtube.com/watch?v=9wjM8ude3Rs https://www.youtube.com/watch?v=9wjM8ude3Rs
- simcop2387 10y ago
  The big difference there is that the gameboy didn't have a way for you to draw on the screen directly. It was a sprite/tile-mapped only system. Same with the NES and SNES, which is why a co-processor such as the SuperFX was needed, to generate the tiles needed for arbitrary graphics. the Megaman X series also used a coprocessor (in 2+ i think?) that allowed them to use compressed data and arbitrary rotation of a sprite by generating the tiles on the fly.
  - camhenlin 10y ago
    Interestingly, in MegaMan X2 and X3, the Cx4 coprocessor built into the game cartridge is used for some very specific wireframe animations used in only very specific areas of each game and was largely unnecessary. (Only 2 scenes in X2: a miniboss and the final boss, and one scene in X3: after defeating the final boss)
    - simcop2387 10y ago
      Interesting, I had thought it did some sprite compression also but it looks like I was confusing it with the SDD-1. There's a lot of neat co-processors out there that got used. It's one of the things I loved about the cartridge era systems because it let them get upgraded in ways you can't do anymore.
  - khedoros1 10y ago
    Some few games on the NES had RAM instead of ROM for graphics storage. Many more games supported bank-switching. Each 8KB bank of graphics tiles would provide enough tiles to uniquely cover a little over 1/4 of the screen, and hsync time would be enough time to switch to the next bank, every 1/4 of the image. I think that transferring 60K of data from the CPU to PPU every frame would be completely infeasible, though. All that in mind, I'm very impressed by how well the game Elite runs: https://www.youtube.com/watch?v=zoBIOi00sEI https://www.youtube.com/watch?v=zoBIOi00sEI
- zeta0134 10y ago
  I remember playing that in high school! That's really impressive use of the tech, and was staggeringly impressive to me at the time. Learning z80 assembly on the TI series got me into programming at an early age. It's worth pointing out that the TI-83(+) contains a proper z80, running at 6MHz, with full support for the z80's extended instruction set and 16-bit arithmetic functions, which certainly helped this game out quite a bit. The Gameboy itself is somewhat underpowered in comparison; its Sharp80 processor is considerably stripped down, lacks most of the extended instruction set, and runs at a slower 4MHz. Given these limitations, I'm (a) staggeringly impressed to see Wolfenstein running on the thing in any capacity, and also (b) totally understand why the coprocessor is necessary to make it work, especially at that buttery smooth framerate. There's no hardware graphics scaling for one, all tech demos I've seen that do scaling appear to be doing so entirely in software and using hblank trickery to speed things up a bit. Doing a raytracer without hardware scaling for the texture lookups (or any ability to rewrite VRAM mid-scanline for that matter) would be pretty tough. It's also curious to point out that this probably wouldn't be possible on the Black and White Gameboy (Pocket); from his frame disassembly, he's using the arbitrary DMA copy hardware exclusive to the Gameboy Color, and I don't think a straight sharp80 copy routine would be able to complete all 120 tiles during a single vblank and still have any room to do much of anything else. I'm presently working on a Gameboy Emulator in Lua, and it seems like this is another esoteric cartridge I'll have a ton of trouble supporting. An entire additional CPU inside the cart! What sorcery :) http://bgb.bircd.org/pandocs.htm#gameboytechnicaldata http://bgb.bircd.org/pandocs.htm#gameboytechnicaldata https://en.wikipedia.org/wiki/TI-83_series#Technical_specifications https://en.wikipedia.org/wiki/TI-83_series#Technical_specifi...
  - vanderZwan 10y ago
    How does one even copy such a cartridge to a file?
deleted 10y ago
[deleted]
ChrisClark 10y ago
I wonder what techniques Faceball 2000 used on the original Gameboy ( https://www.youtube.com/watch?v=iZq31JUYf8M https://www.youtube.com/watch?v=iZq31JUYf8M ) That was the first FPS game I played, and it appears to use a very limited form of raycasting. Maybe just drawing entire walls with one raycast and some scaling.
- mysterydip 10y ago
  It looks like "pop-in" happens frequently on that so I'd wager that a short ray and not very many to create a whole circle (which would necessitate only looking at closer things) meant a ton less calcs per frame.
Frenchgeek 10y ago
http://www.cyberroach.com/vidpac/vidhard/new_vid_c7010.htm http://www.cyberroach.com/vidpac/vidhard/new_vid_c7010.htm

CoolGuySteve 10y ago

The SNES had Doom running with a SuperFX 2 coprocessor in 1995. https://www.youtube.com/watch?v=n18tcF4nbqE https://www.youtube.com/watch?v=n18tcF4nbqE The Gameboy had several address banks which allowed for whatever coprocessor you wished to put in, you just DMA out of the address space. I suspect the unit volumes just weren't there to justify the enigineering expense in the Gameboy's case. Coincidentally, the Gameboy game X from 1992 ( https://www.youtube.com/watch?v=AyjU4MtonZM https://www.youtube.com/watch?v=AyjU4MtonZM )was developed by Dylan Cuthbert, who later went on to work on Star Fox and the Super FX chip.

digi_owl 10y ago
That Doom music. :D

vanderZwan 10y ago

Someone managed to make this for the TI-83+, which only had a Z80 chip and nothing else: https://www.youtube.com/watch?v=9wjM8ude3Rs https://www.youtube.com/watch?v=9wjM8ude3Rs

simcop2387 10y ago
The big difference there is that the gameboy didn't have a way for you to draw on the screen directly. It was a sprite/tile-mapped only system. Same with the NES and SNES, which is why a co-processor such as the SuperFX was needed, to generate the tiles needed for arbitrary graphics. the Megaman X series also used a coprocessor (in 2+ i think?) that allowed them to use compressed data and arbitrary rotation of a sprite by generating the tiles on the fly.
- camhenlin 10y ago
  Interestingly, in MegaMan X2 and X3, the Cx4 coprocessor built into the game cartridge is used for some very specific wireframe animations used in only very specific areas of each game and was largely unnecessary. (Only 2 scenes in X2: a miniboss and the final boss, and one scene in X3: after defeating the final boss)
  - simcop2387 10y ago
    Interesting, I had thought it did some sprite compression also but it looks like I was confusing it with the SDD-1. There's a lot of neat co-processors out there that got used. It's one of the things I loved about the cartridge era systems because it let them get upgraded in ways you can't do anymore.
- khedoros1 10y ago
  Some few games on the NES had RAM instead of ROM for graphics storage. Many more games supported bank-switching. Each 8KB bank of graphics tiles would provide enough tiles to uniquely cover a little over 1/4 of the screen, and hsync time would be enough time to switch to the next bank, every 1/4 of the image. I think that transferring 60K of data from the CPU to PPU every frame would be completely infeasible, though. All that in mind, I'm very impressed by how well the game Elite runs: https://www.youtube.com/watch?v=zoBIOi00sEI https://www.youtube.com/watch?v=zoBIOi00sEI
zeta0134 10y ago
I remember playing that in high school! That's really impressive use of the tech, and was staggeringly impressive to me at the time. Learning z80 assembly on the TI series got me into programming at an early age. It's worth pointing out that the TI-83(+) contains a proper z80, running at 6MHz, with full support for the z80's extended instruction set and 16-bit arithmetic functions, which certainly helped this game out quite a bit. The Gameboy itself is somewhat underpowered in comparison; its Sharp80 processor is considerably stripped down, lacks most of the extended instruction set, and runs at a slower 4MHz. Given these limitations, I'm (a) staggeringly impressed to see Wolfenstein running on the thing in any capacity, and also (b) totally understand why the coprocessor is necessary to make it work, especially at that buttery smooth framerate. There's no hardware graphics scaling for one, all tech demos I've seen that do scaling appear to be doing so entirely in software and using hblank trickery to speed things up a bit. Doing a raytracer without hardware scaling for the texture lookups (or any ability to rewrite VRAM mid-scanline for that matter) would be pretty tough. It's also curious to point out that this probably wouldn't be possible on the Black and White Gameboy (Pocket); from his frame disassembly, he's using the arbitrary DMA copy hardware exclusive to the Gameboy Color, and I don't think a straight sharp80 copy routine would be able to complete all 120 tiles during a single vblank and still have any room to do much of anything else. I'm presently working on a Gameboy Emulator in Lua, and it seems like this is another esoteric cartridge I'll have a ton of trouble supporting. An entire additional CPU inside the cart! What sorcery :) http://bgb.bircd.org/pandocs.htm#gameboytechnicaldata http://bgb.bircd.org/pandocs.htm#gameboytechnicaldata https://en.wikipedia.org/wiki/TI-83_series#Technical_specifications https://en.wikipedia.org/wiki/TI-83_series#Technical_specifi...
- vanderZwan 10y ago
  How does one even copy such a cartridge to a file?

deleted 10y ago

[deleted]

ChrisClark 10y ago

I wonder what techniques Faceball 2000 used on the original Gameboy ( https://www.youtube.com/watch?v=iZq31JUYf8M https://www.youtube.com/watch?v=iZq31JUYf8M ) That was the first FPS game I played, and it appears to use a very limited form of raycasting. Maybe just drawing entire walls with one raycast and some scaling.

mysterydip 10y ago
It looks like "pop-in" happens frequently on that so I'd wager that a short ray and not very many to create a whole circle (which would necessitate only looking at closer things) meant a ton less calcs per frame.

Frenchgeek 10y ago

http://www.cyberroach.com/vidpac/vidhard/new_vid_c7010.htm http://www.cyberroach.com/vidpac/vidhard/new_vid_c7010.htm