Tux

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 !).

For the dsw no it depends on the machine emulated, a lot of them only read these dsw at boot and after that they ignore them, so you need to reset the game after changing the dsw in this case. Now I am not 100% sure that all the dipswitches are correct but final fight should be correct normally. For the shader, yeah the intel integrated card is not renowed for its speed, try some other shader or try to disable the shader entierely... Hello again in this new place, by the way !

I had a look at this kof94 issue because it looked like some easy cliping error, but there is nothing easy left in this driver now ! Actually at this point the y coordinate suddenly becomes < 0, and it goes through quite a lot of transformations necessary for some specific drivers. Touching this thing is quite dangerous. The good solution would be to rewrite this part entirely, but it's no easy task... I'll think about it ! (not sure it's worth to take the risk to break everything just to fix this small annoyance... but maybe it's possible, I'll see).

No worry it's just surprising that such a simple thing as this sky animation can create such problems so it will take me some time to check this... later then ! EDIT : this little thing comes from an old fix for blazstar stage 2 ! The fix is probably not perfect, there is too much inaccuracy when reading the frame counter in the emulation, I am probably missing something, but this little thing is actually *VERY* tricky ! So I'd suggest ignoring the sky at the end of stage 1 for now, easiest workaround for now, I'll try to find out a better solution for that, but it will take time ! EDIT 2 : it's finally fixed, and pushed to git ! It might also fix the problem reported by mer-curious, I'll have to check that later. ! For the record, the cause was really a detail : I just computed the frame counter for the animations after drawing the sprites, and it needed to be computed before! I really didn't expect a game to need this kind of precision but apparently the frame counter is updated during the vbl before starting to draw the screen so it makes sense. Anyway with that blazstar is totally fixed, end of round 1, and the whole stage 2 ! I'll take a break now !

Ok I was finally able to reproduce this, you have to saturate the game with buble so that it happens ! I had never tried that before ! Ok, I'll investigate... EDIT : what I found so far : - hard to reproduce, when I restarted a new game I was unable to reproduce this, even at stage 11 and even with fast bubbles I don't know what's needed exactly for this to happen but it seems quite hard to reproduce from scratch. - it's been there for a long time, even raine 0.60.1 had this already, and so it's not a recent change which produced this at least. Well I'll take another look later... EDIT 2 : well I found a work-around, a hack. Apparently you can saturate the cpus with bubbles and if they become too busy then the interrupts start to be on wait and to fill the stack, and since the stack is very small it can quickly crash everything. Now I would love to be able to reproduce this by myself to know if it's specific to raine, but I guess it is, and then find why, but I can't, without your save I can't saturate it enough to create the crash... ANYWAY ! The work around (dirty) is simply to add some cycles to the cpus when they become saturated, this way you won't see any slowdown in the game, and it will never crash ! I tried that with your save, it works perfectly. Of course the real hardware can't do that, so it's quite disturbing, but oh well... I think I'll keep this fix anyway ! EDIT 3 : after some more thinking I think I know why raine crashes here, it's because it doesn't handle the interrupt lines and so there can be many irqs waiting on the stack, which should never happen. So the best theoric fix would be to handle this interrupt line here, but it would be less fun, so I'll keep this work around for now : the game will never slow down anymore !!! (if you use git, the fix is committed, otherwise you'll have to wait for the next binary...).

Actually it's not true for all romsets, keeping compatibility with ever changing romsets can be very tiresome at times... bublbobl for example is not the same mame set, but here it's a specific reason, the main bublbobl set in raine uses a 68705 mcu where mame says the main set uses a different mcu,so it's not compatible and we don't emulate this mcu at all so we'll never use this set ! But yeah for most romsets I guess we are compatible !

Well the name of the super admin in charge here is Alpha, so I guess you should send a message to him (yeah it's not me anymore, but I am in charge of this raine forum !). I was actually glad to leave the forum admin part to someone else ! Anyway I sent a mail to him with the url of the topic...

Yeah yeah still trying, opened to suggestions for now.

I really wonder how you did that, because it's probably the arcade game I play the most, and I still play it from time to time, again lately to add the cheat to emulate the bublredux level skipper... Anyway I just tried it on a fresh install on a very old pentium4 computer (I am not at home), and I played level 11 without problem, I stopped at level 12. Well no idea, I used the bublbobl set, the original one, nothing special default configuration. Try to make a savegame just before it happens and if you can reproduce it easily send the savegame and explain how you do it !

Hi, Tux. Thanks for the maintenance release. I’ve come across some graphics glitches in Marvel vs. Capcom. Take a look: Here’s a savestate before we fight Onslaught so that you can check it: http://www.4shared.com/file/oTi45F_Pce/mvsc.html I don’t know if it matters, but I’m using transparency effects and the SABR shader. By the way, I’m getting this message when trying to use the Curvature.OpenGL shader: When I return to the shaders options, it shows “None”, so I guess it didn’t work. Is this a problem in Raine or in the shader? Still talking about the shaders, is there a key to cycle through the shaders, showing their names? It would be a nice feature to quickly check their effects! Finally, I noticed the blend files are the only supported files which don’t have their folder created by default, no? So I’d like to know if you could add it in the next releases, maybe just to point new users where the blend files should go. It would also save us the job of creating it on a new install/unzip. And one last thing, there’s that old request left of checking the raster glitch in KOF’94’s Japan stage. I guess this is very unimportant, but if you are motivated and if you find it easy to fix, why not? Perhaps it could benefit some other game more significantly. Here’s a savestate right before the Japan Stage shows: http://www.4shared.com/file/_c_VOCX_ce/ncd_kof94.html The glitch happens when the ground becomes black at the end of the camera movement over the street (moving to the fighters’ direction) when the stage begins (it’s actually the stage animation). Here’s a screen capture: It doesn’t happen in FBA nor in the real NGCD console as you can see in this video (please skip to 24:00 to check it quickly): That’s my quick feedback for now. Thank you so much in advance for your great time and attention.

Just a short message to check the forum is ok, but it should. I might copy and paste some topics from the old forum later, but for now I am not sure it will be useful... !