Tux

The big thing in this release is a fix for the gui display bug in fullscreen, it's not ideal, it currently uses some deprecated api in sdl-1.2, I have tested it only with a windows 10/nvidia system (and linux), so I can only hope it will work everywhere, I'll need some feedback here. The idea is just to try to display the gui in opengl since the bug prevents a proper restoration of the screen to display a non opengl gui. Oh well, just switch to fullscreen, test and report ! Except that : - a dos version ! This is the result of finding a djgpp version of gcc in arch, read about it there : There is only a version using allegro for sound for now because it's the sound driver with the best results with "recent" sound cards, if you really need seal to support some extremely old sound card, post something ! - the status & clones settings of the game selection list are now saved and restored - there is a new cache for the rom directories, it was made mainly for the dos version in an emulator, but it will have an effect everywhere. If you use a rom directory on a removable device, a dvd for example, and you change the dvd while raine is running, the list won't be updated, you'll need to restart raine for that. - the borderless window was updated since it was useless in windows, now it tries to emulate fullscreen, that is, the window is placed at 0,0 with a full size, the idea was to try that against the bug which hides the gui in fullscreen, but it failed, the bug also shows with this kind of window ! I kept it anyway, now when you switch to a borderless window the window is maximized. - some fixes for -romcheck and -rcf, and fixed the archive name for bubbolbr1 Oh yeah, the download section link is now at the top of the screen, in the forum title, but anyway : http://raine.1emulation.com/download/latest.html

It's not perfect, it's at the limits and even beyond of what can be done with sdl-1.2 and it shows, it's disabled in linux for fullscreen and borderless fullscreen windows because it creates amazing bugs there, but luckily linux doesn't have any problem with the gui in fullscreen so it's still fine, but you really feel why this api is deprecated here ! I just hope it will work the same in all windows, which is not guaranteed with windows... ! Thanks for the paypal idea, but it's nice to be able to make free things sometimes, and it would require a lot of people to give to make a real difference, so forget it for now, and enjoy the free things !

I found a recent gcc (latest version actually) for dos in arch, so I got curious to see if I could make the dos version to run now... Weirdly I have some trouble with dosbox, raine crashes at launch with it in install_allegro, no idea why, I tried a few dosbox versions and always the same result. With dosemu it's also harder, it had the best results before, now I am obliged to use a pre-version of their 2.0, which is not super stable. Here it works, sound and graphics (well vesa 2.0 linear which is not bad, but no triple buffer at all). Only file accesses are very slow for some reason, so I took a moment to add some basic cache for the rom directories in raine and it's now much faster, it will also benefit a little to the other versions, linux and windows. And it also works in virtualbox, using a freedos boot ! No vesa support at all there, clearly their goal was not to allow some dos games to run, we are stuck in mode-x. There is a working soundblaster 16 emulation though, but only with the allegro sound driver, seal doesn't detect it at all. With that, it's a little slower than dosemu ingame, but much more stable, and what works is working perfectly ! Quite surprising and impressive ! Oh well, it's probably time for a very last raine dos binary then ! (I might make 2, one with the seal audio, the other with the allegro audio).

No problems with ryzen chipsets, usb and so on. Don't worry I made peace with my win10, I use it only to launch games or test raine from time to time, and it has all its advertising disabled, a restored and usable start menu, in this state it looks very much like win7 actually ! The best option to work around the display bug in fullscreen : disable opengl double buffer ! There is really a problem when leaving opengl using double buffer, so if you remove the option, the problem disappears. I tried a borderless window to emulate fullscreen : bug still here, but with a border it doesn't show ! I tried explicitly turning double buffer off before displaying the gui : still doesn't work ! So the easiest way it to disable double buffer in fullscreen for now ! edit again : I was finally able to fix this display bug by using the idea I got while replying to your post : make the gui displayable in an opengl screen, I was lucky, there was some deprecated functions for that, it was not easy, I had to find what made them deprecated, undocumented stuff making them to behave in strange ways, and opengl double buffer which refuses to be disabled, but finally it works ! I can't release now because I made some more changes elsewhere which need to be improved, but it's a relief to finally have fixed this thing ! It's not even committed to git yet... The gui doesn't look different in opengl, it's just some basic blit function everywhere, but at least now it's never hidden !

windows7 is usually the best windows, right ? I would have kept it myself, except that updating the machine doesn't leave any choice with some low level drivers impossible to find for new hardware on win7. No idea why your mouse is not captured, never heard or seen that before... ! Notice that in this extreme situation you can use fullscreen, just don't call the gui or if you do and it's not visible, then you can either return to the game with esc or quit with q or alt-f4 (alt-f4 quits without saving the settings). It's not super convenient, but it's very do-able ! I am not sure I'll be able to fix this, but I might try again later, but don't hold your breath, it will take time... !

I confirm on my side, just tested natively with windows 10, with a window which is not fullscreen, the mouse is captured by raine only when playing arknoid2u (or any other game with the same mouse requirement). I was afraid for a second that I had yet another incompatibility between windows & sdl-1.2, not this time ! Standard windows 10, nothing particular about it.

