Tux

cpu frameskip : it was a way to slow down the game before having something to tune precisely the fps, now using the fps setting in game options is probably better. benchmark : if using opengl just disable double buffer in the opengl options, the limit framerate of course, and you are good to go.

4-9 : can't reproduce. daioh pause -> cpu at around 6% for raine, 100 being 1 core fully loaded. Tried the windows version in wine too with the same result... 4-10 : not at alll normal, raine is super efficient on the cpu, it's more like cpu in power saving mode at 1 GHz and using 2% cpu power... ! No idea what causes this, never seen or heard anything like that. I just booted in win10 to make sure I get the same results as in linux for that : yes of course. I don't have any xp boot so I can't test xp. You can eventually try to play with the UseRdtsc seeting in the config file but it shouldn't change anything, the rdtsc is only used for the profiler display (f11 key 3 times), there is an sdl timer for the synchronization now. I have run it on quite a few computers now, and never seen anything like that until now... edit : after checking in the code to refresh my memory on this, on its normal behavior it goes explicitely to sleep waiting for the next frame to start which makes cpu usage super low. Start by checking the profiler (f11 key until you see many % numbers in game). The last one, Free should always be the greatest one. If you see it go down while blit goes up, it means your screen has a refresh rate < the game refresh rate, but normally this should not put any load on your cpu, video drivers normally just wait without loading the cpu in this case, unless you have a problem on this side. You can also lower the game refresh rate in this case, 59 fps instead of 60 can be enough for a monitor with 59.25 fps for example. I can't say anything more on this, you'll have to investigate, I can only say it's not normal at all. A last thing though : raine uses only 1 core, it was made for old cpus so there is not much point to use more than 1 core considering its speed.

3-2 : 2 very stupid bugs when rewriting stuff in a more compact way... ! 3-3 : it's about loading a game which has no region after one which has some. Amazing it got unnoticed for so long, you are good at finding these bugs, you probably spent quite a lot of time on this... ! Graphic bugs : too long to fix, sorry, it's known raine has some graphic bugs on some games, lately I fixed syvalion (controls and zoom effect on the title screen), but I don't do that often because it takes a lot of time. Well since I don't kinow the arcade version of darius 2, and I never played it on any other emulator, I never noticed anything, but it's possible I guess... ! Here too, too long to do now, we'll keep that somewhere for some other time... 3-9 : yes I have sound, and from the very first seconds (music during attract mode). 3-11 : More detail ? Is it really obvious ? 4-1 : you need to actually run something to get some info here ! You weren't really intuitive on this one... ! 4-2 : I'd say that sometimes you loose the background for some unknown reason, yeah I know, hard to track and to fix, maybe one day... 4-3 : ah yes it keeps on fixing the aspect ratio when resizing the window, forgot about this. It's more intended for the difficult fullscreen modes where you want to get rid of these black borders at the cost of some quality. 4-4 : Normal blits are for fullscreen, even if they can work in windowed modes they are not meant to be used in windowed modes, it will work but just don't resize your window all the time then... ! 4-5 : the shaders never resize the window ! The hq2x shader produces an hq2x output but then it's resized to fit the window, it's your job to choose a mode where it makes sense, but anyway you usually get a better zoom wihtout even caring about the mode. In this case yeah the window should probably resize to its previous size all the time, the easiest fix is to always have a window big enough so that it won't resize. This kind of thing is a pain to fix, especially with sdl-1.2, switch to sdl2, one day, in distant future... ! 4-6 : I'd say it's more a windows bug related to sdl-1.2, it works fine in linux, don't expect a fix soon, I hate tracking windows bugs like this... ! 4-7 : ok, there is really a problem here, it seems to use the setting from normal blit to adjust the window size when in opengl, it shouldn't touch the window size at all in this case, I'll try to look into it... ! edit : ok, it's done, now the window is resized only when using normal blits and choosing to set the mode automatically, which should always have been the case, sorry ! Actually this code is some old code from allegro adapted to work with sdl, and it's quite messy. Anyway, much nicer to use when in windowed mode now.

