RJM wrote: ↑Mon Feb 15, 2021 4:10 am
In all honesty, I thought 1-2 frame glitches between levels are to short to cause any troubles and I let them be to focus on delivering game on the deadline.
Well, they might not actually be a problem, and for such a low-scale game, I guess nobody cares.
However, it does show that the way you do things on the NES isn't already the typical, established way it is usually done.
Sprite flickering or those color glitches on the right side of the screen in "Super Mario Bros. 3", those are system-specific issues that are accepted because there's no easy way around it.
(SMB3 has four-way scrolling and a status bar, therefore horizontal mirroring had to be used and that's where the color artifacts during horizontal scrolling come from. In SMB1, those artifacts would have been bad programming since that game has no vertical scrolling, so it uses vertical mirroring. That's why there are no scrolling artifacts in SMB1.)
But screen change glitches never need to occur on the NES if you do it right.
Hence, if you use the disabling of the PPU properly, if you use buffer values for your background data and scrolling positions that then only get written to the actual registers while you're in NMI etc., then those glitches don't appear in the first place.
Those are some of the things that you should organize pretty early in the beginning when you start a new game and shouldn't treat it as "polishing" or cleanup for later. Because as soon as you make it right, these specific artifacts and glitches won't be an issue ever again.
So, for your next game you should read this article:
https://wiki.nesdev.com/w/index.php/The_frame_and_NMIs
If you're already well-versed in general game development, you might be able to skip a pure demo game and start with the one that you want to do right away. After all, much of the stuff isn't NES-specific, but simply requires general knowledge of programming.
However, you should check how much time you want to invest and then check what kind of game you want to do. I worked on "City Trouble" for approximately 1.5 years (working in the afternoons) and it's a relatively simple game. But that's exactly what I wanted: I wanted to do a first game that I can actually finish in a reasonable amount of time. Something like "Castlevania" probably would have required me to spend three years on it.
Regarding the programming language: You don't need to program in pure Assembly. There is a working C compiler for 6502-based systems like the NES: cc65. And despite what some people might say, it isn't that bad.
There are a few things that are not perfect.
The most bothersome issue is the fact that accessing
pointer[index] produces highly ineffective code: The compiler copies the pointer to its own internal zeropage pointer since
LDA (pointer), Y only works with zeropage variables. But it does so even if your own pointer is already in the zeropage, which is a total waste of ROM memory and CPU time.
But that's what inline assembly is for:
Code: Select all
/* variable = pointerAsArray[index]; */
#define SetVarFromPtrAtIdx(variable, pointerAsArray, index) \
{ \
__asm__("LDY %v", index); \
__asm__("LDA (%v), Y", pointerAsArray); \
__asm__("STA %v", variable); \
}
And of course there are general things that you should keep in mind, like not using local variables etc. because their access produces more code than global variables.
Anyway, while you should still write some stuff in pure Assembly (for example the whole NMI background update stuff or setting the hardware sprite values based on the characters' meta sprite definitions), you can write most of your code in C.
RJM wrote: ↑Mon Feb 15, 2021 4:10 am
I also need to look up all of the time some details about the hardware on nesdev wiki, as I simply haven't done it long enough to remember things like which memory address corresponds to what in PPU and so on.
This is what constants are for. I don't write
STA $2006, I write
STA PPUADDR and have a general include file that has all those NES-specific registers defined.
RJM wrote: ↑Mon Feb 15, 2021 4:10 am
The thing I haven't added in Immunatio was a boss fight, so I was thinking that my next game ( or a tech demo ) could be all about fighting different bosses in 2D platformer style.
A game with
just boss fights? I don't know. Wouldn't this be a bit too boring?
Unless you only want to do this as a demo game. But after you said that you already programmed a bunch of games for other platforms, I'd say you can skip the demo proof-of-concept game. This would have been just for someone who hasn't programmed
any proper game yet: Let him create a simple side scroller like that "Challenger" train level, so that he gets a feeling for game physics, computer AI, background interaction (platforms and gaps), scrolling etc.
But someone who has already written small games on the PC, that person can go from "test program that lets you learn the NES internals" right to "proper NES game".
The only question is: How big shall that proper NES game be? "Kung Fu" complexity? "Castlevania" complexity?
It depends on how long you can motivate yourself to work on a game without having a finished product.
If you only want to work a year or so, take the smaller game. If you don't mind three years, take the longer one.
But don't exaggerate it. I would advise against something like "Castlevania III", unless you want to dedicate more than half a decade of your life to that game. Or if you can work fulltime on it, eight hours per day. Then it might be possible to finish such a huge game in a reasonable amount of time.
But as a side project for evenings and weekends, "City Trouble" alone took me 1.5 years for the ROM and a few additional months until the manual and box was finished and the game could go into production.
And if your game is a really great game, for example if you program a true NES game that looks like the original plans for the retro-inspired PC game "Steel Assault" (minus the things that are simply impossible on the NES):
https://www.youtube.com/watch?v=ILE-eNMxpaE&t=1m50s
If such a game of yours is 99% finished, then you may want to start a Kickstarter campaign for financing the physical production.
