Shmupmame 4.2: Lagless Mars Matrix, Strikers 1945, Galaga 88

[Zaarock]

I want to compile on mac. Do the shmupmame patches go on top of vanilla mame 140 or should the 140u1 and 140u2 patches be applied first?

I patched the 2.2 lagless drivers on top of 140u2. taito_f3 and cave video drivers dont compile, but everything else works. Getting ketsui drivers etc. to compile on 140 might be a bit tricky.

Thanks to all the people who worked on the PGM emulation and nimitz for the lagless stuff

edit: btw, the pgm driver used here does not have the ARM emulation from raidenii.net, so it will run faster.

[Kaiser]

Question, is rank in DOJ Black Label really fixed in shmupmame v2.2?

[Drachenherz]

I have a question to Shmupmame 1.5, the build based on the 0.99 MAME.

The Mame32.exe doesn't work at my computer, running win 7 64 bit home-premium. I tried it at a friends laptop, which also runs win 7 64bit home premium, and there it works...

Any idea what could be wrong with my own comp? (I'm at work right now, I'll post the error message when I'm back home).

[PROMETHEUS]

Thank you guys so much for lagless Ketsui and DOJ.

I do have a big problem with this version but also every other version on which I had tried Ketsui and DOJ. Half the time I boot my computer, I cannot run the games at all, all I get after I ask MAME to run them is a black screen that lasts for 20 seconds, then back to windows, and I have to use CTRL/ALT/DEL to shut MAME down. If I reboot my computer, sometimes it works again, sometimes not. I have no idea what causes this, but another guy on the french forum seemed to have the same issue. Running windows XP 32bit.

[mjclark]

Working great here on a low end XP machine
Thankyou so much for this-it's really appreciated!
As a suggestion for the next build, how about an option to rotate the GUI itself so that it's correctly oriented on a tated monitor ( then I wouldn't have to crick my neck with my permanently tated MAME setup).
This has been a great week indeed on this forum so hats off to you!

[zakk]

I just compiled this on my OSX box.

Get mame140 source; extract.
Get mameuifx source; extract on top of mame140 source
Get shmupmame source; extract on top of the above.

You'll need to make a few changes.

First, in the top level makefile, comment out the setting of OSD and TARGETOS, we want it to auto-detect.

Then, in src/mame/includes/pgm.h

Search for 'pgmcrypt', should be a comment and then a list of prototypes. Add these to the end.
void pgm_espgal_decrypt(running_machine *machine);
void pgm_ket_decrypt(running_machine *machine);
void pgm_ddp3_decrypt(running_machine *machine);

in src/mame/mamedriv.c

Search for 'ddp2a' Should be a DRIVER(ddp2a) line.

Change it to DRIVER(ddp2100)
Add: DRIVER(ddp2101)
Add:
DRIVER( ket )
DRIVER( keta )
DRIVER( ketb )
DRIVER ( ddp3 )
DRIVER ( ddp3blk )
DRIVER (espgal)


That should be it. Compile by typing 'make'

Thanks for the hard work, shmupmame team!

I want to compile on mac. Do the shmupmame patches go on top of vanilla mame 140 or should the 140u1 and 140u2 patches be applied first?

[z0mbie90]

and I have to use CTRL/ALT/DEL to shut MAME down.

I also have this problem. It always stays on the processes. Everything else works really great. Nice work

[joeboto]

big thanks!
and i dont know whether im late or what, but batsugun garbage sprite is fixed!

[emphatic]

As a suggestion for the next build, how about an option to rotate the GUI itself so that it's correctly oriented on a tated monitor ( then I wouldn't have to crick my neck with my permanently tated MAME setup).

Easy, just run Windows in TATE. That is all.

[BPzeBanshee]

I love this release, dont get me wrong, but I notice the performance of Shmupmame has dropped significantly as a whole, Especially Battle Garegga and the toaplan2.c games. I used to be able to run Batrider at full speed with v2.0 and now its at 87% speed with v2.2. And Thunderforce AC still hasn't improved since the v99 pro build.
Is this because of the change to C++ in the default MAME build or something? I heard the change was causing extra "bloat" in filesize and this release certainly takes up more RAM usage than the previous release.

[mjclark]

As a suggestion for the next build, how about an option to rotate the GUI itself so that it's correctly oriented on a tated monitor ( then I wouldn't have to crick my neck with my permanently tated MAME setup).

Easy, just run Windows in TATE. That is all.

Oh yeah-thanks! I'm embarassed to say I didn't even realise this was an option til I looked at my nVidia Control Panel.
Now all good except v2.2 isn't saving my option changes or rom audit on exit.

[Aquas]