3-1 : all fixed, these were all very old typo errors in the dsw definition, for the cps1 one (mtwins) it was because my converter didn't like a comment which was added in the middle of the definition and it got lost because of it. Very old bugs, I suspect that at a time they were not making the emu to stop because it's hard to believe they would have gone unnoticed for so long, probably an effect of the not-so-new dipswitches dialog. Much later for the rest, need to get out now !

1-5 : I don't know how to detect the default language in windows. Raine is multi platform and each platform has a different way to do it, even osx which is an unix doesn't do it the same way as linux (although it's rather similar). But in the case of windows you have to call some windows api function for that apparently, no way to find it from the environment, and since I almost never program the windows api directly I have no idea which one to use. I would need a real windows programmer to take care of the windows version, but again, nobody seems motivated enough for that. So you'll just have to choose the language in the gui, I added the choice for italian now... 1-6 : it's a samurai spirits rpg option, only when translating, if you see it anywhere else, report... and you shouldn't try to use it, it's some really low level stuff. 1-7 : yeah I know, fed up at editing the year all the years so I just stopped, don't complain, I am still here anyway ! 2-1 : not for me, and probably for lots of other people, I only tested on 1 game though, I guess something is broken in your cue, send it, just the cue file, you can use mail for that (or send a link to the whole package eventually). 2-2 : U key usually, check the raine keys, it's associated with "Test"... ! 2-3 : default key is LCTRL s, I even removed my config file to check, reported as LCTRL in the gui and working with LCTRL, and indedd if you put RCTRL instead, it works. 2-4 : yep it's for those who can compile only, reserved to debug builds, you wouldn't know what to do with this anyway, and the cause of the crash is not always there, most of the time you need a debuger for that. 3-1 : if you had a proper console (like the one from mingw, but you are not a dev so I guess it's normal), you would have seen an error when raine quits : "unknown extension 0", it's a collision with some new way to write dipswitches, thanks for finding this one, I'll need more time to look into it... later again then !!!

I didn't really understand what you meant about the logo, your version has more colors which creates a slower color scrolling, it's nice but I also like the old one (faster scrolling = more "lively"). Both are good... The ascii version is a good idea, I never tried to create one... But I wouldn't want to use that in the exe though.... For the translation, yes all the strings are not translated, because I used some script to guess which strings to translate, and they are now encased in _("...") in the source, all the strings which have no _("...") are not translated (and there are some strings which must not be translated). Year : 2006 is just the 1st initialisation of the year field, it's overwritten later by the real thing... this one should not be in the po file... ! That's where the fact that you can't edit the sources is too bad, here you could have added the _(...) where appropriate and then propose a patch for that... ! About categories I am thinking about ditching this entierly, I had never any feedback on this and it can make things awkward when handling a lot of game drivers to update and you don't have the information... Getting rid of it is probably the easiest fix here. For controls / language in the dsw, I don't see why to change the string heree, it's still about controls and language even if it's in the dipswitches... lol for the disappeared "pause when focus lost", I never used this because on my system it thinks it looses focus when switching from gui to game mode in windowed mode, maybe I should add a few frames of lost focus instead of just 1 to make this useful. Anyway I took it back, this dialog is a little crazy taking settings from everywhere and it lost this one when I added the "no hud messages"... ! For the command line in windows I guess it probably works anyway but I can't test it here, you'll have to wait some more for that... ! Later again then ! edit : a last one, for the sprite viewer for vertical games, just switch to fullscreen !!! By the way this feature is just a curiosity for most games, it was added when trying to translate "samurai spirits rpg" neocd game, and that's the only game where it can be useful... but you can use it on any game anyway... After testing quickly in wine : of course the command line works even in windows, maybe you just get no output in your console, in this case use it like that : raine32 -h > output and then check the output file. I might test this later in a real windows, but I am sure it will work. For the .po, you decided to create it without asking anything, good, but normally .po files are created from an initial raine.pot file which is created automatically from the sources using some commands. Then you rename the .po to something related to your locale, edit it, and then pass it to some other commands to generate the .mo file which is actually used by raine, this last pass must be done by the makefile and not by any other tool even if you can use another tool for testing, because these files should be generated on demand. That's why there must be no error in this last pass and why I had to edit your .po. I can keep the ordering of course, if some people want to take the italian .po file as a base to create a new one they'll get something to start from, but the tool which creates the default .po file doesn't care about ordering, it just adds a comment to say where the string comes from in the sources, that's all... ! 1-4 : well I tried to load 1941 first, got the option to appear in the menu, then loaded buble boble, and the option was gone... you'll need to be more specific then !

