Post v1.42 ZSNES WIPs

[Nach]

SRC: Removed some alignment dependancy, removed some archaic code such as Dracula X hack. [Nach]

That has no effect on any code at all.

[Deathlike2]

That has no effect on any code at all.

My bad.. I'm only guessing here.. wasn't trying to point fingers here.

Maybe it is just me or that this bug could be just like the CT Black Omen bug.. it comes and goes...

In any case, I assume it is an alignment issue or is it something else?

[pagefault]

Thanks to Jonas Quinn for tracking it down. It is the BG latch behavour we implemented a while back and it still has issues with the current code. But we are also still working on the mode 7 version of these modifications so hopefully this will correct the issue.

[grinvader]

But we are also still working on the mode 7 version of these modifications so hopefully this will correct the issue.

It is hell in a box

And it's gonna break states badly. We need to overhaul the damn state format to allow compatibility or else it's gonna break for every core fix we do.
The current states are using the alignment of the vars declared in asm to save them all at once. Which is bad, since I don't want to rely on alignment. I like to add vars in the middle of the list (where they belong, like I put m7scrolx just under the other mode7 vars) instead of at the bottom - which would still break things anyway.
I thought of something, tell me about it:
1- Easiest case once the binary 94-char packing is done in parsegen would be to use it to generate states. Each var would get assigned and read independently, any extra variable wouldn't be read and if a var was missing we could add an auto-initializer for those.
Big advantage: states would now be plain text and extremely easily editable for hacking or debugging, at the expense of a fair size increase.
2- If that's for some reason not good, then we would have to use some other format, hybrid text-binary. It wouldn't be editable easily (since there would be all chars from 0-255), but the size would be smaller.
I thought about such a format:
NameSizeDataNameSizeDataName...
With name in ASCII, Size a number in bytes (to read the next <number> bytes of binary), and binary data.
No line breaks, of course, or else the \n might be read as data.

Feedback ? (Users are free to comment on this too, after all state compatibility mainly affects them)

[SquareHead]

But we are also still working on the mode 7 version of these modifications so hopefully this will correct the issue.

It is hell in a box

And it's gonna break states badly. We need to overhaul the damn state format to allow compatibility or else it's gonna break for every core fix we do.
The current states are using the alignment of the vars declared in asm to save them all at once. Which is bad, since I don't want to rely on alignment. I like to add vars in the middle of the list (where they belong, like I put m7scrolx just under the other mode7 vars) instead of at the bottom - which would still break things anyway.
I thought of something, tell me about it:
1- Easiest case once the binary 94-char packing is done in parsegen would be to use it to generate states. Each var would get assigned and read independently, any extra variable wouldn't be read and if a var was missing we could add an auto-initializer for those.
Big advantage: states would now be plain text and extremely easily editable for hacking or debugging, at the expense of a fair size increase.
2- If that's for some reason not good, then we would have to use some other format, hybrid text-binary. It wouldn't be editable easily (since there would be all chars from 0-255), but the size would be smaller.
I thought about such a format:
NameSizeDataNameSizeDataName...
With name in ASCII, Size a number in bytes (to read the next <number> bytes of binary), and binary data.
No line breaks, of course, or else the \n might be read as data.

Feedback ? (Users are free to comment on this too, after all state compatibility mainly affects them)

Provided you were to do solution #1. Does zsnes only have decompressing routines in it? I mean for jma and zip? If you were going to use plain text for zsnes savestates, would it be worth it to add in a compression routine and automatically compress these after theyre written?

[grinvader]

Nach is already talking about gz-compressing states. It'd save a lot of diskspace, but you'd have to decompress them yourself to edit them afterwards. Not that GZ is an obscure format, just pointing the extra step.

It seems it wouldn't really impact ram usage, since there are functions to work on the gz data directly instead of decompressing the whole state to RAM then working on it from there.

[Aerdan]

The advantage of PSR/<some other plaintext format> isn't just easy editing, in case anyone's confused. It's also useful for debugging purposes.

[Deathlike2]

What kind of size is expected for the first format (yes, it is big, but define the storage space for the worst case scenario)?

As long as they aren't the size of overbloated Word documents, then most people should be fine with them. (size of savestate should be < size of ROM)

Somehow I knew savestate compatibility would be broken at some point (it should just be put out in the FAQ just because.. unless you can get a "final savestate" revision.. the savestate format is its own WIP)

Even before 1.43, 1.42 already had "borked" savestate compatibility... I think now it is almost pointless to even write code to maintain the compatibility (unless it is to stop ZSNES from reading older savestate formats to produce unpredictable results).

[Aerdan]

We would need to complete the PSR-based state format before we can say. It'll already be gzipped, so it should be about the same, filesize-wise.

[grinvader]

Hmm, well. If we just turn all the data in a normal state into 94-base strings, the values themselves should take roughly the same size (old size x1.061, to be precise) but the big addition are variable names.

So, the smallest states would probably go from 267kB to around 400... that's a wild estimation, it could be bigger.
After that, the GZ compression will probably bring that down to 120kB, more or less some dozens kBs.

EDIT: Err, wait. I did bad math here. it's new = old x 1.22 + names. So around 450kB for the smallest states before compression...

