Jump to content
Search In
  • More options...
Find results that contain...
Find results in...


Emulator Author
  • Content Count

  • Joined

  • Last visited

  • Days Won


Tux last won the day on June 5

Tux had the most liked content!

Community Reputation

94 Excellent

About Tux

  • Rank
    Author of Raine
  • Birthday August 18

Profile Information

  • Gender
  • Location
    Nantes, France

Recent Profile Visitors

1,395 profile views
  1. 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 !
  2. 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 delete the cue file, raine will know the zip file contains what should be in the iso, and guess the ogg files are the audio tracks, and the result will be much smaller while being readable very quickly !
  3. ... 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 change for 0.91.6, so those who don't have such raw rips in multiple tracks for neocd don't need to update, and 0.91.5 was linux exclusive. Oh by the way I removed the blend files from this release, you'll have to download them from the extras section or use them from a previous release if you are interested, it's better to have a default without them. http://raine.1emulation.com/download/latest.html
  4. 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).
  5. 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, so have the basic libs + the dynamic loader installed, it's an endless headache to try to have this packaged in an appimage, with a lot of effort I could run the binary, but it could not open a graphical window ! So it was fun to try, but I don't think it's interesting for raine. If 32 bits apps are a problem, just install the 64 bits one, it should be easier to execute anywhere... Even if it uses quite a lot of shared libs now, these are still very standard and easy to find libs, so these appimages seem too much here.
  6. 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, when the windows version is 0.91.4, but the only changes except the title bar of the window which now contains the version number are changes to the makefile to correctly install everything in linux. Also this version does not contain the blend files, history.dat or hiscores.dat, so you might want to visit the extras section to get the relevant files if you are interested (I might remove the blend files from the windows version, I added them because they are not big, but it creates small graphical glitches sometimes so it's probably better to let them for those who know what they are doing). All the data files can be installed either in ~/.raine or /usr/share/raine. It's in the usual download page, bottom of the page, there : http://raine.1emulation.com/download/latest.html
  7. 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 see how, graphics and sounds are separated, it would have to be a tremendous bug for that. No there is probably something which is not saved correctly somewhere. For your sound associations you probably found a game which has yet some other sound commands, there are already quite a few found, and it's quite tedious to analyze the commands to find how it's working, so I delay this for now, but it won't create any other problem by itself, it's just about how the sound commands are interpreted, it can't create any graphic glitch.
  8. Just restored the scripts to handle the 2 binaries + the dlls for versions >= 0.90, it's mainly for the old versions page, but the latest page (main download page) is handled by them now again. Next time : the linux binary, oh yeah... (well maybe then, but no hurry !).
  9. Ok, thanks for the info about the saveram. The file is not directly readable if I remember correctly, something about words accessed strangely, but it's good to know. Notice that if you are right, then this info can be lost very easily, it's enough to play a few neogeo games until your kof99 becomes the oldest and it's then overwritten. If you have a .hi file then you have a hiscore.dat, and an old one, the latest one (2.11) doesn't have any info about kof99, and normally it should be enough to make it survive a region switch. edit : after checking in the code, 8 games only fit on the memory card, so just play 8 other games after your kof99, and bye to your scores, unless the .hi file saves you ! For the corruption of your screen, how did you do it exactly, I guess saving and loading anywhere is not enough ? Oh you want the version number in the title bar ? I don't really see the point, unless you run a few instances of raine at the same time which is not something most people would do, but anyway it's easy to add ok, and it will not eat too much space... edit : it's done (and committed to git).
  10. Hola, big mess here. The hiscore support is mainly for games which don't save anthing anywhere, it's done at the emu level and is not in the hardware at all, and it saves only hiscores of course. Now the neogeo hardware has a memory card (where it saves the progression, but I don't think scores are saved here), and a permanent ram area, called "save ram", shared by all neogeo games (64 Ko), the bios allocates automatically slots for games here, when it's full the oldest one gets overwritten. I don't know exactly where the scores are saved actually... Some arcade games like cps1/cps2 also have an eeprom but there is no eeprom for neogeo/neocd (useless since there is already a saved ram). It happens... The bioses are selected by number, so if I change the order here I change the number for a lot of bioses and some people might end up in an unwanted bios if they saved their config. It's probably safer to keep this order, even if it doesn't seem very logical. Yeah well I'll keep that in a corner somewhere but won't look into that for now, consumes too much time. Later... What do you call "window frame", it's already in the title bar isn't it ?
  11. I took a while longer to look into this : the fact is that some time in the past, we had some hiscore support for some of these games, actually I think I edited the hiscore.dat myself to have these scores for the neocd games, but it should work also for most of the neogeo ones (not all of them, some have a different memory map). Anyway if you add back this data in the hiscore;dat, it will save you from the eeprom erased, because the hiscores will be reloaded after the game has rebooted (I just tested it with kof96, and it works - I edited the hiscores directly in ram, made sure they were saved in my .hi file, then changed the region in the bios, and the scores got properly reloaded after the reboot). You have the old hiscore.dat which is still on the site there : http://raine.1emulation.com/archive/hiscore.7z if you need to search for some score in a game not in this file, I can give you a few tips to do that with the console !
  12. Ah ah, yeah well still thinking about fixing this page for now taking a little break ! Raine takes a lot more care about the hiscores than most emus I am sure, I have some code in place to survive a reset (f1 key), and even survive loading a save state, but I guess maybe I missed this one, if the bios reads its eeprom and overwrites the hiscores from the eeprom content, this time the scores are lost, yeah ! If you don't have a backup, the scores are lost. The error message in the old version is "normal", there were lots of bugs related to cheats fixed, if you go back, you hit them again. I'll have a look at that, but it's not sure I'll be able to do anything here, even if you give it a default eeprom, it will still overwrite the hiscores with the default content... Tricky ! Not sure there is a solution, but I'll have a look. But not now, in a few days then... (maybe earlier !). edit : I had a look, it was quick because scores are not even saved in the hiscore.dat for these games (mslug, and the kof games). They are just saved in the eeprom, and when you change the region, the eeprom is cleared, all the games do that, even the taito f3 ones, too bad ! There is not much which can be done about it then... ! You can either open your hiscore.dat file in a text editor or look at the github version there, the format is easy : shortname: then the information, so just search for mslug: or kof... https://github.com/mamedev/mame/blob/master/plugins/hiscore/hiscore.dat
  13. ... and uploaded 0.91.4, aka the return of emudx ! the bug fixes are generic but it's really mainly for emudx, not sure they could be triggered elsewhere... on the todo list : - update the linux build, but it won't be on debian this time, it will be arch, and since I never made any arch package it takes time to find the motivation... it shouldn't be hard anyway, it seems to be easier than for debian ! (and the result is a tar.xz, so other distribs can extract it directly and try to run the binary, it should work on most distribs this way). - the old versions page is stuck on 0.64, I had scripts to handle versions automatically, but they don't work anymore since there are 2 binaries / version, should take the time to fix that one day...
  14. Ok, I confirm there is a crash, specific to windows again... sigh, sometimes I wonder why I still try to make this work in windows... ah yes , because most people keep on using it ! Ok, I'll look into it later... edit : it's fixed, both problems, the crash was because this version of sdl-1.2 in windows doesn't behave like the one used in 0.64.16, I guess a patch has probably been lost somewhere, but it's easy to workaround the bug. Then the broken ratio is because of a very old bug in the way the geometry of the screen to display is decided.By the way if you wonder what Mike DX and his team are becoming, you can have a look there : http://div-arena.co.uk/games/view/104/ This is the page about dkong, but most games there are remakes and not emulation, but it's worth a try ! and most of them are playable online !
  15. Oh well, search that in a search engine, there are some pages about this weird code, but at this point, it's your system... if you unpacked the raine package to a directory, then the dlls in the same directory and then launched from there and got this error, then you should check your system, read the pages about that. Hint : raine doesn't use any visual c++ redist files, nor microsoft .net, so you don't have to check that ! Good luck !
  • Create New...