Tux
-
Posts
1,062 -
Joined
-
Last visited
-
Days Won
220
Content Type
Profiles
Events
Forums
Blogs
Downloads
Posts posted by Tux
-
-
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 !
-
1
-
-
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.Still on the GUI, I've noticed that when you are in a fresh install/unzip of the emu and set a shader, the "Shader" string will not immediately change to show the shader selected until you leave and visit the Renderer/OpenGL options menu one time. That is, the "Shader" will show as "None" even though you had selected a shader prior to leaving the dialog for the first time.
No idea, can't reproduce it.It's most likely gui related, linked to the new clipping of strings.I would also like to report something strange I noticed in my games list. There's a "blank" string which seems to correspond to Fatal Fury 3. Take a look:
This wasn't like this on the previous version. Does it have to do with the Mame roms updates?
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...By the way, I played the game for like 10 minutes and everything seems fine. I just found a weird glitch in the Andy's fire ball ("hadouken") when in a specific stage. I've made a savestate to take you there. See the attached file in my post.
Just fire a fire ball and you'll see it blinks weirdly in this stage. The command for Andy's fireball is the same as a hadouken but to the left side, so: down, down-left diagonal, left + A (assuming you're in the player 1's side).
Finally, would you consider adding support to "Teenage Mutant Ninja Turtles" and "Teenage Mutant Ninja Turtles - Turtles in Time" games? They are nice beat'em up games released by Konami for the arcades. There are actually many arcade games released by Konami for different hardwares. FBA shows the hardware for these two games are the GX963 and the GX063 respectively.
That's my feedback for now.
Thank you again for your excellent support.
-
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...
-
1
-
-
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
-
2
-
-
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 !
Tux - try now with the old setup.
-
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.
-
EmuDX games
in Raine
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.
-
1
-
-
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).
-
1
-
-
Hi, Tux. Thanks for the new release.
I'm seeing a little GUI glitch in the inputs menu that is bothering me a little. It happens when you use the default window size and have a long string for the gamepad.
I've recorded a video so that you can see what happens: http://www.4shared.com/file/Ant7GqDXba/00004.html
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 !
It seems there's a bigger background menu behind a barely smaller one in the frontground, so when you move the mouse cursor you see these weird "PPlayer 1" and "CCoin" being formed in the very end of the left side. It happens everytime you visit the inputs menu.
I guess I've already reported this in the old forum but I don't remember your answer. Of course that a simple workaround is just to resize the GUI, but what if we need or want to use the default window size? Maybe now you could figure a way to fix it?
Anyway, it's a very minor issue. I'm reporting it because I liked the "new look" of the inputs menu and this glitch somewhat jeopardizes the visual experience.
I don't know if you'll be able to reproduce it. I guess you would need a PSX to USB adapter or a gamepad with a long string to show in the menu and trigger the glitch.
Yeah well I guess it's possible to reproduce it by playing with the size of the window...
Finally, I have a suggestion for the custom game inputs feature. Currently if we click on the "switch to custom game controls" and want to undo this action we need to leave the menu and then return to be able to revert the change to the default controls. I'd like to know if you could let us enable and disable the changes on the fly, that is, without needing to leave the menu to switch to either custom or default controls.
I guess that way the option would be more intuitive to use, once a new user wouldn't have to "guess" we need to leave and return the menu to revert the action of clicking on the custom controls, because he/she would instantly see the changes on the screen when trying to click on it again.
Except this, all shaders are working fine now.
That's my little feedback.
Thank you again for your great support.
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 !
-
1
-
-
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 !)
-
1
-
-
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...
-
1
-
-
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... !
-
1
-
-
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 !
-
@Tux
Regarding the game list, in 0.51 it's fast with the same amount of games. The latest version you posted is really slow with the same amount of games. I haven't tested any other versions except 0.51 and the very latest you posted in this thread.Infact I just measured it:
- very last binary you posted here takes 48seconds to load a 12 game list - HDD constantly works
- 0.51 with 162 games takes 1.5-2secs to display the list
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.
Regarding the ym3812 , before starting labeling "people like me" it would be a good idea to do a self-check:
a. you don't provide documentation
Yeah, you want to write a doc ? Because I am lacking help around here...
b. you don't provide any message in the emu saying that changing this option requires an emu restart
Because this allegro gui for dos is insane, the less is done with it, the better. Already posted about that, at lenght.
c. you don't provide constant emu behavior: changing output Hz requires a game reload , changing YM3812 option requires an emulator reload
Yeah the world is harsh... !
I can understand that writing docs now is boring but at least a message at the sound options shouldn't be that hard.
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.
edit:
regarding the speed of the game list:
I have an identical setup to my 233mmx pc (same mobo/bios version/ bios settings/vga/soundcard/ram/dos setup) but with a 200mhz mmx cpu.
So I took the latest raine setup (same as 233mhz one) and run it on the 200mhz pc. List loading is the same as 0.51: fast and no HDD working all the time. Could it be a timing issue of some sorts because of the extra +33mhz?
The 233mhz pc is faster in emulation as expected but 20x slower when it comes to load the game list. If there are any info I can provide that help solve this I'll gladly provide them.
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...
-
1
-
-
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.
Raine 0.64.9 : still a little messy, but improving...
in Raine
Posted
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 !