SH3 Blitter Delay Discussion Thread

[KAI]

I've noticed different slowdown rates when using DDRAW instead of D3D, or maybe I'm just feeling the placebo effect.

maybe in the future I will have enough free time to test it.

1

[Ed Oscuro]

Something bugs me about this thread - Hitachi owns SH-3, not Cave. However, when I read blitter, I think of something that's written in software. Would work need to be done on just one, or both?

[trap15]

When people say Cave SH-3, they mean the entire board. They should be calling it CV1000, but whatever.

The blitter is done in an FPGA, which is sort of "programmable hardware", if you will. The FPGA itself is high-level emulated, because properly emulating the FPGA would not only be painfully difficult, but insanely slow.

According to what MetalliC has said, most of the games use the same "code" for the FPGA, so they behave the exact same.

Work needs to be done on the SH-3 side because there is no emulation of the memory wait-states (which makes the SH-3 effectively run slower, but it depends on the memory it's accessing, and if it is accessing memory at all). Work needs to be done on the blitter HLE side because the timing for the blitter execution is incorrect (and the Blitter Delay setting is only partially correct).

[Ex-Cyber]

The blitter is done in an FPGA, which is sort of "programmable hardware", if you will. The FPGA itself is high-level emulated, because properly emulating the FPGA would not only be painfully difficult, but insanely slow.

Yep. Lest anyone think that "insanely slow" is hyperbole, those simulators exist, and they run at something like 0.00001% of full speed. And that's with pretty considerable optimization effort. If you have really deep pockets you can blow a few million USD on purpose-built hardware to speed it up to about 0.01% (at which point things like firmware testing become tolerable).

[nesrulz]

Now we have UME 0.151 ("cv1k.c"), so this is again topical...

My blitter settings:

Mushi Futari BL: 59% (until recently I held the 63%, but now I see that it is perhaps better to 59%)
DDP DFK: 50%
DS / DS MBL: 63%

What are your settings? Someone tested DFK?

[abcabcabc339]

1) What is blitter speed/delay?

2) Why can't it be simply 30/60 fps with 2/5 frame delay like everything else is?

[nesrulz]

1) What is blitter speed/delay?

2) Why can't it be simply 30/60 fps with 2/5 frame delay like everything else is?

Blitter is used to simulate the deceleration of the game as realistic as possible.
Slowing the game at certain sections in certain situations - many bullets on the screen, and large explosions.

Example: try Mushi Futari BL (boss on the third level) without blitter.

[thetricker24]

please what's your advice for espgaluda 2 on mame slowpoke blitter delay??

[tzakiel]

Using the new cave driver in mame 152ex2...... I just can't see any difference in % settings when I adjust them, perhaps I am just blind. Is blitter delay enabled by default or do i need to turn it on in the ini or tab settings somehow first?

[Nasirosuchus]

Using the new cave driver in mame 152ex2...... I just can't see any difference in % settings when I adjust them, perhaps I am just blind. Is blitter delay enabled by default or do i need to turn it on in the ini or tab settings somehow first?

Press "Tab" while the game is running and go into Game Configuration.

[BareKnuckleRoo]

The blitter is done in an FPGA, which is sort of "programmable hardware", if you will. The FPGA itself is high-level emulated, because properly emulating the FPGA would not only be painfully difficult, but insanely slow.

So basically it's never going to be properly emulated like other older consoles are, because it's using a piece of hardware that'd be extremely hard to emulate on a normal computer? I'd hate to see their CV1000 games never really playable via emulation years down the line. How are they doing it with their console ports? Are they using an efficient form of emulation they developed that's basically as close as possible, but not really quite the same?

[trap15]

They're just simulating it. It's entirely possible to simulate it with enough accuracy to be indistinguishable (even though the ports still don't do this, but that's partly because the blitter is only part of the equation; the CPU causes a fair amount of slowdown as well [YGW games in particular are more stalled on CPU performance than blitter]). But you'll never get "true" emulation that performs at any acceptable speed.

[BareKnuckleRoo]

How many other systems are out there that require this sort of 'fake' emulation to be emulated at an acceptable speed? I guess NES-era consoles are low end enough that they're emulated with more accuracy in terms of the expected behaviour of the console without any speed issues?

[Ed Oscuro]

Haze mentioned on his blog that even some really primitive systems, like the ZX Spectrum, require a level of structure for dealing with timing issues, and that structure isn't in MAME or MESS at all. I believe that MAME was originally written with the assumption that most CPUs (and controlling hardware) it emulated had enough modern design features in place to deal with many timing issues (wait states, preventing race conditions). Of course all the games in MAME have their own hardware implementations and can probably break this assumption in small but strange ways - let alone the managed chaos that happens in systems that don't have refined control methods. Then there's TTL logic, for which the usual CPU emulation strategies don't apply, and where your options are to just create a high-level approximation or reimplementation of the correct behavior, or deal with very slow simulation in software.

Hopefully I haven't misrepresented the issue here but I will leave it to trap15 to comment further whether this is a useful starting place for the answer, or whether it should be chucked entirely.

[trap15]

