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

[moa]

actually changes started before but 0.145 is polished

144u6
-----
Major bitmap-related changes throughout the system: [Aaron Giles]
There are almost certainly some regressions lurking. Let me know if
something seems busted.
Bitmaps are now strongly typed based on format. bitmap_t still exists
as an abstract base class, but it is almost never used. Instead,
format-specific bitmap classes are provided:
bitmap_ind8 == 8bpp indexed bitmap_ind16 == 16bpp indexed bitmap_ind32
== 32bpp indexed bitmap_ind64 == 64bpp indexed bitmap_rgb32 == 32bpp
RGB bitmap_argb32 == 32bpp ARGB bitmap_yuy16 == 16bpp YUY
For each format, a generic pix() method is provided which references
pixels of the correct type. The old pix8/pix16/pix32/ pix64 methods
still exist in the short term, but the only one available is the one
that matches the bitmap's pixel size. Note also that the old RGB15
format bitmaps are no longer supported at all.
Converted model1, megadriv, and stv drivers away from the RGB15 format
bitmaps.
New auto_bitmap__alloc() macros are provided for allocating the
appropriate type of bitmap.
Screen update functions now must specify the correct bitmap type as
their input parameters. For static update functions the SCREEN_UPDATE
macro is now replaced with SCREEN_UPDATE_RGB32 and SCREEN_UPDATE_IND16
macros. All existing drivers have been updated to use the correct
macros.
Screen update functions are now required for all screens; there is no
longer any default behavior of copying a "default" bitmap to the
screen (in fact the default bitmap has been deprecated). Use one of
the following to specify your screen_update callback:
MCFG_SCREEN_UPDATE_STATIC(name) - static functions
MCFG_SCREEN_UPDATE_DRIVER(class, func) - driver members
MCFG_SCREEN_UPDATE_DEVICE(tag, class, func) - device members
Because the target bitmap format can now be deduced from the screen
update function itself, the MCFG_SCREEN_FORMAT macro is no longer
necessary, and has been removed. If you specify a screen update
callback that takes a bitmap_ind16, then the screen will be configured
to use a 16bpp indexed bitmap, and if you specify a callback that
takes a bitmap_rgb32, then a 32bpp RGB bitmap will be provided.
Extended the bitmap classes to support wrapping a subregion of another
bitmap, and cleaner allocation/resetting. The preferred use of bitmaps
now is to define them directly in drivers/devices and use allocate()
or wrap() to set them up, rather than allocating them via
auto_bitmap_*_alloc().

Death to SCREEN_EOF, which was ambiguously called either at the start
or end of VBLANK depending on the video flag
VIDEO_UPDATE_AFTER_VBLANK. Replaced with SCREEN_VBLANK callbacks which
are called both at the start and end of VBLANK, so you can operate
either way, and be explicit about it. Updated all callers. Also
updated screen_device to use device timers and some other minor
cleanups.

I can't believe you didn't notice any change in gameplay. I saw the difference immediatly. try Sorcerer Strike, Kingdom GP, Dimahoo or even Phoenix

[BPzeBanshee]

I'm no expert but that reads nothing like anything that would improve things in the way Shmupmame is meant to (ie. input delays, which I've tested on a few games including the ones you mentioned). If anything I'd expect the bitmap changes and such to improve the quality of what we're seeing on screen, but I haven't even noticed that.

Maybe one of the actual experts (ie. nimitz himself or Haze or someone similar) might be able to clarify, but I'm just not seeing what you're seeing.

[Ed Oscuro]

The default macros, "default" bitmap, SCREEN_EOF (which interacted with vblanking) and the use of device timers don't sound like sources of a speedup?

Just a few minutes with EmuCR's MAME Plus shows that Mahou Daisakusen behavior appears identical between 144u7 and the new 145. Gain and Miyamoto both take from one to two frames to reverse direction (holding down one way and then switching the next for the next frame). Didn't try enough to do a statistical analysis of the times one has one frame and the other has two but it's pretty close.

