Tux

Don't tell me you didn't find the setting, it's pretty obvious, maybe there is a problem about that with sdl-1.2 on your system, sorry if it's the case !

I'll eventually think about it if I continue development, for now it's on hold. I just realized that it's becoming too big for me alone and it makes debuging sessions longer and longer, which is really annoying, and so the dev work is much less fun lately. So in these conditions there is not much point in putting back this banner. It's likely raine will stop here, after 15 years it was not bad I would say. I would have loved to attract more developers so that things would have gone faster and that someone else takes the lead, but anyway it was not bad.

It's obvious it's a problem with your opengl implementation, now I can't help you anymore on this, I don't know what's wrong there, maybe nvidia broke something in its latest drivers... These are not opengl 4 shaders, it's some rather old stuff mainly, but there are different versions out there. By the way you can just disable the shaders and then use the default opengl output, you have 2 options there, it should be enough, shaders are not mandatory here. To disable the shaders, select a new shader, when the list appears either press esc or the mouse button 2, it will ask you if you want to disable them, it's probably your best option here. You can also try to use the drawpixel opengl rendering, it has no shaders. I hope it helps ! By the way I won't switch to windows 10, I don't want to have anything to do with microsoft spyware mess...

Ok, sorry for the long delay, anyway it doesn't require a release to fix this at least, it's because of the speed hack for mslug2 which interferes here. So the solution is to simply disable speed hacks from the neocd options before playing this game. I'll put a fix and some comments in the code for that. Code updated in git, next release will have a workaround for this. (actually it was the garou speed hack which was creating problems here, but this started to happen because of some changes for mslug2... sigh !). EDIT : on 2nd look the problem is very specific to aof3, it shouldn't happen in any other game.

These are opengl shaders, so they depend on your opengl implementation only, I'd say your best bet is to update the video driver then... Eventually try windowed mode instead of fullscreen it might help for the menu issue you have (just resize the window to fullscreen).

You didn't even mention if it's with the neocd or neogeo version ! There is indeed a problem with at least the neogeo version, interesting that it's reported only now. For info raine incorporates the code from neocd but it's newer, so if it worked with neoraine it just means that a fix for something else created this black screen problem. Sorry I won't look into this right now, but I'll probably take a look later...

I'd say the most likely cause is a disk corruption and since it's a laptop maybe after some power failure... run a scandisk !

When it's a missing dll you see a message with the name of the missing dll if I remember correctly. Try to google the exact message you are getting, if it's really a missing dll they should tell you how to get the missing dll name, but I doubt that's the cause here...

Hi Huggybaby ! Well you might be too late this time, it's not only the small bugs which annoy me, I am loosing inspiration, motivation, and fun. I have some big commits which were waiting about adding some sh2 emulation using the asm core from gens, but finally, no motivation anymore. I think more and more about stopping here, hey it was not bad, 15 years of raine after the date where it should have stopped if Antiriad hadn't opened the sources ! At least I won't emulate some popcorn machine like some mame devs lately, they really can't quit emulating things, even if it becomes crazy ! For now I take a break, if someone wants help to code on raine I am here and I'll help, but for now I think the best course is to stop here, it's becoming crazier and crazier to take care of raine alone, it has become too big now, and since I am still alone, it's really better to stop here. Sorry, but it was fun, and it's still a good emu anyway !

Sorry for the lack of feedback from here, but it was to be expected... !

As I said the fixes are over for now, if you want to code and to send patches it will be highly appreciated. Otherwise, just wait, I have other things in mind for now... Vimana doesn't have any sound at all for now, so no, impossible to override its music since there is no music to override !

Nope I have got a savestate while the fireball is flying, for me it was better, if it's not good enough well too bad, fixes are over for now, eventually for the next fixes session if there is one... Anyway I am not sure it can be fixed with the current rendering system and I won't change it.

Yeah enough fixes for the 0.64 version, this proves at least that raine is becoming too big for me alone ! At least this time I got some very welcome help from Romain who built the osx binary this time, so it's not from me and I wasn't even able to test it for now, but it should be ok, feedback highly appreciated on this binary !!! You'll find it there in the downloads section : http://raine.1emulation.com/download/latest.html A few things about the osx binary though : it's quite different this time because Romain had troubles with all the asm inside, so it's using a C version for the video functions and for the 68020 core, which is a very first time in raine. With modern cpus you shouldn't be able to see the difference anyway. A few of the fixes this time : - a surprising bug in the clipping of text in the gui which should not have been there - the fix of mer-curious fireball, hopefully ! - a fix for a crash during nam1975 demo because of a stupid fadeout effect ! - But also finally the video priorities for the gunbird driver have been added, plus a few sounds which couldn't be heard before are now played correctly (for almost all the games in this driver). - neocd music now adapts to the sample rate chosen in sound options - the fix for the bug about cawing reported just after releasing 0.64.9 ! - plus a few small fixes here and there not worth mentioning...

