RPG Time!

[CutterCross]

Second thing is I don't want any colour swapped monsters. So no Dragon, Ice Dragon Fire Dragon that have different stats but are only colour swapped. With 32Kb... Not going to happen. Even if I put the monsters graphics in the PRG ROM I would have even more limits on what I could be done...

I think you're misunderstanding how graphics are stored on a mapper like UNROM 512. ALL of your graphics are stored in PRG-ROM, because the mapper uses CHR-RAM. It HAS to store graphics in PRG-ROM to copy to CHR-RAM, which the PPU is able to read 8 KB at once for both pattern tables. The 32 KB refers to the four pages of CHR-RAM which can be swapped out on the fly like typical CHR-ROM banks, except they can be overwritten.

From the sounds of it, I think you're ballooning your scope way too far if you're seriously considering ditching an already large mapper like UNROM 512 for something with even more ROM, especially for a first project. The last thing you want is for this sort of thing to spiral out of control on your first outing. That, or you're not taking the time to consider better methods of approaching the game's design that could fit the constraints you're given. Most of the appeal of NESdev or any other vintage console dev is to do the most with the least possible.

 

[Nishi]

I think you're misunderstanding how graphics are stored on a mapper like UNROM 512. ALL of your graphics are stored in PRG-ROM, because the mapper uses CHR-RAM. It HAS to store graphics in PRG-ROM to copy to CHR-RAM, which the PPU is able to read 8 KB at once for both pattern tables. The 32 KB refers to the four pages of CHR-RAM which can be swapped out on the fly like typical CHR-ROM banks, except they can be overwritten.

From the sounds of it, I think you're ballooning your scope way too far if you're seriously considering ditching an already large mapper like UNROM 512 for something with even more ROM, especially for a first project. The last thing you want is for this sort of thing to spiral out of control on your first outing. That, or you're not taking the time to consider better methods of approaching the game's design that could fit the constraints you're given. Most of the appeal of NESdev or any other vintage console dev is to do the most with the least possible.

Just going to apologize head of time, if I seem to be rude at anytime. Just replying as a geek.

I know the difference between ROM and RAM. But like I said before I was running into issues with running out of memory. So putting my graphics Into a CHR-ROM, worked by freeing up memory.

The next issue was my maps. Since the world map takes up Map 0, two towns with shops, Inns and keeping things down to story based insides, and two dungeons... I was running out of room 15% threw the story.

Yes I would love to use one of the VC mappers, but I want to keep things to "new parts" only. I'm also trying to keep things inside NESMaker.

With switching the CHR-RAM to ROM. It let's me move from 32Kb to 512Kb for graphic memory, that isn't shared with the PRG-ROM.

Extending the banks to allow the extra chips, will let me keep my maps as they are and work on the rest.

This is my first NES game, but not my first game. I started with things on the TI-83 back in highschool because I was board, and did things on the C-64.

 

[GlassFrog]

Wow, impressive work. I love the monster artwork.

 

[CutterCross]

Just going to apologize head of time, if I seem to be rude at anytime. Just replying as a geek.

I know the difference between ROM and RAM. But like I said before I was running into issues with running out of memory. So putting my graphics Into a CHR-ROM, worked by freeing up memory.

The next issue was my maps. Since the world map takes up Map 0, two towns with shops, Inns and keeping things down to story based insides, and two dungeons... I was running out of room 15% threw the story.

Yes I would love to use one of the VC mappers, but I want to keep things to "new parts" only. I'm also trying to keep things inside NESMaker.

With switching the CHR-RAM to ROM. It let's me move from 32Kb to 512Kb for graphic memory, that isn't shared with the PRG-ROM.

Extending the banks to allow the extra chips, will let me keep my maps as they are and work on the rest.

This is my first NES game, but not my first game. I started with things on the TI-83 back in highschool because I was board, and did things on the C-64.

I understand your sentiment, but I'm not sure you've considered all your options yet. If you're that concerned about graphics space, you could use one of CHR-RAM's greatest strengths, which is the ability to compress graphics data in PRG-ROM and decompress them when copying to CHR-RAM. There are many documented compression methods for doing this, some can go as far as cut your CHR size in half. https://wiki.nesdev.com/w/index.php/Tile_compression

