Tux

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

Yeah it works in ftps now, just need to disable certificate check, it's probably a home made certificate. Perfect, works again, thanks for the info !

Gonna give it a try... but I think filezilla has only a graphical interface and I need a text interface (to be able to pass commands through a script). Without this debian packaging becomes a real pain (it's not super easy to begin with, but here it becomes a nightmare...). Anyway I'll compile it and I'll see (gentoo here, compile everything or almost !). Not sure it will work though, it's announced as a proprietary protocol and filezilla is opened, and something not supported by lftp is very suspect ! But it's worth a try... Nope it doesn't work. filezilla has ftp/ftps/sftp like lftp, here it's not sftp, it's ftp inside ssh, the prioprietary way. You can think it works if you try sftp because the connection is initializeing and you see it sending the password and that's here that it fails. But actually it sends a password for ssh here and it can't work, it's supposed to initiate the authentication through ftp inside a ssh tunnel. Crap. Oh I guess I'll just put a temporary link through mega for an ultimate release and forget all this for quite a while...

In the race for an "always more secured server", 1emulation is now using some ftp protocol inside an ssh2 connection, specifically called securefx, which is a proprietary protocol which works only in windows, supported by the flashxp client. We had already a much slower and way less convenient ftp connection than the rsync/ssh connection I had before, but now I am supposed to use some windows program to upload things ? EDIT : after some thinking, even if flashxp works in wine (untested), it's not a reliable solution, I use scripts to upload things for new versions, and it would be extremely inconvenient to do this manually, so for now everything is on hold until something changes.

if you have the emudx files it will ask if you want emudx support when loading a game which has support for them. The list of games is rather short anyway, just look at the available files in the extras section. Now it will also warn you when the game has only emudx sound and you don't have the emudx files to tell you that you will hear nothing, but it's not released yet. From memory : puckman (maybe with some clones if they don't change the levels), mspacman, dkong (and dkongjp), galaxian, frogger. How it works well it just uses user files instead of the original sprites or sounds. Plus some more graphics effects sometimes like optional transparency for pacman ghosts. It was made by Mike Green originally, I thought it was too bad to let this disappear so I proposed to merge the functionality, he accepted and voila. Too bad no more games were made but it actually requires a lot of work and it's hard to make it right. The best one is probably frogger (in my opinion), followed by dkong, and the worst galaxian.

Ah ok, actually it worked before it's a regression of 0.64.8 : I wanted a fancy function to switch the language in options without restarting the program, just for the show. The consequence is that all dialogs use a copy of their data now to preserve the original texts and so all dynamic dialogs are broken in 0.64.8. I had already found the loading dialog and the about one, but I had missed this one. For now the changes are short so it's ok but if too many things require patching like this I'll have to ask to restart raine to change the language, it will be easier ! Anyway the controls dialog is patched too, and it works (commited to git).

lol ! Details will kill you, I expected something horrible, actually it's just a small redraw problem when the dialog is that big... Really you should be able to survive this, at least for a while ! By the way you know 4shared is quite a horrible host, their download page tries to push you to subscribe to their site, and it's full of clickable ads which try very hard to be clicked instead of the right button to download the file, I wouldn't be surprised that half of these downloads contain malwares... I'll take a look, but it's not an emergency. I am testing openmw this week-end, the reconstruction of morrowind but 100% free this time. I guess to many people ended up fed up by the unfixed bugs from bethesda and finally decided to try to do this. It's actually already quite impressive, but they want to keep a small version number anyway (0.36), quite odd... anyway it's fun to test ! Yeah well I guess it's possible to reproduce it by playing with the size of the window... Well as you saw yourself the inputs window is already quite full, so adding an option to switch the controls which is already elsewhere would only make it more loaded. Plus I don't find this difficult to use... anyway ! A good sign that you didn't find any more bugs, thanks !

Between this and a gauntlet version there are quite a few arcade titles on steam, but this one is really an arcade version, there is even an overkill option which has just been added... Times change, emulation becomes useless since editors make their own portage to pcs now... Default game play is hard though, it's for gamers who didn't have enough in the arcade, but the game is impressive ! http://store.steampowered.com/app/323460 (and it's for windows, but it works perfectly in linux using wine !)

The other topic for the dos version was overloaded, so here is a new one. I had a quick look at triple buffer : it's disabled for vesa 1.2 and 2.0. You can only have it with vesa 3.0 and vbeaf apparently, which means univbe for me here, but even with univbe I can't get it. Anyway it's something low level setup between allegro and the vesa bios of the card, the hacks have nothing to do with it finally... So it's very hard to get. The funny thing about triple buffer is that it's very hard to enable, but there are functions in allegro to do it manually with as many pages as you want, to make double buffer for example, which should be much easier to enable. We'll see if you need this... Now until now the vsync was only about palette in raine, to prevent colors distortion when changing palette at start, but it really calls vsync here too. There is a hack here too because at this time everything was good to win a few cycles so there is a super fast asm palette update function which is enabled by default, but which calls vsync too if you enabled "vsync palette" in the video options. You can choose the C function from allegro by setting "fast_set_pal" to 0 in raine.cfg, the comments say it's safe to leave it enabled on almost any system though. Then there is the problem of color depths > 8. In this case the palette is not updated and vsync was called only sometimes ! Actually it was called only for pixel double or double width blits, for all the other blits with depth > 8 it was just ignored. So I fixed that, now if vsync is enabled in video options and depth > 8 then a call is made after each blit to enable vsync. So the problem is if you tested with bpp = 8 and you couldn't get a decent vsync. For info it's done when updating the palette, before the blit which is a little strange. If you have a problem here, I'll make a test with updating the palette after the blit. So here is a new test build : http://raine.1emulation.com/archive/rained.7z it has changes for vsync for depths > 8, + all the other fixes discussed in the other thread. If you still have problems with vsync and bpp = 8, we'll need to make another test. Finally notice that if you are sure that your video hardware has the right speed for this game, you can just disable "limit speed" and just enable "vsync palette", raine should sync only on video, but it's not a good idea since some games have a sync which is not precisely 60 fps. Finally I have ran a recent raine on a tv yesterday and since it's france, it's 50 fps for tvs here by default. The funny thing is that raine is forced to 50fps, you see it when you enable the fps display, but you can't see any distortion on speed or anything else on screen... It just skips 1/6 of the pictures I guess, but it doesn't show at all ! Anyway it was very different from this dos setup, it was with the opengl driver...

Yeah yeah yeah, well to explain why I got so excited in the previous post : very heavy weather here for a few days in the row, after some time it brings on my nerves. And the other reason is that finding these bugs doesn't take much time, but fixing them is more than a pain ! I spent a big part of the evening fixing the cave driver ! Because actually the crash was not a gcc bug, it was because they changed the way variables were stored and suddenly a buffer overflow which was harmless brought havoc and destruction ! And then I realized the line-scroll / col-scroll code was broken in opengl and in dos 8bpp, actually it worked only in 16bpp (yuv overlays...) ! It took me quite a lot of time to fix, this code is insane. It was just because it was written at the time where the only fast rendering was the yuv overlays, so I optimized 16bpp, and never bothered to test the other depths. Well they were both broken ! Tss, everything is fixed for cave now, I checked the line scroll works correctly in the highscore screen of dangun feveron even in dos ! (but I guess you'll need quite a fast machine to see that...). So this bug is not only for the dos version, but for opengl too. And the crash happens in linux and windows too since they are using the new gcc version... Talk about a bad day... ! Anyway I'll take a well deserved break from this for now, and I'll come back to it later. I hate when there are suddenly a ton of new bugs to fix, especially when they are hard as these, but it was worth fixing them finally, even if conditions were horrible. Weather is finally cooling down, so things get back to normal here, finally ! EDIT : dkong and frogger are emudx games, I fixed them for dos, now they know how to handle the dx2 files. It uses some code inspired from sdl to do the resampling so it's short, fast, and sounds good ! Also I added some warnings to these games to warn that the sound will not work if the dx2 audio files are not present, for those who don't know these are emudx games, and also to tell to use at least 16bpp with emudx graphics, they can't work in 8bpp or 15bpp. Now puckman and all the games of its kind including mspacman have their sound broken in dos, it's due to too outdated sound engine here. Obviously it doesn't handle streams with their own sample rate as the sdl version, the resampling doesn't work and I have no idea why. This part never worked for dos anyway, so if someone wants to fix it, great, otherwise too bad ! (they don't crash, the sound is just at a very bad sampling rate !). I guess that's the end of it for now... EDIT 2 : it's just a seal bug ! Actually it messes frequency rates ! So to sum up : seal is faster but inaccurate and in some cases buggy (like for the sound of puckman) allegro is slower but more accurate and puckman's sound works. I guess I'll make 2 binaries for this time, but this time only then... !

What I can say is that 0.64 also added .7z support, which means that it also searches for the 7z version of the game which takes more time. Also even if you have 16 games only, it searches for all the games it knows to build the list of available games, so 1000 games to search and for each a directory version, a zip and a 7z version, searched in all rom directories defined. Now I won't look into this matter any further, if you want to try to improve the source on this side, you are welcome. It makes absolutely no sense for me to try to fix a gui issue on a 200 or 233 MHz today (+ it's not something easy to improve). And I don't care if 0.51 worked better for you, use it if you prefer, but in this case don't expect any update, nor any neo support. EDIT : by the way, I shouldn't have to tell you this because if you still use a dos system in 2015, you are supposed to know a minimum about how it works, but if your hd is continually reading while raine builds its game list it means your disk cache doesn't work at all ! It doesn't write anything to disk while doing so, just scanning the rom directories it knows. So it just needs a few kb to cache these directories that's all. If you see your disk reading it means the directories are not cached, which shouldn't happen. I just fixed the pause, it's not related to seal finally it's just that the normal version uses a new pause which is not broken by returning to the gui (to allow to test shaders while remaining in pause), which was incompatible with the dos version. So it's fixed in dos too now, and the 2 versions share more code. For the rest, I am starting to get tired of all of this, don't post anymore, I won't do anything anymore on the dos version for now. When I started this it was fun, it isn't anymore. Find an editor and a compiler if you want to work on this ! Weather is still too hot to get annoyed by this kind of stuff ! (I looked into the dfeveron issue though, it seems to be a compiler issue since the crash happens only on optimized builds. Well it doesn't happen in linux nor windows, and compiler issues are really hard to fix especially in dos. So for now I just stop here). Have fun fixing the bugs you found, the source is opened after all !