Ed Oscuro pretty much hit the nail on the head. But really, just about everything is being simulated at a high level anyways. The only difference is that most devices' behavior can't be changed from software, and the blitter (which is an FPGA) can be. Games don't change it mid-execution or anything, but there are different microcodes uploaded depending on the game. I seem to recall there being 3 different ones. You'd need to completely reverse engineer all of them separately in order to get the correct emulation, because it's not safe to assume that they all act the same. One could theoretically "find" the differences between them by analyzing the uploaded netlist, but you'd need to figure out and reverse engineer the netlist binary format for that to be feasible.

There's nothing making each any harder to properly emulate though, it's just the same ol' thing like any other VDP. Someone's just gotta actually do testing and figure things out. Knowing MAMEdev, don't expect this to happen for a long long time until someone finally gets bored enough to try.

[Stevas]

Are you guys still on about the slowpoke mame that was posted here ages ago, or have there been some recent developments I'm unaware of (that would actually make Ibara run better)?

[Muchi Muchi Spork]

The games were added back to mame and more dumps were added. With Ibara so long as your computer is fast enough to run it you could probably fix the slowdown by underclocking the emulated cpu bit by bit on stage 3 until it feels like it's performing like the board. That would probably be closer to the original than Cave could do in a port.

[tzakiel]

The games were added back to mame and more dumps were added.

And blitter delay is now in mame 152ex1 and ex2, as an on/off and a slider. And there is a new cave driver, cv1k.c

[Ed Oscuro]

Ed Oscuro pretty much hit the nail on the head.

Every dog has his day, I guess. But thanks!

[Stevas]

I tried the slowpoke, and, apart from some pauses (to load?) just before stages/bosses, my laptop seemed to handle the likes of Mushi, GaludaII, Muchi, etc quite well. It was just Ibara that wouldn't run at 100% (for the most part it was okay, but when it got a bit hectic it would drop quite noticably).

I have the ports for just about everything else, just Ibara that I was really bothered about trying.

Thanks guys, I'll check it out.

[PROMETHEUS]

I'm not sure what Blitter Delay is,
but just want to say I've just tried DFK on MAME UME 152 (64bits) and I'm really happy to see the quality there, even savestates seem to be working fine.
The only significant problem I have is too big input lag (maybe 4 frames) which is a bit too much for me so I would really love to see a shmupMAME version that can run this soon :D

edit : actually no savestates don't work too well :p but after reaching a stage, can load a savestate as long as it's in the same stage. Perhaps loading a savestate right before game loads next stage graphics update graphics memory and then it means it's easy to "manually fix", will see

[KAI]

Still looks like crap to me.

[Muchi Muchi Spork]

I tried the slowpoke, and, apart from some pauses (to load?) just before stages/bosses, my laptop seemed to handle the likes of Mushi, GaludaII, Muchi, etc quite well. It was just Ibara that wouldn't run at 100% (for the most part it was okay, but when it got a bit hectic it would drop quite noticably).

I have the ports for just about everything else, just Ibara that I was really bothered about trying.

Thanks guys, I'll check it out.

If you underclock the emulated cpu then not only will it be easier for your computer to not stutter (if you are on the verge of full speed as you appear to be), the game slowdown on stage 3 etc. will also be more accurate to the pcb. Tab / Slider Controls / Overclock CPU

[tzakiel]

I think it's more about the quality of emulation when at 100% speed. You can't really evaluate mame games at less than 100%. That just indicates a system that is too slow.

I have a 4.3 ghz and I am running groovymame on a crt monitor. It looks crispy and perfect at native resolution and runs 100% all the time for all the sh3 games I've tried. I use the latest mame 152ex2 which has the new driver and I turned blitter delay on and set to about 63% for most games. To me it's playable but I don't have a pcb to compare side by side. But it seems to run close to the videos of the pcbs I have seen. I've determined that I just need a lot more practice.

[nesrulz]

Does anyone know how to solve this problem?

I have a problem with playing a replay (inp) records, there is desynchronization @ Stage 2 - Mid Boss, probably because blitter 63% option. I'm trying to find a solution, because I want to make a video...

http://shmups.system11.org/viewtopic.ph ... 56#p986956

RGDS,
Miroslav

[nesrulz]

Is anyone managed to play the entire (blitter) inp replay without errors?

[IseeThings]

the blitter delay option is marked as 'unsafe' for a reason

it's completely unsynchronized

[nesrulz]

Yes. Then this is my only solution for "replay": ume64 futariblk -aviwrite futariblk.avi

Nothing..., go back to chasing 1CC, again.

Now we know.

[nesrulz]

My Mushi Futari BL 1CC video - with UME 0151 ("cv1k.c" & nonag) (32&64Bit).

http://www.youtube.com/watch?v=rvEE_v7Eq6k

I think this blitter (63%) looks good. Compare with arcade PCB and Xbox.

https://www.youtube.com/watch?v=SPQ2NPUci6k
https://www.youtube.com/watch?v=wVRR5HA-1U8

Better do the work just fine for now, and I do not agree with those who say it is not playable.

[tzakiel]

Would like to hear what you guys have found are the best blitter rates for Mushihimesama (not futari) and for Espgaluda II (assuming newest driver). Both I find are too quick for me to make much headway. But it could be my skills.