Tux

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.

Try this : video options / use double buffer (ignored by opengl) : set this to "never" Then you can eventually use the opengl double buffer if you want : video options / renderer options / double buffer And then tell me if the problem persists for you in fullscreen ! (didn't know the borderless rendering was broken in windows sorry, can't do anything about it it's sdl specific).

Better workaround : use a fullscreen window ! Actually I tested fullscreen only by using the ctrl+return short cut while in windowed mode and no problem there, so just avoid the real fullscreen, you shouldn't miss it. There is even an option to have a borderless window if borders are a problem. You can also try to force the directx driver for windows instead of the default windib (not sure it helps, but maybe). The slow mode changes were only in windows, in linux you don't see much difference, but it's better to avoid useless mode changes anyway.

Wiow, 2 releases in 1 week after 2 months, I would not have believed that ! Anyway these are only fixes, and some quite serious : - all the neocd games which loaded some data during the game were broken because of a fix for garou (neogeo). Yeah it's quite big, I didn't play any neocd game in 2 months, I really needed a break there ! - Gui : windows doesn't need a colour depth change anymore, and the mode changes should be invisible - while cleaning up the taito f2 driver (yeah very old stuff, never completely finished), I noticed you couldn't access the pulirula dipswitches, so it's fixed too. That's all for this time, the most serious bugs should be fixed so it should be more quiet for a while now ! http://raine.1emulation.com/download/latest.html

greatxerox : confirmed, thanks for the info, it's probably recent I played the french version for quite a while. Please post in English in the forum so that the others can read it ! I'll have a look at that asap, probably something very stupid. EDIT : it was again because of the garou fix, it's fixed now.</p> ramonz: thanks, I didn't know that, I don't test much in windows, and in linux the desktop isn't affected. I used 16bpp for the gui only because it uses standard blits so it's faster. I guess I can leave it in 32 bits to avoid this. Making an opengl gui would be even better, but it's not that easy, so I'll probably just switch it to 32bpp for now if the desktop is in 32bpp. EDIT : it's because of a windows specific bug, luckily it's commented in the source, it's because when using the windib driver in fullscreen mode, when leaving opengl and or double buffer, the gui screen is not fully restored when it should. It happens only in windows and only with this driver. As a workaround I found that changing the color depth forces the full restoration of the screen. I wasn't aware that changing the color depth of 1 application changed the color depth of the desktop ! Oh windows is full of stupidities, really tiresome... Well for now I don't know how to fix it. I'll think about it..

Nope raine can't be compiled in 64 bits because of all the assembler there is inside (actually I made once a very limited 64 bit version, but it supported only a very few z80 games, and it was not using the normal cpu emulators). But for info I use it in windows 7 64 bits and on a 64 bit linux system without any problem, so the cause of your crashes/freezes is elsewhere...

Ok, sorry for the very long delay, I didn't think I would actually fix this... In case someone still reads this : I finally got curious about this bug and actually took the time to read the output of raine when the shaders didn't work with the new nvidia drivers, and there was actually something weird to read ! It was all because there was a bug in nvidia drivers <= version 355.11 which made them to return a buffer of 1 byte for the info log of the shader program when there was nothing to report ! I made a workaround for this and totally forgot about it, but it failed when nvidia fixed this and now the buffer has correctly 0 bytes when nothing to report... !!! Anyway it means shaders now work correctly for any nvidia drivers, and it could probably affect some other video cards as well. Those not using shaders don't need to update, this 0.64.12 only fixes shaders, and the fix is very short ! http://raine.1emulation.com/download/latest.html

Maybe it's not you, anyway it was in the older forum so I don't have the post here anyway... 1st I have not used mingw in ages, I have been compiling windows binaries from linux for years now, so maybe I'll have forgotten a few things. You need to use the msys shell, install it if it's not the case, normally if you use it OSTYPE will be defined to msys without doing anything, that's what you need 1st. Do that and post again if you have some more problems ! For the strlwr definition, it had disappeared from the mingw headers a long time ago, you are sure you are using some recent mingw version ? Well if it's really the latest stable mingw version and you really have a conflict here, then you'll have to comment out strlwr from source/sdl/compat.h and source/sdl/compat.c. For info my string.h is from mingw runtime (called mingwrt here : https://sourceforge.net/projects/mingw/files/MinGW/Base/mingwrt/ ) version 3.18. From my crosscompile environment, 3.18 is said stable, 3.20 and 3.20.2 are "testing" (maybe still in this state because not enough testers) and 4.0.3.1 is said unstable, so I think I'll keep 3.18 for now. While I am at it for the dependancies you'll need : libpng (well you have it obviously even if it's not the latest version, if you get an error while compiling related to png stuff then it's too old) sdl (latest is 1.2.15, you can keep 1.2.14 if you want) sdl-image sdl-ttf sdl-sound (preferably the mercury one because the latest "stable" one is unable to read mp3s containing id3 tags which can be a problem) muparser And then depending on the audio cdecs and the pictures formats you want, you might need some more libs (libjpeg, libvorbis, libogg, libflac, libmpg123 if using mercury version of sdl-sound, otherwise it's an outdated mp3 lib I forgot about, etc...). And you can find the pre-compiled stuff there : http://raine.1emulation.com/download/dev.html sorry I didn't show the versions used, just the dates the packages were made that's all. I never had any feedback about these packages, but if they are correct you just need to unpack them at the root of your mingw installation, below the include and lib directories. Good luck !

About that you were the one who asked the pre-compiled libs weren't you ? I never got any feedback about that ! The main (only ?) difference between djgpp and the other platforms is that there is alot more dependancies with the other platforms. You got a pretty clear message when you are missing one. It's long and tedious to compile everything when you are starting from scratch but the libs need to be compiled only once. Some of these libs are hard to compile as a dll, but you are not obliged to make dlls here, and it will work the same way in raine. Without any precise problem I can't tell anything anymore !

You can try that, or just use an older nvidia driver, they are still downloadable from their site.

For now I'd say use neoraine-1.4.3 then, I am in no mood to debug this for now !

Yeah yeah I don't use the same method to apply shaders, I don't use frame buffers at all. They are broken for the old method anyway since it worked before even with ati cards, so I guess it will be fixed eventually. Sorry I don't plan to convert the shader system to frame buffers, if someone wants to do it, I'll be glad to apply the patch ! Even if raine accept the shaders from bsnes, it isn't the same code at all to process them, not even slightly, I rewrote everything from scratch.

At least the february and the march versions are broken in windows. I know that at least the 355.60 version from august 2015 works fine, there are probably some others which work fine too. If you upgrade your nvidia driver to one of these recent versions and you get a black screen when using a shader, don't complain here ! I guess nvidia will probably fix this soon anyway !

disable speed hacks in neocd options ? Sorry testing this requires to restart from scratch, no saved game because they would contain the speed hack.

A very small release, mainly : - fix the black screen in garou at stage 3 - using a real cd for neocd will work better, but notice that the cd handling functions in sdl-1.2 are very unreliable, so it's more a proof of concept that something really usable. The good news is that it's possible to rewrite this using libcdio in a more reliable way that would work on all platforms. But it would make yet another dependancy and raine has already lots of dependancies, and it will be used by almost nobody, so not this time, maybe another time... - A new option to turn the hud messages off (the text messages in the lower left corner of the screen) - a fix for aof3 speed hack (neocd/neogeo) - a fix specific to mac osx since now they forbid strcpy(s,s) ! But they are not interested by this binary release anyway ! That's all ! Linux package uploaded already.