It is currently Sat Dec 16, 2017 4:24 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 43 posts ]  Go to page 1, 2, 3  Next
Author Message
PostPosted: Fri May 15, 2015 3:03 pm 
Offline

Joined: Sun Mar 08, 2015 12:23 pm
Posts: 251
Location: Croatia
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?


Top
 Profile  
 
PostPosted: Fri May 15, 2015 6:41 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19348
Location: NE Indiana, USA (NTSC)
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.


Top
 Profile  
 
PostPosted: Fri May 15, 2015 7:07 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10165
Location: Rio de Janeiro - Brazil
"?" 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.


Top
 Profile  
 
PostPosted: Sat May 16, 2015 3:40 pm 
Offline

Joined: Sun Mar 08, 2015 12:23 pm
Posts: 251
Location: Croatia
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?


Top
 Profile  
 
PostPosted: Sat May 16, 2015 4:33 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19348
Location: NE Indiana, USA (NTSC)
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.


Top
 Profile  
 
PostPosted: Sat May 16, 2015 4:34 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10165
Location: Rio de Janeiro - Brazil
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. :mrgreen:


Top
 Profile  
 
PostPosted: Sat May 16, 2015 5:16 pm 
Offline

Joined: Sun Mar 08, 2015 12:23 pm
Posts: 251
Location: Croatia
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?


Top
 Profile  
 
PostPosted: Sat May 16, 2015 5:31 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10165
Location: Rio de Janeiro - Brazil
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.


Top
 Profile  
 
PostPosted: Sat May 16, 2015 5:55 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19348
Location: NE Indiana, USA (NTSC)
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.


Top
 Profile  
 
PostPosted: Sat May 16, 2015 7:03 pm 
Offline

Joined: Thu Aug 12, 2010 3:43 am
Posts: 1589
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)


Top
 Profile  
 
PostPosted: Sun May 17, 2015 10:26 am 
Offline

Joined: Sun Mar 08, 2015 12:23 pm
Posts: 251
Location: Croatia
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?


Top
 Profile  
 
PostPosted: Sun May 17, 2015 10:42 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6534
Location: Seattle
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.


Top
 Profile  
 
PostPosted: Sun May 17, 2015 11:15 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19348
Location: NE Indiana, USA (NTSC)
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.


Top
 Profile  
 
PostPosted: Sun May 17, 2015 12:12 pm 
Offline
User avatar

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 3157
Location: Nacogdoches, Texas
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
320x240.png [ 38.1 KiB | Viewed 2486 times ]
76800 pixels.

Attachment:
256x224.png
256x224.png [ 53.52 KiB | Viewed 2486 times ]
57344 pixels. Nearly 3/4 as large. (.74 and 2/3.)

Attachment:
240x160.png
240x160.png [ 40.74 KiB | Viewed 2486 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.


Top
 Profile  
 
PostPosted: Sun May 17, 2015 12:30 pm 
Offline

Joined: Sun Mar 08, 2015 12:23 pm
Posts: 251
Location: Croatia
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?


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 43 posts ]  Go to page 1, 2, 3  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group