Tux

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 makepkg -si to install the pkgbuild file ? yay is useful to install automatically packages from aur, but here there is no repository so there is not much point in using yay... and edit 2 : the package name has no errors : raine is the name of the 32 bit package because it's the default version, the one which exists since 1998. raine64 is the new 64 bit version using C cpu emulators and C video functions instead of asm. Since they both share the same data files it was a little awkward, I thought about making the data files an external package but since there is no repository it wouldn't be very convenient. It's the best way I found so far...

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 status line at the bottom of the screen : the text won't do a buffer overflow but you can still make text to overlap in such an extreme situation, I won't do anything about that. Not sure to understand your 3rd line, on the status bar ? No way ! But I can expand the string for the long game name, I hadn't noticed it was too short for some games. In my opinion the proper fix here would be to shorten this way too long name, but since it's a mame name here, I'll just expand the string a little... ! Is it to your liking ?

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 version because of the old dlls which were not recompiled !

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 !

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 !

... 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

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).

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.

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

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.

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 !).

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).

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 ?

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 !

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

... 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...

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 !

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 !

Thanks for the info, yeah hopefully these shouldn't affect me here ! They were quite crazy to choose something like that, I don't like utf8, but compared to this it's paradise !

Ok, I'll start by what took me the biggest amount of time, even if it's very specific, the unicode filenames in windows ! So to see the problem you need some non-standard characters in a folder or filename, it's easier if it's on a folder containing some neocd game. I visited the wikipedia page about "the king of fighters", and got the japanese name of the game from there : (ザ・キング・オブ・ファイターズ 京). So just copy and paste this at the end of the name of such a directory. Then run any previous version of raine : the directory will be impossible to find ! It might be possible to do that with just 1 character, and less exotic, but I am not sure about this, and I am sure about the japanese name ! The reason is because microsoft has some inherently broken api to access its files, if the filename contains some non-standard character for the current code page of the system (which can't be utf8 of course !), then the usual functions to access files return a filename which is absolutely unusable. So the old versions find nothing when trying to access the dir, and forget about it. I am not going to tell the whole technical solution I found, if you want to see that, go to the git page. But shortly, the file selector now uses windows native functions to get the file listing, but since it still needs a standard file name for the file operations, it uses the short filename when available, using the usual long one just for display in the file selector. This means the workaround will work only if your volume has some short filenames, but normally it's the default for any volume created in windows - I created one in linux and used it in windows, in this case it didn't have any short file name, and it took me quite a while to find out how to reactivate them for this volume ! Anyway, after this you should see something for the directory if using this version. If you really want to see the Japanese characters in the gui, you'll have to replace the Vera.ttf in raine's font directory by some font containing these characters. All the biggest fonts in your windows fonts directory should work, assuming it's not too old. msyh.ttc for example, just copy this one to fonts/Vera.ttf in raine's directory and you are done (I prefer the look of Vera, but it has no japanese chars !). (difficult to copy that using the explorer because it doesn't show filenames from the fonts directory ! Oh well, you can always use the very outdated cmd.exe for that, dir /Os to have the biggest files, then make your choice and copy !). Except this big annoyance, the other changes : - fixed again some cheats, this 0.91 version is mainly about that after all, there were some bugs for kof98 particularly, I found quite a few which obliged me to redo the conversion for most of them. - added some new command line switches : -nb, -wb, -rp, see raine -h for details. - Fixed the display when starting raine without any gui in opengl (-n switch). So that's quite a big one, once again... I hope I won't have to deal again with these unicode characters at least, I couldn't leave it like that with some files impossible to access, but it's a mess I prefer to avoid otherwise ! Still the same page : http://raine.1emulation.com/download/latest.html (oh by the way the previous versions had some useless xml files in the scripts directory, useful only for conversion, they are gone now, so if you unpack this version in the same directory you can remove all the xml files in scripts).

Sigh. It's used like this : raine -geometry 800x600+10+10 -n 1944 (for a 800x600 window placed at 10,10) As I already said, passing a zip, or a 7z is to read neocd games, not standard roms, this message makes sense in neocd only ! I added a few command line options, -rp to set the 1st rom path assuming you never ever use the gui to do that, which is rather weird, -nb to have no border, and -wb to have a normal window with border, useful since -geometry removes the border (better like that when you want to place precisely a gaming area on a tv where the borders of the image are invisible). They will be in next release.

There is a problem with windows that I discovered lately, but usually it doesn't happen with a simple character such as ' but you never know with them... The trick is that when you have a character which can't be represented with an 8-bits representation, then you must access it with some utf16 representation specific to windows only and absolutely not portable. On the other hand such characters are usually represented as utf8 in other OSes, but it's just impossible in windows, no utf8 support (or almost none, there is a very basic one for the console only, but nothing internal). So... ! if raine stumbles on such a file, it will get an unusable filename for it ! Usually I see that by adding some japenese characters to a normal filename and even like that with some japenese characters the file can still be accessed normally, but not with all of them apparently. A big mess from microsoft, as usual. I considered the idea to try to access the files as wchar* as they call this insanity, but the problem is that it changes all variables in the program which depend on the filename and since it's not portable at all it will create a big headache in linux to say the least ! So the idea is to stay with the basic representation for now, and keep it for as long as possible. So maybe your ' was not a standard ', windows changes that sometimes to some weird character which creates some problems when reading that in another os... ! Well no luck in this case I guess. I don't know anyway to avoid this utf16 nonsense in windows, and I don't want to break compatibility because of it, so for now the best solution is to rename the files when you find something like that !

Probably because you passed a zip file on the command line, so it assumed it was a zip containing files for a neocd game, ipl.txt being the main one if it doesn't find it, it stops here. You are going to have to learn at least the basic, I can't answer all the basic questions !

Yeah yuv overlays are disabled in 64 bits because the color conversion is done in mmx asm, very fast, but 32 bits only. You can also try the windowed mode. -fs 0 with -geometry. Reminds me that I should add a command line option for "no border"...

-g is optional but is not followed by a path, but by a game name. If the game is the last parameter then you can forget -g A path is used only when passing a neocd cue or iso file. Now you are out of luck there seems to be a bug with opengl when using -n Meanwhile you can use -video 1 which is working with -n, or wait, but I don't plan to fix it just now, sorry, or try to patch it yourself... !