Hello everyone,
Is it better to get a game engine working without sound and then add it in (background theme music, 'event' based sounds, etc...)?
Or is it better to begin working on sound support as soon as you can get a few tiles displayed? My assumption here is that sound support eats into the CPU cycle budget and is best dealt with up front.
Any words of wisdom?
As you add features to your engine, you can verify the CPU budget by playing with the PPUMASK and seeing how far down the screen the effects show up. Before you wait for vblank, turn on the monochrome bit (PPUMASK bit 0) for about 113 cycles and then turn it back off. This will give you a bright gray line across the screen that shows you how much CPU you're using; when it gets too close to the bottom, you're coming close to your CPU budget. Untested code follows:
Code:
;;
; Shows a monochrome bar roughly 1 scanline tall.
; To measure your CPU usage visually, call this before
; waiting for vertical blanking.
showCPUUsageBar:
ldx #%00011111 ; sprites + background + monochrome
stx PPUMASK
ldy #21 # add about 23 for each additional line
@loop:
dey
bne @loop
dex ; sprites + background + NO monochrome
stx PPUMASK
rts
How many cycles or scanlines does a typical NES game's music+sound effects engine take, and how many bytes of RAM?
Thanks tepples, that idea sounds really cool.
ps- I'm curious about most people's avatar choices. What is your avatar from?
clueless wrote:
What is your avatar from?
Some old movie.
I've used Nerdtracker2 almost exclusively. Just be aware that there will be (relatively) big spikes in the CPU cycle usage at certain points (at the beginning of new pattern, for example). Always design around the worst-case. Give yourself maybe 30 scanlines at the most. NES is plenty fast enough for it, so it's only a concern if your game is really gonna be pushing it.
What tepples showed with the monochrome bit is the way to go. Also I like to combine that with changing the "color emphasis" so I can mark different routines with different colors.
If you're just starting out on the engine, these benchmarks might not be visible because it may happen entirely during vblank.
Also, my avatar is cover art for a great Iron Maiden song (Aces High) based on the Battle of Britain.
Thanks for the advice.
I'm really not sure what part of the "game" that I'm going to start on. I figure I want to be able to handle 8-way scrolling on an MMC1 cart. MMC1 means that most likely there won't be a status bar, or it will be at the very top and split-scrolled via sprite-0 hits.
8-way scrolling because I want my game to have play mechanics like Crystalis (one of my all-time favorite games that I mostly REd [1]).
MMC1 because I want to be able some day to build some physical carts, and the products at
www.retrousb.com seem really slick.
Someday later I might ask what it would take to reconfigure the CPLD on the retrousb MMC1 cart to support 1 or 2 scan-line IRQ counters, 8k non switching char-ram and an ultra-simple prog-rom bank-switching: $c000-$ffff fixed and swapping the rest 16K at a time. But I'll hold off on that until I think I need it.
Since I'm posting links of stuff I did years ago... I also reverse engineered Faria enough to figure out how it stores all of its maps EXCEPT for the tower internals and town building overlays. I wrote a full-blown win32 Faria map editor.[2] The people on Zophar's didn't seem very interested...
But if anyone wanted to see the source code, let me know and I'll post it or something. Anyway, I know that this is the 'nesdev' community and not so much into ROM hacking, so I won't have a big deal about it anymore.
[1]
http://hera.ecoligames.com/~djenkins/Cr ... ols.tar.gz
[2]
http://hera.ecoligames.com/~djenkins/FariaEditor.exe
Wait... When did Zophar's domain come back?
My advice to you on starting would be to make an 8-way scroller like you said. You'll most likely want to use vertical mirroring, as you can hide attribute updates and stuff with NTSC. You'll probably want to make a scrolling/updating routine before you make a map-decoding routine. This is what I did. But believe me: scrolling can be a major pain. You have to be very sure when exactly you update and where. There are just lots of little scenarios to pay attention to. I'm really close to being done with my map decoding routine; I just have to tell the screen to stop scrolling when it reaches the boundries of the map.
Then you'll want to make a sprite drawing routine. This updates OAM completely every frame or so to update positions of sprites and whatnot. But after that, maybe you'll want to code collision and just basic running around for the player. Perhaps then code a sound engine. Then you'll have pretty much completed the basic parts for your "Window" to the game world. When I say that, I mean, all this stuff goes on inside the NES that is just numbers. But these routines will make all of that mean something to the player through audio and visuals. When you have these, then you'll want to start coding AI and more game logic. That's just my advice; you don't have to follow it.
Though there are other basic parts you might code depending on your game. For example, other "basic" parts in my game include some enemies being part of the BG (Like Dracula in my picture), or 3D intro movies.
Oh, and one last thing. The character with the sword in my avatar is something I drew. It's kind of supposed to be me, but a little more badass. And the gigantic enemy is Dracula's final form Nintendoized from Castlevania Dracula X: Rondo of Blood, and also, the intro to Symphony of the Night. And Memblers, your pic makes me laugh when you describe it, as I made a cartoon about the Battle of Britain for a history project in 8th grade.
For the overworld, Dragon Quest games decompressed the RLE on the fly while updating the tilemap. In order to save time, Dragon Quest 4 split the overworld map in half to eliminate the cost of seeking through the RLE to the mid-way point of a row.
If you want to build carts, it's best to keep it simple. I'm pretty sure I could design a mapper like what you described, using a couple bucks worth of very common parts. Even better if your game can get by without an IRQ counter. Sounds like you want UNROM with an IRQ.
Memblers wrote:
If you want to build carts, it's best to keep it simple. I'm pretty sure I could design a mapper like what you described, using a couple bucks worth of very common parts. Even better if your game can get by without an IRQ counter. Sounds like you want UNROM with an IRQ.
Yup, sounds about right. But like you said, I'm going to try it without the IRQ first. In fact, I might not need anything more complicated (for the non-scrolling 'status' area) than something like the "health" meter used in Blaster Master. But, unfortunately, I want to display a bit more... about the same amount of data as in Zelda-I. However, I have nothing beyond my title-screen and a partial map-compressor (written in perl), so I'm not ready for this part of the project yet.
Don't forget crazy stuff like DMC IRQ. Codemasters used that instead of an MMC3.
Dwedit wrote:
Don't forget crazy stuff like DMC IRQ. Codemasters used that instead of an MMC3.
I haven't... It is weird... I actually thought of that on my own and then read about it a few days later while reading the forum archive.
I might experiment with it when the time comes.
btw- The fancy ending music on Metroid-I... Is that something that can be played without devoting much CPU time to it? It seems to me that the rest of the game didn't have music that... er... "complicated". I have not REd that game yet, so I don't know. Just curious what the gurus here think of music like that; if it is feasible to do during the "action" part of a normal game.
Metroid's ending music isn't any more complicated than any other music from Metroid. It's just longer.
Well, even if music is complicated, it doesn't have to take much CPU time, as only one pitch/volume is calculated for 4 sound channels each frame (I think). My sound engine at the very most (With calculating arpeggios and all that stuff) takes about 15 scanlines to execute the whole thing. When all values are the same, it takes about 3. Complicated sound generally doesn't mean lots more CPU time; it usually means more PRG space though. So if you want my opinion, though I, and most likely other people here, don't consider me to be any guru, I see it as really possible to have this type of music during gameplay. It's just a matter of space.
clueless wrote:
I wrote a full-blown win32 Faria map editor.[2] The people on Zophar's didn't seem very interested...
Haha, you're the guy that did that? I used it for a short while during my love/hate relationship with that game to make
this. =P Now if it'd just handle dungeons -- maybe they could be made less repitive (many are literally symmetrical in design and utterly boring.)
Too bad the game's music is
utterly atrocious. Aside from that and some other small nitpicks, it's not too bad of a game for the NES.
wow! cool. someone used it
but.. your PNG file doesn't look any different from the original game. Did you make any changes?
The main reason why I wrote the editor is that I wanted to know what the over-world looked like when zoomed out. The game never provided any kind of "map" like that. You were always zoomed so far in...
(ps- I love the "Push B-Select" in Final Fantasy-I game.)
If you're ever interested in reverse-engineering a commercial sound engine for CPU-saving tricks, Isolated Warrior (and probably most other games developed by KID) might be worth your time. It has some pretty "complicated" music, yet uses less CPU than some other relatively simple engines (i.e. Mega Man 2).
clueless wrote:
wow! cool. someone used it
but.. your PNG file doesn't look any different from the original game. Did you make any changes?
No, just for viewing (and to have it as a big refrence without needing to use it). =P
I did experiment a bit, but I never really used it for anything past just goofing off.
BMF54123 wrote:
If you're ever interested in reverse-engineering a commercial sound engine for CPU-saving tricks, Isolated Warrior (and probably most other games developed by KID) might be worth your time. It has some pretty "complicated" music, yet uses less CPU than some other relatively simple engines (i.e. Mega Man 2).
Thanks for the tip.
I wonder exactly how Famitracker's sound engine stands up to the rest CPU-usage wise. But yeah, Capcom's sound engine is notoriously inefficient. I've heard about it from romhacking message boards. People have optimized the sound engine to get more CPU time for their megaman romhacks.