PasseGaming
Active member
Wow, I really hope you release the module. It looks fantastic. Would love to make a straight up RPG.
Issue with releasing a module, is the fighting system, monster/character tables, items and so on are all code. Which means there isn't a GUI for people to quickly make changes to the stats, names and so on.Wow, I really hope you release the module. It looks fantastic. Would love to make a straight up RPG.
Don't feel bad. Depending on how things go, I may release my code once it's done. But with that said, it would be "As Is" with no support.Oh... well that's disappointing. Hopefully Joe manages to finish the one he has been working on, otherwise many of us just aren't going to have that opportunity. Anyhow, I hope all the best with your project.
Honestly, I think that is the most anyone would expect from any custom module. Hopefully you do decide to release it, might end up being a lot of work but having a framework is a far better start then nothing.Don't feel bad. Depending on how things go, I may release my code once it's done. But with that said, it would be "As Is" with no support.
I would give documentation on how things work and how to edit, but that's still a fair amount of time down the road.
Iād probably say to go with option 1 because it would be a lot easier although I would say that maybe the actual save code could be reduced like having a designated tile on each screen for the players save spot, or just having designated save spots or stations as a more ācheckpointā based save system with issue 2 on that I donāt quite understand, why would you be limited to 100,000 saves, I mean itās not really a problem because itās not like your gonna save that many times if your not doing it on purpose. Even with that though I think it would probably be the best and with some proper testing we could find all the possible ways that it could over flow a bank, only really could think of one way that could happen though, if you where on the seem of the next screen. So all in all I think it would be the best solution since it also keeps the price down so probably more people might buy it as well.
Already looked at the post a while ago, and used it as a base for what I was doing. But still have to worry about the issue I posted about.Reading through this thread might help you understand flash saving better: Lets talk about saving [4.1+]
Note that the thread was written when Mesen didn't support self-flashing yet, so ignore that part.
I doubt there is much to change when it comes to adapting it to version 4.5.X.
No. I've limited myself to breaking the game and saves as someone would as a player.You say the FF 3/6 save glitch is simple, but you need to consider that the requirements are so specific that none of the playtesters nor the majority of players would have noticed it at all.
You're probably breaking the save system more than the average player ever could, to be honest. What do you mean by "saving while glitching the game"? Are you messing around in the memory viewer or something?
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.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...
Just going to apologize head of time, if I seem to be rude at anytime. Just replying as a geek.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.