Tux

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.

lol ! Just remember that the binary was updated for that, if you can't compile yours I'll release a new one but it's less convenient it's the "stabilization phase" where I fix things quickly and I would really not like to publish a new binary evertime I fix something... Normally it's harmless, it's because it's a string which looks like a printf string where the % sign introduces a format, but here it's a real string with a real %, no format. Ah ? I don't know, I keep everything as-is, and I don't get any strange character in raine here, something specific to poedit ? Anyway you can remove this line without problem, it's just a comment normally. lol ! I forget you are on the other side of the world, it feels quite strange ! Well here I change my habbits, since it's very hard to sleep during the night, I sleep less during the night and when I can during the day, like some sailors... ! it's said it will cool down on thursday, quite a good news for me ! Ok, pushed to giti, I have already made a few updates on my side... A few hints : be careful at not changing the locale while editing your files, it happened to me because I tried to edit the french file on a computer which used a latin1 locale instead of utf8, it wrecked havoc in the file it took me quite a long time to fix things. Otherwise the comments with the place in the source files where the original text are there in case you forget what the text is about, but since you have never seen this code it's probably not very helpful for you... Well maybe just the filename can help sometimes. Otherwise there are some dipswitches where even I don't know what they mean exactly, so when you find something like that, just don't translate it ! And don't feel obliged to translate everything of course, we have already done the most important part anyway. Also even if you don't update your binary you'll see the updated texts in the gui in most places (except the ones I fixed lately like the headers). It will work for inputs and dipsitches for example. That's because everything which is displayed in the gui is sent to translation no matter what. Also, I have added the ability to translate the strings which appear at the bottom of the screen during the game, but be careful with this : in the original raine this uses an old font without any accent, and even if you use the opengl overlay as it's called which displays this texts with a more modern font, it's still a latin1 font, not an utf8 one, so the accents will still be broken. 3 possibilities : either leave this in english, translate without accents, or convert your translation to latin1 (not tested here). Anyway there are not a lot of these texts, it's a very little minority, but they are different from the rest. That's all for this time ! EDIT : for info, raine.pot to version 0.3 with loading messages included (I had forgotten these). It's just a few messages more, about 1560 strings now !

Just pushed the big commit to translate also the C part, it's huge, hopefully it doesn't add any error. For info I have not even started to try to translate this, the number of strings jumps from about 300 to about 1500 ! There are stupid strings inside, just ignore them, I tried to remove as many of them as possible but some have to stay. When there are formats like layer %d, keep the %d in your translation, you'll get a warning if you don't anyway. I'll go back to this when the weather is less hot. For now raine.pot + all the source files updated.

Woa, you are rather energetic about this, let's see... Yeah, special case for the dialogs headers, you'll have to get a new binary for this, how goes your compilation then ? thanks by the way, I hadn't noticed, it's the same word in french. It's a dynamically initialized dialog,some other kind of beast, which means the "Neo-Geo bios" string is simply ignored normally here and overwritten by what you see. It's fixed, but you'll need to update your translation (it will look like "Neo-Geo bios: %s") These are because I use some script to locate the strings to translate, it would be way too long to do it manually, and it didn't appreciate the "(" and ")", I taught it about them... Dynamic again, same rules apply... This time my automatic tool didn't like the "+", "<" and "="... Yeah it's because these strings are used elsewhere already so they are already known. For the inputs, I'll update them all later in 1 time, but not now (big thing). Yeah I know but actually the date and time is a constant generated by gcc so they can't be translated, and so it doesn't make a lot of sense to translate only "compiled on", plus it would be messy to translate just this little part of the string... ok It doesn't make much sense to translate the console, it's a dev tool, most dev tools are in english. Plus there is a big help in the console, you would have to translate a vast amount of things, try to type help, then you have some help for almost all the commands (help command). So no... Woa, it was actually quite long, oh well I'll probably push an update for the inputs some time today or tonight... thanks ! EDIT : ok, verything pushed to git, the files are growing fast, inputs later.

Ok added your file to the sources, you can see it there with the others : https://github.com/zelurker/raine/tree/master/locale It's more convenient than grabbing them from an http link. And it will be in next release then, thanks again ! By the way the raine.pot there is already more recent than the one you used for your translation, about 20 messages more, so you can grab it from git if you are curious !

