Tux

Ok, he replied by mail only for some reason, the cheat is not from him nor his team, but he found this old comment about it anyway : ""Enable this selection cheat as your chosen characters are walking into the ring. If necessary pause the game and select the character you want." I didn't test this, but it should work normally... ! EDIT : weather being way too hot currently, I took the time to test this anyway. The location of the cheats are good, but not the 2nd number which gives the character. Here is what I found : # 0 : hulk hogan # 1 : ultimate warrior # 2 ; Jake the snake # 3 : Big BossMan # 4 : Legion of Doom # 5 : Legion of doom again ? # 6 : Sgt Slaughter # 7 : Mr Perfect # 8 : Earthquake (unreadable at presentation !) # 9 : million dollar man Cheat09 = 1C0607:04:00:00:Play as LOD Char. 1 Cheat10 = 1C0191:05:00:00:Play as LOD Char. 2 So if you use these cheats, you get only 1 big logo for the 2 legion of doom chars, and they are slightly different. I guess that's what you were looking for... !

I guess there is a specific moment to enable these 2 cheats. This is probably the game which got the most posts on the forum and one I don't really like.. ! Anyway I forwarded the question to Stephh who was the expert for the cheats, I don't guarantee he will reply, and even if he does, it will probably take time !

I have read that apple wants to remove the ability to run 32 bits applications from osx, maybe it's already done ? In that case you can tell bye bye to raine, there will never be any 64 bits version of it, too many things to change for that. Best options in this case are either to use something in osx to run windows programs and run the windows version, or to run it from a virtual machine (supporting opengl, most of them do now). Anyway the readme was actually updated 7 months ago, that's not that old, the latest version is here : https://github.com/zelurker/raine/blob/master/README.OSX It was not using frameworks anymore already, but if your brew doesn't support 32 bits binary anymore, you are screwed. I tried to make some binaries for osx but sadly the osx tools tie the binaries with the osx version they were built on, and the osx version I used was already old (sorry I don't have any real mac around, using a virtual machine for that, and it was heroic because apple doesn't want you to run osx from a virtual machine running on anything else than osx, so it required some unofficial patches that I was lucky to find !). Too bad homebrew removed support for 32 bits binaries so quickly it was working very well and was easy to use. I can't do much for you in this situation. Post something to homebrew forums to tell about that if you have the time... there might be a way to install a version of homebrew which still supports 32 bits binaries and in this case it might be your easiest solution. Good luck and please post here if you find a solution !

An outstanding bug report I just received from the git interface (by mail), sf2 inputs lacked the punch inputs since the addition of input combinations 1 year and a half ago ! it was just 2 characters to change to fix it, but it's quite outstanding ! I am currently lazy so it's fixed on git and those who compile their own binary can use the fix, but is it really useful to make a new binary for this now ? (1 year and a half before someone noticed it, I guess it can wait some more !). Anjyway reply to this thread to complain if you really want a new binary !

The videos on youtube don't tell if they were recorded from the arcade or from mame, so it's hard to tell but assuming this one is from the arcade : ( video sjv7lpp5nTU in case it doesn't show in this quite broken forum !) https://www.youtube.com/watch?v=sjv7lpp5nTU I guess the difference you are talking about is the sound which can be heard while seeing the astronaut in the 1st images just before zooming on the planet, right ? Anyway the intro is the place where we see the most the bad zooming emulation in raine, I had hoped Antiriad would finish this one day but he lost all interest in this long ago (about 17 years ago actually !). Well the code is quite different if you had a look at the code for raine in the git section, we still don't use the c++ interface for one, and the update function uses 2 levels of while loops, I'd admit your code is clearer, there was some hasty testing in this area in raine and nobody never tried to clean things up... I am not sure I want to risk a rewrite just for this missing sound, I'll think about it...

Well there is no issue with the f3 sound afaik, but ok send the file, I'll take a look (we shared the one in raine with mame but it hasn't been changed for a very long time and I doubt the interface is still compatible, but anyway, send it !).

Good news at least ! Stupid apple to make this kind of restriction, there is nothing specific to 10.12 in raine of course, so it's done by the compiler... ! Anyway happy new year then, even if it's going to be hard probably !

Not sure I have the motivation to do that now, mcu stuff is pretty tricky usually, but thanks for the info anyway !

It's a good old build where you drag directories and it just works, contrary to all the mess of last year. A kind of christmas present ! It was built on Sierra, it might be compatible with some previous osx versions but I didn't test that. You'll find it at the top of the mac os page. You need the frameworks linked from the page to make this version to work. There are a few osx minor fixes in it : new default key for fps counter f12 instead of f11 since f11 is reserved for the finder, fix to detect mounted directories in the file selector, included m68kdis and dz80 since it's difficult to install them in the current osx version (usefull only in the console anyway), allow to use opengl when non accelerated (actually probably only usefull when running from a virtual machine !). Also this version returns to using the assembler version of the video core and the 68020 emulator, which is more like the raine spirit ! Also I wonder if it's worth updating the windows version, a small fix for kof98 for mer-curious in it, the fix to force the double buffer setting in opengl, the ability to setup the locations of m68kdis and dz80 for the console... Most of the previous changes were for osx, but there are a few details which could be usefull to other operating systems as well... The updated instructions to compile raine in osx are there.

