Tux

Too many bugs in 0.64.7, so here is a quick fix for : - no more stdout.txt file generated when launching the program - the shaders don't turn the opengl interface to black anymore - controls using the command.dat graphics can be changed again (0.64.7 was just exiting in this case). Also the command.dat graphics are a little better, and I managed to add 1 last shader, not totally sure it renders correctly though... And added a few combination controls to cps1 and cps2 (not a lot). Thanks to the testers who quickly spotted the problems !

For the translations you don't enable them manually, they detect the language on your system and if some translation is available it's displayed. I am thinking about maybe adding a setting to keep english for those who are used to the short cuts because it changes all of them of course. Since you don't have a spanish or a french system you can't see anything... maybe it's time you contribute a few strings from your language to see the difference! For your crash no idea, I have messed a lot with the inputs since the release and no problem so far, I can always test in a new folder... EDIT : actually it's not a crash, it's easy to reproduce, it just quits because it doesn't recognize the new input (command.dat is interfering here). You are probably the only one who found this because most people use the old config and so they don't need to remap all the controls all the time ! I thought I had tested this, but I have forgotten, thanks for noticing ! By the way : I have added 3p and 3k for cps2, mainly because they are already in the listings of the command.dat inputs, but it's impossible to add 3k for player 2 in cps2 (at least for ssf2, but probably for all the games using these 6 buttons) because the wiring of the game is crazy and the 3 last buttons are not mapped on the same byte. There is at least a limitation in raine for combinations, the inputs must be mapped in the same byte (1 bit / input). Oh well, it will be harder for player 2 ! EDIT : for now, just cps1 2 buttons added B1+B2 (actually there is a 3rd button for final fight, but it's unused ?) for cps1 6 buttons added b1+b2+b3 (3p) for cps2 6 buttons added 3p and 3k that's all for now. Actually from the command.dat there are very few 2 buttons combinations, so it seems overkill to map all possible 2 button combinations when there are so little actually used. Also fixed the mapping of new inputs of course and improved the representation.

I like its style, it was drawn by Antiriad by the way, it's based on the default allegro style but with some improvements. But it's really absolutely horrible to program ! Anyway glad everything works now !

I guess you are talking about game specific settings ? Yeah they are saved in games.cfg in sections using the short names of the games, no need of the source filename for that. Nobody had the need to use the driver name here instead so far, so... ! For stdout.txt, no I don't like it so I won't keep it like that, but it's something you easily forget, and I need to make a new binary to fix that, not just update SDL.dll, so it will be for next version... Actually I try to use gentoo ebuild files to avoid to forget the settings when recompiling now, but it was my 1st try using this, so of course I forgot about stdout.txt. It's updated to remove it now.

Ah yes, spoke too fast, sorry the config is not read and restored for neogeo in dos. I guess I'll need to make an update then... EDIT : it's done, I added 2 checkboxes to the game setup dialog for that, the 2nd one is a bonus to allow/disallow speed hacks, you shouldn't have to touch this one, but anyway... Who would have believed I would update the cursed gui in 2015 ? I still hate updating this code, but since these were only 2 ridiculous checkboxes, I did it... And this time the config is saved and restored. EDIT 2 : and re-uploaded the dos 0.64.7 with this update. Since it's something already available in the normal 0.64.7 version, there is no need to change the version number !

The 16bpp that you see is only the tip of the iceberg, there are a few settings which are changed when going to the gui , for example if you keep double buffer then you have to draw the mouse pointer yourself or otherwise you can't see it anymore ! Another solution for me would be to create a full opengl gui, which wouldn't be a bad idea, but it isn't super easy neither ! So the best fix for now is really to use a standard window !

Of course it can be done, but you are right, we shouldn't add too many combinations, I'll test this and see how it goes. How do you find the command.dat inputs in the controls menu now ? By the way there seems to be a small bug with the new shaders code, it makes the overlay interface strings black if using the opengl overlay interface, which makes them unreadable. Maybe it doesn't happen for all video cards. For now just don't use the opengl overlay interface if you use this.

Yeah I know it'a actually the main problem of the gui in dos, most of the time adding a single button is a mess, where it's extremely easy to do with the modern gui. I'll see if something can be done without too many problems. Meanwhile you can do it by editing raine.cfg, normally you have a [neocd] section in it now, this setting is "disable_irq1", so to disable rasters you must have : [neocd] disable_irq1 = 1 By the way I re-uploaded the dos 0.64.7 version without the 44100 Hz hack, so you should be able to use 44100 Hz now if you re-download it (but it will be slower so it's probably not a good idea).

