nesdev.org

Can you be specific about what sort of "documentation" you're looking for? The NES and GBC are similar in power but otherwise very different systems. Rewriting a game for the GBC basically constitutes...rewriting the game.

IIRC
Note that both Table and the Procs need to be part of the current program bank.

That clear things up?

This is really interesting/impressive/cool. Thanks for sharing.

dougeff wrote:I like a 'look up table' for multiplication/division. It's faster.

Yeah, especially here, when you know your products will be so small.

If you want to actually do the calculation, at least do binary multiplication (like the one Kasumi linked to here) instead of repeated additions.

Yeesh. I'm surprised games would run so (sorta) well on a bad CPU, and here it seems like very specific addresses giving bad data, which is why I guessed RAM. But there was another big long thread on here of someone diagnosing their broken SNES and it was the CPU too (the whole stack subsystem was b...

Besides, there's no possible way I could store animation for an explosion of this size statically, (full size is 64x64, but I never really drew past this, which is one of the initial frames) which is meant to play after blowing up a vehicles and explosive objects and for rocket explosions and what ...

A linked list is a data structure that lets you create an arbitrarily large list. Each entry in the list is paired with a pointer to the next one, so as long as you can allocate another entry somewhere in memory, you can quickly add to the list. It's also easy to remove entries from the list - if yo...

You know though, I also find it kind of weird that something that seemed pretty obvious to me like looking through vram for open slots for each sprite had never really been done before. Well, there's a reason for that - broadly speaking doing things dynamically is almost always way slower and way m...

If I had to guess, this sounds like a bad RAM chip. Do you have any way of running the SNES Test Program?

Neat, thanks. The FFL3 trick is pretty classy but the FFL2 code is about as nasty as I expected this would be.

Can you give an example of this? I'm curious as to how these routines access their arguments and fix the return address.

Not a huge fan of scrolling, myself. Aside from the added code complexity (particularly on 8-bit CPUs), scrolling worlds tend to be bloated and unmemorable. Something about limiting the designer to a single screen seems to make it easier to get into the mindset of using space efficiently and packing...

Naw naw naw, I meant don't transfer during hblank. It's extremely short - only around 200 cycles - so you'll barely increase the number of bytes transferred, and you're burning through the time you should be spending on your game logic waiting for it. In fact, by my math, with all the overhead in yo...

I'd strongly advise against trying to transfer during hblank - on the GB, almost all of your processing time happens while the screen's drawing. If you're spinwaiting for hblank, you're wasting almost all of your CPU time. Doing the math, aside from the OAM DMA transfer, your vblank is taking around...

Unfortunately there's probably not an especially good answer for you, only some hard truths: vblank is short, the GB is slow, graphics are big. If you want to do anything interesting, your vblank routine needs to be as absolutely tight as possible (almost definitely in assembly and not C), and there...