Ah yes I remember now, I took a look at your savestate, but there is no obvious solution, this one is a tricky one, I don't promise I'll fix it now... Plus it's not super easy to produce the fireball at will for me which makes it even harder to fix... EDIT : I think I fixed it, you'll have to confirm, but it's much better now. The fix is totally crazy, just limit the maximum number of sprites blocks on screen to 381 instead of 384 ! 384 was an old value from the neocdpsp days, I knew mame was using 381, but I never felt the need to change. But here it was worth a try anyway, and apprently it works ! The new version will have quite a few crazy fixes like that. Another example : if you launch nam1975 neogeo and leave the demo playing, it will crash at the end of the demo. It's because the game using a fadeout effect without having any track to play in the associations, very crazy bug, the fix takes 2 lines only, it's just a forgotten test, this one was found by Romain !

If you are talking about the blank string for fatal fury, it's exactly the same bug, the clipping of strings in the gui. For the shaders I'll double check it's fixed, I won't require a restart yet. There is a new version coming, with these fixes I added a few others like finally handling the video priorities of the gunbird driver and adding the few missing sounds (because I happened to play a ps2 version of gunbird and noticed it was playing some sound I had never heard before. So I made an investigation and found the sounds were there in the arcade, but not played because the z80 didn't have time to see the command !). Plus Romain who updated the osx build, plus a few minor changes. Enough to make 0.64.10. It will finally be the end of these fixes this time !

About the clipping error : it happened a lot here with some big filenames used in neocd, so it was easy to fix for this. Of course it was very stupid, sorry for the delay to locate it !

All your git changes merged, there is probably a way to enable the ASM_VIDEO_CORE in osx but for now it will do with the C core !

Ah yes I had even completely forgotten about these. If I am not wrong this c directory is from the early days of raine32 when the guy who created it first tried to revert to the C version because he couldn't make the asm version to work, but he used visualc and not mingw32, it was probably the main cause of his problems... You are in uncharted territory here, never used these files ! But it could be interesting to take a look... The idea to have an optional C version of raine is not new, I gave it a try last year to see what we could do with android (their tool to pseudo compile C code by converting it to some bytecode, forgot the name, but it's slower than java this way and it's not low level at all). Anyway it was hard, produced a very large binary with bugs very hard to track (good luck with the debugger there !). So I gave up, too many problems, too frustrating, and raine is not about some too big thing where you can't go to low level, it's the opposite actually ! The other reason would be to make an amd64 pure binary but I don't think it would be faster, even with the new registers and the new instructions, this code is insanely optimized, and anyway with modern machines it takes less than 1% cpu when running any emulated game ! But still it could be interesting. The problem is that the cpu cores can't be just replaced, they are not compatible with each other, plus most of them were modified in raine either to be faster or to adapt to some tricky emulation problems, so it would not be an easy task to replace them. For the cpu cores to take, I am not totally sure : - cz80 seems nice for the z80 and very easy to adapt. Now as I said it's not finished and what remains to do is not easy ! - for the 68k, I am not sure, there is this old unused c code for the 68020, and maybe the updated starscream to amd64 asm, but it would probably be better to have some pure C code here, and maybe merge 68000 and 68020 (which was the idea at the beginning of raine, they had the hope that starscream would eventually support the 68020 but it never happened). Well uae evolved in this way now with their core you can emulate anything from the 68000 to the 68040 with some jit options which could also be interesting. Now it would not be easy, the changes integrated to raine would need to be reapplied there, and usage of this thing is probably very different from what we have now. - 6502 : absolutely no idea. It's not used in a lot of drivers anyway but still I guess I would need to find something in this case... - and then there is the case of this sh2, I have started a git branch for that trying to integrate the asm core from a saturn emu which would fit very well raine, but I am not sure I'll finish it. Anyway I'll take a look at this, eventually create a repo on github with your sources and send the url, it would be easier to check this 100% cpu problem, but my first guess would be that this C emu doesn't work because a few of the required changes made to raine were forgotten in the C version... ! It would be much easier if you can make it work using mprotect, but I think mprotect works only for allocated memory, here it's already compiled code. You could always try to move it but it would be tricky ! There is probably a global option in osx to do that. It's called "data execution prevention", browsing google about that, I found this : http://www.cnet.com/news/how-to-bypass-gatekeeper-in-os-x-mavericks/ maybe it could help ? The other way is to use mprotect which is really tricky here... EDIT : just pushed a change to git to make this c version of the 68020 usable. Just uncomment C68020 in the makefile to use it. It probably never worked, there was something really stupid in Execute68020, it divided the asked cycles by 16 (!) before executing ! Everything was going so slowly... ! Also the speed hack handling needed to be adjusted the cycles can't be set directly to 0 with this version. And apparently the timing of instructions was just thrown to the trash in the asm version, all the instructions used 4 cycles, never noticed that until now ! Well with all the speed hacks used for the 68020 I guess it didn't really matter anyway...

Yeah when it can't execute any code in the data segment and crashes instead it's the sign of a hardened os which removes the execution permission from the data segment, it's a little over-paranoid if you ask me, buffer overflows are in the stack segment usually, not in the data segment, but I guess there are ways to inject code there too... For the 68020 crashing, in the beginning this core was the C core from uae, then Antiriad and friends took the asm produced by the compiler and started to modify it directly... Yeah these were crazy times ! Now what we have is the modified asm version and the c version is lost ! I guess the crash is probably in Execute68020 in source/68020/newcpu.c look at the comments, there is an ifdef to use the asm version for everyone, you might want to try the c version instead for you here...

Excellent news ! I am french too by the way, but let's keep english on the forum ! For info I had given up on the osx build because I didn't get any feed back for it or almost nothing plus I had to build this on an hackintosh and it was not really convenient. I have a pc built around and amd athlon64 so it's not really convenient to run osx stuff on it. For the asm code, yeah it's bleeding edge auto-modifying code, it's moved in the data segment precisely for this reason, the code segment is read-only on all modern os-es. I had found a work-around for this in osx, if you test my last osx build which is quite old now it should work and it's full asm, but it's very old stuff for me so I forgot exactly what I did ! There is a lot of asm inside even if using the c video core which should be complete now, the 68020 core is 100% asm, the 68000, the default z80 core, the 6502 core, plus some other functions here and there in the code (s files, but also inline asm in C source, usually the inline asm doesn't auto-modify itself though). So all of this requires quite a lot of testing. To test 68020, either run a taito f3 game, or gunbird. Also the z80 c-core is not finished, currently I used it only as a proof of concept to make a full amd64 binary with very few drivers inside. The rom bankswitch doesn't work which means that most drivers wouldn't work with it. I don't remember which driver I took but it worked ! But making a compatible code for the rom bankswitch is a real pain because the way mz80 works obliged to make a lot of special cases and now they are very hard to port to some other cpu core... there are some perl scripts to build a raine with only some specific drivers so you can easily build something with just the C z80 core + a good driver which will work with it. The emudx games work fine with it, that's what I used for the amd64 build, it worked fine. Yeah git pull requests are all the rage these days so if you want to make one you are welcome, or just send a simple patch either to the forum or by mail. I just checked the git log, the last modifications for osx seem to date from december 2013 already ! Ah yeah after looking at the comments I remember I was unable to build a working binary with osx 10.8, I had to do it in 10.6, but for some reason the resulting binary seems to work everywhere, it might be related to this asm problem. Notice that normally even on hardened systems which don't allow that there should be a way to make an exception and to tell it to accept raine, but no idea if it's possible in osx (it is in windows and linux at least). Search for "osx" in git log if you want to have a look, I am not sure some of these changes are necessary on a real mac, my hardware behaved strangely sometimes in osx ! I think I covered everything, congratulations for your work anyway, it's rare to find someone willing to spend so much time to build raine, especially in osx where it's very hard !