If it's so slow it means you don't use any disk cache like smartdrv which is insane. And by the way 0.64 has more than 1000 games when 0.51 has 700 games, that's about 50% more. Yeah, you want to write a doc ? Because I am lacking help around here... Because this allegro gui for dos is insane, the less is done with it, the better. Already posted about that, at lenght. Yeah the world is harsh... ! It takes only a few seconds thinking to find this out. It's just about trying it, seeing it doesn't work, then realizing it works for others, so trying to do it differently. A few seconds only, and it avoids posting useless things here. Again disk cache issue. The list is relatively fast if reading only from hdd, even on a 200-233 MHz, although that would be slower of course !

Ok... ! 1st keropi : I removed all the forgotten printfs, so you won't get messages anymore, and I had a look at cookbib, actually there was indeed a very small buffer overflow (reading, not even writing, this dos setup si very sensitive !). Since it was a 1 byte buffer overflow it was never found so far because modern systems count only in 32 bits boundaries. Anyway I fixed it, cookbib should work again for you. I still don't know what slows it down in dosbox though, but anyway... Anyway no new binary for now, you'll have to wait a bit. EDIT : almost forgot : I took a look at this mpxplay player, quite an impressive player for dos for sure ! Now it's based on open watcom, so I am not sure the code is portable to what I have now, but it's impressive at least. It's probably too different to be used here, but maybe it's worth another look later... (when it's less hot !). EDIT 2 : Also forgot : about the buffering of the game list to speed things up when loading a game : it was done a long time ago in the current windows/linux version but this code is gui specific so it was not back ported to dos of course ! There is a work-around though : just use the command line to run a game, like : raine bublbobl ! If you have enough motivation to backport this code to dos, you are welcome to, I am in need of some help here ! For your bublbobl problem : you are the kind of person who made me to remove the option about emulated ym3812 in the 1st place ! Try to think for some time before posting or I might remove this again ! This option affects the sound initialization of the game driver, which means you won't hear any change if you change it during game play. You need to enable ym3812 emulation, then quit, then restart the emu, load bublbobl, play. See the posts of theelf about where it works. theelf : about the ps2 : exact same setup here except that I use the network instead of an external hd. It's mainly for ps2 games though, not for emulation, I didn't even know you could force 240p on a ps2, I might look into this one day ! I am using the network because the dvd drive of the ps2 is the 1st thing dying when it ages and it was giving me bad signs so it's better this way. Plus you get the virtual memory card too, which is convenient ! There are a few "monumental" video games there if you ask me, I am in a persona 3 fes run again, I might not finish it this time, but I found a translated walkthrough from japenese on how to get all the social links in just 1 run, so it's interesting... ! By the way I wonder how these guys from Japan spend their time now, there are way less interesting games currently... anyway ! Your job seems very interesting ! I read a post on slashdot today about a mathematician who is now 77 years old and who says he never worked in his whole life, he just played. It's because his definition of "playing" is not the same as the one most people use, he is seen as a genious by most. But still, it's an excellent way to live your life... Actually in an ideal world everybody should do the same I guess... yeah we are very very far from an ideal world ! Anyway I think I would have liked this kind of job too ! For the vsync still broken : I feared that, I never experimented how it worked in allegro and on my setup I can play most games without any flicker or almost, at least nothing noticeable, so I don't care. So fixing this will be harder. It's a little strange that you need such a complex video mode to go flicker free or almost... Anyway if it works for now, that's good. I might take another look at the issue when the weather becomes more friendly again... At least it means that for now I should re-enable the hacks for the vesa driver in the next builds...