Hi all, I just wanted to show you the progress of my under development NES game. It's not much of a game yet, well here is a link to the blog where I write about the onging work: http://sites.google.com/site/picccca/nes/nighttime-bastards. You can also download the .nes file there. Comments and thoughts are always welcome.
It would probably be better to have the new updates on top on that page. Not much more to say, but like always it's good to see more homebrew.
yes of course, I have planned to do that for a while now before there will be any more stuff on there, but I just have not done it yet 
Cool, more homebrew stuff. Always good to see people having fun and making stuff no matter how simple/weird. Well, except for tepples, who is just downright weird. ;-)
Also, something technical: your format for the gamebackground data could be significantly compressed without using RLE or anything as well. I don't know what range of values you need (in your example you're only using $0 to $2), but I'll assume you need values $0-$F (0-15). You could combine 2 metatiles into a single byte (e.g. what you would declare now as $F,$2,$1,$0,$0,$0 would become $F2,$10,$00) with very little CPU overhead (bitshifts take care of all the complexity). Something to think about, especially given the ROM space savings per screen.
Of course, if you actually need more than a nybble ($0-$F) for your tile numbers this won't work. In that case you might consider a simple RLE method. What I used in the FF2e/j intro was pretty simple and made a huge difference when there were lots of repetitive tiles of the same value. Had to use this in my case since there wasn't enough free ROM space.
Also, something technical: your format for the gamebackground data could be significantly compressed without using RLE or anything as well. I don't know what range of values you need (in your example you're only using $0 to $2), but I'll assume you need values $0-$F (0-15). You could combine 2 metatiles into a single byte (e.g. what you would declare now as $F,$2,$1,$0,$0,$0 would become $F2,$10,$00) with very little CPU overhead (bitshifts take care of all the complexity). Something to think about, especially given the ROM space savings per screen.
Of course, if you actually need more than a nybble ($0-$F) for your tile numbers this won't work. In that case you might consider a simple RLE method. What I used in the FF2e/j intro was pretty simple and made a huge difference when there were lots of repetitive tiles of the same value. Had to use this in my case since there wasn't enough free ROM space.
This is pretty cool! You may find this thread of interest for background collisions. I recently struggled with this myself. For your game you won't have gravity, and your velocities may be constant, but the sequence of steps needed for correct background collision and response is there.
Also I admire someone that can come up with a good, unique idea for a game and implement it without a mapper. Every time I sit down to design a game I end up with something that reads "remake [name of awesome commercial game] but make it WAY cooler!" Not very practical or feasible
Good luck!
Also I admire someone that can come up with a good, unique idea for a game and implement it without a mapper. Every time I sit down to design a game I end up with something that reads "remake [name of awesome commercial game] but make it WAY cooler!" Not very practical or feasible
Good luck!
The other way, as used by Super Mario Bros. series, is to make each map a list of (x, y, thing) tuples: one byte for x and y, and one for what's at that location: it could be a block, a row of blocks, etc. If you can draw concepts for later maps, I might help you figure out what kind of map representation would work best.
koitsu wrote:
Also, something technical: your format for the gamebackground data could be significantly compressed without using RLE or anything as well. I don't know what range of values you need (in your example you're only using $0 to $2), but I'll assume you need values $0-$F (0-15). You could combine 2 metatiles into a single byte (e.g. what you would declare now as $F,$2,$1,$0,$0,$0 would become $F2,$10,$00) with very little CPU overhead (bitshifts take care of all the complexity). Something to think about, especially given the ROM space savings per screen.
I have never thought about this, but it sounds very interesting and indeed something for me to consider, thanks for the tip.
I want your opinion on the OAM cycling show in this .nes file. What do you think, is it good, does it look too horrible?
The techniques I'm using are:
a. Write #$F0 to all sprite entry's Y-position first of all.
b. skip 7 entries (28 bytes) between sprite writes.
c. add 24 entries (96 bytes) to the OAM start address each frame.
And I was alternating the write order (first to last and last to first) each frame but I did not see improvements, so I skipped it.
The techniques I'm using are:
a. Write #$F0 to all sprite entry's Y-position first of all.
b. skip 7 entries (28 bytes) between sprite writes.
c. add 24 entries (96 bytes) to the OAM start address each frame.
And I was alternating the write order (first to last and last to first) each frame but I did not see improvements, so I skipped it.
Haven't seen the ROM because I'm at work, but...
You might save some CPU time by only doing this to the unused sprites, once you're finished defines the ones you will use. If your game is really busy and lots of sprites are being used, you certainly don't want to waste time hiding sprites just to bring them back into view later.
picccca wrote:
a. Write #$F0 to all sprite entry's Y-position first of all.
You might save some CPU time by only doing this to the unused sprites, once you're finished defines the ones you will use. If your game is really busy and lots of sprites are being used, you certainly don't want to waste time hiding sprites just to bring them back into view later.
I dunno how that works, but I'd say to try to put enemies on the screen in a different order. I mean I guess that works, but I'd make whole enemies disappear. I think that'd look better.
Try 9 instead of 7, see how that goes.
picccca wrote:
I want your opinion on the OAM cycling show in this .nes file. What do you think, is it good, does it look too horrible?
The techniques I'm using are:
a. Write #$F0 to all sprite entry's Y-position first of all.
b. skip 7 entries (28 bytes) between sprite writes.
c. add 24 entries (96 bytes) to the OAM start address each frame.
And I was alternating the write order (first to last and last to first) each frame but I did not see improvements, so I skipped it.
The techniques I'm using are:
a. Write #$F0 to all sprite entry's Y-position first of all.
b. skip 7 entries (28 bytes) between sprite writes.
c. add 24 entries (96 bytes) to the OAM start address each frame.
And I was alternating the write order (first to last and last to first) each frame but I did not see improvements, so I skipped it.
I use this techniques too (but not exactly).
Except a, that I clear remaining sprites only as suggested by tokumaru.
I alternate the write order because if your objects use more than 64 (63 for me as I skip sprite 0) sprites you can draw up to 128 by alternating the order.
OAM cycling is a bit weird for me, because sometimes I need to preserve the priorities between the sprites of an object (and sometimes even between different objects). To solve this, instead of "randomizing" the sprite slots, I randomize the order in which the objects are processed and rendered. I'm not sure if this looks better or worse than the other way, I haven't tested it much.
I also have 2 virtual sprite layers. When objects call the sprite rendering function they specify whether the sprites should go on the top layer or the bottom layer. This causes the function to output the sprites to the bottom end or to the top end of the OAM buffer ($200-$2FF). Since the top layer has priority, I avoid putting sprites there unless they absolutely need to be in front of all other objects.
I also have 2 virtual sprite layers. When objects call the sprite rendering function they specify whether the sprites should go on the top layer or the bottom layer. This causes the function to output the sprites to the bottom end or to the top end of the OAM buffer ($200-$2FF). Since the top layer has priority, I avoid putting sprites there unless they absolutely need to be in front of all other objects.
Dwedit wrote:
Try 9 instead of 7, see how that goes.
I have actually tried a few different skipped entries per sprite as well as per frame, and these are the numbers (7 and 24) that I think looked the best.
tokumaru wrote:
You might save some CPU time by only doing this to the unused sprites, once you're finished defines the ones you will use. If your game is really busy and lots of sprites are being used, you certainly don't want to waste time hiding sprites just to bring them back into view later.
Ok, sounds very reasonable, I'll do it. But how did you guys think it looked, I can't remember playing any game with this obvious sprite flickering.
picccca wrote:
But how did you guys think it looked, I can't remember playing any game with this obvious sprite flickering.
Looks about right to me. There's no miraculous OAM cycling technique that will make it look like the NES is able to display 16 sprites in a row... flickering will look bad no matter how you do it.
You probably don't remember this much flickering in commercial games because when things are moving and you are in the middle of playing there's too much going on for you to focus on the flickering. But when everything is static like in your ROM you have nothing to do but stare at the flickering and notice how ugly it looks.
tokumaru wrote:
I also have 2 virtual sprite layers.
That's not a bad idea.
I had planned to work with sprite priority by adding the number of hardware sprites in the object * 4 to the sprite-that-needs-to-be-on-top's index, and using the result index for that sprite if there was a carry, otherwise just go as normal.
In other words, the sprite-on-top is put in the slot immediately before the other hardware sprites needed for the metasprite unless any one of the slots would wrap back to 0. In this case, I use the sprite slots after the carry would have occurred for the high priority sprites, then go back to fill in the lower priority sprites.
This method (I think, haven't implemented it)) means only one object can outpriortize another object with its high priority sprites, and every other object will have all its sprites entirely behind the objects that outprioritze it while still keeping priority intact for each individual object.
I haven't even thought about flickering, but I will probably do my best to do it by object, since having parts of sprites missing always looks odd to me.
tokumaru wrote:
Looks about right to me. There's no miraculous OAM cycling technique that will make it look like the NES is able to display 16 sprites in a row... flickering will look bad no matter how you do it.
There are ways to flicker on purpose without it looking bad, but they're pretty limited in scope.
Quote:
You probably don't remember this much flickering in commercial games because when things are moving and you are in the middle of playing there's too much going on for you to focus on the flickering.
That and someone probably had little or nothing to compare it to, seeing as platforms with more sprite capacity (Genesis and Super NES) weren't out yet.