I have fixed the po as I said, you can grab it from git to see the differences from your file by yourself... Later... For the old dos link, in case you are interested by the fixes inside I am afraid I forgot them completely, this was 4 years ago ! Maybe some of them were merged into the main source, I am not sure about that. Anyway yes the download link is broken for some weird reason, they seem to have installed something to limit the bandwidth I would say, and as usual it seems to fail miserably... ! Sorry I don't have a backup of this specific file (at least none that I know of !), and I can't retrieve it, even using the ftup access I get the same error, the download begins to stall at about 66% and then it takes forever. It seems to progress though, but very slowly, I'll try to keep it to see if I get a usable file in the end.... Yeah I guess I should migrate all this to a saner place one day, but I miss a free host, you could do that on sourceforge once, but they limited so much the shell access that it was crazy to handle it. Oh well... ! I am at 75%, maybe 1 chance left ! Sorry it's totally broken, it never ends and fills the file with crap. Well I guess we can only wait at this point ! edit : here is a link to the very latest dos version (0.64.16) : https://mega.nz/#!3JkxWIoA!DEoZ2SwyylRWYLcpaOVCwZaaNvqBavRC6zSTW-xCikc there is only the exe inside, it needs at least raine.dat from a previous dos installation. And it includes at least the change for vsync discussed in september 2015, that is, there is an explicit call to vsync for dos now (which probably makes things slower, but it also probably works better now that the allegro hacks are mostly lost).

Post too long, it will take me ages to reply ! I already replied to the private one though... And added the italian locale to github, and tested it, it was a few errors in the po file, I wonder how you wrote it, usually you take an already existing .po from an other language for that but oviously you did it differently otherwise you wouldn't have all the errors. Anyway it's fixed and committed... it's working, I guess you can't compile a binary and would like to see it in action ? Too bad these locale files can't be added without a recompilation, and there was a bug added recently there anyway... ! For you super long changelog, it's just some extracted stuff from git, right ? Well the thing about changelogs for users is that you need to filter a lot of things from this to make it usable by a normal user, the git changelog is for developpers, but I am usually too lazy to create a proper one for users, I just summarize things quickly in the release post. Anyway I guess it could eventually be useful... ! By the way the git changelog doesn't have all the releases, far from it, it started sometime in the sdl version so it was already > 0.43. For the link to the dos version : where did you take that from ? You need to download it from the download page so that it works. For the rest : later !!!

Just tested raine in osx 10.13.3 : the old binary which was built with 10.12 and which is still on the site (0.64.10) doesn't work anymore, apparently it's a problem about security with self-modifying asm code... and since apple officially abandons 32 bits binaries, there is no point following them in their madness. In theory raine should be buildable on 10.13, except that brew already removed all its --universal options and even trying to edit the formulas to add the option back fails with an error while trying to build sdl-1.2 ! + osx 10.13 becomes heavy and requires a powerful setup to run, while raine is light and runs everywhere ! So no more support for osx for the time being, I might eventually try one day to make a full c version of raine, which could run on any cpu and in 64 bits, so it would run even on this crappy osx, but as Antiriad says, raine without the asm wouldn't be exactly raine anymore... so I am not sure at all about this, plus it would take a lot of time, so it's probably going to remain a dream for now... ! It would be nice to be able to at least update the binary to 0.64.16 for osx 10.12, but since brew dropped the universal option already it becomes hard, it's possible but it must be done from scratch, and since I have almost no feedback at all for osx, it's not worth the trouble, clearly.

