From what I tested the blitter delay is working for the cv1k driver.
Thought there were some issues as Deathsmiles Mega Black Label was stuttering with bad sound, but it’s just because it’s too expensive to run with Shader + Hard GPU Sync.
It was struggling the same with or without the Blitter Delay hack on.
FYI a high blitter delay value makes the game slower with fewer sprites on screen, while something under 40% will be quite the same as blitter off (=normal speed).
So it seems to be working as intended on Retroarch as well which is great.
BTW, about the mame cores, is the mame151 being replaced with the mame 152 core? Would be nice to have different cores depending of the mame core because of the different romsets and not being updating them all the time.
Also, is the mame151 core gonna get the cave driver? This is getting more awesome by the minute
I don’t think they want to keep every iteration of Mame in Retroarch.
One Mame core being big enough to cause some concern for download filesize on mobile platforms.
That’s annoying but roms update is unavoidable.
Or you can keep the older core along the newer one: name it differently and make an info file with that same name and edit its content.
The last update is sweet! I can confirm that custom bindings work flawlessly now no matter if I go to desktop, resume content from main menu or switch cores. Thanks, guys!
A minor issue with rgui remains - when I hit a button to close (resume content) it also counts as in-game action.
BTW for now , 0.151 are the more stable core for mame2013 ,
0152 is new and not very tested, and for now have some pb with the android build
( which don’t run if you don’t backport the portion of netlist source code to 0.151 see git issue for more detail)
anyway if someone care about testing android 0.152: http://www39.zippyshare.com/v/96362999/file.html
For cvsh3 drivers , 0.151 have the old cavesh3 driver and 0.152 have the new cv1K drivers .
Only some time for testing and report how the new perform (like Tatsuya79 report) can lead to remove the old one for the newer one in 0151 source code. As i don’t know about cavesh3 very well , i let SquarePusher decide of this (as he add the old one in mame2013 )
Now for know which core will be bundle here , as mame2013 is not include in official release , only lordashram can decide this for his test build.
This is exactly the issue I’m having. I posted a separate topic on it but apparently it cant be changed? Quite annoying to resume content to find that you have jumped off a cliff or something
The d3d driver does not work on the Win64 bui;d & I could not build MAME2014 for Android yet.
Also, when I built MAME2014 using gcc 4.7.3 for Win64 it would crash when loading a rom but works ok with gcc 4.8.1 for Win64.
Once my health & eyesight get back to normal I plan to build an all new gcc 4.8.2 toolchain and see if the cores that only compile/work with gcc 4.7.3 and the ones that only compile/work with gcc 4.8.1 for Win64 fair better with that.
@AndresSM when I can, personal issues have been keeping me away from the computer as of late.
I have updated my Win64 compile toolchain to GCC 4.8.2 using Maister’s GCC 4.8.1 toolchain and using MinGW’s x86_64-4.8.2-release-posix-sjlj-rt_v3-rev2, I can now compile everything and akaik they all work too.
I have added a dev_tools folder to my dropbox with the updated toolchain and also updated headers & libs and a redist with the needed dlls if anyone is interested.
Besides the toolchain I also updated some of the libraries to:
freetype-2.5.2
SDL-1.2.15
zlib-1.2.8
And with this new toolchain, I recompiled everything that can be compiled for Win64 for this newest release.
I went ahead and made my own info file for TGB Dual, it will be in the next update. As for picodrive, I have noted to the devs about the Windows filename but I haven’t posted it (along with several other PR’s I need to get around to do) on the github so it can be taken care off. Until then I can add to my own compile scripts to rename it.
The Desmume core (I think this is the first time it’s been included in a Windows build) seems pretty great so far! I tested it with Order of Ecclesia and it scrolls so much smoother on my 120hz monitor than on the stand alone version of that emulator. Pixellate makes the scaling look much better too.
How come it doesn’t work on my end?
Any game which uses a save tells me it cannot create it and refuses to launch.
Is there a bios or an ini to put somewhere?[/quote]
I just started getting that save file problem too. It only happens when I launch from the command line (using Hyperspin) though. I first tested it by launching Retroarch normally and loading a zipped rom through RGUI, which works. This core uses whatever you set your system folder for saves.
So I think it’s something wrong with command line launching. It doesn’t seem this core needs any ini file or BIOS.
I’ve got a new laptop (Model Samsung Ativ Book 6 with core i5 and Windows 8.1)
I’ve tried the latest win64 build, but couldn’t run it properly (I can run the official 32bit edition, though).
At first, it complained about d3dx9_43.dll. I’ve passed this point by copying that dll to retroarch folder.
Then, there’s another issue I can’t resolve. Now it gives me an OS error when I try to run Retroarch.exe for the first time. It returns this OS error code: 0xc000007b.
(by googling, I found this issue is very common, but couldn’t find a solution)
