Tux

You pointed both time to 0.91.9 to be the last dos version with working sound, and then having broken sound. (ah ok, the 2nd link is for the ad version, sorry my bad). Well if I am not wrong this a was for allegro, if that's right then the last released binary (0.97.6) also uses allegro sound. Anyway this 0.91.9 is from 2020, you could have posted earlier... ! Well I had sb16 emulation working in pcem but it doesn't do any autodetection, it relies entirely on the BLASTER environment variable, if you set it badly, you don't hear a thing. It's a little strange you don't get any sound on a sb16, it's the base card for a lot of things, but if you double checked this blaster environment variable, there is not a lot more things I'll be able to do... !

Yeah the sources are available of course. Some sources archives are on this site, up until 0.51.11 I think. If you want something more recent, use the github icon to go to the github page, click on the tags to select the version you want, then it will give you links to download the sources for this version in zip, or tar.gz. The problem is allegro, you need to find some sources for allegro4, then there are some patches, I use these, some from arch linux which probably come from somewhere else, some from the old days of Antiriad with the dos version : patch -p0 < ${startdir}/makefile.all.djgpp.patch patch -p0 < ${startdir}/makefile.dj.djgpp.patch patch -p0 < ${startdir}/misc_mdhelper_sh.djgpp.patch patch -p0 < ${startdir}/src_misc_vbeafex_c.djgpp.patch patch -p1 < ${startdir}/diff-inline patch -p1 < ${startdir}/raine_hacks.patch patch -p1 < ${startdir}/vesa.patch Of course all this is for djgpp. I compiled the whole thing for version 0.96.6, and it worked quite well with PCem, which is quite a serious emulator for old x86 hardware... The best I could do with triple buffer is trying to enable it from a 320x240 mode-x -> black screen (instead of the usual error message "Can't enable triple buffer").

Out of luck here, I remember cleaning up old files not too long ago and deleting a rained.7z file which I didn't recognize... ! Well if I remember correctly I didn't get much feedback from this build, so I don't know if the changes inside were merged into the main version or not, but I'd say it's likely. Anyway, even with PCem and in 16bpp with univbe, I still can't enable triple buffer, and it doesn't say why, it just says it can't, so I can't test that at all.

Hum, looong post... ! Well no need for an update since the update can be loaded with the crc warning. Let's wait and see... ! Your return key is just the gui way of working at its base : no button, then the only key handled is ESC to close the dialog, or button 2 of the mouse etc... If there is at least 1 button, then either Return or the 1st letter of the string inside the button selects it. And yeah sorry I don't think about adding a button all the time, this gui accepts dialogs without any button so I use this sometimes, but sometimes it just feel right to have a single ok button below the message. Just accept it that's all ! Double line in the crc message : after looking at the code it's actually inherited from the dos version, which explicitly added the double line feed, so I did the same without wondering anything. Oh well you are the only one reacting to this kind of detail... More interesting is the fact that this particular last line escaped from the translations, I'll have to try to update them then... Ok, updated for the french translations, a few new strings to translate eventually for the others too... I'll update the others with empty strings for now. Also there is only 1 line feed now, although you are probably the only one interested by that ! For the crc error : it's very rare to actually need the 2 crcs at this point. Those who need it can check the zip archive. The crc displayed is the expected one, and for zip at least, when the message is added the actual crc of the file is not even known, it just knows it's different ! So I will leave it like that.

Well for emulating raine in dos I wouldn't need anything more, everything works perfectly, sound rdtsc, even some vesa modes using univbe, eventually some svga chip supporting more vesa modes but even with the few I had it was enough to test. And even with the windows version I used, which works perfectly in wine. it was abandoned, but then taken again by someone else, I don't remember the details, but yeah there seems to be quite some chaos in the x86 emulation world currently (even dosemu & dosbox seem to have a hard time creating their next stable release). Anyway thanks for the info, it was useful and allowed me to fix a few bugs related to the sh2 emulation, even if there are still some problems with this dos version, it's better, and a working version in 2024 is already quite a feat !

