Jump to content

Tux

Emulator Author
  • Content Count

    434
  • Joined

  • Last visited

  • Days Won

    69

Everything posted by Tux

  1. I found a recent gcc (latest version actually) for dos in arch, so I got curious to see if I could make the dos version to run now... Weirdly I have some trouble with dosbox, raine crashes at launch with it in install_allegro, no idea why, I tried a few dosbox versions and always the same result. With dosemu it's also harder, it had the best results before, now I am obliged to use a pre-version of their 2.0, which is not super stable. Here it works, sound and graphics (well vesa 2.0 linear which is not bad, but no triple buffer at all). Only file accesses are very slow for some reason, so
  2. Tux

    Raine 0.91.7

    No problems with ryzen chipsets, usb and so on. Don't worry I made peace with my win10, I use it only to launch games or test raine from time to time, and it has all its advertising disabled, a restored and usable start menu, in this state it looks very much like win7 actually ! The best option to work around the display bug in fullscreen : disable opengl double buffer ! There is really a problem when leaving opengl using double buffer, so if you remove the option, the problem disappears. I tried a borderless window to emulate fullscreen : bug still here, but with a border it doesn't
  3. Tux

    Raine 0.91.7

    windows7 is usually the best windows, right ? I would have kept it myself, except that updating the machine doesn't leave any choice with some low level drivers impossible to find for new hardware on win7. No idea why your mouse is not captured, never heard or seen that before... ! Notice that in this extreme situation you can use fullscreen, just don't call the gui or if you do and it's not visible, then you can either return to the game with esc or quit with q or alt-f4 (alt-f4 quits without saving the settings). It's not super convenient, but it's very do-able ! I am not sure
  4. Tux

    Raine 0.91.7

    I confirm on my side, just tested natively with windows 10, with a window which is not fullscreen, the mouse is captured by raine only when playing arknoid2u (or any other game with the same mouse requirement). I was afraid for a second that I had yet another incompatibility between windows & sdl-1.2, not this time ! Standard windows 10, nothing particular about it.
  5. Tux

    Raine 0.91.7

    The mouse is captured for games needing it, you shouldn't have any problem in a window (at least tested for arkanoid, so it's good for games using relative moves).
  6. Ok, double error here, LOAD_IGNORE wasn't ignored by -rc & -rcf, plus a partial rom load from the driver shouldn't print any error. All fixed ! (it shows that nobody has been running a serious romcheck for a very long time or at least they didn't report the errors).
  7. Typo error on my part : filenames recognized : { "bubble_bobble_romstar2", }, { "bubbobr1", }, { "bubbolbr1", }, The last one should have been bubboblr1 and not bubbolbr1. Will fix that for next time, but I had the original archive which still has the short name bubbobr1 and didn't notice it. This change was from 2015, so it was not a problem for a lot of people. Anyway next time it will recognize the right name then... !
  8. Tux

    Raine 0.91.7

    It's a long standing bug between double buffer fullscreen and sdl-1.2 in windows, it's been here for years ! Workaround : use a maximized windowed mode. The bug doesn't happen all the time, but it's very frustrating. Could also use a borderless maximized window for that, but they are so hard to use in windows (what a bad name for an os which is so bad at handling its windows !), that the setting isn't even saved in the config file. It's not fixable in raine, it's an sdl-1.2 bug. and actually raine is not frozen when it happens, it's just a display bug, the gui is invisible, so
  9. Tux

    Raine 0.91.7

    Excellent, thanks !
  10. Tux

    Raine 0.91.7

    As the version number implies, it's all bug fixes inside : - -rcf didn't work with romsets using LOAD_CONTINUE (like sonicwi3), it's fixed - sf2m8 used a dummy rom load instead of a FILL which created a romcheck error. - don't consider neogeo games as clones of the neogeo bios in the games display - fix broken iso.gz support for neocd (usually compressing an iso to iso.gz without touching the cue file at all used to work, it was broken in 0.91.6 because of the changes there). - and neocd again : when trying to guess an audio track name and there is no cue file, check the exte
  11. On 2nd thought, the fix is not hard to make, only a few lines. So I'll do it again, there are a few minor fixes already committed to git and I needed a reason to make a new binary. Plus I need to recompile all the 32 bits windows dlls (oh joy), to get rid of the dependencies to the old gcc, anyway, I'll release this soon... (already fixed in git)
  12. Tsss... can't insert my reply in the middle of this, so it will do here : 1 : Not for me, sorry, I don't know exactly what happens for you, but the rom loads fine here. 2 : Ah ok for this one, the -romcheck command doesn't handle very well the roms loaded with a ROM_CONTINUE, actually these roms are very few, and it's the 1st time this is reported... Anyway what happens is that it says bad size 0x20000 because the rom is loaded by parts of 0x10000 with a ROM_CONTINUE for the 2nd one. It's harmless anyway, but thanks for the info. 3 :Since you didn't give any example I am obliged
  13. lol, yeah but I know there are some beos lovers out there and they used it on pcs. Some amiga lovers too, this year they got a doom port : https://games.slashdot.org/story/20/04/26/0156227/developer-attempts-doom-clone-for-the-amiga-500
  14. I wouldn't want to port it to libretro, libretro is good for emus which run their games with a minimum of options, raine has a swarm of options ! so no, forget it. And for aur, yeah well it would mean trouble for me, because signed packages, make the package to be accepted and so on. For now I chose the easiest path for me, sorry if it's too hard for some ppl... !
  15. Ah some feedback at last ! Thanks, yeah the guy seems to auto build a lot of packages, probably too busy to reply to almost anything ! Well no version is better, but they are really different, I mostly use the 32 bit one because it's fast even for a debug build without optimization. why didn't you try to install the .tar.xz files ? They are not signed but it shouldn't matter. I don't know this --editmenu flag, I'll take a look later, thanks for the feedback anyway ! (normally installing the xz file is done using pacman -U file.tar.xz simply). and why not using simply makep
  16. it's not exactly a bug although in this case it's not convenient, it's because all neogeo games share a parent : their bios ! So if you hide clone, you hide them too, maybe it would be nice to find a trick here... Ok, I just added an exception for neogeo games, it's easy to do... You insist on playing with the gui set to a low resolution, well there is a minimum allowed font size for readability, then if you hit both limits (the resolution + the font size), then your text is clipped, it's normal. And no I don't plan on having game names on multiple lines ! And same thing for the s
  17. What a mess... let me guess, libstdc++ too then ? The weird part is that this time I tested it, from linux, but it was better than nothing... Oh sigh ! Ok, I'll look into it, might be able to create a whole new dlls package for that... ! Here is an updated package, tested in windows this time : dlls32-0.91.6.7z I still don't understand how it can work in linux with wine, I guess there is some trick about the gcc libs there... Anyway I hope there won't be any other gcc update anytime soon, I had to recompile muparser for this... Oh, and both libgcc are required for this ve
  18. Good one, since I cross compile, I don't test everything all the time, but this time gcc was updated automatically, and the dll changed for the 32 bits version, but the 64 bits version kept the same name and is apparently still compatible ! So I just updated the dlls32-0.90.7z package, adding the new libgcc for this gcc-10.1 inside, I keep the old one for those who want to test old versions. Sorry for the inconvenience, you will see the updated date of the package in the download page, and thanks for the post !
  19. Not what I meant, it's probably as good as any other dump, the problem when reading would be with big endian cpus but they become rarer and rarer these days, so you can forget it. But it's still more convenient to have wav files at least to convert them more easily to mp3, ogg or flac. For me the ideal format is probably : extract the files from the iso and put them in a zip file, then convert all the audio tracks to ogg (neocd audio is not symphonic, it's just a waste of space to keep uncompressed audio here, and ogg is probably the best format for that, or mp3 if you prefer). Then just
  20. ... which produces raine 0.91.6 to handle this new kind of cue. It's far from an ideal one, everything in raw even the audio tracks, which means that you could get bad sound if the endianess of the computer who created this rip and the one reading it differs but here it works with some good old x86 endianess. This obliged me to change the way the iso is detected in the cue file, previously I was taking the "binary" track, but here all the tracks are binary ! Normally it shouldn't break anything, I quickly tested with some good old normal rip and everything seems ok. That's the only
  21. Give a link to your re-dump by private message so that I check it... ! Be sure to at least use the latest version of raine (0.91.x).
  22. I have just taken some time to look into an appimage : that's a way to bundle some libs with an executable, for linux, similar to osx packages. The advantage : to be able to run it on any system without installing any shared lib since they are already in the package. The idea is interesting, but for raine there are 2 problems : 1) the small package becomes very big with that, for the 32 bits package without libX11, libc and libstdc++, it's still 25 Mb ! With these 3, 32 Mb ! Very far from the usual 2 Mb ! 2) The target system would still need to be able to run 32 bits binaries, s
  23. So it's for arch although a tar.xz should be usable by anyone who is not afraid of shared libraries error messages. Feed back is welcome, the PKGBUILD file is so convenient for me that I wonder if I shouldn't just remove entirely the tar.xz files and keep just that, so post there if the tar.xz files are useful for you. The PKGBUILD is inspired by the version in Aur, with modifications for the latest version instead of the old 0.64.16, optimize for pentium3 for the 32 bits version, and use -O3 for gcc, so thanks to the original author, it made this easier. Oh, and it's actually 0.91.5, wh
  24. Nice video, but it's the memory card they talk about, there is already 1 memory card / game in raine, but the save ram is in common and 64 K max. in savedata : *.bin : memory cards neogeo.saveram : the famous saveram, that's the one you said contained scores, right ? I know for sure the saveram contains the soft dips settings, and what is called "book keeping", the stats about how long the games are played and how many times, see b+c+d while booting with unibios, then book keeping. You can change the soft dips from there too, or from the dialog included in raine. No I don't
×
×
  • Create New...