It is currently Wed Dec 19, 2018 6:14 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 25 posts ]  Go to page Previous  1, 2
Author Message
PostPosted: Mon Feb 12, 2018 2:13 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 11018
Location: Rio de Janeiro - Brazil
If you want to do the "role-playing" thing with your own projects that's fine, but don't enforce this on everything else like it was some sort of rule for working with retro consoles. Not everyone chooses to code for the NES because they want to pretend it's still the most advanced technology there is, maybe they just have fond memories of the console, or find the limitations fun to work with, or want to prove that the hardware can do something that's generally considered impossible/unpractical, or whatever.

Different programmers pick different platforms for different reasons, but even if you look at this from a purely commercial angle, it may still be more profitable to code a game for the NES, that has an established fan base that consistently purchases quality games, than to target a modern platforms (PC, mobile, etc.) that's flooded with games, good and bad, making it harder for yours to stand out and make any money.

You always have to make decisions about the scope of your projects. You may be pretending you're a Nintendo employee in 1987, or you might be participating in a competition that'll culminate in a multicart with all entries, and both are acceptable reasons to stick to modest mappers and memory sizes, but you can't generalize and put everyone under the same constraints.


Top
 Profile  
 
PostPosted: Mon Feb 12, 2018 5:23 pm 
Offline
User avatar

Joined: Fri Jan 24, 2014 9:05 am
Posts: 164
Location: Hungary
I agree that sticking to certain limits does not necessary mean someone wants to "role-play".
On the one hand, I'm also developing with a small cart in mind, but that's because I want it to be easy and cheap to build a real cart, and I also don't have a budget to hire someone to create graphics for me so I'd have no excuse for limited tilesets otherwise. On the other hand I also want to have a small game pushing certain aspects of the NES with little to no help coming from "the outside". But I think I've done enough topic de-railing for a while now.


Top
 Profile  
 
PostPosted: Tue Feb 13, 2018 12:53 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7605
Location: Chexbres, VD, Switzerland
Quote:
Well, you're the one who jumped up to defend the MMC5 as a target platform after my criticism

Sorry I don't think I ever did that.
Quote:
and now you've saying the MMC5 shouldn't be an option at all? I'm confused about what point you're trying to make?

I'm not trying to make any point specifically, just answering to what had been said with some insight.

Quote:
You do seem to be quite concerned about engaging in some form of 1990s coder role-playing game, which I can respect. But I am curious how far it goes? After all, have you *really* developed a NES game if you've taken advantage of all the modern tools of cycle-accurate emulators with visual debuggers, Python scripting tools for your build toolchain, and last but not least the in-depth hardware knowledge that is available with the nesdev wiki?

I don't really have an answer for that, but using tools to make work quicker than what a developer could have done in more time back then is definitely fine, as as you said yourself, our time is limited.


Top
 Profile  
 
PostPosted: Thu Feb 15, 2018 12:12 pm 
Offline

Joined: Mon Apr 04, 2016 3:19 am
Posts: 85
Personally I code because I think it's fun, and developing for the NES has been the most fun programming I've ever tackled. I don't necessarily need to produce some sellable product like Battle Kid, nesdev isn't my day job, and having to prioritize stuff like that rather than the fun would just... suck the fun out of it. I just really love to do nesdev, like a painter who loves to paint but doesn't care about selling his paintings or putting them up in a museum. It's fine if that painting ends up in the trash can once it's done, it was the act of painting that was interesting and meaningful.

The MMC5 is fun to experiment with because it's not widely used, so it has lots of uncharted seas to explore. Not that other mappers wouldn't be fun, but there is just something magical about reaching to new unknown potential heights on my poor little childhood hardware. To figure out some new trick that nobody else has come up with before.

Lately I've been experimenting with the the WRAM bankswitching by using 64K memory divided into 8K pages, which can be used as a crude hardware accelerated array of sorts. Got an update routine pointer for each of your gameobjects? No need to do the reverse RTS trick with all the expensive "LDA Obj_Update_Address,X" stuff, instead you just switch the RAM page and call JSR Obj_Update_Address! :D