Most of the changes in this one are for the dos version and were released as 0.96.6 for dos anyway, but : - fixed an amazing bug for pengo which was here since 0.43.2, that was in september 2005 !!! See the thread in the forum if you want details. - galaga will now display a message when loaded if it can't find anything for the explosion sample, you can ignore it, it's for info. - gui fixes : games states, transparency, length of game title + size at bottom of screen. - a new "color theme", it was just because I noticed the dos version had actually 3 color themes, but it was done simply by rotating the colors rgb values, here it's a little more involved. Anyway the red theme had been forgotten in the sdl versions... http://raine.1emulation.com/download/latest.html

And finally fixed the text truncation, for info the string was cut at 99 characters long because we still need finite buffers to store strings, it seemed to me that 99 characters was way enough for name (size), but some crazy games like samshope seem to need more... I think this name should be shortened, but I enlarged the buffer to 200 characters to avoid this kind of problem in the future anyway.

Didn't know it neither, might be very old, it's not amongst the most played games... ! Reproducible with the asm version too... It was extremely old indeed, from between 0.43.1 & 0.43.2 ! But it was a stupid mistake, related to how regions with more than 1 gfx layout are handled, the big target here was cps2, and it got most of the work, and pengo stayed with some not totally finished code, which produced this effect. The fix is 2 lines only actually, but it took me quite a while to find out what happened ! Thanks for the report !

Updated the rained-0.96.6.7z archive on the site, the only changes inside are related to sh2 emulation explained in the previous post, date of the exe inside : 14th of January !

I had a look at this PCem, it indeed looks interesting, but where is the documentation ? Since there is no interface, how do you want to use this without any documentation ?!!! Even in the forum there is no basic documentation, no default configuration file, nothing, it's quite extreme ! I found the github repository containing all the bioses but they are useless without a minimum set of documentation... If you have a link on how to start using this thing, I am interested... ! Ok, understood, you need the windows version to get the interface, the guys who wrote this are heavily addicted to microsoft... ! But the good news is that it runs fine in wine, and so I can create the config file this way ! Crappy way to do things though... ! After testing on a pentium2-300 with pcem (splendid emulation of the machine this time, this emulator is really THE emulator for dos), gunbird2 runs perfectly with a solid 60 fps. I saw a zooming problem during the intro, specific to this dos version (the flying carpet man while he approaches), I don't know why, but at least it runs smoothly with a serious margin, even with sound (soundblaster 16, 22 Khz). For reference, this sh2 runs at 57/2 MHz, but with almost all instructions taking only 1 cycle (risc), so I'd say it's equivalent to at least twice this frequency for a "normal" cpu. Which means good emulation, raine honor is safe ! I thought about trying some heavy optimizations on this one, I didn't want to do it first because the driver would loose in readability and I didn't think it would make a big difference. After this test I am sure I don't need to do it ! Thanks for the info on pcem though, not sure it will be useful soon because maintaining the dos version today would be crazy as I said, but it's good to know there is a way to test this properly. For info the linux version sucks, no configuration manager which makes it useless alone, and when I try to run it with the config created in wine, it just crashes without any message. As I said these guys are heavily addicted to microsoft, but their program is good anyway (the windows version!) The only advantage of dosbox is that you don't need to create a disk image, but the emulation is less precise for sure on this kind of thing, I could even select a mach 64 gx to have 2d acceleration and then run univbe on it using pcem, quite impressive, even if I was limited to 512x384 16bpp for this test, but it was enough (and the resolutions < 512x384 in 8bpp are all broken in vesa3 for some reason, it seems their emulation isn't totally perfect here). But all this is quite impressive compared to what we had so far ! edit : PCem being quite fascinating to use, I fixed the crash in 8bpp, and the black sprites in 16 bpp for the dos version, this was just that color depths other than 32bpp were badly handled, and 8bpp was crashing because of an overflow in the color map. It's likely that other 24bpp games have problems in 8bpp in dos then, maybe I'll check that later. About 60% cpu free during most the intro on a pentium2-300 in 8bpp, I'd say it runs quite well ! The colors look a little pale in 8bpp, it's normal, it's the effect of the color conversion to fit all this in a 256 colors palette, switch to 16 bpp if you want bright colors ! I didn't find a way to mount directly a vhd in linux yet, I found something on the net about that but it doesn't seem to work, so I work on the vdi used by virtualbox, and then convert it to vhd for PCem using some virtualbox tool, really sub-optimal, but even if that's quite a lot of steps, it's quick to do and manageable. Oh well, I think I'll be able to stop here for now ! The proper way to mount a vhd in linux : https://devicetests.com/mount-virtual-hard-disk-ubuntu (method 1 works perfectly).