A forum post to ask if you can send a pm ? what a waste ! Send your pm or post it publicly ! The big difference by the way between the long past where it was comparable to mame and recent years is simply that I was alone to try to keep it alive for way too long while mame team was getting bigger and bigger.

Yeah as you say, maybe all this has aged too much now, 1998 till now it's been 20 years, and it was getting crazier and crazier to be alone on that, it was time to retire for sure ! Oh well don't worry also on your side, for me compiling the dos version is easy the tools are already installed, the hardest part is to upload it actually, the server here is quite troublesome ! For the job, no it's not ideal, far from that, but it's out of the subject anyway ! Anyway it was good talking to you, thanks !

Not sure, dos version has become increasingly difficult to test because the only way to test it on modern hardware is through dosbox (or dosemu which allows to run it at the real cpu speed instead of an emulated one), so it's not ideal to appreciate eventual speed changes, and there is no problem related to the emulated sound card in dos box too... ! Also I never had enough feedback, only 1 user in this forum to report about the dos version, and even in the previous one, posts about the dos version were more than rare. I remember one from India which made me happy though ! Neocd was never made dos compatible because having mp3 decoding in dos is messy, but you can have neogeo assuming you have enough ram for that, there are games which require more than 64 Mb of ram, and it's quite rare in dos ! So in short, you should test and see by yourself. If you can compile your own one then you have more options, you can choose to use seal or allegro for the sound, and you can choose for which cpu to compile (although it won't make a big difference since raine core is in asm... !). I have added a few fixes recently while testing in dosbox : a crash in the about dialog if the history for the game was too long, happened with bublbobl for recent versions of history.dat, and another one if you had a recent cpu with a very long name (like "AMD Ryzen 7 2700 Eight-Core Processor", which is really the name of the cpu !). If you are interested by these and can't compile your own, I can make a very last dos binary !

I have a mac mini, but from 2004, the time when apple was really good (and Steve Jobs was alive !). I don't use it anymore of course, it's retired at my mother's now, it has only 512 Mb of ram and it shows, + it's a powerpc... ! For all the crap displayed, it's not a surprise, it's a very long standing bug in the server configuration which never recognized correctly the 7z files. Clearly there is more than 1 web server to serve the requests, and not all of them are affected, so depending on the server, you get either a download dialog, or some crap on screen. It's always been like that here... ! Later then... !

Ok, just posted a 0.64.16, see the git page for the changes but they are mainly what I said. Sorry for the delay, it was because passive mode didn't work anymore with the ftp, and I had forgotten how to deal with this... ! I had to update the conf for that and was not very motivated to do it. I only uploaded the windows binary, I don't think anyone else would need something else. By the way osx has gone crazy, deciding to stop supporting 32 bits binaries and even opengl, so I won't ever worry about osx anymore (that's a good news after all !). In case you forgot, the download page : http://raine.1emulation.com/download/latest.html and the old versions were updated too there : http://raine.1emulation.com/download/old-versions.html by the way there were some fixes for the dos version too, but it was only because I was in the middle of some crazy testing, I hope the dos version is not useful anymore to anyone... ! And merry Christmas to anyone reading this !

Lol, you are alone, this site is almost dead I think ! Oh well, I'd love that more people could build it, it would be easier, with every thing installed it's : git pull -> update the sources make and that's all, eventually a make install if you want to install it in the system in linux, otherwise you can play directly in the directory, much easier for everyone including me... Ok, I'll try to post a binary anyway this week-end, it will be made with an old gcc though, but it shouldn't matter since raine's core is still in asm...

There were quite a few fixes since the last released binary, and even "fairy land story" which is now playable (and it was way harder than what I had anticipated, a very old game, but not an easy one !). There are no major fixes anyway, see the git log and post here if you are interested ! The git log is here : https://github.com/zelurker/raine/commits/master (these are mostly fixes for me and those who might be interested by the code itself, just posting here to make sure there is nobody left interested by a binary ! )

