NES has a PPU without a CHR-RAM. The CHR-RAM/ROM is located on the cartridge. Depending on the mapper, you can have no animation of ? blocks, yes animation of ? blocks and custom copypasted animation (like with CHR-RAM) which is slow. One fully filled CHR pattern data is 8KB. But how much is it on GBC?
GBC has a CHR-RAM with 2 banks of 8KB in itself and I suppose that the BIOS loads the CHR pattern tables from the cartridge to that place.
Code:
8000-9FFF 8KB Video RAM (VRAM) (switchable bank 0-1 in CGB Mode)
<- this is what it says.
Now, is it possible to do bankswitching where a SMB3 ? block is animated? I need to know this so I can make blocks animated or static.
Is it possible to have multiple enemy banks like in SMB3? If not, would copypasting from PRG-ROM to CHR-RAM be a good option? How do many Pokemon sprites in Pokemon games get loaded?
And where do I begin drawing sprites and where the background? First 256 tiles are background or sprites?
Quote:
One fully filled CHR pattern data is 8KB. But how much is it on GBC?
Game Boy has a total of 8 KiB of video memory. This main background nametable (1 KiB), the window nametable (1 KiB), and CHR RAM (6 KiB). The CHR RAM is divided into 2 KiB for sprites, 2 KiB shared between sprites and background, and 2 KiB for background.
Game Boy Color has twice that. There are two 6 KiB banks of CHR RAM, and each nametable has an additional 1 KiB attribute plane telling which palette, flip, priority, and CHR bank each map space uses. See
pandocs: video display.
Quote:
I suppose that the BIOS loads the CHR pattern tables from the cartridge to that place.
Nope, you have to do that yourself like on NES games with CHR RAM or Super NES games. But it's essentially just implementing
memcpy() unless you want to get fancy with compression. On Game Boy Color, you also have CHR HDMA (character horizontal-blank direct memory access), which copies one 16-byte tile from ROM or RAM to VRAM for each of the 144 scanlines. If you're making a GBC-exclusive game with spinning Koopature Science Floating Storage Cubes, you'll probably want to use CHR HDMA to animate them.
"?" blocks can always be animated, it's just the method of animation that changes depending on the hardware. Fine (1KB or 2KB) CHR-ROM bankswitching is what SMB3 uses, but a CHR-RAM game could do it by overwriting the 4 tiles (64 bytes) in the pattern table.
Ultimately, a game could modify all instances of the animated blocks in the name tables to use other tiles. If I'm not mistaken, the NROM version of Driar does this to animate the stars.
Can the HDMA transfer be done only in H-Blank or can I do multiple those in V-Blank?
And how come if you have 1 background and 1 window that SMB DX has a status bar, level and pause menu at the same time?
The CPU can also access video memory during vblank, but vblank on the Game Boy is much shorter than on the Super NES or even the NES.
8bitMicroGuy wrote:
And how come if you have 1 background and 1 window that SMB DX has a status bar, level and pause menu at the same time?
Open it in an emulator with video debugging and you'll find out.
tepples wrote:
vblank on the Game Boy is much shorter than on the Super NES or even the NES.
Should I use GBA instead then?
8bitMicroGuy wrote:
Should I use GBA instead then?
Are you afraid of constraints? If so, you should target PCs instead. If not, pick the platform you like that can do what you want to do in your game, and when unsure about how to implement something, take cues from existing games that prove that what you want to do is possible.
If you're brave, you can even try things that have never been done before in a certain platform, but then you'll be on your own, since there won't be any existing solutions to study.
8bitMicroGuy wrote:
tepples wrote:
vblank on the Game Boy is much shorter than on the Super NES or even the NES.
Should I use GBA instead then?
Use GBA if your game needs GBA features (affine backgrounds, affine sprites, large sprites, multiple layers, high color depth, color math, more RAM, PCM audio, shoulder buttons, and single-pak multiplayer) or if you're trying to reach users of Nintendo DS or DS Lite. But as I understand the specs, there's so much available time in hblank on GBC that you don't really need vblank except for writing a new sprite display list.
tokumaru: PC has its own constraints, such as audio latency, DLL hell potential, and needing to manually configure controllers whose
button order differs from that of the Xbox 360 controller.
tepples wrote:
But as I understand the specs, there's so much available time in hblank on GBC that you don't really need vblank except for writing a new sprite display list.
To avoid tearing? (same reason why you'd use vsync on a modern system)
My biggest problem is the sprite limit. I'm trying to remake a friend's game made in Game Maker to work on a retro console. It's a 2D platformer and so many sprites are used on a scanline.
If I use arm-gcc with the GBA library, will the code be efficient? Will the compiler correctly link everything at correct GBA databus and ROM addresses or do I need to set the linker up myself?
Which IDE is the best for GBA development, playing and debugging?
The defining character of a "modern" software renderer vs an older hardware dynamic sprite engine is the limited overdraw (& total sprite count). If you just want to not have to worry about it ... you're explicitly wanting to avoid the thing that makes it retro instead of "retreaux".
As far as targeting GCC &// LLVM to ARM, certainly ARM is one of the modern ISAs that both actually care about. But to just say "efficient" is disingenuous; it implies that such a thing has a single optimal choice. it's a hard thing to quantify, and hand-written assembly for many ISAs is often "more efficient". (caveat: humans are usually worse at superscalar and SSE stuff)
Minimal effort to bootstrap yourself is probably something like devkitARM.
If you're hitting the sprite limit hard, GBA might be the best choice. Its CPU is a 16.78 MHz ARM7TDMI (with a lot of wait states), and its PPU produces a 240x160 pixel display with four tiled layers and about 4x sprite overdraw. Get devkitARM.
tepples wrote:
its PPU produces a 240x160 pixel display
That's what kills it for me. (The GBC obviously runs at a lower resolution though.) Just look at how it holds up to the original picture, and even the SNES which isn't exactly renowned for its resolution.
Attachment:
320x240.png [ 38.1 KiB | Viewed 4817 times ]
76800 pixels.
Attachment:
256x224.png [ 53.52 KiB | Viewed 4817 times ]
57344 pixels. Nearly 3/4 as large. (.74 and 2/3.)
Attachment:
240x160.png [ 40.74 KiB | Viewed 4817 times ]
38400 pixels. Half as large.
tepples wrote:
and about 4x sprite overdraw.
I thought it was 5x? I thought I remember hearing that sprite multiplexing cuts it down to 4x for some reason.
For me, retro isn't when the limits ruin your fun, but when you have full freedom on programming something 8-bit or 16-bit pixelated like Mario and when the hardware is dedicated for these stuff. I'll use devkitPro. I think it has devkitARM inside, right?
8bitMicroGuy wrote:
For me, retro isn't when the limits ruin your fun, but when you have full freedom on programming something 8-bit or 16-bit pixelated like Mario and when the hardware is dedicated for these stuff.
You mean like a tile based system? That's why I eventually plan venturing the unknown of the M92 or M107. They are both strong (with the M107 being stronger) and they are both 2D systems. Now that I think about it, I don't think there's ever really been a perfect 2D home system technical wise. I'd say the Sega Saturn, if it weren't for the slow CD technology and limited amount of vram. (Which is held back by the CD drive.) It also isn't great from a programming perspective from what I've heard and would immagine, but I'm not counting that. I'd say the most well rounded is the SNES, but it has a good deal of its own problems. That's why I plan to work on the M92 and the M107 eventually, but I will miss the special effects the SNES offers like transparency, even if some of them aren't the most practical.
8bitMicroGuy wrote:
I'll use devkitPro. I think it has devkitARM inside, right?
I think there's an installer, and it asks what you specifically want. If you chose everything, You'll get DevkitARM but you don't need to if that's all you want.
Espozo wrote:
It also isn't great from a programming perspective from what I've heard and would immagine, but I'm not counting that.
It's much easier than people claim it to be, honestly I was looking at the SDK used by Sega and using it isn't really any more complex than say Allegro (well, pre-5.0 Allegro, that is), it even handles the second processor for you so you don't have to waste time thinking on doing optimized multithreading, and also nearly every tool at the time used N-gons so being stuck with quads wasn't as bad as it sounds. I guess the problem with the Saturn was that the VDP1 lacks support for some stuff the PS1 GPU can do natively (like alpha blending).
Programming it from scratch without Sega's SDK (which you'd need to do to stay legal) is a whole different issue, although again I imagine you don't have to use all of the hardware either (and you aren't doing 3D stuff so that's less complex calculations to deal with).
Sik wrote:
It's much easier than people claim it to be
People have always acted like the SNES was difficult to program for, but I haven't had a problem. (Save the 1/4 of vram for sprites.)
About the Saturn though, it was never really meant to be a 3D system, is that right? It seems like it supports sprites that can be transformed instead of actual polygons.
Espozo wrote:
People have always acted like the SNES was difficult to program for, but I haven't had a problem. (Save the 1/4 of vram for sprites.)
Well, compared to the Mega Drive it
is hard. Besides the CPU's instruction set requiring more verbose code, the format of hardware registers and tables can get really annoying sometimes (and don't get me on how you have to pass data around to the SPC700, the Z80 on the Mega Drive has it bad with the bank switching but in my opinion the SPC700 has it worse). It's much harder to get started from scratch, essentially.
Now, moving from NES to SNES would be like moving to heaven though.
Espozo wrote:
About the Saturn though, it was never really meant to be a 3D system, is that right? It seems like it supports sprites that can be transformed instead of actual polygons.
The PS1 GPU also doesn't know about 3D either, it only sees 2D polygons.
Honestly I get the impression it was always meant to do 3D, it's just that Sega underestimated how important it'd be and Sony went all out as well. Sticking to quads seems dumb now, but back then nearly everything used mostly (or even only) quads and many games of the time handled quads internally (it was still wild times for 3D gaming), so the idea was definitely appealing. Also it seems the second CPU was added just to handle 3D transformations and such to pass preprocessed 2D quads to the VDP1 (the same way the Z80 on the Mega Drive was left with the intention to handle sound).
Also don't get fooled on the fact that there are two VDPs, this is comparable to the two S-PPUs on the SNES: they handle completely different parts (in the case of the Saturn, VDP1 renders quads to the framebuffer, while VDP2 renders the tilemaps).
EDIT: also this post looks like going heavily off-topic ( ・・) Point stands, Saturn is easier to use than it sounds if you aren't trying to push it to its limits (but every system is hard if you're trying that).
Sik wrote:
Well, compared to the Mega Drive it is hard. Besides the CPU's instruction set requiring more verbose code, the format of hardware registers and tables can get really annoying sometimes
I've never had a problem, but I can see how somebody else could. I like having a little amount of registers because it's less to keep track of. (I wouldn't mind having a Z register like the 65CE02 though...) Really, nothing I've made so far has really warranted more than 4 registers. (I use direct page quite a bit now.)
Sik wrote:
Now, moving from NES to SNES would be like moving to heaven though.
Hmm... No one seems to complain about the NES though. (It has a lot more people programming for it.) The SNES seems far more appealing to program for, in my opinion.
Sik wrote:
The PS1 GPU also doesn't know about 3D either, it only sees 2D polygons.
I guess that could be why there's no perspective correction?
Sik wrote:
EDIT: also this post looks like going heavily off-topic ( ・・)
Oh well!
So there isn't a fully functional 2D tile-based hardware system? Like isn't there a way to go around the sprites-per-scanline limit?
By definition, a 2d tile-based hardware system has a sprites-per-scanline limit.
lidnariq wrote:
By definition, a 2d tile-based hardware system has a sprites-per-scanline limit.
I wonder what kind of overdraw the After Burner arcade board (Sega X board I'm pretty sure) had... Also, does this mean that you could potentially see overdraw problems on the Saturn?
Ultimately, it's always about balancing time. All systems, regardless of whether it's scanline-based or framebuffer-based takes a certain amount of time to blit a certain number of pixels. In a framebuffer-based system, that affects the total number of polygons you can have in a scene, but you can make the tradeoff of dropping the total FPS in exchange for drawing more total things.
A tile-based system (not a quad-based system, mind) doesn't give the programmers the ability to make that exchange: there's no framebuffer, and so you only have the time of one scanline to figure out what you're drawing on that scanline. So for the NES you just always get 25% overdraw, because that's how the hardware was designed. This amount of overdraw is a fundamental property when the silicon is designed, and although it could be made arbitrarily huge, there's no point in wasting silicon on something that'll never be used.
Espozo wrote:
lidnariq wrote:
By definition, a 2d tile-based hardware system has a sprites-per-scanline limit.
I wonder what kind of overdraw the After Burner arcade board (Sega X board I'm pretty sure) had... Also, does this mean that you could potentially see overdraw problems on the Saturn?
It was framebuffer based, at least the sprite part. Incidentally, this is exactly the same deal with the Saturn, framebuffer for sprites + dedicated tilemap layers.
Sik wrote:
It was framebuffer based, at least the sprite part. Incidentally, this is exactly the same deal with the Saturn, framebuffer for sprites + dedicated tilemap layers.
What was up with him saying this then?
lidnariq wrote:
By definition, a 2d tile-based hardware system has a sprites-per-scanline limit.
Are the objects that are being translated and scaled on the Sega X Board actually not considered sprites then? I do remember hearing something about how the frame buffer gets rotated instead of actual sprites though. I also remember hearing that the system didn't support tiles, but I thought they just meant BG tiles. So far, it doesn't sound like it could really be considered a sprite based system but rather a really limited PlayStation or something. After reading all this, it seems like the Neo Geo should have been built with this setup, but I'm sure it was expensive back then, and the Neo Geo isn't necessarily what I'd consider a Ferrari in terms of arcade hardware.
I was interpreting "hardware tile-based" as "just-in-time rasters" as opposed to "framebuffer".
Certainly there've been a number of other systems that have hardware-accelerated bitblits with transparency to a framebuffer without scaling or rotation.
Alright. How about sandwiched tile-based system?
Buffer-tiles-buffer-tiles-buffer-tiles-buffer-tiles-buffer.
This way you'll have 4 tile layers and 5 buffers for sprites that you can transform however you want.
Does this exist?
8bitMicroGuy wrote:
Alright. How about sandwiched tile-based system?
Buffer-tiles-buffer-tiles-buffer-tiles-buffer-tiles-buffer.
This way you'll have 4 tile layers and 5 buffers for sprites that you can transform however you want.
Does this exist?
Not that I'm aware of. If it does, it's probably one of Sega's inventions. I know that none of the super scaler series of arcade boards do, but I'd imagine the System 32 would be good enough: segaretro.org/Sega_System_32
Nintendo DS has a sandwich.
The GBA PPU has four tiled layers, and each two can be replaced with a mode 7 layer, or all four can be replaced with a software-drawn frame buffer. Games using 3D rendering, such as Doom and Payback, use a frame buffer mode.
The DS has an upgraded GBA PPU that has two fixed-function tiled layers and two layers that can be switched among tiled, mode 7, or a frame buffer. It also has a 3D unit that renders to a 48-line-tall circular buffer and supports about 6,000 vertices (1,500 triangle or 2,000 quads) per scene. Most games just send this circular buffer directly to one of the screens; others use half of the system's 512K texture RAM for a pair of frame buffers so that they can push more polygons (at a frame rate cost) or do 3D on both screens.
EDIT: I left a word out
But developing homebrew for DS is illegal because it circumvents the security measures and also only the R4 cart can do that and it's been illegalized in UK and Japan. I wouldn't like to be seen having those. GBA is still good because all development kits are legal and the patent of the console has run out.
If you want DS features, make a PC game or move out of the UK and Japan. Here in the States, we have a Supreme Court that ruled in Lexmark v. Static Control Components to limit how successful a "circumvents the security measures" legal theory can be when "the security measures" exist primarily for the purpose of subjecting complementary goods to vendor lock-in. For a while, the major electronics chain Best Buy was selling Datel's Games 'n Music, a DS flash cart that can run only homebrew.
Neither GBA nor GBC is more than 20 years old.
tepples wrote:
The GBA PPU has four tiled layers, and each can be replaced with a mode 7 layer, or all four can be replaced with a software-drawn frame buffer. Games using 3D rendering, such as Doom and Payback, use a frame buffer mode.
I hate to be a stickler for details, but you mentioned the GBA, so I have to.
The GBA allows for up to 4 tiled layers in Mode 0, but successive modes limit the number of available layers. The SNES Mode 7 is not a native mode on the GBA, but it can be emulated via per-scanline BG scaling and rotation operations. Unfortunately all modes that permit these scaling and rotation operations have less than 4 layers. Technically, only BG layers 2 and 3 can be scaled and rotated, so not all four layers can be replaced with a Mode 7 like layer. Additionally, only BG layer 2 can act as a framebuffer for software rendering; all other layers are disabled in Modes 3-5, however.
It would have been amazing to have 4 layers constantly available outside of Mode 0, but things didn't turn out that way. I won't speak about the DS because I've yet to write an emulator for that, nor have I investigated homebrew hardware tests for it.
8bitMicroGuy wrote:
But developing homebrew for DS is illegal because it circumvents the security measures and also only the R4 cart can do that and it's been illegalized in UK and Japan. I wouldn't like to be seen having those. GBA is still good because all development kits are legal and the patent of the console has run out.
Realistically speaking, at worse, you'd get a C&D letter of some sort. Seriously, although any company could come and "get you" with court cases, it's often just not a profitable move to go after some Random Joe Smoe making homebrew games.
I now realize that I had left a word out of my original post, an error that I failed to catch in preview. Would "each two can be replaced" have been more accurate?
- Mode 0: tiled, tiled, tiled, tiled
- Mode 1: tiled, tiled, mode 7
- Mode 2: mode 7, mode 7
Thank you tepples, my nerdish
obsession attention to detail has been satisfied
I'm having trouble understanding modes. Can you tell me which mode is used by Super Mario Advance 4?
8bitMicroGuy wrote:
I'm having trouble understanding modes. Can you tell me which mode is used by Super Mario Advance 4?
Mode 0. There are 4 BGs including the scoreboard.
There's an overview of the different modes here ->
http://problemkaputt.de/gbatek.htm#gbal ... controller Scroll down the LCD section for more info on them.
If I recall correctly:
- Mode 0: four background layers
- Mode 1: three background layers, one rotates/scales
- Mode 2: two background layers, both rotate/scale
While modes 3-5 are different bitmap modes. Somebody correct me if I'm wrong, but if I recall correctly that's the gist of it.
What does Super Mario Advance 4 use?
Espozo wrote:
8bitMicroGuy wrote:
I'm having trouble understanding modes. Can you tell me which mode is used by Super Mario Advance 4?
Mode 0. There are 4 BGs including the scoreboard.
Sorry. I couldn't find my post. I thought I closed the window and that it didn't send.