I love this release, dont get me wrong, but I notice the performance of Shmupmame has dropped significantly as a whole, Especially Battle Garegga and the toaplan2.c games. I used to be able to run Batrider at full speed with v2.0 and now its at 87% speed with v2.2. And Thunderforce AC still hasn't improved since the v99 pro build.
Is this because of the change to C++ in the default MAME build or something? I heard the change was causing extra "bloat" in filesize and this release certainly takes up more RAM usage than the previous release.

Get used to hoarding different versions of MAME if you haven't been already.

[Zeron]

Not sure if I should report this at the "Whatever happened to the Kesui dump" thread or here after entering my initials(with a spare credit entered) then being redirected to the Ketsui logo the game does a low bzzzzz sound.

[nimitz]

I love this release, dont get me wrong, but I notice the performance of Shmupmame has dropped significantly as a whole, Especially Battle Garegga and the toaplan2.c games. I used to be able to run Batrider at full speed with v2.0 and now its at 87% speed with v2.2. And Thunderforce AC still hasn't improved since the v99 pro build.
Is this because of the change to C++ in the default MAME build or something? I heard the change was causing extra "bloat" in filesize and this release certainly takes up more RAM usage than the previous release.

Thanks for that observation, I might revert the next version to 137 then. Mame is now using c++ (since ~138) which makes it slower.



For people who have problems with the new build, was Shmupmame v2.0 running without problems?



Zeron : sound problems are not completely fixed, that being said those "stuck" notes always end when a new sound is played on the same Oscillator.



Edit : also for those who have problems, try updating directx and your video card drivers, this may well be the problem.

[croikle]

I just compiled this on my OSX box.

Get mame140 source; extract.
Get mameuifx source; extract on top of mame140 source
Get shmupmame source; extract on top of the above.

You'll need to make a few changes.

Would it be better to apply u1 and u2 patches to 140, or is this patch specifically for 140 base? It seems like 140u2 would probably make those changes you list.

I'll try it and see what happens.

[jepjepjep]

Thanks for the help with compiling. I have it running well on mac now. I used 140 source without u1 and u2 patches. But I had to modify as zakk suggested:

Then, in src/mame/includes/pgm.h

Search for 'pgmcrypt', should be a comment and then a list of prototypes. Add these to the end.
void pgm_espgal_decrypt(running_machine *machine);
void pgm_ket_decrypt(running_machine *machine);
void pgm_ddp3_decrypt(running_machine *machine);

in src/mame/mamedriv.c

Search for 'ddp2a' Should be a DRIVER(ddp2a) line.

Change it to DRIVER(ddp2100)
Add: DRIVER(ddp2101)
Add:
DRIVER( ket )
DRIVER( keta )
DRIVER( ketb )
DRIVER ( ddp3 )
DRIVER ( ddp3blk )
DRIVER (espgal)

[zakk]

I just compiled this on my OSX box.

Get mame140 source; extract.
Get mameuifx source; extract on top of mame140 source
Get shmupmame source; extract on top of the above.

You'll need to make a few changes.

Would it be better to apply u1 and u2 patches to 140, or is this patch specifically for 140 base? It seems like 140u2 would probably make those changes you list.

I'll try it and see what happens.

I don't know; his info post says it was based on MAMEUIFX so I started by grabbing their source. Never tried applying u1 and u2.

[croikle]

I ran into problems with class running_machine in various places, and eventually gave up and went for your method. Works fine. Thanks!

[Zeron]

This is more of a MAME general issue the just ShmupMAME


Everytime I rotate windows in NVIDIA controll panel then I go to config a game, I select 640x480 85hz(or should I say 480x640?) but it never sets it to 85hz(it works fine if windows is not rotated) I would not have issue with the game running in 60hz but there is a annoying line that passes through all the darn time

Anyhelp?

[nimitz]

That's because the game runs at 59.17hz.

If your video card drivers allow it you can create a custom modeline and use it for 59.17 (assuming you have CRT screen)

http://xtiming.sourceforge.net/cgi-bin/xtiming.pl

if not I highly suggest you run the game with your screen at 60hz, running it at 85hz will have your screen duplicate some frames and will fuck up the timing even more (if you look carefully you will see it is far less smooth)

[captpain]

That's because the game runs at 59.17hz.

If your video card drivers allow it you can create a custom modeline and use it for 59.17 (assuming you have CRT screen)

http://xtiming.sourceforge.net/cgi-bin/xtiming.pl

if not I highly suggest you run the game with your screen at 60hz, running it at 85hz will have your screen duplicate some frames and will fuck up the timing even more (if you look carefully you will see it is far less smooth)

Thanks for the tip... I always run at 85hz because it looks better, but I guess I shouldn't for this!

[Zeron]

That's because the game runs at 59.17hz.

Running it at 480x640 60hz and no strange line passing by thanks Nimitz


