My Video Blog

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

Moderator: Moderators

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

Post by thefox » Sat Mar 12, 2011 8:18 pm

Very nice demo! Keep up the good work. You could use sprites to show some status info if other methods are troublesome.
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi

User avatar
cartlemmy
Posts: 193
Joined: Fri Sep 24, 2010 4:41 pm
Location: California, USA
Contact:

Post by cartlemmy » Sat Mar 12, 2011 10:05 pm

tepples wrote:...Another way to do it, as long as you aren't playing sampled drums, involves splitting the status bar between the top and bottom.
Hmmm, I am using sampled drums and to me sampled drums are more important than a status bar :lol: And thanks for refreshing my memory to the reason that it is hard to put the sprite 0 activated status bar at the bottom.
WJYkK wrote:I noticed that after the music starts playing, if you leave at a specific point, you can hear some "static" noise. Is this accidental or intentional?
Haha, yeah. Well it is a bug, but one that I was too impatient to fix before I released this demo. I just left out the code that silences the noise channel. Also, in the actual release the music will play throughout the entire level.
thefox wrote:Very nice demo! Keep up the good work. You could use sprites to show some status info if other methods are troublesome.
Thanks. Yes, I will certainly keep that in mind.

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

Post by tokumaru » Sat Mar 12, 2011 10:27 pm

tepples wrote:The "issue" is that there needs to be an overlap between a solid sprite pixel and a solid background pixel somewhere in x=0 to 254 (or x=8 to 254 if using the clipping window).
Not only that, but you also have to make sure all your frame calculations end before the sprite hit every single frame, or else the status bar will jump/flicker. In a platformer, with all the flow of enemies showing up and leaving/dying, I think it's pretty safe to assume that there will be an occasional CPU-intensive frame, and I'm sure you don't want the status bar to glitch up in that case.

Status bars at the bottom of the screen are only 100% safe with IRQs. Are you against placing the bar at the top of the screen? Those can be safely implemented without the aid of mappers or interrupts (well... technically the NMI is required, but you should be using NMIs anyway).

User avatar
cartlemmy
Posts: 193
Joined: Fri Sep 24, 2010 4:41 pm
Location: California, USA
Contact:

Post by cartlemmy » Sat Mar 12, 2011 10:36 pm

tokumaru wrote: Are you against placing the bar at the top of the screen?
Not at all. Sounds like my only option if I'm ever to reproduce this thing on a real cart. Right? What mappers would a company like Retrozone be able to reproduce without costs being excessive?

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

Post by tokumaru » Sat Mar 12, 2011 11:37 pm

cartlemmy wrote:Not at all. Sounds like my only option if I'm ever to reproduce this thing on a real cart. Right?
I wouldn't want to rely on mapper IRQs while no NES cart publisher (is RetroZone is the only one?) has a mapper with that feature.

For a status bar at the top of the screen, here's what you have to do: after the usual graphical updates, set the scroll to display the status bar and prepare a sprite 0 hit for a location near the end of the status bar (which is easy, because the status bar doesn't move). Then wait for the sprite hit flag to be cleared (from the previous frame's hit) and then wait for it to be set again. You can do other tasks before these waits, as long as you're sure they'll finish before the sprite hit (the sound engine would be a good thing to run during this time, for example). Once the hit happens, you just have to set the scroll for the gameplay area using $2005/$2006 trickery (example code here).

This will work either in an NMI handler or in the main loop (in case you use NMIs just to set a flag indicating that VBlank started), but it's obviously better to use the NMI handler, because they deal with lag frames gracefully, without visual side effects.

BTW, I was peeking at your code and it seems you have an NMI handler, but for some reason you trash X by reading from a variable and comparing its value to $02, but soon after you save A to the stack. If you had a lag frame, trashing X like that would be very bad. You should probably use A to check that variable instead, after having backed it up to the stack (and obviously restore it before RTI'ing). Or better yet, if you can use bits 6 and 7 to represent the states you need, you can use the BIT instruction, which doesn't trash any registers, and use BPL/BMI and BVC/BVS to make decisions based on those bits.
What mappers would a company like Retrozone be able to reproduce without costs being excessive?
I think they have basically two boards: one that can be configured for most discrete logic mappers (NROM, CNROM, UxROM, AxROM) and another for various MMC1 configurations. Those are your safe bets, but some people say that a good MMC3 game might just be the incentive RetroZone needs to develop an MMC3 clone and board. Personally, I wouldn't risk it.

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

Post by tepples » Sun Mar 13, 2011 9:32 am

tokumaru wrote:but some people say that a good MMC3 game might just be the incentive RetroZone needs to develop an MMC3 clone and board. Personally, I wouldn't risk it.
I can think of one hedge. Develop two versions of your game, one for MMC1 and one for MMC3, with extra features in the MMC3 version. With good architecture, they should be able to share most of the source tree.

User avatar
cartlemmy
Posts: 193
Joined: Fri Sep 24, 2010 4:41 pm
Location: California, USA
Contact:

Post by cartlemmy » Sun Mar 13, 2011 9:43 am

tokumaru wrote:For a status bar at the top of the screen, here's what you have to do...
Cool thanks :)
tokumaru wrote:BTW, I was peeking at your code and it seems you have an NMI handler, but for some reason you trash X by reading from a variable and comparing its value to $02, but soon after you save A to the stack. If you had a lag frame, trashing X like that would be very bad...
I created that NMI code when I first started with the 6502, so I'll have to give it a look. The odd thing is I just did a test yesterday to see what would happen if my engine had to drop a frame (I wanted to see if I had it set right so the sound engine didn't slow), and everything worked fine. It ran at half speed, and the music stayed constant.
tepples wrote:I can think of one hedge. Develop two versions of your game, one for MMC1 and one for MMC3, with extra features in the MMC3 version. With good architecture, they should be able to share most of the source tree.
I really like this idea, and I think I'll do just that. Can I do chr rom bank switching in MMC1?

