Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation since 09/10/2025 in Posts

  1. I'm having second thoughts on this idea, for the same reason that HBMAME is still at 0.245, so sorry to alarm you all. You can still give your opinions though. Also, the forum performance is horribly slow, possibly due to the rampant bots that seem to be infesting many other forums, as they harvest everyone's input for their own nefarious use. So, sorry about that. It might be that we'll have to restrict guest access entirely. We'll see.
    3 points
  2. I'm having thoughts on adding the HBMAME romset to ARCADE64, with the eventual aim of closing down HBMAME. It will be a very slow process, taking more than a year. But first, I want your thoughts on this idea. Good? Bad? Don't care?
    1 point
  3. As far as I know, game configs work exactly on traditional MAME, MAMEUI, ARCADE and, if ROM available in the list, HBMAME. Just move the appropriate folder ("cfg", "autofire", etc.) from one emulator's path to another. The same goes for other INI and CFG settings. I generally keep ARCADE and HBMAME in the same folder. I even merge their ROMs, and everything works fine. Only Knights Of Valour 1: Super Heroes Plus had problems with different file sizes when checksums were the same, but as of a certain release (0.279, it seems), that's in the past.
    1 point
  4. Actually I don't love fighting games, it's just that there are lots of fighting games in cps1 & cps2, but I don't love them ! I liked playing some very old fighting games a very long time ago against a friend on an atari st, and I played matmania with my cousin in the arcades too, but except that no, no love for fighting games sorry ! And no I won't buy an italian version sorry! I totally missed this dash story because I never had to handle these cps cartridges directly of course... thanks for the info !
    1 point
  5. 1 point
  6. Yeah nothing major this time, it's more because a few things were committed to git this week to finish properly stuff in 0.97.5, and since there's nothing in the works for now it's better to release some new binaries now rather than wait an indefinite amount of time... So the changes : - Add a configuration for the joysticks dead zones in the inputs dialog, all joysticks share the same setting, don't complain since arcade joysticks don't use precise placement, it's just up left down right and center that's all. - cheat dialog: fix bug when text for the status bar is too long to fit on the screen normally the bar flashes and you can click on it to get the full text. Except the click has been broken since the transition to sdl2 ! At least this feature is not used often, which is not a surprise. - new region switches for xmvsf, mvsc, hsf2 - mshvsf: Enable "Norimaru" for all regions. It's an extra character which was reserved for Japan only previously, but it didn't make much sense to keep it only for Japan after adding a region switch to this rom. - And ffman1985 produced a new console script for sf2hfj. That's all, and this time it should be the last release for quite a while ! AppImage files updated too by the way, since sdl was updated it was too bad not to include the updated version... I didn't update the sdl2 dll in the dlls package for windows, you can grab the updated version directly from github if you are interested, but it's really about minor fixes inside, nothing major. win64 dll: https://github.com/libsdl-org/SDL/releases/download/release-2.32.2/SDL2-2.32.2-win32-x64.zip win32 dll: https://github.com/libsdl-org/SDL/releases/download/release-2.32.2/SDL2-2.32.2-win32-x86.zip I didn't even update the version number, but you can check the date of the binary either in the archives or in the about dialog, compiled a few minutes ago!
    1 point
  7. Err maybe you could have reduced the amount of text here... ? Anyway it's fixed in git, it's just the parameter of the callback to remove, it's useless, never been used, it's some code from mame and in mame they pass a parameter here. We don't. It's fixed in git, so if you update your git repo it will be fixed. I guess you might need an updated PKGBUILD file if you don't update your git repo by yourself... ! edit : updated the PKGBUILD files, 0.97.5c for the 64 bits, 0.97.5d for the 32 bits because there was yet another incompatible pointer type in the z80 asm core used by the 32 bits version. These are minor problems except they are making all the compilations of all previous versions to fail now ! Oh well... and in the meantime since last binary release wml had become incompatible so I had to update this too... ! Anyway everything updated and working now.
    1 point
  8. Nope apparently the resolution change is because of something done at low level, raine has absolutely no control on that, it just thinks that the real resolution is the one it displays in video info. And that's the goal of this function anyway to scale the screen and make everything on it to appear bigger. Normally this kind of thing is handled by a dpi setting, but dpi is mainly for text, then the graphical parts of the interface should scale comparatively, linux seems to do a good job for that, although it's been a long time I have seen a linux or a unix run on some really big screen, but when I switched to linux at university the servers were already using some very big screens ! I am not into the hd stuff because I find usually after 1k the improvement of the picture seems minor in most cases when switching to 2k, 4k, or anything beyond, but the increase in size for the pictures or the videos is absolutely huge, which means more storage, more processing power needed, and all that seems mostly wasted. When you think that we used screens at 576p for pal, and 480p for ntsc until not so long ago and it lasted for tens of years and nobody complained, all this seems quite crazy. But the world is turning crazier and crazier lately anyway !
    1 point
×
×
  • Create New...