Ok I got the file from mega, and this time the attachment shows in your post, so it's ok ! Good news for the list, yeah I probably forgot some texts here and there. For the hard drive, smartmontool is a good tool to know where your hard disk is in its life, I don't know if there is a windows version though, I think there is, yeah it's there : https://www.smartmontools.org/wiki/Download read the doc, but it's rather good. For the idea of using command.dat, yeah well it would do for the arrows and the buttons when using neogeo, but not even sure they could be used for normal arcade games. Plus the graphics don't really exist in command.dat, it's just an ascii file, I had to draw them myself after looking at a few pictures underscaled, so they are quite far from perfect, but it's better than nothing ! And I didn't add yet the ability for the gui to have nice icons beside the text, but it's probably very easy to do anyway, this gui is extremely extensible and easy to program at least (contrary to the gui of the dos version which was nice to look at, but a nightmare to program !) And good for the mo file, it probably did the same thing for me but I didn't notice since I already had a mo file... Good for poedit then !

Oah ! Congratulations ! I am impressed ! How did you do to generate the mo file, did you find this in poedit or did you download gettext ? I didn't find the attachments ! Where ? It's not a pm, it's not in the mails, nor in the forum ? I am lost ! For the untranslated parts, you can make a list. For now : for the dipswitches it can be done, but I'll have to change the way things work, making _("...") just a dummy function, here just to be able to locate the strings to translate when creating raine.pot. Same thing for inputs. Something else ? And thanks for the dream idea ! EDIT : just updated the pre-compiled packages, added jpeg.7z, gettext.7z and updated the sdl libraries. Let me know how it works if you try this compilation !

Ok it's still about bug fixes, but it also adds some experimental translations using gettext. For now there is only the french translation, it should be detected automatically in linux and windows if your system uses the french language. If you want to help you can visit the forum there is a topic on how to translate this there : http://www.1emulation.com/forums/topic/35440-compiling-raine-the-easy-way/page-2 Except that there is a fix for a surprising bug in bublbobl, for very fast players who can saturate the machine with bubbles everywhere... this bug has probably around here for very long actually, I chose an original fix, the game won't slow down anymore, so it will never saturate now. And a final fix for some animation problems in blazstar, it might affect some other neocd/neogeo games but it's the only I knew with this problem. There is also a new dos build, but I heard it's slower than 0.51.0, so it's investigated for now, it's in the old versions for now, 0.64.5, even if it contains already most of the 0.64.6 changes. That's all for this time, this version is mainly to allow people to test the translation stuff... EDIT : also there are some new pre-compiled packages for those who want to try to compile raine in windows, you can find them in the dev section. But since some dlls changed and some new ones appeared for this version, I'll already have to update these soon... ! And the downloads are here : http://raine.1emulation.com/download/latest.html easier url by the way...

Hehe, yeah. Well I just finished the french translation. For now still a lot of things are untranslated, I was too optimistic at first. Like the controls names when customising controls. But it's a nice start, most of the gui is translated now, which is quite impressive. I'll probably release a new binary tomorrow so that you can have a look, but I need a break for now (been doing this for at least the last 2 hours, more if you count the time to add gettext functionality !). Meanwhile I'll update the raine.pot and french.po and es.po files with new text I have added since I last posted them. For info I did mine with gvim, because I am fast with gvim and I didn't find how the automatic translation worked with poedit (I didn't search for very long). One of its useful features it to be able to add the new strings to translate when raine.pot is updated. Well I did the same using gvimdiff, a special mode of the editor where you see what changed, so everybody does as he likes ! I'll edit the previous post when the update is done.

Ok, well I have tested and it works perfectly in windows as promised (and in linux too of course) ! Judging from your profile I guess you want to try to make a spanish translation then... So you can do it by using a program, it's called poedit there : http://poedit.net/ Or you can edit directly the text file for your language. Here is the base texts, all in english in case you want to create a new language using poedit : http://raine.1emulation.com/archive/dev/raine.pot Here is the french translation (unfinished) that I started as an example (it's just started, not done much yet !) : http://raine.1emulation.com/archive/dev/french.po And here is a file you could use for spanish, nothing done yet inside : http://raine.1emulation.com/archive/dev/es.po All these files are in ascii, you can either open them in a text editor or handle them using poedit. Inside you have a header where you can put your information to be contacted in case of future problem (!) then you have the strings in this format : # a comment which starts by a # and which shows from which source file the text comes msgid "the original text in english" msgstr "the translation" and so on. If you leave msgstr empty for a string, then the english text is kept, which allows to test things without finishing completely the tranlsation. For now I have only put the texts from the gui, so there are not so many texts to translate finally. I don't think it's a good idea to try to translate dipswitches, or cheats, and even less history (for history you'd better translate their file directly !), nor the game names. So I think it's good as it is now, but we can always add more texts later if we want. For info in the end the po file must be converted to the mo format to be used by raine, I am not sure poedit can do that. Normally I do that from the command line like this for the french file : msgfmt -c -v -o raine.mo french.po if you want to try that you can get a windows distribution of gettext there : http://gnuwin32.sourceforge.net/packages/gettext.htm I guess it works the same way and you would need to use the command line for that (gnu tools love the command line !). Otherwise I can make the conversion for you. EDIT : update done, all the 3 files are updated, you'll need either to refresh them manually in your browser or to restart your browser.