Top
 Profile  
 
PostPosted: Thu Feb 15, 2018 5:48 pm 
Offline

Joined: Mon May 25, 2009 2:20 pm
Posts: 65
Oh i think i know what you mean (maybe) about the JSR'ing in RAM thing.

I actually do that a whole bunch of times on megaman odyssey. At the very start when you boot the ROM, i load several areas of "un-rolled" code, and put them in 6000-7FFF RAM page 01 ...so that the game can JSR to those places faster than any regular bankswap stuff.

I also load the whole weapon menu graphics/screens into RAM page 02 ..so that during the game, it doesnt have to read level data or many other things normally, making it load twice as fast.

And again, it's thanks to the MMC5 mappr only. :) because of how you can have more than just 1 "6000-7FFF" area.


Top
 Profile  
 
PostPosted: Thu Feb 15, 2018 6:51 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20899
Location: NE Indiana, USA (NTSC)
MMC1 (wired as SXROM) and FME-7 (wired as loopy speculated and l_oliveira confirmed) can also bankswitch $6000-$7FFF.


Top
 Profile  
 
PostPosted: Thu Feb 15, 2018 11:34 pm 
Offline

Joined: Mon May 25, 2009 2:20 pm
Posts: 65
wow. and i always thought mmc5 was the only one to have more than 1.
did not know. that's interesting. :)


Top
 Profile  
 
PostPosted: Fri Feb 16, 2018 1:20 am 
Offline

Joined: Mon Apr 04, 2016 3:19 am
Posts: 85
kuja killer wrote:
Oh i think i know what you mean (maybe) about the JSR'ing in RAM thing.

I actually do that a whole bunch of times on megaman odyssey. At the very start when you boot the ROM, i load several areas of "un-rolled" code, and put them in 6000-7FFF RAM page 01 ...so that the game can JSR to those places faster than any regular bankswap stuff.

I also load the whole weapon menu graphics/screens into RAM page 02 ..so that during the game, it doesnt have to read level data or many other things normally, making it load twice as fast.

And again, it's thanks to the MMC5 mappr only. :) because of how you can have more than just 1 "6000-7FFF" area.


It's based on the same idea, but you can take it even further. I was about to write up a long explanation but I figured I might as well make a new topic instead of polluting this one.


Top
 Profile  
 
PostPosted: Fri Feb 16, 2018 2:52 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7605
Location: Chexbres, VD, Switzerland
Drakim wrote:
Lately I've been experimenting with the the WRAM bankswitching by using 64K memory divided into 8K pages, which can be used as a crude hardware accelerated array of sorts. Got an update routine pointer for each of your gameobjects? No need to do the reverse RTS trick with all the expensive "LDA Obj_Update_Address,X" stuff, instead you just switch the RAM page and call JSR Obj_Update_Address! :D

There's no need for bankswitched WRAM, or even WRAM at all, for doing such tricks. Having a JMP instruction in ordinary RAM can do similar achievement.


Top
 Profile  
 
PostPosted: Fri Feb 16, 2018 4:16 am 
Offline

Joined: Mon Apr 04, 2016 3:19 am
Posts: 85
Bregalad wrote:
Drakim wrote:
Lately I've been experimenting with the the WRAM bankswitching by using 64K memory divided into 8K pages, which can be used as a crude hardware accelerated array of sorts. Got an update routine pointer for each of your gameobjects? No need to do the reverse RTS trick with all the expensive "LDA Obj_Update_Address,X" stuff, instead you just switch the RAM page and call JSR Obj_Update_Address! :D

There's no need for bankswitched WRAM, or even WRAM at all, for doing such tricks. Having a JMP instruction in ordinary RAM can do similar achievement.


Only if you all you need is that one JMP. With bankswitched WRAM you can have several of them in "parallel" across the WRAM banks, and invoke one of them based on an index.

I've made a topic about this technique here:

viewtopic.php?f=2&t=17064


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 25 posts ]  Go to page Previous  1, 2

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 3 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group