Edit I cannot see it in Ketsui thats for sure but in Strikers 1945 its still there though

strange in my monitors display timings I can never get 31khz 640x480 59hz it runs in 31.5khz.

[Tigershark]

Sorry for posting in this thread but the other one was locked.

Trying to play ketsui.

Got the Rom.

Started the exe and got a "pgm_t01s.rom missing" report.

Downloaded the ket_igs027a file and put it in the zip and tried again. Same result.

Can anyone help?

Thanks.

[Zeron]

Sorry for posting in this thread but the other one was locked.

Trying to play ketsui.

Got the Rom.

Started the exe and got a "pgm_t01s.rom missing" report.


Can anyone help?

Thanks.

PGM_t01s.rom can be found in the PGM bios.

[emphatic]

I converted an .inp file into an .avi file before, and the output is @ 60. As the game is 59.175, won't the video/audio run too fast, or is this taken into the equation while writing an .avi file, by adding frames?

[Tigershark]

Thanks. All sorted.

EDIT:

Bloody hell I'm playing Ketsui.

[Pulsewidth]

strange in my monitors display timings I can never get 31khz 640x480 59hz it runs in 31.5khz.

Depending on the timing of the non-image data parts of the video signal the horizontal sync rate can different even if the refresh rate stays the same. There are several method of calculating the timings: GTF (old method), CVT (new method), CRT with Reduced Blanking (note that officially this only works at 60Hz, but in practice it works at any supported refresh rate if it works at all). If your monitor syncs to it with no distortion and without having any adjustments set to the extremes of their range then it's a good signal, so don't worry about the exact timing details.

I converted an .inp file into an .avi file before, and the output is @ 60. As the game is 59.175, won't the video/audio run too fast, or is this taken into the equation while writing an .avi file, by adding frames?

If you're playing a 59Hz game on a 60Hz display then you'll have to either duplicate [partial if vsync is off] frames or distort the audio. Duplicating frames is the default on most emulators and it looks terrible. Exactly how the audio distortion will sound depends on the details of your audio driver and audio buffering, but in my opinion it's always been much less annoying than the visual distortion. There's also the option of changing the audio sampling rate to match the incorrect speed, so the only distortion is the pitch/speed. Unless you have absolute pitch perception (perfect pitch) this will be completely unnoticeable, so it's the preferred option if you can't run the game at the correct speed. CabMAME supports this with its SoundSync hack, but it's Windows only so I haven't tried it.

Of course the ideal solution is to use a monitor refreshing at the same rate as the original, using vsync as the timing source (throttle 0 autoframeskip 0 multithreading 0). You should use vsync as master timing source anyway because using CPU based timing will inevitably drift out of sync with the display and you'll get annoying video glitches. It's a pity that vsync implementation varies so widely across platforms/drivers, so the emulator authors are forced to set the ugly option as default.

[nimitz]

Not sure what you mean by "using vsync as the timing source" but if that means turning vsync on, then that should be avoided at all costs, Vsync will *always* add one frame of lag. The whole point of this build is to remove lag.

[Pulsewidth]

Not sure what you mean by "using vsync as the timing source" but if that means turning vsync on, then that should be avoided at all costs, Vsync will *always* add one frame of lag. The whole point of this build is to remove lag.

There is no other method of reliably showing the entire emulated frame exactly once per frame. If you turn off vsync you will get tearing or frame skipping or frame duplication. Vsync will add *at worst* one frame of lag. Depending on how exactly the CPU based timing works it might not add any lag at all. You can reduce the lag to almost nothing if your CPU is fast enough and your OS scheduler is good enough by adding a delay (preferably spinning the CPU, not yielding to the OS) just before the input polling. My black frame insertion hack does this as a side effect of its simple CPU time wasting implementation. I've actually made a version of MAME with both black frame insertion and extra pre-input-polling delay, but the delay needs to be carefully tuned to remove as much lag as possible without being too long and causing frame duplication, so it has to be carefully tuned for each game and CPU combo, and I never got round to figuring out MAME slider controls and I got annoyed with having to recompile to change the delay so I gave up on that idea for now. It's only a few milliseconds at stake. If you're running at 60Hz then it's more serious.

The other source of delay I'm looking into eliminating is the input polling delay. PS2 keyboard interface should theoretically be fastest because it's interrupt driven, so I'm thinking of using an Arduino or something to interface my arcade stick to my PS2 keyboard port. This way I get to use a non-stupid debouncing method: trigger immediately on switch close, wait 16ms (game only polls once per frame), and then change mode to trigger immediately on switch open, wait 16ms, repeat. Search "debouncing" and you'll see all kind of crazy lag causing methods being used. I don't see any reason why my method shouldn't work with zero added lag.

[Strider77]

Free Ketsui.... enjoy and celebrate.

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