Too close for comfort? the revival?

[AntiFritz]

Finally got around to trying this out. Had to grab it now that Cave sent out a C&D letter

Downloaded the latest slowpoke mame, but can't find this slider people keep referring to?

So far I've tried espgaluda 2 and ibara. I used the 64bit version on my core2duo 2,19ghz laptop. Esp Galuda 2 ran great and only dipped to 95-98% once while the boss died. Didn't expect it to run this well on my laptop?

Press tab then slide controls

[Vamos]

@ jonny audio glitching only happens when the emulation speed is dropping below 100% , try playing with f11 speed showing doesnt sound like its running aswell as you think .

[1up]

Finally got around to trying this out. Had to grab it now that Cave sent out a C&D letter

Downloaded the latest slowpoke mame, but can't find this slider people keep referring to?

So far I've tried espgaluda 2 and ibara. I used the 64bit version on my core2duo 2,19ghz laptop. Esp Galuda 2 ran great and only dipped to 95-98% once while the boss died. Didn't expect it to run this well on my laptop?

Press tab then slide controls

thanks

[alastair jack]

So all the sound is good if your computer is also good?

[Vamos]

So all the sound is good if your computer is also good?

It should be as far as im aware , the sound only stutters or dips when the emulation goes below but maybe its just my experience. You need to play with the speed showing for a whole game and see what it does when the sound stutters .

[shmuppyLove]

I hadn't tried before. It worked fine.

Oddly enough, it worked with direct x on the mame setup in the cab, but not on my other computer.

What is even weirder is it runs better on the P4 3.4ghz 4 gig RAM radeon x1600agp than it does on my amd dual 2.4 4 gigs RAM nvidia gtx250.

Futari runs pretty smooth, god mode slows down a fair bit on black label.

Mushi runs great, and for some weird reason ultra seems to run smoother than maniac?

Ibara black label runs ok, slows down a bit on the bosses and mega explosions.

Galuda 2 seems to run really well too.

Audio glitching on everything, although mushi is better than the rest.

Really impressed with how well these are running. Hopefully they continue to improve on this and soon it will be running perfect.

Emulation is all about raw processing speed, and you gain nothing from having multiple cores. I'm sure there are very technical explanations of why you can't use multithreading in emulation, probably something to do with sync or out-of-order execution or whatever.

Even my Athlon X2 7750 OC'd @ 3.0GHz has stutters here and there. Maybe try overclocking that P4 a little bit and see if there's any improvement?

[jonny5]

I hadn't tried before. It worked fine.

Oddly enough, it worked with direct x on the mame setup in the cab, but not on my other computer.

What is even weirder is it runs better on the P4 3.4ghz 4 gig RAM radeon x1600agp than it does on my amd dual 2.4 4 gigs RAM nvidia gtx250.

Futari runs pretty smooth, god mode slows down a fair bit on black label.

Mushi runs great, and for some weird reason ultra seems to run smoother than maniac?

Ibara black label runs ok, slows down a bit on the bosses and mega explosions.

Galuda 2 seems to run really well too.

Audio glitching on everything, although mushi is better than the rest.

Really impressed with how well these are running. Hopefully they continue to improve on this and soon it will be running perfect.

Emulation is all about raw processing speed, and you gain nothing from having multiple cores. I'm sure there are very technical explanations of why you can't use multithreading in emulation, probably something to do with sync or out-of-order execution or whatever.

Even my Athlon X2 7750 OC'd @ 3.0GHz has stutters here and there. Maybe try overclocking that P4 a little bit and see if there's any improvement?

It is overclocked.

[Vamos]

I hadn't tried before. It worked fine.

Oddly enough, it worked with direct x on the mame setup in the cab, but not on my other computer.

What is even weirder is it runs better on the P4 3.4ghz 4 gig RAM radeon x1600agp than it does on my amd dual 2.4 4 gigs RAM nvidia gtx250.

Futari runs pretty smooth, god mode slows down a fair bit on black label.

Mushi runs great, and for some weird reason ultra seems to run smoother than maniac?

Ibara black label runs ok, slows down a bit on the bosses and mega explosions.

Galuda 2 seems to run really well too.

Audio glitching on everything, although mushi is better than the rest.

Really impressed with how well these are running. Hopefully they continue to improve on this and soon it will be running perfect.

Emulation is all about raw processing speed, and you gain nothing from having multiple cores. I'm sure there are very technical explanations of why you can't use multithreading in emulation, probably something to do with sync or out-of-order execution or whatever.

Even my Athlon X2 7750 OC'd @ 3.0GHz has stutters here and there. Maybe try overclocking that P4 a little bit and see if there's any improvement?

uhh metallix build uses multithreading.

[Drachenherz]

Allright, I guess this weekend shmupping will get way toooo close for comfort...