Windows specific, fullscreen with double buffer, and it doesn't happen in my old windows 7, didn't test it yet with my new computer which has win10... Anyway a possible workaround is to play in a fullscreen window, there is even an option to use a borderless window if borders are a problem. Or disable double buffer, there might be some tearing but it's rather rare in most games. Sorry, not enough people programming raine !

Nope, still using a ps3 sixaxis controller here, it also can be used like an xbox controller using some software converter for all these games which know only about xbox controllers (I guess microsoft used something to convert games from consoles to windows, but doing anything to change the controls... !). It works well, one of the best part of the ps3 !

2 years, wow ! Raine is not really portable in its current state, using too much asm for that. It's better than before though, you can choose to use a c version of the video functions now, and there is a partially working z80 C emulator (not all the functions are done so it can't work with all drivers). But you would still need some 68000 C emulator, so it's possible but not easy, you would have to be very motivated. I gave the idea a try some time ago, maybe 2 years ago actually, to experiment with emscripten and to see what could be done with it. I got some unexpected problems with sdl first, so you could add to that 1st convert raine to sdl2... ! So it's quite a daunting task, I gave up for now. I'd suggest trying mame for android for this, they use only C so they are portable at least. But I am not sure an emulator is a very good idea on some android device, it would eat the battery very fast, and virtual controls on screen are probably less convenient than real controls...

It's an old raine, there was a bug related to sf2 inputs fixed in 0.64.15, so use 0.64.15 ! I have updated the linux binaries not too long ago so it shouldn't be a problem. For the line where it says "unknown key", it just means that some not recognized key was saved in your configuration for some reason, just click on this line and choose a key / joy button when prompted to. But you are missing some inputs on this screen, that's what was fixed in 0.64.15 !

Not that easy to do. I'd prefer to update the gui first so that it can be displayed with opengl, currently it can't, it has to change the video mode when going back/from the gui, and it creates problems. Anyway yeah this thing should be updated too, eventually ! But these art files are more for vertical games where there are huge black borders, shoot'em ups usually, here it was never a problem for me. I am sure you can get used to this !

This is the result of my experiments with docker, I finally built a debian i386 image in my gentoo using docker and used it to update the raine package. Signing the package was a mess because of pinentry mysterious "permission denied" messages, but oh well, finally it works... As a surprise, the binary seems to be totally compatible between debian and gentoo... It's an updated thihng by the way, I played with the source again while we had a lot of rain, so there are toaplan1 fixes inside, console fixes, and fairy land story becomes fully playable with sound (hacking its 68705 with the tools to recompile it was insane, but it's another story... !). I should also update the history package one day because I made a script to make the recent versions much smaller, but I lost the files to rebuild it and I am too lazy to rebuild it from scratch now. Oh well, I don't expect to have any feedback for this, but it should work. The displayed version is still 0.64.15, even if it has more things inside ! Ah yes I also included a hack to skip the slow display of the copyright page in ddonpach. tnzs sets have been reviewed, some dips fixed. For toaplan1 : vimana got sound, graphics alignment and priorities fixes for most games, and added some clones for demonwld and outzone (some useful ones which really change the game !) And some small gui fixes as often... ! I didn't actually expect to release this now, but since the debian package build succeeded, here it is !

it's just that raine already supports many cd formats, if this one added something like allowing to have smaller games on disk I would add it, but on the contrary they are probably bigger than standard images, espeically if using an iso + mp3 format. In fact mame did this because it's easier for them to handle chds everywhere. For me it doesn't add anything except eventually problems if I wanted to support this !

Ah yes I had heard they wanted to convert the cds to chd. Yeah indeed I don't really see any reason to do that. If someone wants to do it, patch welcome though !

Never heard of a chd for neogeo. At the time, the cdrom was all the rage, and it's called neocd in this case, and it's emulated already...