The mouse is captured for games needing it, you shouldn't have any problem in a window (at least tested for arkanoid, so it's good for games using relative moves).

Ok, double error here, LOAD_IGNORE wasn't ignored by -rc & -rcf, plus a partial rom load from the driver shouldn't print any error. All fixed ! (it shows that nobody has been running a serious romcheck for a very long time or at least they didn't report the errors).

Typo error on my part : filenames recognized : { "bubble_bobble_romstar2", }, { "bubbobr1", }, { "bubbolbr1", }, The last one should have been bubboblr1 and not bubbolbr1. Will fix that for next time, but I had the original archive which still has the short name bubbobr1 and didn't notice it. This change was from 2015, so it was not a problem for a lot of people. Anyway next time it will recognize the right name then... !

It's a long standing bug between double buffer fullscreen and sdl-1.2 in windows, it's been here for years ! Workaround : use a maximized windowed mode. The bug doesn't happen all the time, but it's very frustrating. Could also use a borderless maximized window for that, but they are so hard to use in windows (what a bad name for an os which is so bad at handling its windows !), that the setting isn't even saved in the config file. It's not fixable in raine, it's an sdl-1.2 bug. and actually raine is not frozen when it happens, it's just a display bug, the gui is invisible, so you can still control it with keyboard shortcuts, like : esc or return : return to game q : quit There are actually 2 ways to fix this, switching to sdl2, but it's extremely long and tedious to do, sdl2 is not a plug and play replacement for sdl1.2, or change the gui so that it can be displayed on an opengl screen, this way might be more interesting actually. But since it happens only in windows and I almost never use windows (or for some very specific things), I am not motivated, and it would require quite a lot of motivation, the 2 possible fixes are not easy at all !

Excellent, thanks !

As the version number implies, it's all bug fixes inside : - -rcf didn't work with romsets using LOAD_CONTINUE (like sonicwi3), it's fixed - sf2m8 used a dummy rom load instead of a FILL which created a romcheck error. - don't consider neogeo games as clones of the neogeo bios in the games display - fix broken iso.gz support for neocd (usually compressing an iso to iso.gz without touching the cue file at all used to work, it was broken in 0.91.6 because of the changes there). - and neocd again : when trying to guess an audio track name and there is no cue file, check the extension to avoid to select a picture as an audio track ! There is also a big shared libraries mess with this version because of some updates. The 32 bit windows binaries require the new dlls32-0.91.7 package. I have also updated the dlls64-0.90.7z but this one remains compatible with the old versions. For the arch binaries, the guy who is supposed to update libmuparser on aur is missing and unreachable, which means that you won't be able to build a 32 bits raine with the current muparser installed (incompatible with the old lib32-muparser from aur). Updating the muparser file is not too hard, but I can't do it officially for now, have to wait 2 weeks for that. So I don't know if I'll release the 0.91.7 linux binaries now, maybe only the 64 bits version then ? edit : finally I released both, but I don't guarantee the result if you use the 32 bits version with the old muparser, last time I tried that it crashed when opening the console ! (the console also handles cheats). Oh yeah I need to remind the link to the download area, it would be nice to have it inserted in the forum somewhere : http://raine.1emulation.com/download/latest.html

On 2nd thought, the fix is not hard to make, only a few lines. So I'll do it again, there are a few minor fixes already committed to git and I needed a reason to make a new binary. Plus I need to recompile all the 32 bits windows dlls (oh joy), to get rid of the dependencies to the old gcc, anyway, I'll release this soon... (already fixed in git)

Tsss... can't insert my reply in the middle of this, so it will do here : 1 : Not for me, sorry, I don't know exactly what happens for you, but the rom loads fine here. 2 : Ah ok for this one, the -romcheck command doesn't handle very well the roms loaded with a ROM_CONTINUE, actually these roms are very few, and it's the 1st time this is reported... Anyway what happens is that it says bad size 0x20000 because the rom is loaded by parts of 0x10000 with a ROM_CONTINUE for the 2nd one. It's harmless anyway, but thanks for the info. 3 :Since you didn't give any example I am obliged to guess here, and chances are you stumbled on another game using ROM_CONTINUE, like sonicwi3 for example... ! That means also that nobody seriously used -rcf in the many years it existed, it's from before 2009 (start of git in august 2009, and it was already here). Wow, it just shows I spent too much time on this already ! I'd say not worth fixing it for now, sorry !

lol, yeah but I know there are some beos lovers out there and they used it on pcs. Some amiga lovers too, this year they got a doom port : https://games.slashdot.org/story/20/04/26/0156227/developer-attempts-doom-clone-for-the-amiga-500

Sorry can't help you, never even used beos !

I wouldn't want to port it to libretro, libretro is good for emus which run their games with a minimum of options, raine has a swarm of options ! so no, forget it. And for aur, yeah well it would mean trouble for me, because signed packages, make the package to be accepted and so on. For now I chose the easiest path for me, sorry if it's too hard for some ppl... !

Ah some feedback at last ! Thanks, yeah the guy seems to auto build a lot of packages, probably too busy to reply to almost anything ! Well no version is better, but they are really different, I mostly use the 32 bit one because it's fast even for a debug build without optimization. why didn't you try to install the .tar.xz files ? They are not signed but it shouldn't matter. I don't know this --editmenu flag, I'll take a look later, thanks for the feedback anyway ! (normally installing the xz file is done using pacman -U file.tar.xz simply). and why not using simply makepkg -si to install the pkgbuild file ? yay is useful to install automatically packages from aur, but here there is no repository so there is not much point in using yay... and edit 2 : the package name has no errors : raine is the name of the 32 bit package because it's the default version, the one which exists since 1998. raine64 is the new 64 bit version using C cpu emulators and C video functions instead of asm. Since they both share the same data files it was a little awkward, I thought about making the data files an external package but since there is no repository it wouldn't be very convenient. It's the best way I found so far...

it's not exactly a bug although in this case it's not convenient, it's because all neogeo games share a parent : their bios ! So if you hide clone, you hide them too, maybe it would be nice to find a trick here... Ok, I just added an exception for neogeo games, it's easy to do... You insist on playing with the gui set to a low resolution, well there is a minimum allowed font size for readability, then if you hit both limits (the resolution + the font size), then your text is clipped, it's normal. And no I don't plan on having game names on multiple lines ! And same thing for the status line at the bottom of the screen : the text won't do a buffer overflow but you can still make text to overlap in such an extreme situation, I won't do anything about that. Not sure to understand your 3rd line, on the status bar ? No way ! But I can expand the string for the long game name, I hadn't noticed it was too short for some games. In my opinion the proper fix here would be to shorten this way too long name, but since it's a mame name here, I'll just expand the string a little... ! Is it to your liking ?

What a mess... let me guess, libstdc++ too then ? The weird part is that this time I tested it, from linux, but it was better than nothing... Oh sigh ! Ok, I'll look into it, might be able to create a whole new dlls package for that... ! Here is an updated package, tested in windows this time : dlls32-0.91.6.7z I still don't understand how it can work in linux with wine, I guess there is some trick about the gcc libs there... Anyway I hope there won't be any other gcc update anytime soon, I had to recompile muparser for this... Oh, and both libgcc are required for this version because of the old dlls which were not recompiled !

Good one, since I cross compile, I don't test everything all the time, but this time gcc was updated automatically, and the dll changed for the 32 bits version, but the 64 bits version kept the same name and is apparently still compatible ! So I just updated the dlls32-0.90.7z package, adding the new libgcc for this gcc-10.1 inside, I keep the old one for those who want to test old versions. Sorry for the inconvenience, you will see the updated date of the package in the download page, and thanks for the post !

Not what I meant, it's probably as good as any other dump, the problem when reading would be with big endian cpus but they become rarer and rarer these days, so you can forget it. But it's still more convenient to have wav files at least to convert them more easily to mp3, ogg or flac. For me the ideal format is probably : extract the files from the iso and put them in a zip file, then convert all the audio tracks to ogg (neocd audio is not symphonic, it's just a waste of space to keep uncompressed audio here, and ogg is probably the best format for that, or mp3 if you prefer). Then just delete the cue file, raine will know the zip file contains what should be in the iso, and guess the ogg files are the audio tracks, and the result will be much smaller while being readable very quickly !

... which produces raine 0.91.6 to handle this new kind of cue. It's far from an ideal one, everything in raw even the audio tracks, which means that you could get bad sound if the endianess of the computer who created this rip and the one reading it differs but here it works with some good old x86 endianess. This obliged me to change the way the iso is detected in the cue file, previously I was taking the "binary" track, but here all the tracks are binary ! Normally it shouldn't break anything, I quickly tested with some good old normal rip and everything seems ok. That's the only change for 0.91.6, so those who don't have such raw rips in multiple tracks for neocd don't need to update, and 0.91.5 was linux exclusive. Oh by the way I removed the blend files from this release, you'll have to download them from the extras section or use them from a previous release if you are interested, it's better to have a default without them. http://raine.1emulation.com/download/latest.html

Give a link to your re-dump by private message so that I check it... ! Be sure to at least use the latest version of raine (0.91.x).

I have just taken some time to look into an appimage : that's a way to bundle some libs with an executable, for linux, similar to osx packages. The advantage : to be able to run it on any system without installing any shared lib since they are already in the package. The idea is interesting, but for raine there are 2 problems : 1) the small package becomes very big with that, for the 32 bits package without libX11, libc and libstdc++, it's still 25 Mb ! With these 3, 32 Mb ! Very far from the usual 2 Mb ! 2) The target system would still need to be able to run 32 bits binaries, so have the basic libs + the dynamic loader installed, it's an endless headache to try to have this packaged in an appimage, with a lot of effort I could run the binary, but it could not open a graphical window ! So it was fun to try, but I don't think it's interesting for raine. If 32 bits apps are a problem, just install the 64 bits one, it should be easier to execute anywhere... Even if it uses quite a lot of shared libs now, these are still very standard and easy to find libs, so these appimages seem too much here.