Today, my Desktop-Replacement-Notebook arrived, with enough power under the hood to play the sh3-games stutterlessly...

And I'm going to hook it up to the PJ in the living room and play me some Shmups on a 2.8m Wallscreen, yeaaaah!

[shmuppyLove]

uhh metallix build uses multithreading.

It does but I think it's only for decompressing data or something? I vaguely remember it was only a slight improvement in playability, but that it didn't really improve overall emulation speed very much.

[Muchi Muchi Spork]

64-bit with multithreading enabled in the ini helps a lot in general. Nobody sane would use a 32-bit build with a multi-core CPU and 64-bit OS. You might also get more speed (overall) by enabling cheats and then underclocking the emulated CPU in the tab/slider menu unless the driver hacks already utilize this sort of tweak.

[Vamos]

uhh metallix build uses multithreading.

It does but I think it's only for decompressing data or something? I vaguely remember it was only a slight improvement in playability, but that it didn't really improve overall emulation speed very much.

It improved emulation speed by alot actually around 30%.

[IseeThings]

uhh metallix build uses multithreading.

It does but I think it's only for decompressing data or something? I vaguely remember it was only a slight improvement in playability, but that it didn't really improve overall emulation speed very much.

It improved emulation speed by alot actually around 30%.

Multithreading in emulators is risky. Emulation is fundamentally an in-order process, everything depends on the previous stage being completed, it's the classic 'you don't get a baby in 1 month by getting 9 girls pregnant' in it's most basic form. 30% speedup from threading is actually very impressive in emulation terms because it's really not a task which suits multi-threading.

Obviously, because you've seen threading work, In some cases it's not quite that black and white. There are times when you KNOW a task performed by another piece of the hardware in the original system where you can potentially thread things off to improve performance, however you have to make sure to fully sync everything on ANY change which would be detectable or you risk the actual -behaviour-, not just performance of the emulation changing depending on the system running it.

Prior to the decision not to include it the official MAME builds were using a safe thread implementation for the blitter, behaviour was guaranteed to be the same between systems, buffers were used to shadow data used, and waits were in place on any read / screen update operations which required the threads to be complete. This was 'safe threading'

The Metallic / Demul team builds were based on an unsafe threading concept, the later ones were safer than the first ones present, but you could glitch them out (especially if you made your 2nd core busy for example) because they made no attempt to wait for threads to complete, or shadow data so it didn't change in the middle of operations. This was faster, and made it easier to implement the 'slowdown' emulation, but because it's unsafe code it simply wasn't suitable for MAME.

Basically the more correct, and safe you make the emulation, the tighter you need to keep components in sync and the less you can depend on threading for a performance boost. Naturally this doesn't bode well for emulation in the future as the main improvements with CPUs is likely to be the # of cores, not the basic clock speeds and for something like the emulation of a single CPU you simply *can't* split that across cores.

[BryanM]

Maybe try overclocking that P4 a little bit and see if there's any improvement?

I have a 3.8ghz P4. It can handle the first and second stages of Mushi well in the slowpokeeee build, minus some boss patterns. DeathSmiles is a bit like water torture.

The P4 is not an efficient beast. Modern CPUs can do much more at less. Not as much as we'd hope from old moore's law tho...

[kevenz]

People still use Pentium 4 in 2011 (almost 2012) ?...... humm that's Jurrasic computer

You need at least a dual core for mame...... 1 core for windows and 1 core for mame.

[xMetalliCx]

IseeThings
talking about multithreading, I do not think it's something bad, the real PCB works this way and all its components working in parallel, it's just in the case of emulation the correct synchronization of threads is not an easy task.

in the case of that system it is even easier, before setting a status "blitter ready" need to wait until it finishes its work (Demul works this way, and real PCB as well), but in the case of MAME that will kill some speed, and "wait for end blit thread" was done before starting the next blit instead.

anyway, who cares until it works without glitches.

2ALL
thanks guys for "Blitter Delay"s values for different parts of games and comparing emulation speed with PCB and superplays.

but the fact that different parts of the games require different values ​​makes me a bit sad. This means that we need more complex logic emulation slowdowns, but nobody knows what it must be.
I see no way to calculate how it works inside empirically. maybe some day we can benchmark the speed of PCB using homebrew tests.
until this is done, I can not imagine how to make a more accurate emulation.

add:
Estebang
initialy latest Naomi games must be released on GD-ROMs, but since Sega killed the production of these discs these games was released on the cartridges.

nZero
They're basically console + DIMM + GD-ROM
I would not be surprised if the encryption is exactly the same, as was used in Naomi GD-ROM games.

[emphatic]

Aren't there some "markers" in the games where blitter values are changed? If these ,makers can be identified, would it be possible to change the "base" blitter value at those instances? I imagine that's how CAVE implements 'em.