Keep your money !

That's obviously another "dynamic dialog" problem, maybe I should just require a restart when changing the language it's not done often and it would create way less problems. No idea, can't reproduce it.It's most likely gui related, linked to the new clipping of strings. Yeah it's possible to emulate, but not easy, usually there are custom weird grahpics chips in konami games. And I have no passion for their games...

That's the kind of thing I love, this one was there since at least 0.63.16, maybe more, and it's reported the day I release a new binary, after 2 weeks waiting for reports which never came... !!! Sigh ! Anyway I'll take a look... EDIT : ok, fixed, but since it's a bug from jully 2013, it's no emergency ! The fix is in git anyway...

Yeah maybe, thanks again for the help anyway !

Ok, sorry for the long delay, I thought I would have some testing for the dos binary, but it's been more than 2 weeks now, so maybe the dos version is back to sleep mode then ! Then I spent quite some time patching the openmw binary, and then there was this upload problem in 1emulation ! Anyway, I thought that after all this it would be nice to upload a final fix for the 0.64 version, I'll decide later if I make a 0.65 or not. Since 0.64.8-4 : The most surprising fix is for the cave driver, a crash in dfeveron with the latest gcc versions and the line scroll code was broken for most color depths (except the one used by yuv overlays : 16bpp). Except that some fixes linked to the translations and how they are displayed in the gui, some clipping issues fixed in the gui, the emudx games which don't emulate the original sound will now display a warning if you don't have the dx2 files, and a fix for cookbib, mainly for the dos version but it could be useful for the other versions... Also I added sound commands to the bubble bobble driver, just for fun to see how it works, probably useless for most people. Maybe with some function to be able to associate a random song it could be useful to use more variety in the background music ? Except that the dos binary to be tested is still in its thread, I won't update the dos version anymore without any news from there. I'll upload the debian binary a little later. Actually a lot of changes were for the dos version this time, so it's a shame, but at least there were quite a few fixes useful for the others... The download page is there : http://raine.1emulation.com/download/latest.html