Tux

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 !

The slow part is probably related to the sound too, disabling sound would probably make it fast again. Sorry to hear that but I can't do anything about it, I compiled this version just for the very few who can still use a dos version, but I can't test it with my normal hardware. There is an old unused pc in a corner, but it's still a 1 GHz, so it might even be too fast to experience this problem, but anyway it's in a corner and it would really not be easy to test a recent raine on this... You know hardware is less and less expensive ? You can even buy ultra mini computers on a board nowdays for less than 100$, I'd say it's time for you th leave this computer you use behind...

Yeah after some more time on this one, it's the limit of a hack here which allows neodrift (among others) to work. If you tune this hack so that the scene in this kof94 intro is not clipped, then neodrift doesn't work correctly anymore ! You could say "get rid of the hacks". Yeah well easier said than done, mame uses a full rom of zoom data here, and I don't want to use a full rom for that. Without the rom apparently the only thing which works so far is a collection of hacks... maybe there is something better to do than that, but it's not easy to find. Maybe later, but not today !

afaik neogeo cdz uses some original code, and the psp version was open sourced ! Anyway I might try that later, it should be possible, just very dangerous ! For your hd3000, it seems it supports hardware shaders (from wikipedia). Some intel cards had software support for shaders which was extremely slow, so at least this one is better, maybe you just found a shader it doesn't like.... or the card is still slow maybe ! (by the way I just upgraded my system, it's not for raine, it's just that i lost again too much time testing mods in skyrim and I hit the limit of my system there. Since prices on ram and on graphics cards are very low now, I upgraded. I doubled the ram for 1/3 of the price I had paid this same ram a few years ago !).