Even with a CHR-ROM based mapper, if you're not already finding ways to compress stuff like nametable and attribute table data [without needing to actually change the content], you're doing yourself a disservice for a project this large of scope. Moving to a larger mapper, especially one that's not already widely available for manufacturing, just seems like an overkill solution.

I also apologize if it sounds like I'm being antagonistic here. I'm only trying to show other alternatives that may be better off for you in the long run.

 

[Nishi]

A 2MB (megabyte) cart based on Mapper 30. Few coding issues to fix, but hardware wise this little one is ready.

It has the memory address to support 8MB... But ran out of room with what a NES cart gives.

Three draw backs from a normal Mapper 30 cart:
-Flash programming doesn't work and all the chips have to be programmed and placed correctly.
-This isn't 100% compatible with NESMaker since it allows for more space, and you HAVE TO PROGRAM the banks and how things are accessed.
-There is no software emulation for this yet. So lots of taking the chips off and on to flash/program them.

 

[Nishi]

Like I posted on FB. Things became broken with the new board setup, and are slowly getting fixed. 4-way scrolling down, and now getting the collision working again.

https://www.facebook.com/video.php?v=10157633131370940

 

[Logana]

woah, thats cool, btw why did you change the players color pallet? or is that just a glitch, nice to see more of the game though

 

[Nishi]

Went back to the Alpha build to get things sorted out. She'll be back to her normal colours soon.... And she'll look better to!

^_~

 

[Logana]

Owwwwwwwwwww Nice

 

[Basty]

Nice to see that you got the world map working. Exciting to see more development on this one.

 

[Nishi]

So been doing work on the board since I ran into an issue, but I'll have a post in that this weekend or next week when I get some more work done.

Changing the design of the sprites abit, and went taller. Also now working with 11 frames instead of the old 3 frames. ^_^

 

[Bucket Mouse]

I'm sad that we'll never get to use this module...

 

[Nishi]

I'm sad that we'll never get to use this module...

Its not like I won't release the build with a crap tone of notes, but I need to finish everything first.

 

[Basty]

When you are making such an elaborate walking cycle, I'd personally would use extra layer especially for lower part of the body.

 

[Nishi]

Four way scrolling.... About 90% working. ^_^"

https://www.facebook.com/video.php?v=10157709334315940

 

[Basty]

Hmm... Aside for lack of typical 16x16 pixel locked box movement, I really don't see any issues with it.
That should be an easy fix though. Just add variable to lock gamepad functions till she has moved 16 pixels with char speed and timer set to 4 then release.
Adding a simple 5-10% monster encounter check per every movement shouldn't be a big issue either.

However, really nice work thus far. I am excited to see how far this goes and to be fair, this 4 way scrolling could be used for other projects as well.

 

[Nishi]

Hmm... Aside for lack of typical 16x16 pixel locked box movement, I really don't see any issues with it.
Really nice work. I am excited to see how far this goes.

Using an old sprite design, since I'm not done the new one yet. If you look up at: http://www.nesmakers.com/index.php?threads/rpg-time.6203/post-36879

You'll see the new design I'm going for.

 

[Basty]

Using an old sprite design, since I'm not done the new one yet. If you look up at: http://www.nesmakers.com/index.php?threads/rpg-time.6203/post-36879

You'll see the new design I'm going for.

Yeah, I did notice and comment on that one as well. You can set 16x16 hit detection to the lower part of her body.
However, for 16 pixel box movement, 11 frame walking cycle is bit troublesome "while not impossible", for the sake of your own sanity,
I'd suggest toning it down to 8 frames per cycle.

 

[Nishi]

Just in case people thought I was slacking off... Board design vr.2

This one was done with the help of my friend Benjamin, and still need to get the programming done for the Xilinx chip. But it's still a peice of art!

This one is alot less chip heavy. With 1 PRG-ROM instead of 4, 1 CLPD instead of the 4 logic chips, still one CHR-RAM and an added SRAM with battery for saving games. (Sue me I want to have the PRG-ROM locked.)

Few options with the size of memory, since the same chip family with the same layout/pinout goes up to 4GB... ^_~