Jump to content

Tux

Emulator Author
  • Content Count

    423
  • Joined

  • Last visited

  • Days Won

    68

Everything posted by Tux

  1. I am really cursed with this one, sorry, at least I have you to test the linux installation, yeah I never install here, I always run it from its source directory. Ok, it's fixed again, but it has to be called 0.91.15b this time, for info the brasil.cfg is an old allegro file that I decided to remove lately, it will probably break the dos version if I try to recompile it one day... ! I also uploaded the 32 bits binary package, at least I tested the installation completely this time to avoid any other problem, no need to test the 64 bits version too, it's the same install. No you can't ins
  2. The unofficial translations are legion on snes too ! And congratulations to the team who did that too, it was without the sources, and they made miracles to patch the roms there... I am no expert for mame, although I have read the source quite a lot for some drivers, but you simply need to launch it in opengl, it might even be the default nowdays, if not just do "mame -video opengl -rp your_rom_directory 'game name'", and it should work. Didn't try any zinc game yet though... edit : I just tried it, and I confirm, it works (although I had to update gdarius2.zip and get some bios)
  3. my bad, I forgot the PKGBUILD file was read from a specific directory to generate the latest page, it's fixed, and I uploaded the latest PKGBUILDs files for the 0.91.15, you won't have to fix them manually (and I should at least update the maintainer line at the top of these files, on the todo list).
  4. To be slightly more precise on this bug, it's not the emulation itself which has a problem, it's the final blit which should display its result, the blit is unstable in this configuration and sometimes it has problems like here. Nothing can be done in the current situation, it's pushing sdl-1.2 to its limits, but since it's unmaintained the only solution is to switch to sdl2... !
  5. Alright finally found the problem and it made me crazy since it didn't make any sense, it's related to the gui in opengl, I can't explain how exactly, but it creates a strange problem in the rendering here. The last version with a working neo turf master was 0.91.7, just at the moment where I decide to delete the old useless builds, I couldn't have guessed such a super strange bug was hidden there ! Well the bug can't be fixed for now, it would mean taking back the opengl gui which would take back the big bugs which were here in fullscreen for windows, and that would be all the drivers, n
  6. Try to disable the speed hacks in neocd options... garou should work fine with speed hacks disabled, I'll remove its speed hack for good in the source, the mystery is why did this thing worked at a time and not anymore ? But anyway it already created too much problem, better remove it. For neoturf it's a totally different problem in windows, absolutely no idea why there is a difference with linux for now ! finally able to reproduce neo turf master's problem in linux... in windowed mode only, in fullscreen it's perfect ! Never saw something like that before !
  7. Actually I had a quick look out of curiosity : I can't reproduce these problems in linux, but I don't understand yet why they are windows specific, there is nothing afaik specific to windows in this code ! There might be a problem with the gcc for windows ? Not sure yet, anyway I'll need more time for this. Anyway so far : for neo turf masters the quickest way to reproduce is how to play from main menu, shows garbage in windows, perfect in linux, no idea why yet. (neocd) For garou : I played a stage without problem, windows seems ok too but I didn't go far in windows, where did y
  8. If I am not mistaken, you got the info about garou which might have problems from me ? I knew I should have tested it ! And for neo turf masters, not this time yeah. Well too bad, I need a break from testing too many things, I'll look into this eventually, but not now !
  9. It's almost only fixes, but there are quite a few : neocd/neogeo : - unlikely incompatibility between mslug2 & pbobblen, this fixes both this time. - there were some problems in neocd with speed hacks, they are now disabled for the kof games and kabukikl - still on neocd, there was a crash when reading an audio track merged with the main data track, this worked before, but anyway it's fixed. - old capcom savegames prior to some time in march 2020 couldn't be restored anymore, I added a callback to fix things on the fly, it might not work for all the games, I don't have savegame
  10. The message is quite clear I thought, even if technical, it says it can't find the ids for the 68000 and the z80 in the save game, which is normal since it was saved in 32 bits so these are not even the same cpu emulators here. For the 32 bits version, you hit an incompatibility I added for the 64 bits version, musashi didn't want the original speed hack, and it was right it was more dangerous than I thought, but now the savegames made with the old speed hack become incompatible ! I didn't even think about that. I just spent too long to add some hack when loading the savegame to restore t
  11. No no, this kind of nostalgia is a common disease around here, absolutely not boring ! I agree about not replacing them, zsnes was a major emu no matter what, I didn't play much with it because I actually played most of my snes games on the psp, using a snes emulator on the psp, but I tried it a few times and I liked its spirit (quite similar to raine for the spirit). Even though the graphics are outdated, there were some very good games on snes, and I finished some on the psp ! (and arguably there were probably more good games on snes than on the psp, what made it excellent was actually
  12. I didn't see the message, but I guess so yeah probably. In this case it means it can't restore the 68000 data, but sometimes it works anyway if you are lucky, it depends on the way the emulated game is made and at which point you tried to load the save state, quite a lot of these games have a main loop, and they wait for the vbl at the end of the loop, so if you saved in this loop, and tried to load in this same loop, chances are high you will be able to restore the game even without touching the 68000 registers ! Don't count on it though, it's more likely to crash with a very impressive
  13. Tux

    more fixes coming...

    And I just found that one of the cheats for puzzle bobble 2 has more than 100 choices, which makes raine to quit with an error message, probably invisible in windows. This is the cheat to select a starting level. And yet another fix... !
  14. Tux

    more fixes coming...

    In may 2019 I suddenly discovered that one of the simplest game for neogeo, puzzle bobble was completely broken suddenly. It was because of a fix for garou. I tried to revert it while not breaking too many things but I knew it was probably going to create problems, but I was too lazy to retest all the neogeo games. Well the bug report finally arrived last night : https://github.com/zelurker/raine/issues/26 It was in metal slug 2 finally, from the introduction. Well it's fixed in git, for good this time hopefully. But I am too lazy to make a new binary just for that right now, after a
  15. lol ! yeah it's in december in japan so I guess it can change around the world... For the sound, no idea, even if it's not the right one, it doesn't sound so bad, so I decided it was not worth spending a lot of time on it, thanks for the links though. Too bad you can't code, you would be able to try things directly on the source !
  16. Yeah the fix affects quite a few games, it's on a low level function so it's used by quite a few, that's why I released a new binary because of it. Yes your problems are related to rasters, and I never tried to emulate them in cps2, maybe they are easier than the neogeo ones though ! I thought about the year actually, I wonder if there is a gcc define which inserts the year the program is compiled, it would fix this for good, but I didn't check gcc docs yet, on the todo list.
  17. - one is about the speed of games like pang for the 64 bits version (they were too slow !), it's specific to the z80 emulation using the C version only. - and the other is quite original, a graphical glitch in some cps2 games like hyper street fighter 2 and some others which was unnoticed for more than 10 years ! You can see pictures along with the discussion there : https://github.com/zelurker/raine/issues/25#issuecomment-799135733 That's the 2nd one which pushed me to make a new binary, you don't see this kind of bug everyday ! http://raine.1emulation.com/download/latest.html
  18. Do you know there is a "record to wav" option for that ? Why is the shout different ? Good question ! Next question please ? (aren't you supposed to think about love instead of about fighting today ? )
  19. Ok fixed, what annoyed me here is that it was a general incompatibility in the way irqs were handled between mz80 and the mame z80 core we use in the 64 bits version. So I just added some code to make the mame core compatible, our way to handle interrupts is actually easier, you don't have to know how long the irq line must stay active, an irq just becomes pending and is executed as soon as it can be executed. It was inspired by z80 books so it doesn't come from nowhere, and it simplifies things, even if I am sure there are very good reason about accuracy to do this differently. Anyw
  20. Ok, confirmed, it's specific to the 64 bits version again... ditch the 64 bits version ? Well I won't look into this just now, maybe later...
  21. It's a z80 alone for both these games, it's not really powerful, they seem ok to me, at least they always were like that... Compare eventually with the 32 bits version. Pang3 uses a 68000, it's cps1 hardware.
  22. Tux

    Raine 0.91.12

    You can't sorry, it's not supposed to happen at all in fact, as I said your 3 saves are broken and unusable now, and I am like you, I can't reproduce this, if you find a way to do it, I am interested !
  23. the main problem this time is in the 64 bits build, all the kabuki games were broken (pang, super pang, block, pengo, and quite a few cps1 games). Also fixes chasehq and continental circus graphics. chasehq and night striker gain a region switch too. And a last fix (hopefully !) for the sound associations with kof99, a song which never stopped during the intro. That's it ! http://raine.1emulation.com/download/latest.html
  24. Thanks for this one, it's specific to the 64 bits build, I was expecting something like that but since I work mainly in the 32 bits build I never found it. All the kabuki games are affected, it's simply because the offset to the decoded area becomes a 64 bits offset for the 64 bits build. I'll release a new binary later today, this bug is here since the 64 bits builds started to appear. Kabuki games include block, pkladies, pang, spang (for the mitchell driver wof, dino, slammast, punisher for the cps1 driver. and pengo, which is probably the 1st game to ever use this. Pa
  25. I played with an old 0.28 in dosbox lately and I can confirm that the old dos version had the right colors (but in 8bpp only, there was not even a setting to display the game in more than 8bpp actually, these were the very old dos days !). But the sound was mostly broken, no wonder it gave me a lot of troubles here, there was some kind of weird bitswap on the sound command, like a protection to make it more complex than what it should be, anyway...
×
×
  • Create New...