See, that's the thing I love about LZ. The Compression doc won't tell you this, but its evil secret is that if you put Distance as 1 and Length as the number of times you need the preceding byte copied, it works just like RLE.

EDIT: *shoots himself, shoots himself some more and then keeps on shooting*

All this freakin' time. Ever since I first found compression in this game, I was fully expecting to find even the script compressed.

Guess what: it's not. The problem is, I should have known that already.

I made a table for it years ago.

That's right, back in the caveman days when I was breaking G Gundam's knees with absolutely no idea who Schwartz Bruder was (and I still regarded Sylvanian Families as being Maple Town's "inferior clone", if I had heard about it at all), I made a table for Patlabor, probably using my crappy old romaji method, long before the idea that I could thwart compression (let alone implement a VWF) ever popped into my head. How I forgot this simple fact, I have no clue, but I've had a fair bit of the work already done for me. Hopefully I can salvage my old table and make the script extraction process a breeze.

...You know, it would be infinitely appropriate if I implemented some kind of DTE or other script compression into this game. ^_^

EDIT #2: Well, what a surprise. It's not quite as prehistoric as I feared: I last updated it May 30th, 2005...conveniently, shortly before I started work on SF1. ^_^; Which would also have been after I made an attempt on SF5.

Anyway, the important thing is, it seems I rewrote it for use with WindHex after all. The whole thing is in Shift-JIS format; problematic if I want to use Atlas, but on the shining upside, I can now make my own insertion/extraction tools.

...I'm probably being premature here, but I think I'm slowly turning into an expert here. And I don't have a single release under my belt. XD

Two major problems here:

1) The overhead of constantly saving states in the background would choke the emulator speed even more. Conversely, if I take snapshots less frequently, then loading savestates will take that much longer. I doubt the user will be willing to tolerate 1+ second delays (though the alternative of no savestates is certainly much worse). After taking the snapshot, I would then have to keep a log of keyboard presses to simulate a series of events. This would add a constant overhead of logging this data nonstop while the emulator is running.

2) There's still the problem of getting to a point where a savestate can be captured at all. bsnes has three active threads at this time (core, sCPU and sSMP). In the future, it will also have sPPU and sDSP. So, ultimately, I will have to capture a state when all five threads are at a point where I can safely enter the routines from the start of their functions, with no disruption. While we can get into all kinds of theoretical arguments regarding this, I really don't think all threads will align in such a way that none are "in the middle of doing something" at any point in time to conveniently take a snapshot. Doing this with just the three threads I have now, however, shouldn't be too bad. I'd probably only miss a few opcodes, which could be corrected with your "save prior and catch up on load" approach mentioned above. Which is very clever, nonetheless. It would work great if there were only two threads to worry about

Let me explain the situation a little better... let's say you wait until a CPU opcode edge, no DMA is running, and no interrupt is executing. You're at a safe point to restart the CPU thread. However, the PPU is right in the middle of a scanline render. You still have a good half a scanline worth of instruction code to execute before you reach a safe resume point (start of a line, let's say). Your SMP is in the middle of an opcode execution as well. So, what do you do? Run the SMP until it's at a safe opcode edge. Whoops, now your CPU is in the middle of an opcode, and your PPU is still in the middle of a function. And now your DSP thread is also in the middle of generating the next sample. It's impractical to wait for all to align. It could theoretically never happen with the right code in place.

Now, the obvious next question is, "why not add more safe return points?"
Simple. Each one is very costly to performance and code clarity. If, for example, you want to add more than just "between opcode" points to your CPU core, that means you have to split your CPU core into a cycle-based core, and split your DMA routine to transfer one byte at a time and return. There's a 60% speed drop in your CPU core alone (~20% total speed hit), and now you basically have a cycle CPU core. That's still not good enough for resuming between bus accesses. So split that in half again, now you have a 40% total emulator speed hit, and your code looks like spaghetti, but now you can basically resume at any point in CPU operation. However, the glaring problem here, even if we assume this is practical, is that at this point, there's no need for having additional threads! You've basically negated all benefits to running separate threads concurrently, or in parallel, like the real system does.

For the same reasons a copier cannot take an accurate savestate on real hardware, bsnes cannot take an accurate savestate during emulation.

I generally agree with Suzaku and that's why I stated BSNES caters to a different userbase than ZSNES earlier.

As far as savestates on the real hardware. You know, my UFO takes some fairly decent savestates. Most of the time any issues get resolved exiting or entering an area and sometimes, there's little to no noticeable issues at all. That's just my observation since it was brought up. I'm not saying you should or shouldn't add savestates nor how to do it.

Well, as I mentioned before, the English Patlabor logo on the game is the same as the official one (except the official one is white). I can probably adapt "The Mobile Police" based on the cover you provided earlier and any other official artwork I can find.

Now, in regards to Asuma's name... it's supposed to be 'Shinohara'. Several backgrounds in the series have the name as Shinohara (since Asuma is the son of the owner of Shinohara Industries, who manufacture the Police Labor AV-98 Ingram models used by Special Vehicles Section II) so the name should be that. But you know, some Japanese don't write down the 'h' in shi, so who knows. I vote for changing that to Shinohara. :angel:

Just send me a palette I can use and I'll see what I can do.

Would you really want bsnes savestates that work "most of the time"? Because I could do that. I could just disable synchronization and run each component up until a safe syncing point. But the problem is, resuming will not be accurate. I doubt it would cause much trouble, but since it's a difference from the real system, it would be possible to crash. The annoyance of taking a savestate, resuming, and then crashing; even 1% of the time; would be far worse in my opinion than not having savestates at all.

Regarding the save states, there was a hardware device that pretty much served this function that I used to own at one point.  I believe it was called a NakiTek Game Saver+ or something along those lines.  It seemed to work OK from what little I messed with it, but I do think there may have been some issues with certain games (been too long to recall honestly).

I wonder if knowing the inner workings of the device would help any?


Edit: Some (very little) additional info on the device here.

byuu:
So that doesn't work then. You could of course do that unreal/blurry savestate thing. Needs a good name though...

Suzaku:
Unfortunately hunting down some bugs (so that you get to a SNES-like emulator) requires either savestates, or wading through massive logfiles.


Ugh... -_-