I did wonders with my vmware image, raine osx now uses the asm code like the linux and windows versions, and uses frameworks anybody can install by just draging them to the frameworks directory like the good old osx versions... Just give me a little more time to upload this tomorrow (it's 3am now, I think I am going to take a break !). Also I have put a few osx specific fixes, it has been a very long time since I was able to test this and there were a few small fixes to do. If you still want to compile it yourself anyway I can try to help you but it will become useless after this. For your message, it means there was a mess between 32 and 64 bits symbols, it's not clear which symbols since TFont_ttf::dimensions is part of raine and should not be affected by this, maybe you need a make clean ? Anyway wait a little more and you'll be able to just install this by draging stuff. For info for those who like compiling stuff : it's still based on the libs from homebrew, or the brew command in osx, very well done, I just use a script to convert these libs to frameworks to be able to distribute a program usable by end users without having to compile stuff themselves... ! Sorry for the long delay before being able to fix all this mess, I just didn't have any access to any osx version.

You should NOT define CC or CXX, it's done by the makefile where needed, and 64 bit is not supported except as an experimental feature (almost no driver can work in 64 bits, and almost no cpu emulator is supported). It's been years since I didn't compile anything on osx, it seems opengl linking must be explicit and not implicit, anyway... So a last try : We'll need to take a back a few frameworks from the LIB line, and change it completely in fact, so edit this part : ifdef DARWIN # Official SDL1.2 frameworks (SDL / image / ttf) in /Library/Frameworks CFLAGS += -I/usr/local/include/SDL/ -DDARWIN LIBS += -framework SDL -framework SDL_ttf -framework SDL_image -framework Cocoa -framework OpenGL # SDL_sound is statically linked from homebrew as gettext, libpng etc. LIBS += /usr/local/lib/libSDL_sound.a /usr/local/lib/libintl.a -liconv should look like this : ifdef DARWIN # Official SDL1.2 frameworks (SDL / image / ttf) in /Library/Frameworks CFLAGS += -I/usr/local/include/SDL/ -DDARWIN LIBS += -framework Cocoa -framework OpenGL # SDL_sound is statically linked from homebrew as gettext, libpng etc. LIBS += -lSDL_sound -lFLAC -lintl -liconv and then remove this block, or comment it out (a few lines below) : ifdef CROSSCOMPILE LIBS += -lSDL_sound -lFLAC # -lmodplug else LIBS += /usr/local/lib/libSDL_sound.a /usr/local/lib/libFLAC.a /usr/local/lib/libsmpeg.a endif #CROSSCOMPILE and this time everything should work, assuming you have correctly installed all the dependencies... good luck again ! EDIT : I finally found a usable vmware image of osx, from Italy and in italian, but I managed to change the language ! It's a sierra image, works well but no 3d acceleration so even if I decide to use it my testing abilities will be very limited ! Oh well this is kind of risky I can't be sure bad things have not been put in such an image, the kind of risk which could be avoided if apple accepted that vmware and virtualbox officially support osx... I'll see if I use it or not to update all this mess...

Tsss, you lost the -DDARWIN flag apparently ! Ok, so undo the change I told you to do in the previous post, I told you to put ifndef DARWIN so just put again ifdef DARWIN and then comment out the line related to frameworks below, this one : LIBS += -framework SDL -framework SDL_ttf -framework SDL_image -framework Cocoa -framework OpenGL and then comment out this one too : else #DARWIN so you'll have the darwin specific flags + the generic ones, and without the frameworks. It might have been easier to just install the frameworks, that's probably what the previous person who posted here did, anyway now that you have started on this, we'll see where it leads ! this is a blind change since I can't test it, you might have some other problems when linking with this, we'll see later. Eventually edit the makefile to uncomment the line RAINE_DEBUG = 1 it will make your compilation much faster, and use make -j4 to compile if you have 4 cores in your cpu. You'll need to run a make clean again after these changes, and restart the compilation from scratch...

I didn't say that in the thread already ? The makefile is written to use specifically a static version of libmuparser.a because at the time I didn't find how to build a shared libmuparser for osx. So... if you want to use a more standard muparser, you need to edit the makefile and replace this : (starting at line 868 normally) ifdef DARWIN LIBS += /usr/local/lib/libmuparser.a LIBS_DEBUG += /usr/local/lib/libmuparser.a else LIBS += -lmuparser LIBS_DEBUG += -lmuparser endif by this : LIBS += -lmuparser LIBS_DEBUG += -lmuparser ... and for your framework not found, I suppose you followed the instructions from the readme.osx file so you got an installation without any framework, right ? This setup is a real mess, the guy who did this stopped in a hurry and never came back, so he didn't even edit the makefile in git to remove the frameworks... anyway, then all you have to do is replace this ifdef DARWIN # Official SDL1.2 frameworks (SDL / image / ttf) in /Library/Frameworks (around line 1072), by this : ifndef DARWIN This is a quick fix to force it to use generic unix rules here for darwin, which should be fine for what you have. Tell me if there is another error after that ! Good luck ! I got a new laptop lately which might be better at running osx, at least in a virtual machine, so I might be able to test all this again... This build should really be more osx like, you download it, drag the icon, and it works, very far from that for now...

!

Re-read what I posted, you did something obviously wrong with muparser, probably linked to this "universal" setting, you are the only one who can fix it !

It means what it says, some symbols found while compiling are not found while linking. Maybe it's because a lib is installed for 64 bits only and it means 32 bits here (i386 architecture). Anyway it's your job to find the bad lib, it's probably muparser here. If you installed it from source you might want to make export CC="gcc -m32" export CXX="g++ -m32" and then re-run configure, make clean, make -j4. to force a compilation for i386 and not amd64. Good luck ! Sorry forgot you were building for an amd64 system, which makes thinks even more awkward. EDIT : and it's probably related to this "universal" option in the package manager you used. I think you just passed this command line option without editing the configuration file as it was adviced, well it was probably not such a good idea. Now I never used this package manager myself, so it's clearly the limit of what I can say about all this.

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