Tux

Bad news your muparser install seems broken, it says it can't link most of what there is inside the lib ! So.... it's starting to be hard to just post something about that but I'll try again. 1) check this package manager you used to install muparser to see if there is a command line switch to build the static version of muparser (.a). If there is, use it 2) and then revert the change in the makefile of the other day to use the libmuparser.a you just generated, check to see where it's installed, maybe it's not in /usr/local/lib but it should. If you can't build the static version with this package manager for some reason then uninstall the muparser you installed with it, download muparser directly from its site (use google), cd to its source directory and type : ./configure --disable-shared --disable-samples make -j4 (if you have 4 cores) sudo make install (it will probably ask for your admin password) then you'll have a libmuparser.a in /usr/local/lib usable by raine, just put back the line in the makefile to use it. EDIT : before doing that, since you upgraded your muparser in the middle of the build, it's very possible that the files using it were not recompiled. So start by just doing make clean and make -j4 in raine directory, it might help.

It's not the same error ! It's what I said, the link doesn't detect the location of your libs so you have to edit the makefile tor that. It's from line 868 in the makefile : ifdef DARWIN LIBS += /usr/local/lib/libmuparser.a LIBS_DEBUG += /usr/local/lib/libmuparser.a so the lib here was forced as a static lib because I had some troube to build the dynamic lib from source, but since you use some package manager to install libmuparser you probably have a dynamic lib. So you can replace the line LIBS += /usr/local/lib/libmuparser.a by LIBS += -lmuparser You are almost at the end of the build, it's the link after that you'll get a raine executable in the current directory. Then you'll have to test it to see if it still crashes ! By the way if you need to rebuild it entierly you can use make -j4 if you have 4 cores in your cpu, speeds things a lot, even though raine is much quicker to build than mame !

Latest version of nasm is 2.12.02, it works, I tested with 2.12.01. It works also with 2.10 and 2.07 and many previous versions. Maybe there is something else here. From the changelog of nasm there were quite a few bugs for osx, so you should use the most recent version if possible. What is your version again ? As I said, edit the makefile to get the exact invocation of nasm, then copy and paste this line to understand why you get the error, maybe there is a space in a filename (which is normally impossible since the sub directories names have no space and only relative paths are given), anyway you have to test this. Never saw such an error, the most likely place of error when building is the link phase because it might fail to find libraries but usually nasm works without any trouble.

