Archive for February, 2013


Shmupmame 4.2

February 18, 2013

Version 4.2 is out now, the improvements in this version can be split into four categories:

1) Bug fixes: Direct 3D problems are now properly solved and all versions work as intended now, I also brought back 1945kiii and G-stream g2020 which were mistakenly removed in Shmupmame 4.

2) A series of small additions to the core system which improve the overall experience: Autofire rate saving and loading between play sessions (which was missing from Mameplus), Autofire delay display in hertz, Customizable autofire rate for custom buttons, A Cleanratio option (aspect corrected cleanstretch that finds the largest scale factor depending on the view), a Viewpercent option which allows to arbitrarily shrink the view (useful if you want a specific scaling factor or a specific resolution) and a few more artwork options (lighter scanlines options).

3) New input latency lowering method, I managed to fix a few shmups with the new lag removal method described in the previous post (all the other games on the namcos1 drivers are also improved and most games in the namcos2 driver):

Mars Matrix
Sengoku Ace
Sengoku Blade/Tengai
Strikers 1945
Galaga '88
Dangerous Seed
Dragon Spirit
Dragon Saber
Blast Off
Pistol Daimyo no Bouken

4) Game specific additions: Autosword feature for Mars Matrix which is mapped to button 2, it behaves just like the Dreamcast version. Samples support for Same Same Same, Fire Shark, Vimana, Ghox and Teki Paki using the thundermame code (thanks to BPzeBanshee for porting some parts of the code).

Get it from the download section: link


Shmupmame 4.2 coming very soon.

February 9, 2013

There were some leftover Direct3d bugs in shmupmame 4 so I took some time to fix them up and everything is working very well now.

A week ago or so, I decided to take another look at namco system 1 (a still laggy driver even after spritebuffer removal) and realized it has a MCU to process input, investigated a bit and realized that I could make the input ports available to the CPU faster by sending them to shared ram instead of letting the MCU do it. Result is one less frame of lag for all games on namco system 1, then I decided to try something similar for namco system 2 and it worked…

So pushing the idea a little further I decided to check some other still laggy shmups to see if it was possible to feed the CPU the input port values a bit faster. This is basically a new way to reduce input lag that doesn’t have any disadvantage (unlike the removal of sprite buffers).

There are a few games that have been fixed this way and will all be included in 4.2, which should be released in a few days.


More info soon