Author
|
Topic: So I took a look at Geiger's Snes9x. (Read 4962 times)
|
Nightcrawler
Guest
|
 |
« Reply #30 on: October 01, 2006, 01:52:45 pm » |
|
Why would they change the offsets for existing information? I don't know the details of what's going on over there with ZSNES but I don't think there is much need to alter the existing information and it's place. Even if there is, they can at least offer the new savestate format as a new version. Do they at least update the file version number when they make these changes?
EDIT: Fixed that jumble of incoherent sentences.
|
|
|
|
« Last Edit: October 01, 2006, 03:49:24 pm by Nightcrawler »
|
|
|
|
Kitsune Sniper
Guest
|
|
« Reply #31 on: October 01, 2006, 02:21:27 pm » |
|
All I know is that the savestates are now hopelessly broken for me.  |
|
|
|
|
creaothceann
Guest
|
|
« Reply #32 on: October 02, 2006, 04:54:48 am » |
|
Why would they change the offsets for existing information? I don't know the details of what's going on over there with ZSNES but I don't think there is much need to alter the existing information and it's place. Even if there is, they can at least offer the new savestate format as a new version. Do they at least update the file version number when they make these changes?
The existing information seems to be still in the old place for now. Eventually the format will become a new one, called PSR. We'll see how easy that will be to support. IIRC the version number is not changed for WIPs, only for official releases. Of course it doesn't help that it's only one byte in size. |
|
|
|
|
Nightcrawler
Guest
|
|
« Reply #33 on: October 02, 2006, 08:30:50 am » |
|
Why would they change the offsets for existing information? I don't know the details of what's going on over there with ZSNES but I don't think there is much need to alter the existing information and it's place. Even if there is, they can at least offer the new savestate format as a new version. Do they at least update the file version number when they make these changes?
The existing information seems to be still in the old place for now. Eventually the format will become a new one, called PSR. We'll see how easy that will be to support. IIRC the version number is not changed for WIPs, only for official releases. Of course it doesn't help that it's only one byte in size. Uh Oh.. I feel a big rant coming on.... yes.. here it comes.... [rant] Too bad ZSNES official releases are YEARS apart usually.. I can't stand when everybody over there snapat some new person that they need to use the WIP version that they have no knowledge of whenever anybody needs any type of support. It's only logical as a casual user that you would use the official versions. The WIP releases can't be found anywhere on the ZSNES site itself. Yet, they act like everybody should know about them and everybody should use them. The last official version was from January 2005!! There's been MANY WIP since then and so many changes it's not even funny. Here's an idea.. RELEASE A NEW VERSION! How many WIP have been released since Jan 2005? 20? They can't produce some stable code in nearly 2 years after all those WIP releases? That's just sad. That's exactly the message I think they're sending when they do things like this. If you're going to look at it like ZSNES is ALWAYS a WIP then how about you just scratch official builds altogether and post a link to the WIP releases. Make up your mind. I just really dislike the direction ZSNES has been going in recent times. Actually SNES emulation in general has taken a dive. Let's look at their main competition: SNES9x. SNES9x people can't even update their own Windows port anymore... SNEeSe isn't too bad, but despite recent advancement, you go to the homepage and it says the last news is from June of 2005. What the hell is going on with SNES emulation? It seems to be falling all to hell. Sure, BSNES is a nice new kid on the block, but BSNES doesn't target the same user base that SNES9x and ZSNES does. BSNES will never have savestates or those types of things that cater to the casual emulation user. None of the other emulators in development (Aside from Super Slueth, are there any others I forgot?) none of them have reached the same maturity or emulation level yet of the big players. Oh well.. I'm done ranting now.. [/rant] |
|
|
|
|
byuu
Guest
|
|
« Reply #34 on: October 02, 2006, 09:40:32 am » |
|
As soon as someone figures out how to pull off savestates in an emulator that uses multiple threads to sync between components with more accuracy than any other emulator has ever had... you let me know, and I'll add in savestates right away.
I'm losing hope with ZSNES. Only one person is able to modify core emulation at this point, and he's only interested in fixing bugs in games. Of course, you know how that goes. You fix one bug and cause two more. Fix those two and end up breaking another game. Fix that game and end up with 10 more broken games. The correct way is to emulate the hardware correctly and eventually all the games fall into place. Since they aren't taking that approach and reject accuracy bugfixes that break games, I doubt you will see 100% compatibility without hacks in ZSNES' lifetime. But I'm still waiting on this CPU rewrite, it could change things a lot for the better.
The SNES9x v1.5+ windows port is pretty easy to get, but it's a little glitchy. Overall, the emulation accuracy is only marginally better than ZSNES, but SNES9x has the advantage that they're actually able and willing to add recent findings and bugfixes into their core. So there's hope that SNES9x will continue to get more accurate in time.
SNESGT is a little better than ZSNES in terms of accuracy, and nobody knows if they use hacks or not. I don't think they do. Windows only, but the GUI is probably the nicest of any windows emulators. Unfortunately, closed source.
SNEeSe, I don't think TRAC has access to the emuunlim page anymore. He updates the sourceforge page. Newest versions have all the emulation features of modern emulators. Color add/sub, awesome sound, etc.
But SNEeSe also lacks savestates and SA-1/SFX support, so it probably has no value to you or other 'casual users' either.
Super Sleuth has everything you want but sound output, and everything I want but source code.
|
|
|
|
|
Aerdan
Guest
|
|
« Reply #35 on: October 02, 2006, 10:05:05 am » |
|
Note: PSR is a plaintext format [we already use it for the config file], so it should be really easy to handle.
|
|
|
|
|
creaothceann
Guest
|
|
« Reply #36 on: October 02, 2006, 01:12:07 pm » |
|
If you're going to look at it like ZSNES is ALWAYS a WIP then how about you just scratch official builds altogether and post a link to the WIP releases.
Yeah. Just add a note which features are new, and release it. An "official" release with completed features is a nice goal, but the number of WIPs has shown that you can't get all the bugs. You'd have to release "updates to the official version", aka WIPs. As soon as someone figures out how to pull off savestates in an emulator that uses multiple threads to sync between components with more accuracy than any other emulator has ever had... you let me know, and I'll add in savestates right away.
Wasn't there a comment on nesdev about loading & saving at certain points in time, and then emulating up to the actual moment when the user hit the save button? But I'm still waiting on this CPU rewrite, it could change things a lot for the better.
Let's hope so.  Note: PSR is a plaintext format [we already use it for the config file], so it should be really easy to handle.
In theory, yes. If I'd have to port ZSNES code over to Pascal then things get a little bit more difficult. I still haven't looked at the newer ZSNES versions' code how they're doing it. I should do that... |
|
|
|
|
Nightcrawler
Guest
|
|
« Reply #37 on: October 02, 2006, 02:44:17 pm » |
|
I'd just as soon give up using newer versions of ZSNES before I'd give up using VSNES if you can't fix it!  |
|
|
|
|
Ryusui
Guest
|
|
« Reply #38 on: October 02, 2006, 03:17:35 pm » |
|
VSNES is freakin' awesome, but please do me one favor: Mention in the documentation that the tilemap data is interlaced with the graphics data in Mode 7. Took me the longest time to figure that one out (though I should have been suspicious when the VRAM in my ZST came out with that funky waffle look despite looking perfectly fine in VSNES). Can I help it if Mode 7 is the only thing I've ever looked at to do such a thing? Oh, and off-on-whatever-topic: Patlabor is the most compression-happy game I've ever had the misfortune of making a serious attempt at. Even more frightening: I discovered that Bongo's recompression routine functions almost identically to the one I originally wrote for Sylvanian Families 5 and repurposed for Patlabor. His uses While loops while mine uses For's, his counts up distance while mine counts down...his uses obscure little concise variable names like "cmp_posi", "cmp_most" and "cmp_back" while mine uses "ReadPos", "Length" and "Distance", but otherwise, I wrote almost the exact same thing he did and I never looked at his code sample until recently. O_O; |
|
|
|
|
Nightcrawler
Guest
|
|
« Reply #39 on: October 02, 2006, 05:11:41 pm » |
|
Why is it VSNES's responsibility to document the way the hardware works?
That kind of information can be found in SNES hardware information documents. It's not a function of VSNES.
|
|
|
|
|
creaothceann
Guest
|
|
« Reply #40 on: October 02, 2006, 05:38:32 pm » |
|
Mention in the documentation that the tilemap data is interlaced with the graphics data in Mode 7. Took me the longest time to figure that one out (though I should have been suspicious when the VRAM in my ZST came out with that funky waffle look despite looking perfectly fine in VSNES).
Well, I wrote it mainly for those who know what they're looking at.  That's also the reason you won't see much technical info there, apart from the comments in the main window. (Which is just a short reference.) I tried to write a technical doc, but anomie's docs are much more accurate and complete. |
|
|
|
|
Nightcrawler
Guest
|
|
« Reply #41 on: October 02, 2006, 05:50:46 pm » |
|
Yes, Anomie's register doc is currently the most accurate SNES hardware document there is. I think it's even more clear than the official manual many times. You can trust the information he provides there. It's all accurate. If there is any doubt at all, he is honest and mentions that nobody really knows or not sure etc.
|
|
|
|
|
Ryusui
Guest
|
|
« Reply #42 on: October 02, 2006, 06:11:30 pm » |
|
I'm not expecting a detailed document...from what I've seen, you could work with this kind of stuff for years and never tangle once with Mode 7. Just a little nudge in the right direction to explain for the humble idiot why the hell there's no "tile map base" entry for it would suffice...
|
|
|
|
|
Nightcrawler
Guest
|
|
« Reply #43 on: October 02, 2006, 09:01:02 pm » |
|
http://www.romhacking.net/docs/regs.txtDid you read this? Anomie's document will tell you everything you need to know. There is an additional section at the bottom on Mode 7. Mode 7 is radically different than any other mode. All bets are off. Do a little reading there.
|
|
|
|
|
Ryusui
Guest
|
|
« Reply #44 on: October 02, 2006, 09:16:36 pm » |
|
The tilemap and charactermap are interleaved, with the character data being in
the high byte of each word and the tilemap data being in the low byte *shoots himself* I used Anomie's docs...just never noticed that tidbit before. Damn. *shoots himself again for good measure* EDIT: Hey, rock on! Special Compression Division 2 (yeah, I can't resist giving my utils funny names) got the original title screen reinserted. ^_^ Tested it and everything. I sorta copied Bongo's While loop method when rewriting it...had the damnedest time getting it to work. Guess that's what I get for ripping off someone else's code. On the plus side, I discovered that MVN apparently has no qualms should source and destination overlap: that's where my optimization was screwing up. Apart from a few immaterial mathematical details, it's almost the exact same thing as SF5's compression scheme. ^_^ |
|
|
|
« Last Edit: October 02, 2006, 11:22:41 pm by Ryusui »
|
|
|
|
|
RHDN Forum Archive