[xMetalliCx]

Aren't there some "markers" in the games where blitter values are changed? If these ,makers can be identified, would it be possible to change the "base" blitter value at those instances? I imagine that's how CAVE implements 'em.

I've traced games and don't seen any markers. All this slowdown things is just hardware speed limitations, and was not strictly programmed.

moreover, recent researches shows that almost all games uses exactly the same blitter FPGA microcode.
argues that even in my thoughts, that we simply do not take into account all the necessary things at the moment (for example, now we consider only the number of points, but not the number of sprites)

[JOW]

but the fact that different parts of the games require different values ​​makes me a bit sad. This means that we need more complex logic emulation slowdowns, but nobody knows what it must be.

Aren't there some "markers" in the games where blitter values are changed? If these ,makers can be identified, would it be possible to change the "base" blitter value at those instances? I imagine that's how CAVE implements 'em.

I think xMetalliCx is saying just modelling blitter operation to determine slowdown is not sufficient - there must be other variables in the system that cause slowdown and are currently unknown. Is that right xMetalliCx?

EDIT: Ninjad by xMetalliCx

[emphatic]

Oh, fine then.

[mjclark]

Somebody please emulate Illvelo successfully please somebody please please somebody please please somebody please please somebody please please somebody please please somebody please please somebody please please somebody please please somebody please please somebody please please somebody please please somebody please please somebody please please somebody please please somebody please please somebody please please somebody please please somebody please please somebody please please somebody please please somebody please please somebody please please somebody please please somebody please please somebody please please somebody please please somebody please please somebody please please somebody please please somebody please please somebody please please somebody please please somebody please please somebody please please somebody please please somebody please please somebody please please somebody please please somebody please please somebody please please somebody please please somebody please please somebody please please somebody please please somebody please please somebody please please somebody please please somebody please...
...please.

[xMetalliCx]

Somebody please emulate Illvelo successfully please somebody please please

do not cheating please please please
we all know you mean "share the dump of illvelo"

[Vamos]

Id love to play illvelo to , and raiden dx and ddp2

[kevenz]

Played Illvelo on the wii a couple of years ago... I'm not a big fan of cell shading shmups

If you want it emulated..... download the wii version + dolphin emulator.

[Drachenherz]

Played Illvelo on the wii a couple of years ago... I'm not a big fan of cell shading shmups

If you want it emulated..... download the wii version + dolphin emulator.

But... but... wouldn't that be... way too close to comfort? *tschh-Bumm*

[jonny5]

People still use Pentium 4 in 2011 (almost 2012) ?...... humm that's Jurrasic computer

You need at least a dual core for mame...... 1 core for windows and 1 core for mame.

You're kidding right? Sure this new stuff requires some beef to run, but pretty much anything non-3d runs fine on anything, even a little netbook. I have been using that P4 as my mame setup in my cab for years, since I upgraded from it with a new main computer. It runs everything fine! Don't forget that not everyone uses the same computer to play games on and do everything else. I'm not interested in dropping money to upgrade a computer just so I can emulate a few games I have already played to death in PCB format.

Especially if you get into older builds of mame, they run fine on stuff even under 1 ghz. It's only in recent times that mame has become a bit more system intensive, but most things still run fine even on low end systems. To say you need at least a dual core for Mame is overkill IMO.

[Vamos]

Tbf i couldnt get sh3 emulation to run on my old dual core , it alone requires some fair wallop.

[mjclark]

Played Illvelo on the wii a couple of years ago... I'm not a big fan of cell shading shmups

If you want it emulated..... download the wii version + dolphin emulator.

Got latest Dolphin, Illvelo runs at 60%-85% max on it. We need that 100% magic

Somebody please emulate Illvelo successfully please somebody please please

do not cheating please please please
we all know you mean "share the dump of illvelo"

We all know requests for roms are not allowed on this forum lol...but yeah screenshots on the Russian Demul forum do suggest it's dumped and working.

IseeThings has been very transparent about the state of MAME developement in this thread, so is there any chance of similar transparency regarding Demul 0.5.7?

[Ex-Cyber]

moreover, recent researches shows that almost all games uses exactly the same blitter FPGA microcode.
argues that even in my thoughts, that we simply do not take into account all the necessary things at the moment (for example, now we consider only the number of points, but not the number of sprites)

Now that I'm bothering to actually read (or at least skim) the code, this really jumped out at me:

Code: Select all

// surprisingly frequent, need to verify if it produces a worthwhile speedup tho.
if ((s_mode==0 && s_alpha==0x1f) && (d_mode==4 && d_alpha==0x1f))

Has anyone tried something like doubling the emulated fill rate for this case?

[Rex Cavalier]

Waits for DFK be MAME'able (im)patiently