The situation with autofire is VASTLY improved since mameplus_bin_x86-0.144r4933-20111123 in which an autofire rate of 3 might be equivalent to an autofire rate of 6 or even 9 in the newer versions, which is a sign that timings have been greatly improved. That may have been a rogue build though (I didn't see it officially uploaded anywhere, just posted to the MAME Plus forum by a forumgoer after the main page stopped updating).

Edit: I was going to check the situation in ShmupMAME but Mahou Daisakusen don't work no more with the current MAME ROMset.

[BPzeBanshee]

The default macros, "default" bitmap, SCREEN_EOF (which interacted with vblanking) and the use of device timers don't sound like sources of a speedup?

A speedup in input response time or a speedup in general performance? I've not noticed any difference in input responses even when trying the frame-by-frame pause, and I noticed instantly how well ESPRade worked on Shmupmame compared to standard MAME builds.

As for your autofire thing, there's been a few unofficial MAME Plus! builds going around, namely the Ashbuilds with their wonky interface and that one which has the Cave SH3 games still in it.

Frankly I'm thinking we would have more users noticing this by now if there was anything actually noticeable been happening. At time of writing I'm counting two people that think there's been some radical improvement in something which probably couldn't be backported to MAME 0.99 even if it actually did anything.

[Ed Oscuro]

I've not noticed any difference in input responses even when trying the frame-by-frame pause,

Compared to..? Besides Shmupmame, which shouldn't be terrible, I would hope.

[moa]

sorry for my bad english
My post was just to know if someone else have noticed the recent changes in MAME
I don't know if it's better than shmupMAME but I pretty sure the overall gameplay of games have been changed

Ive been playing MAME for a long time now. I know exactly where I get killed in my fav games. With newest version of MAME, I can dodge bullets like never before

You must try the hardest games and see the improvements.

A good example is Chopper I, which IMHO was hard as hell before. Now, it is just hard

thank you for reading

[IseeThings]

There's no reason anything in 0.145 should have changed the control 'lag' intentionally.

What has happened is the point at which the sprites get buffered on several games has moved around due to the code shuffling, this has introduced imperfections in some games, leading to graphic breakup and such. These are *bugs* and they should be fixed.

Remember, that's all shmupmame is, a MAME build with intentionally *broken* emulation. The current MAME build has accidentally broken emulation in some drivers.

[Arcade Legends 3]

(Bump.)

MAME Ash-Build, the newest version... Personally had found it lagless at zero FPS to twenty games.

[O. Van Bruce]

As the title says, the emulator doesn't run on Windows 7. Sometimes it works but only 1 out of 4 or 5 times. The rest of the time it just crashes when I open it...

any idea why this happens? how to fix it?

[AntiFritz]

Use a version of mame that isn't from like 7 years ago.

[mesh control]

Nothing new, we have a thread for the shmupmame releases.

http://shmups.system11.org/viewtopic.php?f=1&t=30659

W7 killed some 32-bit compatibility, but no one is sure what exactly is causing the crashes.

[dunpeal2064]

Not sure if this works in 7, but in Vista, I was able to right-click on mame, and in properties, I was able to go to "compatability" and run mame as if it was running on my choice of older windows OSs. I chose xp, and now shmupmame is working fine for me.

Hope this is helpful.

[yosai]

Windows 7

That's the problem right there.

[Iori Branford]

Out Of Memory.

Quit other apps, quit unnecessary services, get lighter antivirus.

[Gus]

Use a version of mame that isn't from like 7 years ago.

[dunpeal2064]

What version of mame might you guys recommend? I'm apparently also using an old version of mame.

[shmuppyLove]

What version of mame might you guys recommend? I'm apparently also using an old version of mame.

I've stuck with vanilla MAMEUI 143u9 for obvious reasons.

[Drachenherz]

Shmupmame2.2
MameUI143.u8 (didn't bother upgrading to u9 as all the relevant games are working for me in u8 and for the "forbidden" games, I use)
Slowpoke Mame.

[Ed Oscuro]

Windows 7

That's the problem right there.

"That's a very helpful post...FOR ME TO POOP ON" - Doctor PC Ninja Dog

There's nothing wrong with using Windows 7 - out of the Microsoft OS lineup, anyway.

Shmupmame2.2
MameUI143.u8 (didn't bother upgrading to u9 as all the relevant games are working for me in u8 and for the "forbidden" games, I use)
Slowpoke Mame.

Dude, you need to check out the EMUCR MAME Plus releases. They are great. MAMEUI is quickly falling behind.

[BPzeBanshee]

Use a version of mame that isn't from like 7 years ago.

A very helpful post right there. NOT.

Shmupmame isn't 7 years old, the base is, and for the record WolfMAME Plus! 0.99 seems to work just fine on Windows 7 64-bit machines from my tests but no one seems to want to validate me by trying it for themselves.

[ebarrett]

Out Of Memory.

Quit other apps, quit unnecessary services, get lighter antivirus.

Nonsense. It is some memory error but you are offending everyone's intelligence by claiming it's a simple "out of memory" issue.

Use a version of mame that isn't from like 7 years ago.

Why would I want to use some inferior version? 3.0b is most of the time much better than any of the alternatives I know of (when it works).

[Cagar]

Man, people have not tried shmupmame 3.0b or something... but the difference in image and sound quality is OUTSTANDING when compared to other emulators. Ketsui's sound is crystal clear, and the graphics as sharp as possible.
Am I missing some other emu which can do the same?

[BPzeBanshee]

Man, people have not tried shmupmame 3.0b or something... but the difference in image and sound quality is OUTSTANDING when compared to other emulators. Ketsui's sound is crystal clear, and the graphics as sharp as possible.
Am I missing some other emu which can do the same?

If you're missing something so am I. The clarity of the sound in Batrider is to my knowledge still not the same as it is in v3.0b, neither is Ketsui (though Nimitz has yet to release a fix for the disappearing sprite glitches present in the PGM games in Shmupmame).

As for the graphics, I've not noticed a difference (besides the obvious desync between sprites and backgrounds which give the extra frame of precision). If you're using DirectDraw in newer builds of MAME it'll appear just as "blurry" as it does with Shmupmame. If anything you'd probably have more issues with the aspect ratios since they're not automated I believe.

[Ed Oscuro]

The clarity of the sound in Batrider is to my knowledge still not the same as it is in v3.0b

Is this based on accuracy (to the original board), or..? The sound side of things can be deceiving, especially with certain sound card / driver setups and when fiddling about with the menus. Not having been able to use this version of Shmupmame, I couldn't say.

I would certainly be interested, at this point, to see what comments Nimitz has regarding the newer versions of MAME and lag. But honestly, FEELS GOOD MAN.

[Cagar]

Long time ago, shmupmame didn't work for me and I completely forgot it. After a few weeks I tried it again, and it worked for a week or two straight. And suddenly, it's the good old error again.
Developer? Help?

[Hagane]

Why would I want to use some inferior version? 3.0b is most of the time much better than any of the alternatives I know of (when it works).

I moved to 2.2 because savestates don't work well in a lot of games I like in 3.0 (such as Garegga, Batrider, etc.), plus sound breaks in Sengoku Blade.

[BPzeBanshee]

The clarity of the sound in Batrider is to my knowledge still not the same as it is in v3.0b

Is this based on accuracy (to the original board), or..? The sound side of things can be deceiving, especially with certain sound card / driver setups and when fiddling about with the menus. Not having been able to use this version of Shmupmame, I couldn't say.

I would certainly be interested, at this point, to see what comments Nimitz has regarding the newer versions of MAME and lag. But honestly, FEELS GOOD MAN.

To be more specific, I recall Nimitz saying something about finetuning the sound channels because apparently they were out of whack in the newer builds of MAME. Have a listen of the Batrider unofficial OST (which was recorded from an earlier MAME build) compared to the newer builds and you'll notice the difference. Whether that's actually accurate to the arcade machine or not - I can't say as I've never had the fortune to have seen one in Australia.

It'd be nice for the man himself to put this straight but considering it's been a year or so I doubt that's going to happen.

[nZero]

Merged separate Shmupmame related topic into the main Shmupmame thread.

[Udderdude]

What Nimitz really did was make Shmupmame for himself, and he was generous enough to share it with the community at large. He could have just as easily only kept it for himself, or only sent copies to the people he hangs out with on IRC.

Honestly, all the "entitlement issue" posts in this thread make me sick. He owes you absolutely nothing, so stop hounding the guy. You are not entitled to any replies from him or bug fixes or anything else.

[BPzeBanshee]

I guess Developer's Ethics account for nothing here then. Sorry for passing my flu onto you Udderdude.

Maybe we should just get a thread lock instead? I'm no expert but I see no need for keeping a thread open when nothing's happening besides this torrent of "entitlement issue posts" (guilty as charged) and unanswered questions. The issues being sprout up are consistently the same and there is consistently no proper answer from anyone.