@lordashram Sorry to hijack your thread again : )
@all
long time since there is no official mame release , and in the waiting of the future 0.153 official release i ll post here an update based on SVN r28292 (for win64 and lin64)
Thanks. Got a few issues though.
I can’t make my mame.ini recognized anymore. That’s the first mame_libretro I’m using since the “path change” so I guess that’s about it. I just want to do a “pause_brightness 1.0” in this ini to take screenshots while using the pause at full brightness, but can’t find the new location to put it in.
Something else: in Mame Gui Sliders menu, changing the brightness makes retroarch crash. Same about loading a game which has a cfg that changes the brightness/contrast. edit: just tried a mame SVN standalone = same issue / not a libretro issue
I read this page that says cheats have to be unpacked but they are working here in retroarch\system\mame\cheats.7z I had to put cfg, diff and nvram in that same retroarch\system\mame\ folder. My neogeo.ini to specify “bios unibios31” is working in retroarch\ini\ folder.
Hello there. I am trying to get my master system bios to activate on Genesis-Plus-GX but retroarch can’t find it even though it is in the Systems folders. Yes I named the files like so (Bios_U.SMS for US Bios, Bios_J.SMS for Japanese Bios and so on.) How can I make the bioses get detected?
[quote=“Tatsuya79”]
Thanks. Got a few issues though.
I can’t make my mame.ini recognized anymore. That’s the first mame_libretro I’m using since the “path change” so I guess that’s about it. I just want to do a “pause_brightness 1.0” in this ini to take screenshots while using the pause at full brightness, but can’t find the new location to put it in.
Something else: in Mame Gui Sliders menu, changing the brightness makes retroarch crash. Same about loading a game which has a cfg that changes the brightness/contrast. edit: just tried a mame SVN standalone = same issue / not a libretro issue
I read this page that says cheats have to be unpacked but they are working here in retroarch\system\mame\cheats.7z I had to put cfg, diff and nvram in that same retroarch\system\mame\ folder. My neogeo.ini to specify “bios unibios31” is working in retroarch\ini\ folder.[/quote]
Hey
I did the path thing, glad it works. I tried with cheats.7z but it didn’t work for me, will have to retry.
I’ll look into the correct location for mame.ini and report back. I guess ini path is not mapped, cfg and ini are not the same in mame. I have planned to make it possible to override the paths with mame.ini paths in a core option.
Thanks for your work. Yes, everything in the same place should be the cleanest way. I mean, everything in this mame folder such as various ini and the mame.ini.
I was thinking something that would be great in retroarch GUI would be to add a “Help / notice” directly in the core options. This would document all those tricky things like cores particularities in a more conventional place than github.
Not very familiar with the new way of path handling , so i let AndresSM answer. BTW not having this pb using the new path system on linux ,the only things i had to do is to put a ume.ini (ume as i use some mess computer/console ) in the same folder where i launch retroarch mame. After i have set up , my system folder with RGUI to some path , and put in system/mame/ : ini,nvram,cfg,diff ,roms,messroms,software… and in this ume.ini setup the differents paths according to the retroarch system path.
And after all works great , ini,cfg ,diff,nvram,snapps… all are created in system/mame/.
Haa , didn’t realize before you point me this issue , if it impact also SVN standalone , we can hope for a fix quickly , anyways nobody report it yet? Strange also not impacting all game , like ridgeracer or atari jaguar you can change brightness in OSD fine without coredump…
BTW seems to be related to palette , BT show reference to bcg_lookup_table(int texformat, palette_t *palette) (in emu/render.c )
Yes , if my ume/mame.ini could be also parsing if it reside in System/mame/ instead of current dir it will be great . (@AndresSM we hope for it)
And yes , i way in libretro core to put some help/doc/notice in RGUI could be a good idea !
LOL didn’t think about that, just renaming it to ume.ini does the trick! Got it in my retroarch folder as usual, that’s working now (on win7 x64).
I reported the brightness crash on mame testers site (even if I’m not sure that’s the place for SVN bugs).
Thanks.
[quote=“Tatsuya79”]
Thanks for your work. Yes, everything in the same place should be the cleanest way. I mean, everything in this mame folder such as various ini and the mame.ini.
I was thinking something that would be great in retroarch GUI would be to add a “Help / notice” directly in the core options. This would document all those tricky things like cores particularities in a more conventional place than github.[/quote]
I got ahead of you. I added that last week, should be there next release there is a core information entry and I already added the info for MAME
https://github.com/libretro/libretro-su … retro.info
Generally speaking, all SAVE data goes into SAVEFOLDER\mame, all extra rom data goes into SYSTEMFOLDER\mame
I’ll check out the ini thing today
Lol , and yes i forgot to mention that it’s a ume release not a mame ( as i use ume for my own purpose instead of mame ).
but BTW ume = mame + mess , with less of Mo 
And yes i saw your issue (closed because they only consider release not svn ) , but they said dev already know this issue , hopefully they ll fix it for 0.153.
@AndresSM
Yes fix the ini could be nice , as i have to let my ume.ini in the current folder instead of system/mame/ else not taking in account .
Also i notice your change in libretro-super , it’s nice and great but speaking in dev part , it will be cool if we can , in the core itself , notice some important things like feature but also button mapping ect … , because who read the readme.md to know R2 is mapping to F11 or R3 to F2 ect …
You can add the info to corename.info and it will be displayed in the core information panel on RGUI
NIce !
Yes it’s better than nothing and it do the job but …
the format is somewhat … only put things in “notes” and all have to be in same line…
Other things that annoying me , have to be in libretro-super dist , so can’t live in the core git , so not friendly/simple to the dev to edit it as he like .
So if the core info could be retrieve by default directly form the core it will be greater (and logic) in my opinion .
display_name = "Arcade (MAME 2013)"
authors = "MAMEdev"
supported_extensions = "zip|7z|chd"
corename = "MAME 2013 (0.152)"
manufacturer = "Various"
systemname = "Arcade (various)"
license = "MAME"
permissions = ""
notes = "- core supports MAME save states|- core supports extracted MAME cheats|- BIOS files go into the ROM directory|- CHD files go into the ROM directory in a directory with the same name|- ARTWORK, CHEATS, SAMPLES may go into SYSTEMDIR\mame into their own directories|- STATES, NVRAM, INPUT, SNAPS, CFG, MEMCARD, DIFF will be saved to SAVEDIR\mame into their own directories1|| |Default controls:| |JOYPAD_START -> [KEY_START]|JOYPAD_SELECT -> [KEY_COIN]|JOYPAD_A -> [KEY_BUTTON_1]|JOYPAD_B -> [KEY_BUTTON_2]|JOYPAD_X -> [KEY_BUTTON_3]|JOYPAD_Y -> [KEY_BUTTON_4]|JOYPAD_L -> [KEY_BUTTON_5]|JOYPAD_R -> [KEY_BUTTON_6]|JOYPAD_R2 -> [KEY_TAB]|JOYPAD_L2 -> [KEY_F11]|JOYPAD_R3 -> [KEY_F2]|JOYPAD_L3 -> [KEY_F3]|JOYPAD_UP -> [KEY_JOYSTICK_U]|JOYPAD_DOWN -> [KEY_JOYSTICK_D]|JOYPAD_LEFT -> [KEY_JOYSTICK_L]|JOYPAD_RIGHT -> [KEY_JOYSTICK_R]| |tips: R2 to tab and select newgame from mameui"
All that stuff occupies memory, I think it’s overkill, Square told me not to overdo it so I didn’t.
I was thinking of doing it notes0, notes1, etc but in the end the result is the same.
I have planned to redo the input mapping sometime soon for MAME too since now with custom mappings per game it’s awkward at times, MAME OSD controls are not consistent.
If every core mapped by default to RetroPad we wouldn’t need explanation
I think a better way to show controls is to add something else to the menu that displays the RetroPad and it’s mappings
There is a handy graphic like this in Kawaks and I have always found it makes it very easy to map your cutom controls.
no comment, but it doesn’t change for me that the things have to be in the core in first place not elsewhere !
MAMEOSD controls are not so bad , Anyways , i’ve planned too to redone my works on input and then add 4 players ,permit to change some hardcoded keys in mame osd and redone kbd in the old ways now kbd callback are supported both in linux and /windows.
You always need to have somewhere somethings witch tell that L2 is mapping to such key by default …
Yes could be definitively great to have this. (if it retrieve key mapping from the core )
BTW, Maybe we can open a MAME thread in Implementations for discuss all this mame related features/request/enhance.
I tried to make this one for that purpose. It worked for a while but we always end up everywhere else! =D
RetroArch-2014-03-12
Android: Updated: RetroArch, Core Info, FinalBurnAlpha, Gambatte, Genesis Plus GX, MAME2003, Mupen64Plus, Nestopia, PRBoom, SNES9x, SNES9x Next
Win64: Updated: RetroArch, Core Info, Gambatte, MAME2014, Mupen 64 Plus, Nestopia, PRBoom, ScummVM, SNES9x, SNES9x Next Added: DeSmuME-future
NOTE: For best results with Android port, be sure to uninstall previous version before installing newer versions.
Noteable Updates: MAME2014: add support for 4 player games
I’ve left DeSmuME in for now but I decided to go ahead and add the Win64 port of DeSmuME-future so that the Win64 port can have an updated version. Though I didn’t put much effort into it, I couldn’t compile the Android port.
I also added prboom.wad & the shareware of doom1.wad zipped up as prboom.zip as an extra download for those that want to play around with PRBoom. You will need to unzip those into your ROMS folder and select doom1.wad as your Content for PRBoom.
Lordashram, out of interest, which NDK version did you compile with for the Android build?
I use NDK-9c with toolchain 19 for everything except Mupen. If I use anything other than NDK-9 or 9b + toolchain 14 for Mupen than it always crashes when trying to load a rom. As I said I did a quick try and it failed and I didn’t document the failure to report back on, but I will try to make sure I have more time for my next compiles to see if I can get it to compile or report back my findings.
Speaking of compile failures, I have yet to be able to compile MAME 0.152 for Android no matter which NDK nor toolchain I use. My kids are on spring break so I will get less time on my computer right now but hopefully I will have time tonight or tomorrow night to sit down and document my compile failures so I can file the issues on the git repo…