Oh là ! You are going to spam the forum if you send the whole build log all the time, only the very last lines matter, here that is : Assembling darwin-sdl/object/68000/s68000.asm... nasm: error: more than one input file specified type `nasm -h' for help make: *** [darwin-sdl/object/68000/s68000.o] Error 1 So I guess something changed in nasm... ! which version do you have ? (nasm --version). I'll try to update mine and check it's still ok. The 1st lines show that everything went ok, osx is called darwin for the build environment... Well nasm is ok for me, use nasm -v to get the version, nasm 2.12.01 here, and I was using 2.10 before. Edit the makefile and uncomment the line VERBOSE = 1 then type make again to see how nasm is called exactly. You should get something like this : Assembling linux-gnu-sdl/objectd/68000/s68000.asm... nasm -MD linux-gnu-sdl/objectd/68000/s68000.d -o linux-gnu-sdl/objectd/68000/s68000.o -f elf -O1 -D__RAINE__ -DRAINE_UNIX linux-gnu-sdl/objectd/68000/s68000.asm Of course this is for linux here and in debug mode, so you'll get darwin instead of linux-gnu and object instead of objectd but the rest should be the same.

Well if you installed all the libs, it's the hardest part in building raine, now all you have to do is build it from source, this way you are 100% sure you are using the latest official version. Just use git clone https://github.com/zelurker/raine.git or download a zip file from the git section. Then cd to the source directory, if all the libs are already installed you should be able to type make and everything should work without problem, it should autodetect everything including the fact you are using osx. If something fails tell me. You can use the very last git commit, there were only fixes committed to git, nothing experimental. The only requirement maybe you are still missing is nasm, well check you have it and if you don't find a binary on internet, it's easy to find. If your build goes well but then it crashes again, then edit the makefile and uncomment the line to build a debug build, it must be the line containing RAINE_DEBUG, then save and rebuild and try again. If it crashes, uses gdb to run it and tell me where it crashes (you'll get the info from gdb). Of course in this case run it in windowed mode and not fullscreen. Good luck !

Ok cool, at least you made it ! For an arm build, raine is full of x86 asm, that's why there is no 64 bit binary, it would break too many things. It can be built without any asm at all, but it's more a proof of concept because it would lack most of its drivers (no 6502, no 68000, some z80 but only games without rom bank switch, which leaves not a lot games). From memory the games which could work in this case : z80 : dkong, puckman and its clones maybe, err maybe not, most of these games use some kind of kabuki encryption which wouldn't work with the z80 c core. Maybe some very old z80 games... forgot which ones though ! 68020 : macross+ (the taito f3 games could probably work by disabling the sound since the 68000 is only used for sound in f3 games), maybe the psikyo driver, not sure (gunbird etc...). As you see it's not really worth it, but I can give you the details if you want !

I am curious : which version of raine on osx did you use before ? Well there is a readme about how to create all the libs you require, but it's mainly for developers, you can give it a try though it's not too complex, but it's clearly not the usual osx stuff where everything works "out of the box". It's here : https://github.com/zelurker/raine/blob/master/README.OSX The one you are clearly missing here is muparser, and it's clearly the most complex one. Tell me if you get something out of this. sdl_sound has probably some problems too here, because you would need the mercurial version if you want it to work right (as it does with the win32 build), but anyway... ! Sorry about this, I had spent quite a bit of time making the original osx build to work "out of the box", but it's really outdated stuff now, and I can't do anything on a mac right now.

I guess you talk about the readme.osx file ? But it was intended for developpers who want to compile it. Osx end users who love to have something working out of the box would have some hard time with that. I think muparser (the lib mentioned in the error message here) was statically linked. But anyway the framework for sdl_sound is nowhere to be found and it was probably a serious problem for osx end users ! Oh well... !

Copy and paste the link to make it work, for some reason the forum stopped at the ! character which prompts for the decryption key. For the lack of compiled stuff for recent osx : not really a surprise, they broke compatibility with some basic stuff in the name of security... We had to disable a lot of stuff in the osx version and use the C equivalent, which shouldn't be noticeably slower on modern hardware anyway, but it's still a hassle. Well even if it's still good hardware I wouldn't want a mac now, too much problem. The only mac I ever had until now was a powerpc mac mini, and I confess I installed linux on it too (but kept osx at the same time), osx was good a the time but feeling too "limited", like a "closed garden" like some people are saying... Thanks for the link anyway ! I'll keep it like that for now...

If you have something to run windows programs on your mac you should be able to run the windows version normally...

Since the guy didn't come back with this decryption key, it doesn't make a big difference anyway, but if he does, you'd better be cautious !

Notice that a binary which comes from nowhere from someone unknown can very well contain bad things for your computer, I am not responsible for this... ! It's too bad to be obliged to think about it, but with all the hacks everywhere currently it's better to think about it !

hum, should I mirror this ? What are the changes from the last "official" build ?

Sorry about the osx build, the guy is "mia", I send mails, they never get any reply. Too busy. And I don't have any mac here so I can't have a look at it ! Maybe he'll come back one day, but not now, sorry !

The artworks in raine were simply to fill the black borders in vertical games ! ssrpg is a horizontal game, no black borders, so no artwork neeeded there. (I am not a fan of artworks which make the displayed picture of the game smaller or which hide a part of it). There are some cheats for ssrpg.

Quite broken with the opengl driver, works with overlays and normal blits though, use the artworks from the extras in the downloads section. Do you mean the yuv overlays ? Well they work out of the box normally, it's just a rendering engine like opengl. What about it ? Works also out of the box when cheats are avilable for a particular game. In this case the "action replay cheats" appears in the main menu, there is also the Alt-C short cut to call directly thsi from inside a game (it's a default shortcut if I remember well). There was a long post in the old forum about how to find new cheats yourself, but afaik it was never used by anyone so it's clearly not worth reposting it here. Same thing, available only for a few games, when it's there you can use it.

Well the guy building the osx version is super busy and usually doesn't even reply to mails but I'll send one to him, you can start to pray... !

Double buffer : it shouldn't happen, but it happens sometimes, a real bug in windows (but there is no such double buffer in linux), I never call the function to swap the buffers but sometimes when returning the gui it doesn't display the right buffer. To work around that in sdl2 they removed the double buffer in windows too by getting entirely rid of the 2d functions, everything is 3d now, with some hidden complexity, quite extreme, but it works. Anyway there is a fix for that for next version, it simply disables this double buffer when using opengl. The shaders : actually I knew about them but I had forgotten, I had a copy of this on my disk from 2013, 3 years already ! The main problem with this is they are using Cg which was a very good toolkit from nvidia (to unify opengl and direct3d), but it's discontinued for I don't know which reason, since something like 2013... The other problem is the multi pass shaders would probably require to use frame buffers which I never used, it would be tricky. This or trying to blindly use their api, don't know yet how easy it is to do... I am going to try to have another look at that later though... And the famous cps2 game with display bugs : afaik it's the only cps2 game of this kind, it uses display interrupts to change the rendering and they are not emulated by raine (and it's the only game using this - with its clones). Add to that that I almost never played this game, maybe once or twice only, so motivation to do that is very low (it's complex to do, synchronize cycles from the cpu with refresh rate on screen... !). So it's unlikely for now that I'll ever fix this.

Ok, reproduced and fixed. It's a very special place to find a speed hack, the pc gets negative if you read it on 4 bytes here (the 68000 reads it on 3 bytes), this is what creates the crash. You can work around it by simply disabling speed hacks in the neo options. I had a look at your freeze while selecting a bios without any neogeo.zip file in your rom directories, it's pretty obvious, but anyway I added some message for this kind of case. I think you'll agree it's not worth releasing a binary for that ! Anyway it's pushed to git. I might eventually have a look a this libretro one day, but weather is too warm for that now, so it might take some time !

I don't know what you did with your setup, but I even tried in windows just now (using wine in linux, but it's the raine32.exe executable, the last one released). No problem at all using unibios 3.1 japan console + your save, can't do anything more here ! video setup, I guess you are using opengl right ?

Sorry I can't reproduce it, what I can tell though is that it's starting to play a new track just after these words, so if you customised your tracks it might be related. The track starting after this sentence is 43 (from the debug messages), see if you did something special with this track. Eventually just move your games.cfg somewhere else and load the game without one, which will make it run with completely default settings here. I used the emubios 3.1 + japan + console, so these are exactly the same conditions (except it's in linux and in debug mode), so it's very likely related to the tracks. Sorry I couldn't help more, I might look at the rest later. By the way it's not that mega asks for a key now, it was saying the file was encrypted and I needed this key to decode it, so you probably did something wrong when storing it there, anyway it doesn't matter now.

Lol, still around after all this time ? Your save got me curious, but I can't check it, mega asks for a key to access the file and I don't have it ! Oh well on my side I've been busy with other things, but I didn't miss raine actually... 16 years of dev, that was amazingly long after all, but I don't even play for now, maybe later... I might take a look at a few of these points though. Forget the fullscreen stuff, that's the reason they created sdl2, too many problems with sdl1 in windows and it's too much trouble to look into this. (EDIT : did you at least try to disable completely double buffer in the main video options screen ?) For libretro I didn't know they had such a collection, the reply is yes probably, but now it's rarely easy. I guess the easiest solution would be to actually use libretro if possible, but even this could be complex. For your savegame it's probably something very stupid, if the emulator just vanishes (and doesn't crash), then it's a specific test which makes it go away, I'll have a look at least at that if I get this key !

Which bg ? afaik, it works... You know there is a very nice bug tracking thing on github where you can post about bugs and be informed about their eventual resolution. there : https://github.com/zelurker/raine/issues if you use it, explain how to reproduce, eventually attach a savegame !

If I ever make a 0.65 version, I'll take it back. For now it would be useless, and it's still unlikely...

Not here, can't reproduce, can't test, can't do anything about it. I can test only with nvidia, and 1 very old intel card without hardware opengl support (it doesn't support any shader but the opengl rendering without shaders work). So as far as I can tell the problem is on your side.