I had a dosemu env which worked not too bad to run the dos version, but dosemu seems to have a lot of trouble to reach their 2.0 version and it's getting hard to make it work, plus it was running at the current speed of the cpu, not emulated, at least it was very fast ! I didn't know pcem, emulator for ibm pc and clones ? And it can even run the dos version ? Wow, I'll have to test it one day then !

1 & 2 fixed in git, I'll keep 3 for later... !

Didn't think of anything, it can read command.dat, but not display it ! So it's enough, updated the download page, it appears below the 2 other binaries, 2.4 Mb, including history.dat and hiscore.dat, these 2 are handled. http://raine.1emulation.com/download/latest.html

Well I had disabled ips support in the dos version yesterday, but after thinking about it I added it today : there is almost nothing to do to add it, but without gui of course, the dos gui is crazy to program. But anyway it recognizes the ips directory and any file it contains, which means if you load a rom whose short name is a, and you have a file ips/a.ini containing a list of files to load from ips/a directory, it will do so. I just tested it with an ips I got for bublbobl, and it works perfectly, it's primitive, but it works ! At least it will be a decent version... ! I'll keep it a little longer to see if I think about something else...

Yeah I did it for that too, still a ton of respect for it even if it's outdated now.

1) Yeah I didn't test it, it would be easier to just remove the option... ! Don't worry, I'll test it... 2) did you at least read what I wrote about editing the colors or reverting to the default themes for that ? Either edit your bg color or revert, or even better revert 1st, and if it's still not enough for you then edit the bg color manually. 3) Nope obviously, didn't do it (boring and uninteresting, but yeah should be done one day). Yeah that's what he is already, and he loves that, too bad he can't code to help to fix these things... !

And here is the conclusion : If someone wants to test this, I'll release the binary... a very last dos version, that was the least I could do ! The not maintained anymore is not totally true, I improved the message box in the allegro gui for this version, I wanted galaga to be able to display a message on a few lines and it was not supported in dos, now it is. But I won't do any major change on it despite its problems, it would be too crazy now... !

And here's a screenshot of the result, gunbird2 running in a dosbox session : It's extremely slow, 6 fps and non constant, it crashes in 8bpp for some unknown reason on the colour mapper, it requires more ram than I ever saw in a dos machine (287 Mb displayed here !), but it works !!! Well, it wouldn't work at all on an old machine because of the ram requirement anyway, but maybe it would be faster, this cpu emulation isn't really very efficient... But at least it's good to be able to optimize stuff ! (and it takes forever to load too !).

Yeah I check everything is working or at least can be compiled. This dos version is really hard to test nowdays. The good news is that it works quite well with dosbox-x, an extended version of dosbox, with cputype = ppro_slow, and memsize = 64 at least. The rdtsc emulation is broken, so you can't even access the rdtsc counter with the f11 key, but except that the rest seems to work alright. I hope that nobody uses the dos version nowadays, except me because I am curious to see how it works now ! It would need a few improvements, like that sample support from the galaxian driver, for now all this is simply disabled. same thing for the galaga explosion... But oh well too much work, not enough use, I'll probably leave it as it is now, at least it works, even if not perfect. The debug build of raine doesn't work in dosbox, it needs an optimized build otherwise it's just too slow ! That was fun seeing it running anyway !