User avatar
Kasumi
Posts: 1292
Joined: Wed Apr 02, 2008 2:09 pm

Post by Kasumi » Sun Mar 13, 2011 9:50 am

Here's a strange quirk with your game. Jump next to a wall while holding A. You fall faster than if you weren't holding A. I do know wall jumping exists which makes this being around a little stranger to me. Intentional or not?

Edit: As for your game working fine during a lag frame, if tokumaru's description is correct, it only worked because the NMI was called in the middle of a routine where the value of X wasn't expected to be something. If that happened in the middle of a loop that used X and X was changed by the NMI, bad things would (probably) happen.

ibeenew2
Posts: 60
Joined: Sat May 01, 2010 9:58 am

Post by ibeenew2 » Sun Mar 13, 2011 9:55 am

tokumaru wrote:Those are your safe bets, but some people say that a good MMC3 game might just be the incentive RetroZone needs to develop an MMC3 clone and board. Personally, I wouldn't risk it.
They have one its just not affordable when the profits need to be split.

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

Post by tepples » Sun Mar 13, 2011 10:04 am

cartlemmy wrote:
tepples wrote:I can think of one hedge. Develop two versions of your game, one for MMC1 and one for MMC3, with extra features in the MMC3 version. With good architecture, they should be able to share most of the source tree.
I really like this idea, and I think I'll do just that. Can I do chr rom bank switching in MMC1?
Yes, but only 4 KiB at a time. Are you animating a lot of background tiles? There may be a workaround.

User avatar
cartlemmy
Posts: 193
Joined: Fri Sep 24, 2010 4:41 pm
Location: California, USA
Contact:

Post by cartlemmy » Sun Mar 13, 2011 10:24 am

Kasumi wrote:Here's a strange quirk with your game. Jump next to a wall while holding A. You fall faster than if you weren't holding A. I do know wall jumping exists which makes this being around a little stranger to me. Intentional or not?
Not intentional, and it is a result of the wall jump (well, actually the wall slide) code. Thanks for the heads up :)
Kasumi wrote: As for your game working fine during a lag frame... ...was changed by the NMI, bad things would (probably) happen.
I will definitely review this. EDIT: I have fixed this.
ibeenew2 wrote:They have one its just not affordable when the profits need to be split.
I will keep this in mind.
tepples wrote:
cartlemmy wrote:Can I do chr rom bank switching in MMC1?
Yes, but only 4 KiB at a time. Are you animating a lot of background tiles? There may be a workaround.
So you have to switch all of the graphics at once with MMC1?

I'm not sure if I will want to animate any, I just though it would be a nice thing to have available if I needed an extra aesthetic touch.

lidnariq
Posts: 9700
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Post by lidnariq » Sun Mar 13, 2011 12:24 pm

(minor tangent) Whatever happened to that "Let's design a mapper that can fit in the same CPLD that RetroZone uses for the MMC1 but is more useful to us" project?

User avatar
Memblers
Site Admin
Posts: 3884
Joined: Mon Sep 20, 2004 6:04 am
Location: Indianapolis
Contact:

Post by Memblers » Sun Mar 13, 2011 2:18 pm

Demo looks really cool.
lidnariq wrote:(minor tangent) Whatever happened to that "Let's design a mapper that can fit in the same CPLD that RetroZone uses for the MMC1 but is more useful to us" project?
I don't know if anyone else has one, but I finished the Verilog for one, I'm 95% sure it will work as-is, but I haven't made the board layout yet. I used the smallest (36 macrocell) CPLD and one 74xx part to provide the inputs needed for the IRQ logic. I have some projects ready to use this board, so this will be moving along before too long.

IRQ operation has 2 modes. Both are PPU-based - based on sprite and/or background tile placement. One mode triggers an IRQ (acknowledge register clears it). The other mode will automatically bankswitch the CHR to your latched value (acknowledge register resets it to a 'fixed' bank). The only catch is that in the latter mode, the NES CPU must keep IRQs disabled. CHR page size is 2kB.

User avatar
dr_sloppy
Posts: 52
Joined: Mon Oct 27, 2008 2:48 pm
Location: Ålesund, Norway
Contact:

Post by dr_sloppy » Sun Mar 13, 2011 3:31 pm

This demo shows a lot of good potential. Well done!

yesyesyall
Posts: 28
Joined: Sat Mar 05, 2011 3:17 pm
Location: Houston, Texas

Post by yesyesyall » Sat Mar 19, 2011 6:06 pm

tokumaru wrote:"Nintendinho"
i LOVE this and am calling the nintendo this from now on

Post Reply