Tux

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.

Hum, I think I know what happened, you used a game with lots of files in it and some of them containing numbers. raine tries to find an audio file 1st when it needs one and if it finds a file with a number in it it will try it. Which makes no sense here when reading directly the game files, so I added a work around for that. But reading a cd directly is totally unreliable with sdl, sometimes the cd is not paused when it should, sometimes it doesn't resume, you don't know the exact reading position, and no control on the playing volume. It's barely usable, but anyway it should work better in next version. Ideally this should be replaced by direct access to the audio tracks data but I am not sure it's possible with a cross platform solution... So I think I'll just keep sdl for now, and simply advice not to use real cds directly !

thanks for the save, it's fixed ! The good news is that your save is still valid, you'll be able to continue the game without the freeze on the black screen. The reason is highly technical, raine uses a simplified "frame emulation" when the game doesn't use raster effects like here to be faster, and I didn't bother with the exact start of the vertical interrupt here. Except that this precise game, garou, expects to read a line number between 0 and 2 at this precise moment, which is impossible if the vbl starts at line 0. So I had to change a little the simplified version to execute the vbl at line f0, it's more accurate even if I thought it was unneeded here, and the game doesn't freeze anymore ! Thanks again, I'll try to post a new binary this week-end...

You made me curious so I found a very old puzzled cd I had and tried it. Well bad news for you it worked out of the box the 1st time I tried it without doing anything special. I used the latest released 0.64.10 version, it's a system with only 1 dvd drive, no cable from the drive to the soundcard so I hear no music in linux but the music works fine in windows. The only bug I noticed is that when returning to the gui in the middle of the game the cd music is not stopped, it's stopped when quitting raine though, so it's not really a big issue, just an annoyance. Well absolutely no idea what you did, the message you get about mpg123 doesn't make anysense, mpg123 is used to decode mp3s, these functions are not even called when reading an audio cd, so I am clue less here. All I can say is that it works here. I should eventually try to pause the music when returning to the gui then... ! Actually there was an even bigger bug than that, the track played was wrong because the data track is just ignored by sdl ! So I fixed that, but audio cd support is very primitive in sdl, you can't tell it to loop a track, there is no way to know the position being read in the track, and in windows there is absolutely no control on the volume the music is played at, which quite breaks the sound balance here. There might be a workaround for the volume, but it would be windows specific, not the kind of code I like here... So I strongly advice against using a real cd with raine ! But at least the next version will play the correct track if given an audio cd ! The music is too loud but except that it's not bad (and you can always adjust the audio cd by using the real windows mixer !). For the music not being paused, I am not sure of the reason yet, with puzzled it doesn't pause the 1st time you return to the gui, but after that it pauses correctly so it's strange, and I can't reproduce that in linux of course so I'll have to debug this more.

For the cd audio all of this is normal, if it can't find any audio file and it receives a command to read an audio track then it will attempt to read it from a cd, no idea why you get this error message about mpg123, like I said I have not tested this for a very long time. You make a full bin/cue backup with either audio tracks or even audio merged in the bin file, but there must be audio in the backup if you want this to work. I will try to find an audio cd to make some minimum tests, but don't be impatient for that. Well the normal blits are supposed to be used with some crt which can handle low resolutions well, if yours can't then you are stuck between 2 worlds (crt with low resolution vs flat screens which never change the resolution). Too bad ! And for the option to remove texts, don't worry it took 5 minutes, it's really easy !

bump (to make this topic to the top so that the edit has a chance to be seen !)

From memory when trying to read an audio cd it must pass a drive "number". Since there was no obvious way to guess this number, I just passed 0, the 1st drive, so if you use an external one with usb it will probably not work. I would need to spend more time testing this, but it's actually hard to test, the cd read this way uses the system function to read it, with linux it means you hear nothing if the drive is not connected directly to the soundcard which is my case. So I must test this in windows, and I reinstalled windows in august so it's not really convenient ! Maybe later, but no promise here. Remove the text messages ? I quite like them, you are actually the 1st person asking for that but I guess some others don't like them. Oh well adding an option for that would be very easy, I'll keep that in mind, even if for now I take a break from raine development ! I just added that to the source, now you'll have to wait for the next binary ! Notice that if you use a crt screen you might want to try the "normal blits" instead of opengl. In this case you get an option to change the video mode to match the original game resolution, which is a bad idea on the modern flat screen but which works well on crts. You can choose 2x resolution if you want. Just try it with hq2x or hq3x, you might get a better display this way with your setup (but in this case it totally changes scanlines, there are no shaders anymore, but there is a scanline option). Good testing !

Ah sorry I actually never tested with an original cd ! I added the support blindingly, but it's not tested. I advice to use a cd image instead, it will preserve your cds this way (the more you read them, the more they risk to be damaged). It shouldn't be hard to do, most of the image formats are supported. A desktop of 640x480 on a 1280 screen ??? WTF ? Do you do that because your characters are too small ? If it's the case just search for a method to increase the font size in windows (normally it's the dpi setting in linux, very easy to change, but for some reason it's not that easy apparently in windows !). You can try to edit the config file, set the resolution like I said above and have fullscreen = 1 at the same time. I never tested such a setup and it would probably have issues, the best is to use raine at the same resolution as the desktop or < (in a window). Good luck again !

A savegame before it happens would be nice. I don't use launchbox and I don't know it but yeah frontends are supported. EDIT : actually there was another bug related to this, so you should try again but disable the speed hacks in "neocd options". It's either this or the raster effects, but my bet is on the speed hacks. Try to reproduce this and save before reaching that point ! Too bad this reply comes a little late !

Wrong topic for your dat, and I never used dat files so I can't help you here, sorry !

What do you mean "stretch the image" ? The image is always scaled to the maximum size when using opengl (keeping its aspect ratio by default unless you told it not to). There is the old renderer method if you want to test it, hq2x/3x etc, but it's not suited for big screens usually, 3x is not enough for them, they are still available in normal blits. For the scanlines, be sure to use the latest raine, you get : caligari-scanlines.shader Pixellate-scanlines.shader scanline-3x.shader scanline-4x.shader Themaister-scanlines.shader Themaister-Waterpaint-scanlines.shader I hope at least one of these works for you ! You can also try to update the video driver, it might help with shaders compatibility. Once again : neoraine is extremely outdated now, it has been merged into raine a very long time ago !

There is a setting to prevent it from preserving the aspect ratio, it's in renderer options with opengl : keep aspect ratio, set no, but it's usually a bad idea in most cases... (neogeo games are not 16:9 games, so on modern screen they would be distorted if you don't preserve their ratio). Still in the renderer options with opengl you have "opengl filtering" nearest or linear, but know that the shaders can force this option, so it's usually usefull only when not using shaders. And finally the only way to have scanlines in opengl is to use a shader which emulates them, there are a few to choose from. Ah for your resolution, well I didn't add an option to force any resolution because the thinking with modern screens is to adapt the game to any resolution used by the screen, and usually it works well. But if you really want to force it, you'll have to edit your raine(32)_sdl.cfg file in the config directory, change screen_x and screen_y to whatever you want. I suggest to use a windowed mode in this case (fullscreen = 0) because otherwise it will choose the closest available video resolution which might not be what you want. Eventually use a borderless window, it's exactly like fullscreen in this case !

Yeah sorry there is no specific vsync option because it's handled by the double buffer mechanism, so there is a main double buffer option in video options which is enabled by default, and a specific one for opengl in "Renderer options" when the renderer selected is opengl, If you enabled both options, it's worth testing fullscreen mode and windowed mode, which might give different results.

it's strange I saw this same story on a movie ! Must be a coincidence !