Nighttime Bastards

A place where you can keep others updated about your NES-related projects through screenshots, videos or information in general.

Moderator: Moderators

User avatar
picccca
Posts: 44
Joined: Wed Nov 24, 2010 12:51 am
Location: Finland
Contact:

Nighttime Bastards

Post by picccca » Thu Mar 24, 2011 3:14 am

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/ne ... e-bastards. You can also download the .nes file there. Comments and thoughts are always welcome.

User avatar
thefox
Posts: 3141
Joined: Mon Jan 03, 2005 10:36 am
Location: Tampere, Finland
Contact:

Post by thefox » Thu Mar 24, 2011 3:36 am

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.
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi

User avatar
picccca
Posts: 44
Joined: Wed Nov 24, 2010 12:51 am
Location: Finland
Contact:

Post by picccca » Thu Mar 24, 2011 3:44 am

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 :D

User avatar
koitsu
Posts: 4218
Joined: Sun Sep 19, 2004 9:28 pm
Location: A world gone mad

Post by koitsu » Thu Mar 24, 2011 6:24 am

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.

User avatar
qbradq
Posts: 951
Joined: Wed Oct 15, 2008 11:50 am

Post by qbradq » Thu Mar 24, 2011 7:05 am

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 :D

Good luck!

tepples
Posts: 22050
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples » Thu Mar 24, 2011 7:12 am

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.

User avatar
picccca
Posts: 44
Joined: Wed Nov 24, 2010 12:51 am
Location: Finland
Contact:

Post by picccca » Sat Apr 02, 2011 6:26 am

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.

User avatar
picccca
Posts: 44
Joined: Wed Nov 24, 2010 12:51 am
Location: Finland
Contact:

Post by picccca » Thu Nov 10, 2011 8:51 am

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.

User avatar
tokumaru
Posts: 11858
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru » Thu Nov 10, 2011 9:36 am

Haven't seen the ROM because I'm at work, but...
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.

3gengames
Formerly 65024U
Posts: 2277
Joined: Sat Mar 27, 2010 12:57 pm

Post by 3gengames » Thu Nov 10, 2011 9:53 am

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.

User avatar
Dwedit
Posts: 4351
Joined: Fri Nov 19, 2004 7:35 pm
Contact:

Post by Dwedit » Thu Nov 10, 2011 10:02 am

Try 9 instead of 7, see how that goes.
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!

Wave
Posts: 110
Joined: Mon Nov 16, 2009 5:59 am

Post by Wave » Thu Nov 10, 2011 10:04 am

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.
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.

User avatar
tokumaru
Posts: 11858
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru » Thu Nov 10, 2011 11:29 am

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.

User avatar
picccca
Posts: 44
Joined: Wed Nov 24, 2010 12:51 am
Location: Finland
Contact:

Post by picccca » Thu Nov 10, 2011 12:41 pm

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.

User avatar
tokumaru
Posts: 11858
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru » Thu Nov 10, 2011 2:23 pm

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.

Post Reply