Ok, just release 0.96.6, no new topic because it's exactly the same kind as the previous one, small things. The difference is that this time there is no new game : - what I hope will be the curl final fix, see a few posts higher in this topic for more info, everything should finally work as expected, it will create html files for index in the raine directory when needed. - a fix for savegames in the gui which showed by mistake the clones saves at the same time, this thing is never used, really. - the neogeo saveram can be saved by game to preserver hiscores, or shared as the neogeo hardware did and as we did until now. Option in neogeo/neocd options. - Fixed the colors selection in the gui (gui options / colors), they were broken since the switch to sdl2 ! and slightly improved the look of the green theme by the way. - The old behavior of the sdl1 gui where menus appeared behind dialogs in transparency is restored, it's only for dialogs, those having a black title bar. You can update the blue theme either by going to gui options / colors / revert to... and choose green, then blue, then exit and the colors are updated. Or edit the bg color in this same menu, and set alpha to 0xc0, same result. Or you can do nothing to keep the old one, but then don't complain if the transparency makes things hard to read sometimes ! The rest are super minor changes, not worth detailing here... http://raine.1emulation.com/download/latest.html

Well finally I got curious about that, why not unleash all the crazy transparency from opengl instead ? And I got this : You have 2 menus and 1 dialog overlapping each other (you can see a very small part of the main menu at the very top, the top of the "Load game" line), plus some moving lines in the background, and the whole thing takes 0% cpu, because transparency was made in software mode in sdl1 but here it's in hardware mode and all this is natural for opengl... ! I had to make the dialogs more opaque to preserve some readability, so you'll have to go to gui options / colors / revert to, to reset the alpha channel to its new default value, either that or adjust the bg color manually (I fixed the color dialog, it was broken since the switch to sdl2, the colors are handled differently in sdl2 and nobody noticed, oh well...). Maybe that's a little too much ? I'll wait a bit, but for now I think it's still very readable ! edit : finally I had to limit myself and revert to something more like what there was with the sdl1 gui, that is : draw the background menu only if the top most menu is a dialog (that is, it has black title bar attached to the menu, no top or bottom frame on screen). The reason is the game selection dialog, the main menu was hiding most of the background picture, which makes the feature useless. That's that, or remake completely differently this game selection dialog. Maybe one day, but not soon for sure... !

It's because with the sdl1 gui you saw the video options menu behind it and for more readability you needed to have this one non transparent. Now I hadn't even noticed that now that the desktop background is drawn (the lines), we don't see anymore the background menu ! Oh well, this gui is not really a multi window system, so I am not going to try to recover the disappeared menu in the background, it would be outside its scope, but maybe restore the transparency here now yeah... !

The Shared, yeah probably right, I'll see that eventually. SDL2, it's the 2.28.3 in raine for now, 2.28.5 on the site, so these are just minor fixes. You have the list of changes displayed in the release page in github : https://github.com/libsdl-org/SDL/releases and they also list the changes in their whatsnew file inside the archive if you get it from somewhere else. Nothing major for us, these are just minor bugfix releases. Apparently their main branch is switched to sdl3 so I guess they will probably release that in a not too far future... Hopefully the switch will be less painful for applications... ! For the way too long name of the game : yeah I thought about that when copying and pasting the info from fbneo, I am tempted to just cut some part from it, but I can also remove any restriction on the length in the gui, now that it's fully opengl there is no risk to display off limits... I'll see, minor problem anyway.

Yeah the soft dips, I forgot the soft dips are stored there too, but not all the neogeo games have soft dips.

... and I disagree ! But, if you want, you can update the brazilian translation and put that in CAPITALS then (for the brazilian language only) !