Tux

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

Oh la la it starts to be too much for me, I am not interested in loosing too much time on the dos version, really. What I can say : bubble bobble music works perfectly here, even using this same dos version in dosbox, so I won't try to understand what you did wrong. It's related to the ym3812 obviously, you should use "emulated ym3812" here. Messages in bbakraid : it's because I use printfs as debuging in linux because the output is separated from the screen there, same thing for windows. I'll remove the messages anyway they are not useful anymore. There are a few games with some forgotten printfs which were not removed, it's a wonder they were not reported earlier, it shows almost nobody uses this dos version nowdays. sb16 & ym3812 : read old posts on that (in this same thread !), it doesn't work with sb16. pause crashing : probably because ot seal, it's some very old code resurrected and I didn't test everything, I'll take a look at this one. bloodbro : no sound, very old game, never had sound. bonzeadv : sound correct in linux and windows, maybe too loud in dos using seal, but there it's more about fine tuning and I won't try to do any fine tuning for now. cabal : no idea, no interest. cookbib : works fine here, except it's very slow in dosbox, normal speed in dosemu. Don't know why it's so slow in dosbox, might take a look later. For now weather too hot again, it should be better in 2 days... !

check that you didn't enable the hardware ym3812, in sound options for the dos version, buble boble has music but you won't hear it if you enable this and you don't have the real hardware. Snowbros doesn't print any error message for me, even in dos, so re-test after disabling the hardware ym3812, if it persists I'll remove the error message.

It would mean look into the sources of this mxplayer to see if they could be used for audio support in dos ? Well who wants to be in charge of the dos version then ? Because this time it's not something light which can be tested quickly ! On a side note this thing could be used to maybe add full neocd support to dos because it would allow to have some mp3/ogg/flac decoder. Currently it's very limited, I think only games with data and audio in the same file could work, and I didn't even test it. Anyway I might take a look out of curiosity later, but not sure I would try that.

For the gus I had one, it finished burnt a long time ago, but anyway it was an isa card, it couldn't be used in any modern computer. And if it doesn't work it means it's a seal bug, and I don't know anything about seal so I can't do anything there. The source is opened though, but no way I could debug this now. Yeah univbe is a good solution. Linux also allows to create any video mode or almost with its modelines (for the xorg server).

The vbe resolutions depend on the vbe driver you use and your video card, raine just reads the available modes. For the roms some are compatible with mame (cps1 & 2, neogeo and maybe a few others), some are older. Some sites still have compatible raine romsets, just search more and you'll find them ! Glad it works well for you, no idea why the gus doesn't work but I can't do anything about that.

Hehe, poor windows 10 user ! I guess it's for work, I thought companies had learnt the hard way to wait a bit before adopting new windows versions, but not all of them apparently ! Anyway... On my side I resurrected my ps2 lately, to play again an old game that I liked very much, but it's heavily moded now, it reads its games from the network, from a samba partiton (windows share if you prefer) formated using zfs... ! I took quite a while to have everything working again, but it's working fine now ! Your new build (exe alone) : http://raine.1emulation.com/archive/rained.7z It's just allegro recompiled inside without the hacks for vesa, so vsync should work, but I don't know if it will be slower. No idea about the code you are referring, afaik, I was never able to enable triple buffer without these hacks and it seems they were broken at a point when upgrading allegro, and since there was poor testing at that time and poor maintaining of these hacks, it can't be fixed anymore. Antiriad wrote them originally, but I am sure he has forgotten everything now ! And since he is never on the forums anyway, you can't ask him. I send his mail by pm if you want to try your luck, but it's very unlikely to work !

Not sure for both I'll check the code By the way in case you didn't notice there is a 0.64.8-4 dos binary with the changes For frame skip Ok, here is the more precise answer : 1st for the timing : if you use the rdtsc (that means, you have at least a pentium and use_rdtsc = 1 in raine.cfg which is the default), then raine uses the timing indicated by the fps counter, so for cps2 it must be 59.62 fps if I remember correctly. If you set use_rdtsc = 0 then the timing is rounded to an int, and probably badly rounded, it probably takes 59 fps here. Don't do that. For the vsync : it relies on the allegro hacks, which I didn't write and didn't test much, in 2000 I was more interested in linux stuff already and these are mainly for dos, and before that there were very few games which had tearing (I can remember armed police batrider during its demo and its giant horizontal scrolling of course). Except that maybe there were small tearings in a few games but I didn't notice. Anyway these hacks mainly disable any vsync wait as much as they can. Apparently the main vsync still works but in only 1 place, and I suspect there is more than one place where it should work. In doubt I can try to compile an allegro without these hacks at least for the vesa modes if you are interested in testing, it might be slower though, your choice, it wouldn't take much time for me to do a test build.

Minor update to the 0.64.8 : just released the 0.64.8-4 binary for dos and windows, the changes are too minor to call that a new version so I continue to add things to the 0.64.8. It's mainly because some things will take time and for now I don't have this time so it's better to release something now. The changes from 0.64.8-3 : - possibility to select the language in "Options" - possibility to choose to save screen settings for each game (mainly for the dos version, I don't think anyone would be interested by that in the normal version, but who knows ? Anyway I added that to the video options). And "frame skip" is also saved there now. - Added b1+b2 combination to cps2 6 buttons games. That's all, so I guess most people can just skip this update !

First you need to compile Raine do that first and we'll talk more!

I don't see this as a waste of time don't forget emulators are about old stuff so you could say he is at the heart of the problem! Ideally there should be someone in charge of the dos version, and I would be in charge of only the linux version, but it's far from ideal for now... !

For info, disastrous sunday, I have exploded my windows installation (forget the reason, too long to explain), and when I tried to reinstall I realized my 2 dvd burners/readers were dead ! So no windows anymore for now, I'll have to buy at least 1 new drive soon though... ! I can't say I'll miss windows, but I need at least some basic installation to be able to test stuff which can't be tested in linux like language support specific to windows, + eventually to play skyrim (but I think I have done everything interesting now on this side). Hum, maybe I could stay a few months without any windows installation then... ! And except that it was a break from raine, I found a big android tablet which I use to read some comic strips, it's been a very long time since I last read those, so I have a lot to catch up ! Plus some idle chat on the web, so nothing productive lately ! Oh well !

Hum, not really ! It was used mainly to check texts in sprites. It's very hard to have the corresponding palette, in most games it is dynamic and can change at any time. Plus a sprite can use any bank in the palette, which adds to the complexity ! I'd say for that the best option is to modify the source so that it displays the sprites like what you want so that you can rip them.

The problem is not on my side, obviously you did something wrong... (we are currently 2 persons to use this file !). Oh well... raine.pot is exactly 54493 bytes, that should be enough to check yours. Open poedit without anything, file menu / new catalog from a pot file give it this pot file, you'll have a form to fill and then it should be ok. For the buttons, it can't be done now, maybe one day we'll add another solution, like adding the ability to map some keys to some cheats and then add a cheat to simulate these key presses, but it would not be trivial to add, so it will be for another time ! Nothing is impossible, but it isn't worth the work for now...