IPS patches

nachch · Post by **nachch** » Tue Nov 29, 2005 1:18 pm

Hi,
I know that Zsnes will autopatch roms if the autopatch option is set, and it finds an IPS file with the same name as the rom file in the saves directory (roms directory if saves dir is not set).

I use a different directory for saves (so all those files Zsnes writes don't clobber my roms directory), and I find it very counter-intuitive that the IPS patches are loaded from the saves dir.

IMHO, it seems a lot more logical that the patches will be loaded from the roms directory (or better yet - a "patches" directory).

So, if it's not too much trouble, perhaps the ips patching routine might look in both roms and saves directories for the patch?
Or, leave it as it is now, but add a patches directory, that when set will be used to search for corresponding IPS files.

Thank you for the good work!

flowrent · Post by **flowrent** » Wed Nov 30, 2005 4:08 pm

What's the use of those patches?
Just get a clean rom, audit it with Good Snes to make sure it's good and everything will work fine.

Clements · Post by **Clements** » Wed Nov 30, 2005 4:14 pm

Translation patches, presumably.

Hyos · Post by **Hyos** » Thu Dec 01, 2005 3:20 am

Word of advice: NEVER USE GOODSNES.

Use NSRT.

http://nsrt.edgeemu.com/

nachch · Post by **nachch** » Thu Dec 01, 2005 5:42 am

Clements wrote:Translation patches, presumably.

Yes, that's the general idea.

Hyos wrote:Word of advice: NEVER USE GOODSNES.

Use NSRT.

I am using nsrt, but that is completely beside the point.

My request is simply for a way to keep my files better organized.
Actually, as long as I'm on the subject, why not make optional settings to define a cheat directory and split the saves directory to save states/SRAM?
This will result in a far more organized file tree for those who want it (otherwise, i.e if directories are not set, just use defaults as it is now).
This should be a breeze to implement, just add a couple of variables to the config file.

Please, only reply or comment about this request, and spare those "helpful" hints that have nothing to do with it.

Thanks!

Jipcy · Post by **Jipcy** » Thu Dec 01, 2005 6:49 am

nachch wrote:This should be a breeze to implement, just add a couple of variables to the config file.

Whoops! You just said the wrong thing. Never, ever assume how easy/hard it is to add something to ZSNES. If it's such a breeze, you're welcome to add it yourself, as ZSNES is open-source.

The Sage Of Time · Post by **The Sage Of Time** » Thu Dec 01, 2005 8:14 am

Jipcy wrote:
nachch wrote:This should be a breeze to implement, just add a couple of variables to the config file.
Whoops! You just said the wrong thing. Never, ever assume how easy/hard it is to add something to ZSNES. If it's such a breeze, you're welcome to add it yourself, as ZSNES is open-source.

You're right, but his request is valid however.. It's a good idea, and if anyone doesn't like it, they can still just assign all the saves\patches to a single directory, so it's win\win really.

nachch · Post by **nachch** » Thu Dec 01, 2005 8:50 am

Jipcy wrote:
nachch wrote:This should be a breeze to implement, just add a couple of variables to the config file.
Whoops! You just said the wrong thing. Never, ever assume how easy/hard it is to add something to ZSNES. If it's such a breeze, you're welcome to add it yourself, as ZSNES is open-source.

You're correct, of course.
And usually I would never say something like that. I just think that this specific issue should really be very easy to implement. We're not talking about some grand functionality, or some emulation issue, or god forbid assembly GUI programming, or anything deep it all. It's a very "superficial" feature.

You're also correct on the fact that I can add it myself... I'll just have to install a Linux distribution as I just got a new computer with only XP installed, and I can't get myself to develop code on that OS.

flowrent · Post by **flowrent** » Thu Dec 01, 2005 8:54 am

Hmm so NSRT is better than Good Snes....
What's the best tool for N64 roms?

Post by **Nach** » Thu Dec 01, 2005 10:07 am

nachch wrote:
Jipcy wrote:
nachch wrote:This should be a breeze to implement, just add a couple of variables to the config file.
Whoops! You just said the wrong thing. Never, ever assume how easy/hard it is to add something to ZSNES. If it's such a breeze, you're welcome to add it yourself, as ZSNES is open-source.
You're correct, of course.
And usually I would never say something like that. I just think that this specific issue should really be very easy to implement. We're not talking about some grand functionality, or some emulation issue, or god forbid assembly GUI programming, or anything deep it all. It's a very "superficial" feature.

Really?
Sure I can add you your variables to the config file in about 10 seconds. AND IT WILL DO NOTHING.

You forget I have to go through every single place in the ZSNES source where a particular save type is being worked with, and add in directory change code. You think that's easy? Do you realize how many hours of work it took to do the overhaul we did for v1.4? Did you forget it also introduced some bugs then that if the save wasn't able to write ZSNES crashed? We had to make a bug fix release right away because in our haste to add this we introduced a bug which wasn't so easy to notice at first till we had mass testing over the next three weeks.
It was also very unpleastant for me at the time since I had the flu, and was feeling awful. But I couldn't let the situation continue and released v1.41. And then even there with all the fixes a new crash bug on game load was introduced, and I had to make another release two days later.
Don't go telling me it was easy, and I'd like to know of someone else who would take enough responsibility of their code that they would use their laptop while in bed with the flu to rectify the situation.
On top of this all, we no longer just have save options in the config file, adding such a feature would require assembly GUI programming.

Now if you want to add it, be my guest. And with all the changes you need to make all over the source code, I hope you test it well, I don't care to have the same fiasco as last time.

nachch · Post by **nachch** » Thu Dec 01, 2005 11:03 am

Ok, you made your point...

It won't be as trivial as I thought, especially since I don't know the code and will have to wade through alot of it in order to catch everything.
But I'm going to give it a try.

Regarding the GUI programming, I don't think it's necessary to have those new options in the GUI, since they probably won't be that widely used - won't it be fine if they only appeared in the cfg?
Btw (and slightly OT), I don't really see the sense in having the two config files, as the GUI cfg isn't exactly specific to the GUI and contains a lot of general settings. Is there a specific reason for that split?

Regarding the issues you had with 1.4, I just wanted to say that I wasn't around and don't actually remember it. What exactly was the nature of that overhaul?
And of course, kudos for your responsibility fixing it like you did...

Post by **Nach** » Thu Dec 01, 2005 12:30 pm

nachch wrote: Regarding the GUI programming, I don't think it's necessary to have those new options in the GUI, since they probably won't be that widely used - won't it be fine if they only appeared in the cfg?

Being that we've been getting requests for everything to be seperate, cheats, IPS, srm and what not, no I don't think just config file would be enough.
I also don't think your average person will be able to figure out the \\ on Windows.

nachch wrote: Btw (and slightly OT), I don't really see the sense in having the two config files, as the GUI cfg isn't exactly specific to the GUI and contains a lot of general settings. Is there a specific reason for that split?

Thank you for your opinion. I'll allow someone else to smash this.

nachch wrote: Regarding the issues you had with 1.4, I just wanted to say that I wasn't around and don't actually remember it. What exactly was the nature of that overhaul?

Ever seen this?

That was added to v1.4.

Some related changes over time:

Code: Select all

2004-01-13 15:12  n-a-c-h

	* src/gui/menu.asm: Oops, couldn't save more than one SPC per game
	before, fixed.

2004-01-13 14:27  n-a-c-h

	* src/: init.asm, initc.c: Made handling of base cart paths more
	logical codewise.

2004-01-13 14:06  n-a-c-h

	* src/gui/menu.asm: Fixed holes in new path code for snaps and
	SPCs.

2004-01-13 10:00  n-a-c-h

	* src/gui/menu.asm: PNGs now use SnapPath.

2004-01-13 01:15  n-a-c-h

	* src/gui/menu.asm: BMPs and PCXs now save in the SnapPath.

2004-01-13 00:54  n-a-c-h

	* src/gui/menu.asm: SPCs now save in the SPCPath.

2004-01-11 14:56  n-a-c-h

	* src/: init.asm, initc.c: BIOS/Base carts now use paths.

Code: Select all

2004-12-08 23:54  n-a-c-h

	* src/: init.asm, initc.c, cpu/execute.asm, gui/gui.asm,
	gui/guinetpl.inc: Removed old, broken, and problematic code that
	wasn't really needed. Fixed more SRAM issues

2005-01-10 04:21  n-a-c-h

	* src/: cfgload.c, init.asm, ui.asm, cpu/execute.asm,
	dos/dosintrf.asm, gui/gui.asm, gui/guikeys.inc, gui/guiload.inc,
	gui/guimisc.inc, gui/guimouse.inc, gui/guinetpl.inc,
	gui/guiwindp.inc, gui/menu.asm, linux/sdlintrf.asm, linux/zfilew.c,
	win/winintrf.asm: Code cleanup. Save location can now be edited in
	GUI. *nix can now correctly save in a location other than ~/.zsnes

2005-02-06 05:32  n-a-c-h

	* src/cfgload.c: Fixed SRAM path saving when loaded from config
	file. Fixed loading of sound off.

2005-02-08 00:18  n-a-c-h

	* src/: cfgload.c, gui/gui.asm, gui/guikeys.inc: SRAMPath should be
	fixed for good now.

Code: Select all


2005-09-19 17:55  jbo_85

	* src/vcache.asm: Fixed SRAM Check+Save once and for all.

Well there was a ton of changes needed to be made to allow the paths for various things to work in the first place. Images was pretty easy, but SRAM for example was a total nightmare. Code for dealing with it is all over the place (and used to be a lot more all over the place).
Tons of things had to be changed for that, and the changes were also need because we had general SRAM saving issues. I recall spending 10+ hours one free day I had fixing up a bunch of them.
Unforunetly, we found all the new code we put in was causing ZSNES to crash if for some reason a save couldn't be created (running from CD?), after the release. We then fixed that and had another release, but then we found zlib issues, and loading problems with IPSs. And even after everything, we got a lot of complaints about the Check+Save option being broken. If you check the full changelog, I think we had over a dozen fixes for Check+Save issues.
Others that remember could elaborate more on the saving issues and especially the Check+Save issue, a feature which I don't use.

And on top of all this, I'm quite disastisfied at the moment about ZSNES' change directory requirement, one of these days I'll try to fix that, should make other things much easier too, but it's a decent sized project.

nachch wrote: And of course, kudos for your responsibility fixing it like you did...

Thanks.

Nightcrawler · Post by **Nightcrawler** » Thu Dec 01, 2005 3:18 pm

Here's my two cents.

I would motion for such a feature as well. I think it is useful and does assist with organization of files. Most other emulators have seperate directories for most things. ZSNES was a mishmash right from the start. Who's idea was it to do everything in one directory to begin with? Not a good one in IMHO. While we're on design issues. Had a defined path string been declared for this purpose, you wouldn't have to search all over the code for many places. The path would be contained in one place. ZSNES certainly has some inherent problems from it's inception that really cause some headaches.

It's not the fact that ZSNES was coded in assembly that is the 'scare everyone away from changes' cause. It's the unfriendliness to change. It wasn't designed for changes from the start. The way I see it we have a fundamentally flawed piece of software. How long are we going to keep patching over top of it?

Wouldn't time be better suited focusing on the continued porting to C? That's essentially turning it into a new emulator. The point in porting to C in my eyes is not necessarily to get away from assembly, but more to get away from the ineherent design flaws that hinder any further development.

I've watched these feature requests and responses to the difficulty of changes for years now. It's ridiculous. It's the same old whiny answer. It takes hours to change anything. Nobody wants to make any GUI changes. Most peoples feature requests are simply attacked with the response that it's too hard to make that change and to go do it yourself. These are mostly to items that in a program designed differently WOULD be a breeze.

How long is this going to continue? How long can you keep patching the holes in the boat before you need a new boat?

ONE new GUI screen caused all those headaches Nach posted above. That's just sad. WHY do we continue to patch software like this? Jobs that should take 30 minutes take 30 hours. Doesn't that sound insane to keep patching said program rather than some redesign work(which in this particular case can probably be accomplished with continued C porting).

What do you do? Keep taking 30 hours to do 30 minute jobs? Or take the time to do the redesign work, and from that point on all the 30 minute jobs take 30 minutes! I'm pulling these times out my rear, but the point is still there. Quit continuing to do everything the grueling way and talking about how awful it is and try and fix the root of your problem.

Ok, I've made my point and rant for the day. I'm done now.

Post by **Nach** » Thu Dec 01, 2005 5:33 pm

Nightcrawler you just seem to be embelishing on my roadmap except in a more negative manner, I suggest you read it (again) http://board.zsnes.com/phpBB2/viewtopic.php?t=4935

nachch · Post by **nachch** » Fri Dec 02, 2005 3:29 am

Nach, that link doesn't seem to be working for me.

adventure_of_link · Post by **adventure_of_link** » Fri Dec 02, 2005 3:53 am

Information

The topic or post you requested does not exist

Clements · Post by **Clements** » Fri Dec 02, 2005 4:06 am

The thread is in a private forum.

Post by **Nach** » Fri Dec 02, 2005 4:48 am

nachch wrote:Nach, that link doesn't seem to be working for me.

The link was not meant for you. See what Clements said too.

Nightcrawler · Post by **Nightcrawler** » Fri Dec 02, 2005 2:40 pm

Nach wrote:Nightcrawler you just seem to be embelishing on my roadmap except in a more negative manner, I suggest you read it (again) http://board.zsnes.com/phpBB2/viewtopic.php?t=4935

My long term retention skills have failed me.

I apologize. I do remember reading that now after a refresh. That's certainly good to hear. However, I'm of the belief these types of problems extend beyond the path issues.

I think you can't stop after that's accomplished. You should take that mentality from this point forward. Always attack the root. Yeah, it's not pretty and it's gonng take some work, but it will be more beneficial in the end because you're not dealing with the same old obstacles over and over and over that pile up the hours. Take a fraction of those hours now to save many in the future.

You need to make sure the foundation is secure before you add another level. I don't really keep up with who all is working on ZSNES and what portion exactly, but it seems like there is still some spread focus amongst the devs. Perhaps your efforts should be concentrated on the same task when it comes to attacking a root problem?

That's all I am going to say. I'm not qualified to be the project manager for ZSNES, but I just felt like sharing some thoughts.

Post by **Nach** » Fri Dec 02, 2005 3:15 pm

Well, it did seem like most of what I was doing lately was finding problematic components and totally rewriting them.

Hyos · Post by **Hyos** » Fri Dec 02, 2005 5:49 pm

nachch wrote:
Hyos wrote:Word of advice: NEVER USE GOODSNES.

Use NSRT.
I am using nsrt, but that is completely beside the point.

...

Please, only reply or comment about this request, and spare those "helpful" hints that have nothing to do with it.

I wanted to correct flowrent's post because he advised to "audit with GoodSnes". No offense intended.

nachch · Post by **nachch** » Sat Dec 03, 2005 5:01 am

Hyos wrote:I wanted to correct flowrent's post because he advised to "audit with GoodSnes". No offense intended.

Yeah, I figured that out a short while after I posted, I just didn't want the thread to lose focus before anyone actually replied about the issue I've raised.
So, I'm also sorry if I offended you.
And if flowrent's a bit wiser now about the ways of the world, and about Good{Bad,Hack,Crap}snes, then you performed an important public service to the community...

Hyos · Post by **Hyos** » Sat Dec 03, 2005 5:27 pm

nachch wrote:
Hyos wrote:I wanted to correct flowrent's post because he advised to "audit with GoodSnes". No offense intended.
Yeah, I figured that out a short while after I posted, I just didn't want the thread to lose focus before anyone actually replied about the issue I've raised.
So, I'm also sorry if I offended you.
And if flowrent's a bit wiser now about the ways of the world, and about Good{Bad,Hack,Crap}snes, then you performed an important public service to the community...

Yeah I still have hope I can change the world

flowrent · Post by **flowrent** » Sat Dec 03, 2005 6:21 pm

Indeed some roms reported good by GoodSnes have a bad checksum when audited with nsrt (btw i am dumb).I will use this program from now on.
Anyway what is the best program for n64 roms? Is it GoodN64?

If you see a "btw i am dumb"i didn't write that...You funny guys,dont modify my posts

xamenus · Post by **xamenus** » Sat Dec 03, 2005 7:17 pm

flowrent wrote:Anyway what is the best program for n64 roms? Is it GoodN64?

Probably. Though I myself prefer dat files over everything. Even the SNES dat from the following link is more up-to-date than NSRT. EDIT: OMG, NSRT 3.3 RC3 has been released! I may have to retract that statement!

http://gbadat.altervista.org

The next release of GoodNES, however, will be superior over any dat. I believe the next release is going to have an iNES header cleaner/database, so I'm happy for that.