If you are really interested in making a translation, I could make raine to use gettext. It would allow you to just translate the text in some text files, then you send the text file to me, I convert it, and you get your translation. Normally gettext works in linux, windows and about everything except dos, but dos used something else anyway. It's not too hard to do on my part, it's just that I never thought seriously about adding some translated text... It would allow non programmers to send their translations for inclusion. I still need to test this in windows, but normally it should work !

Sorry guys, at least it allowed me to update this and edit the config files in bin, you won't have to edit anything anymore normally. And added freetype too now. Now maybe I still forgot something, we'll see how it works ! Now be careful the 7z links seem to display the files directly in the browser as if the web server here didn't know about .7z files. The weird thing is that it works from the main download page though. I'll have to send a message to alpha to see if he has an idea...

You'll probably have some problems with the sdl-config / libpng-config files, they still have the absolute paths from my install here. Well if you do edit these files with a text editor (they are in the bin directory) and replace i686-pc-mingw32/usr by nothing, it should fix the problems.

Ok, good news it means it's not because of some lost hack finally, but I'll need some time to pinpoint the cause then because it's not obvious. For the size it's just because the old 0.51.0 binary was packed using upx, it produces a slightly smaller exe when unpacked (6.4 Mb instead of 6.7), the difference is probably the result of some optimizations and alignment used by the new compiler. Ok, I'll try to reproduce the sound issues in dosemu then, and I'll post later. Thanks for the test anyway ! EDIT : I can't reproduce your sound issues, even with an fps between 20 and 30 in dosbox (which now works !) I still get a perfectly clear sound ! Oh well, in this case I need I'll have to make a few more tests with you then, there are 2 possibilities and I can't really guess here... later... Ok, here is another test, it's 0.64.5 with the sound engine from 0.51.0. The catch is that there is almost no difference between the 2, and the differences shouldn't matter at all, but I have no other idea for now, so give this one a try : http://raine.1emulation.com/archive/rained-test3.7z

lol, it's not mingw to build for dos, you need djgpp + an old allegro lib ! Anyway I didn't even test this build myself I just compiled it and uploaded it, maybe I was too optimistic about that, I'll take a look a little later then... Don't worry it's not too bad doing this. The reason why there were no dos builds is because I couldn't do or get any serious testing, now at least I have a serious tester ! EDIT : same player plays again, new link : http://raine.1emulation.com/archive/rained-test2.7z Same rules, just the exe, it was a stupid mistake from me which was crashing the loading dialog. That's what happens when I don't test things.

Ok, you can find the pre-compiled packages there at the top of the page (section dev of the downloads) : http://raine.1emulation.com/download/dev.html There should be almost everything, tell me if I forgot something (it actually from my linux installation, but it should work without problem with mingw32). As it's said on the page : unpack this where you have your mingw32 bin lib and include directories

Ok I found the source for 0.51.0, and bad news there doesn't seem to be any obvious difference for sound there (for the dos part). So here is a test build of 0.51.0 using the latest tools : http://raine.1emulation.com/archive/rained-test.7z (just the exe inside) get it, put it in a raine directory and compare it to your normal 0.51.0 binary, does it work the same way or not ? (you might be obliged to use a right click on the link and use "save as", the web server here doesn't seem to know about 7z files...).

Well you need time to master it, but it's worth the time spent ! In short, in linux distributions handle dependancies automatically, you say you want to install raine, so it will install all the dependancies 1st automatically. Normally when compiling a win32 program from linux you loose these dependancies but gentoo has the same system to be able to install dependancies the same way when compiling something in windows, but gentoo is really specialized for developpers. I could at least put a binary package for sdl_sound because this one is not that easy. For all the others, it's download the package, extract, run ./configure, make, make install, that's all. So post again if you want to try a binary package for sdl-sound.

Try the rdtsc display to know what eats your cpu time (press F11 3 times), and report which are the highest numbers...