Also: Aerdan proposed an extension renaming for these 'new' states.
1- would an extension renaming be a good idea
If yes:
2- what extension would be best ?
3- should we keep the current "0 == special case" ? [i.e. ZS0 -> "ZST"]

[creaothceann]

My opinion is that compression is only needed for transferring savestates from one computer to another. The size advantage is not that great, compared to MP3, JPEG and video codecs... and you could load text savestates with any editor.

I have a zLib Pascal translation, so for me it doesn't matter much.

Also: Aerdan proposed an extension renaming for these 'new' states.
1- would an extension renaming be a good idea
If yes:
2- what extension would be best ?
3- should we keep the current "0 == special case" ? [i.e. ZS0 -> "ZST"]

1. It would be nice - for Windows & Linux users. DOS won't understand the new filenames though.
2. Just ZST.
3. Nope.

I'd store the cartridge name in the savestate, and let ZSNES DOS scan all savestates in the current directory.

[Aerdan]

1. It would be nice - for Windows & Linux users. DOS won't understand the new filenames though. Confused
2. Just ZST.
3. Nope.

Bullshit @ 1.

Basically, the idea here is to move away from 'zst', since zs? is for the old states, and requires extra processing in order for both old and new states to be loaded without issue. I was going to go for a filename like this:

Game.?.pzs

where ? is the slot number. Alternatively, replace the first . with a _ so DOS shuts the fuck up.

[grinvader]

I was going to go for a filename like this:

Game.?.pzs

where ? is the slot number. Alternatively, replace the first . with a _ so DOS shuts the fuck up.

This won't do... game names are already using the whole 8 chars. We can't add _shit to that, it's the reason zsnes uses this zst-zs9 setup to begin with.

[SquareHead]

I was going to go for a filename like this:

Game.?.pzs

where ? is the slot number. Alternatively, replace the first . with a _ so DOS shuts the fuck up.

This won't do... game names are already using the whole 8 chars. We can't add _shit to that, it's the reason zsnes uses this zst-zs9 setup to begin with.

Although dos wouldnt it end up Gamena~1.pzs through Gamena~9.pzs or something? Or was that added in the dos vesions for windows 95-me?

Why not just use something like SST-SS9? Or something like that?

Or, if you need one and only one extension, is it possible to put all 10 savestates into the one file? Padding the unused space of course. Depending on what slot is selected, use a pointer to read the correct section of the file?

[grinvader]

Or, if you need one and only one extension, is it possible to put all 10 savestates into the one file? Padding the unused space of course. Depending on what slot is selected, use a pointer to read the correct section of the file?

Hey that's an excellent idea, thanks a lot Squarehead !

With a single file... more insane features.
ZSNES would use a single state file, holding X states (X=10 for starters, so we don't have to rework gui stuff). When you select a slot, there will be new functions in GUI->Game:
Export state
Erase state
Import state

Exporting a state would dump the current state slot (if not empty) to your save dir, so you can share it, make a backup, hack it, and so on.
Erasing a state would erase current slot (durr) after confirmation.
Importing a state would load a single state into the current slot (after confirmation if current isn't empty).
No need for padding empty states, we'll use smart headers in this file.

This format wouldn't be limited to 10 states, but you wouldn't be able to access the states > 10 until we rework the GUI.

[creaothceann]

Basically, the idea here is to move away from 'zst', since zs? is for the old states, and requires extra processing in order for both old and new states to be loaded without issue.

You'd just have to check if there're two dots in the filename. "zst" is still a good abbreviation, IMO.

I was going to go for a filename like this:

Game.?.pzs

where ? is the slot number.

I was thinking of almost the same format:

Game.????.zst

where ???? is a string of 4 or more hex. digits.

[Palin]

I've been lurking around for a while and I finally put forth the effort to compile one of the WIPs (mostly so I could try out the CPU optimization.) I just wanted to thank the dev team for all the work you guys have put in. I'm wondering though, what are the criteria for the next stable release? Looking at the forums its pretty obvious that you're working hard, but the front page hasn't been updated since May.

[Nach]

what are the criteria for the next stable release?

Stability - Crush the core ramdomness once and for all.
Complete movie support (and it's needed sister features).
Complete new netplay support.
Graphics overhaul.
DSP-4 finishing touches.

Maybes:
DSP-3.
BS-X.
Sound overhaul.
Improved archive support (do not ask for details, read FAQ).
Mapping improvements.
More porting.

[Jipcy]

Complete new netplay support.

Wow.

[Ichinisan]

Graphics overhaul.

Yay.

No more toggling GFX display engines?

[Truth Unknown]

So a shiny new ZSNES.

[snkcube]

All those tasks will take such a long time. I bid you devs good luck.

[creaothceann]

With a single file... more insane features.

Do you plan to include movies into this file too?

[Jipcy]

I think we should realize, though, that those are simply "criteria for the next stable release." So, I assume stable release means official version, non-WIP. And they are criteria, not necessarily what's being worked on right now.

So, given that list, the next official release will be amazing, and, it seems, rather drastically different from 1.42.

I think it's going to take at least another year to meet those criteria, though.

[SquareHead]

With a single file... more insane features.

Do you plan to include movies into this file too?

That sounds scary.