Yaah it's a sdl-1.2 bug normally you shouldn't see any switch change (these modes use the same timings so there should be no switch at all). The best fix in the lonng run is to use sdl2, but it's easier said than done for now, maybe later. Meanwhile use a fullscreen window instead of fullscreen, eventually without borders, it will feel like fullscreen but without the annoying switch.

Actually it does but I rebuilt sdl lately and forgot to remove their defaut setting which sends all output to the stdout.txt and stderr.txt files in windows. So you'll get the output of -listinfo in stdout.txt. If it's a problem I'll rebuild sdl with the correct configuration this time... For the source file, true, you have to use -lsf with a game name for that. Does it matter to have this for the whole listing ? Also I slightly modified the output of listinfo a few versions ago to include the region of the roms, it shouldn't change anything since it's at the end.

The 0.64.6 version from last week was just a quick release to play with translations, here is the real thing... So the big news are the french and spanish translations (thanks to luixvayo here on this forum, you can still visit the topic if you want to make another translation, you don't need any coder skill, it's just about typing text in an easy to use program, the topic is here : http://www.1emulation.com/forums/topic/35440-the-big-translations-topic-was-compiling-raine-the-easy-way/page-2 ). I must say he translated almost everything, I just translated the most important parts for the french one, too many texts for me ! This translation is quite huge and quite crazy, even most of the dipswitches are translated ! The other big thing is a long overdue update to the shaders. Sorry for the long delay, but it's not my speciality, I just happened to find some stupid bug in the shaders handling so there are now a few more supported shaders, and some which were not working (did they ever work ?) are now working. Don't get too excited though, the new supported ones are not the most interesting ones, but still it's interesting to have some more stuff... and there are some effects I had never seen before ! Except that if some people are still interested in the dos version to run on some old hardware, the dos version has finally been updated, with a return to seal because it's faster (I finally found a real tester with some really slow computer to do the testing !). You can visit the topic about fixing issues for the dos version there : http://www.1emulation.com/forums/topic/35437-raine-dos-bad-sound/ Long version short : it's a success ! Except that a few small fixes for the gui, for the format of the history.dat text, for the test mode of bublbobl which didn't work anymore since the last update. All in all, a good update, especially with the heat lately ! Oh yeah, the download area is there : http://raine.1emulation.com/download/latest.html

lol, it's specific to the ym3812, there is no ym3812 in cps1/cps2 or neogeo hardware, plus I doubt anyone with a modern setup would have an hardware ym3812 (or the equivalent). So no, no luck for you on this side, unless you want to buy a new dos machine at 400 MHz, but if you do, say good-bye to the shaders !

For the 44100 Hz, it's because there was an old uncommented hack in the code replacing the frequency by 44098 if it was > 44098. There was no comment explaining why. So I enabled it again but I think the sound dialog doesn't check 44098 and enables 22050 when it sees 44098, too bad. If you want to test the real 44100, use the build from yesterday (it's slower than 22050 of course). Oh well I'll probably revert this to 44100 then... Nice to know everything else is working though, and 44100 is not really useful for dos anyway, it's useful mainly for neocd music, even neogeo music is not at 44100 Hz. From memory raine reads its list of modes from the vesa bios for all the vesa categories (not modex and vga).

Ok, here is what is supposed to be the final dos build, I have tested it in dosbox and everything seems fine AFAIK : http://raine.1emulation.com/archive/rained-0.64.7.7z So the changes are : seal initializes the mixer to max volume and I have restored a very old setting "use emulated ym3812", you can now find it in the sound options dialog and it's saved if you change it. Until now raine has always used an emulated ym3812, except in the very old days. The reason being that even when I continued the development starting from 2000, I hadn't any hardware ym3812 so I could never test this setting. If you uncheck the box and so you say you don't want to use an emulated ym3812, it will try to use a hardware one, I guess you are the kind of person to still own a soundcard which has the real hardware chip ! Test this with bublbobl for example. If you happen to set this to use the hardware chip and it can't find it or can't use it, then you'll simply hear no music at all when starting the game (when really starting the game after inserting a coin, the few notes when starting the game emulation do not count here). Tell me if you succeed to use this hardware emulation, I was never able to on my side ! I don't think I'll restore the setting to the non dos versions, it's very unlikely to have this hardware chip nowdays and people would probably not understand why it produces silence on some games ! Of course the advantage of using this setting if you really have the chip is that you'll get super fast sound processing, plus this will be the real thing, not an emulation !

No no I don't do os wars, if people are happy with windows it's fine for me, it's just that I want to remain free to do what I want, and they are also free to do what they want, force no one !

!

Oh no there is still a lot of diversity in linux ! I'd say the biggest problem we had lately was rather the fundamentalists who tried to make everyone to use systemd, like it or not. I had to migrate to gentoo because of this (because they actually almost succeeded, almost every distribution obliges its users to use systemd, including debian ! it's the biggest problem, it changes so many things in the system that you can't just uninstall it with a normal distribution). for my main computer, I keep the old laptop on debian testing, and it still has issues with systemd, it's usable though, but I prefer to stay away from it ! And for the graphical env, lxde on the laptop which is light and fast for old laptops, and enlightenment 0.19 on the main computer, which is still in dev, but anyway I like it. It's like lxde but nicer. It still has a few issues though but nothing major. And its terminal, terminology is really good ! Good news for 0.64.7 finally ! I think the soundblaster driver includes the soundblaster 16 too, I'll have to check that in the docs but I am almost certain of it, don't worry raine is very bad at generating 8 bits samples it couldn't possibly work, it's obliged the samples are 16 bits here. I'll check the old docs and the old source about how to restore the mixer and I'll make a new build, but tomorrow now (23:33 here, and it's still more than warm !). In your tests, could you test bubble bobble ? I made some rather experimental changes lately on this one, on the concept of the game which never slows down, but I might have pushed it a little too far, just check how it runs on a slow machine... Happy !

Impressive collection for sure ! Well I guess I can always travel to Barcelona to fix all this, it's not that far (let's wait until it's less hot !). But there is still hope ! Here is another test, 2 exes in 1 archive : an updated 0.64.7 one still with seal which should initialize its sound and keep it much more easily. I advice running it without game first just to initialize the sound, then quit, then load a game with it for extra safety. After that use it normally, assuming you heard something. By the way the mixer is very low with this, there is a way to fix that, but make it work 1st and fixing the mixer will be easy. And Raine517.exe which is a normal 0.51.7 with allegro sound in it, just to compare what you currently have, does it work the same ? Good testing, here is the link : http://raine.1emulation.com/archive/rained.7z EDIT : I have not such a fascination for this kind of old hardware. I preferred when computer didn't contain any fan though (the time of the atari st, the amiga, the amstrad). It can be done with some embedded computers today, arduino like, but it's not the same, and you have to make it yourself. And I agree the old toshiba laptops were excellent quality and made to last, far from what you get now. For the hardware, I also have an athlon64 so not a super powerful cpu but better than a p4 though ! The bigest advantage is that it has 4 cores, which is extremely convenient for compiling (make -j4 launches 4 compilations in parrallel, it makes things incomparably faster !). It had 4 Gb of ram until recently because even in win64 most programs being 32 bits it doesn't make sense to use more than 4 Gb. But lately I tested a lot of skyrim mods and there is a very bad handling of textures, they are clearly kept in ram even after they have been transferred to the video card, so I reached the limit of both my 4 Gb of ram and the video ram of my card. So I updated both because indeed all this stuff is very cheap now. Having 8 Gb feels like having some kind of super computer, but it makes a real difference for this kind of usage and it's very nice to use. And for the rest I use it mainly in linux when I am not busy testing stupid mods in skyrim, and here the extra ram can always been used, at least for a super giant disk cache !

Impressive your collection of old hardware ! I happen to have an old laptop from 2007, but compared to yours it's ultra modern ! Ok, worst than what I thought then, I'll take another look later. Weather was supposed to becomes much less hot today, and I am still feeling like I am living in Panama ! Anyway... Thanks for all this testing at least, too bad it didn't work !

From memory 0.51.0 was clean and had no reference to sdl when building for dos, but anyway... I wanted to try to build 0.51.5 and 0.51.6 because 0.51.6 is at the beginning of the git repository, and there is a patch I would have liked to check just before that, but the sources are not available, so it would be messy to build them. Then I realized that even 0.51.0 is much slower than 0.28 in dos when sound is enabled ! That's obviously because we switched to allegro sound in later versions which is much more stable than seal, but also clearly slower. So I decided to try to rebuild a 0.64.6 version based on seal. It was tricky, in dosbox it works only once, after that it doesn't detect the soundcard anymore and I have to relaunch dosbox to make it work ! Also the sound initialization is slower which makes the sound bad when the game starts but after that it seems ok and it's definitely faster. So try it, it's on the main download page there : http://raine.1emulation.com/download/latest.html If you can't initialize your soundcard with it I would advice to reset the machine and then launch raine again, it's probably the equivalent of restarting dosbox ! Good luck ! (if it doesn't work I might find some other ideas...).

Woa, you are really the master of translations, I have made around 500 translations for the french part, you are at 1200 in this file ! Impressive ! For info the original translations in 0.28 were very far from that, but there were much less functions in 0.28 too, it was only about 100 strings to translate... Your idea was good, normal to take it ! I'll probably make a new binary soon then, but I am curious to hear about your compilation results ! EDIT : a few more updates you might be interested in : 1st, I removed the source references from the po files and raine.pot. Because it made git diffs totally crazy, just add 1 line in a file somewhere and you get a bunch of updated translations just because line numbers change. Plus you can easily find the texts from msgid by browsing the sources so the info is useless. I have removed it from raine.pot, french.po and es.po in git. Tested with poedit, it doesn't mind and finds everything as usual, even updates of raine.pot. It's good to have these files in git, but not at the cost of a super giant diff for each small update done to the sources, especially when it doesn't change any text. 2nd : slightly updated raine.pot with strings using command.dat for the inputs, it looks like "Player1 _8" for "Player1 Up", "Player1 _2" for "Player1 down", etc... It's just in case you want to translate the "Player1" part. Sorry it's repeated for every input added, it expects a constant string here so it was easier to just copy and paste. Also using poedit it's easier to locate useless repeated strings, like "100k only", "100K only" and "100K Only" ! So I removed a few of these... 3rd : while testing I found some small bugs like the short cut keys to select a command in the menus still not working correctly, and the history of a game not displayed correctly (lines too short). Fixed both. EDIT : and finally removed the very long switch/case to use a function to convert inputs to command.dat format, the result is that there is only 1 string to translate now, "Player" alone, big simplification ! Notice that for now autofire inputs won't be converted because it would oblige me to do messy things in c++ (multiple inheritances and virtual inheritance, way too complex for this), so I'll just pass for now.

How did you get this s68000.a file ? Normally it's a s68000.oa file that you should get ! You can generate it manually if you want, for the optimized build it should be nasm -o dos/object/68000/s68000.oa -f coff -O1 -D__RAINE__ -DRAINE_DOS dos/object/68000/s68000.asm But anyway the makefile shouldn't even use any s68000.a file in its link unless you edited it, which you probably did ? but you really have to be motivated to use a dos environment for that you can't even copy/paste from real dos ! Since you didn't reply about my proposed test builds, I guess you want to succeed in a pure dos environment ? Well good luck then ! (quite impressive !)

The implementation of your ideas : I just added some code to re-use the graphics from command.dat in the inputs dialog for ingame controls. The advantage is that it's easy to do and these graphics scale with the dialogs, the disadvantages being that I lack a few graphics (coin and start keys mainly), and that they are not perfect, maybe I should try to improve them but it's really not my speciality ! Anyway I'll keep it like that, we'll see how others like this. Also it's a good idea to remove the "c-code" comment for the transparency strings, even for me it removes a warning which was seen as an error by the makefile, so now I remove these 2 comments everytime I regenerate the raine.pot file.

For the forum maybe there are some issues here I don't know, post to alpha if you have a doubt. For nasm, searching for "nasm exit code -1" in google gives this : http://sourceforge.net/p/nasm/mailman/message/26417391/ apparently it's the joy you get from trying to build in a pure ds environment ! I am not sure about this, you are on your own there, but they say adding a flush to disk might fix it, I don't know how you flush the disk buffer in dos though. If you want, I can also prepare a few builds to test for you (like 0.51.5 and 0.51.6 for a start). I could always remove them later and it will be much faster for me to build them. Yeah even in the dos days I have always hated the 8+3 limitation for filenames, so raine has used long names very early, I forgot about that because even when using djgpp I used it in a long names environment. (in linux there has never been any short filename !). So once you have migrated to long filenames, you never look back ! EDIT : if it's really a disk cache problem, the easiest work around is probably just to wait a few seconds after you got the error and then just type make again, it should work the 2nd time if nasm produced no output the 1st time !

Hi ! Don't apologize for your lack of time, at least you are willing to try to fix that which is quite incredible already ! Well for dos you need a lot less dependancies than for windows so it's much easier. For the compiler you can use the same link that I posted earlier if you want to compile from windows, it works also from windows, or djgpp which might also work for windows (not sure fore the recent versions,maybe). After that you just need : zlib and libpng (use google),and allegro (the one from the Extras page of rainemu,there : http://raine.1emulation.com/download/extras.html at to bottom of the page, allegro 4.2.2. It has some hacks applied and apparently they work since you tested it for the rebuilt 5.10 version that I posted earlier (well I had added a few more hacks but as I said it probably made no difference). What i can say about this : the sound problem is probably a symptom, not the cause of the problem, so I am almost sure it's not the sound emulation which is the cause here but something else which slows things down, but I can't tell you what. Well you can try to rebuild the 0.51.0, and if it works try to update the versions one by one until you get some problems. There must have been some other problems since 0.51.8 dos was silent, but it seems like a reasonable approach, but it would take time. Building the dos version is quite fast though once all the tools are installed. For now I have no more idea on my side, the biggest problem here being that I can't reproduce the problem, I would need a really slow computer for that.