I'd say maybe the easiest way is to do it under linux, because that's what I am doing, and if the distribution is not too dumb it makes getting the dependancies very easy ! Otherwise it's not too hard to do with mingw, you just need to get the dependancies yourself, but it's documented on the download page there l: Oops broken link, I'll fix it later. Well meanwhile you still have the logiqx notes there : http://www.logiqx.com/HowTo/RAINE32.php Anyway from memory you need : (everything can be found by using google) : - zlib - libpng - sdl-1.2 - sdl-image - sdl-ttf - muparser - sdl-sound and it's harder for sdl-sound because if you want to be able to play mp3s containing id3 tags, you need to get the latest mercury version instead of the official latest version, but you can start by using the official version 1st anyway. By the way this mercury version uses libmpg123 for decoding mp3s, so you need this too, search for mpg123 (easier to find in linux, it's included in every dsitribution, but it can be compiled in windows too). Good luck ! (it's long, but it's not too hard, and the reason why I don't make a big package containing everything is because it would have to be maintained when there are updates and it would be quite boring). Also you can compile without the console (edit the makefile, find the place where it talks about HAS_CONSOLE and comment it, there are comments explaining this, it's at the topof the makefile). In this case you don't need muparser.

Ok, I have rebuilt a gcc for dos thanks to this : https://github.com/andrewwutw/build-djgpp It didn't work out of the box, it required some editing but it seems to work. Now the bad news is that I get a crash when running bublbobl with an optimized build, and not with a debug build, which means this gcc has problems with optimizations ! (or maybe it's because dosemu doesn't like pentium3 stuff... hopefully !). By the way which beast were you talking about, because raine is now optimized by default for pentium3, maybe I should revert to pentium for the dos version then ? Anyway it was easier to rebuild than what I thought, I hope you'll be around here for testing soon ! EDIT : ok, it was indeed the pentium3 optimizations, so I made a build for pentium instead, it's uploaded you can find it in the download section : http://raine.1emulation.com/download/latest.html Test this on your hardware compared to 0.51.0, and if it's still slower then test without sound (to know if it's because of the sound or if it's because of something else). Compared to the last dos binary well it's updated to the very last git version, and the allegro lib used has a few hacks added, for me there is no difference from these hacks but maybe you'll see more effect on your side... Good testing ! (also it uses gcc-4.9.2 which is incredibly recent for a dos build !).

lol ! Try linux one day, at least you'll discover a serious command line, even though you can do without it nowdays... after using this for a while you wonder how you could do without it for all this time ! I had a gus too in the old days, it finished burnt after a hardware problem... I can't say I am a big fan of hardware problems actually ! Well I did a quick test of how things run in emulation : with dosbox I have serious speed issues and the sound works only in 0.28, it seems to freeze for 0.51 and 0.63. With dosemu it works fine, sound is ok in 0.28 and 0.63, no sound in 0.51 ! So you see for me all is ok ! Plus I'd have a serious problem to be able to rebuild this I need a dos compiler, and I don't have any right now, and it's always very long to build... when it works which is not always the case ! At least I was able to see that both 0.51 and 0.63 use the same allegro lib, so if there is a difference in the sound output it means some hacks were applied in the 0.51 one but not on the 0.63, and I have absolutely no idea where these hacks could be now ! (I still have an allegro-4.2.2 for dos here in the archives, but I guess it's the one used for 0.63, no hacks to see anywhere... !). Oh well if one day I can build a dos compiler again and you are still around to make some tests, I'll try something, but it's not soon apparently, sorry ! EDIT : I have made some speed tests too with dosemu. In 0.51 it can't make any sound, when using vesa 2.0 linear modes and bublbobl I get about 3000 fps during the intro. With 0.63 I have sound which slows things down to about 1500-1700 fps, when disabling sound in 0.63 I also get a little more than 3000 fps ! At least you used the vesa linear modes didn't you ? (although I am not sure it changes a lot of things for 320x240 mode, in this one the whole video ram is probably mapped in 1 time, no fancy access involved). So again, everything seems fine from here !

hehe, give dosbox a try, some games can actually be played better with dosbox than on our original old hardware because it emulates general midi, and very few people had this in the old dos days ! Ok maybe not everything runs, but probably almost everything, and a big part of this is running better in dosbox ! And what do you miss so much about dos ? Not the command line I hope, it was quite retarded in fact (with 4dos it was better, but still... !). I don't remember clearly what changed between 0.51 and 0.63 for sound, I would have to check but either the lib used for sound changed, or some old hacks were applied for the sound in the old allegro lib used in 0.51 and were lost and became incompatible with the more recent one used in 0.63. So it would be hard to fix !