Tux Posted January 24 Share Posted January 24 Most of the changes in this one are for the dos version and were released as 0.96.6 for dos anyway, but : - fixed an amazing bug for pengo which was here since 0.43.2, that was in september 2005 !!! See the thread in the forum if you want details. - galaga will now display a message when loaded if it can't find anything for the explosion sample, you can ignore it, it's for info. - gui fixes : games states, transparency, length of game title + size at bottom of screen. - a new "color theme", it was just because I noticed the dos version had actually 3 color themes, but it was done simply by rotating the colors rgb values, here it's a little more involved. Anyway the red theme had been forgotten in the sdl versions... http://raine.1emulation.com/download/latest.html 2 Link to comment Share on other sites More sharing options...
_MADrigal Posted January 24 Share Posted January 24 Excellent job - posted on the Zzap!Raine Facebook page, too Link to comment Share on other sites More sharing options...
mer-curious Posted January 25 Share Posted January 25 Hello Tux! Thanks a lot for this new release! 😀 I made a quick test here and everything is working correctly in relation to my reports in the other thread. Also, I can read a little better now the renderer options with the new default settings. By the way, samsho2pe has been updated to v.1.9. The author claims the graphical glitch I reported here was fixed, but I can still reproduce it both in Raine and FBNeo. I reported the issue in the GitHub pull request for the change, but I haven't had an answer yet. Hopefully the author will read it and fix the glitch definitely. You can check it here: https://github.com/finalburnneo/FBNeo/pull/1641 There is also a new change here: https://github.com/finalburnneo/FBNeo/pull/1643 Anyway, I'm not sure if you should update the driver now or wait until this issue is finally fixed... By the way, while trying samsho2pe v1.9 in Raine the emulator showed me a message about different CRC numbers for some ROM files, which is expected: My ROM sets are always updated, so this is the first time I see a message like that in Raine. I went and tried to confirm the game load with Enter to proceed, but surprisingly I have to press Esc for that. I thought that maybe it would be better to have here an "OK" so we could press it? This already happens in some other messages in the GUI, such as this one: It's also more intuitive to use the confirm key I guess, because we are indeed agreeing to proceed running the game with the errors or wrong files. The same for when using a game controller. Finally, I was thinking if the CRC report could also show the found CRC for the files. For instance, "Bad CRC for ROM xyz (found: 123456, expected: 654321)". I'm not sure whether this information would be useful to me, but maybe for someone it could be, especially running a game from an old online repository or using the emulator for the first time. Ah, there also seems to be a double line space between the CRC report and the message "The game might not run correctly". I'm not sure if this was intended though, but it's not common in the GUI as far as I've noticed. Anyway, just some ideas I had after seeing this message for the first time. Thank you so much again for your continuing work. 👍 Link to comment Share on other sites More sharing options...
Tux Posted January 25 Author Share Posted January 25 Hum, looong post... ! Well no need for an update since the update can be loaded with the crc warning. Let's wait and see... ! Your return key is just the gui way of working at its base : no button, then the only key handled is ESC to close the dialog, or button 2 of the mouse etc... If there is at least 1 button, then either Return or the 1st letter of the string inside the button selects it. And yeah sorry I don't think about adding a button all the time, this gui accepts dialogs without any button so I use this sometimes, but sometimes it just feel right to have a single ok button below the message. Just accept it that's all ! Double line in the crc message : after looking at the code it's actually inherited from the dos version, which explicitly added the double line feed, so I did the same without wondering anything. Oh well you are the only one reacting to this kind of detail... More interesting is the fact that this particular last line escaped from the translations, I'll have to try to update them then... Ok, updated for the french translations, a few new strings to translate eventually for the others too... I'll update the others with empty strings for now. Also there is only 1 line feed now, although you are probably the only one interested by that ! For the crc error : it's very rare to actually need the 2 crcs at this point. Those who need it can check the zip archive. The crc displayed is the expected one, and for zip at least, when the message is added the actual crc of the file is not even known, it just knows it's different ! So I will leave it like that. Link to comment Share on other sites More sharing options...
theelf01 Posted January 25 Share Posted January 25 On 1/24/2024 at 10:21 AM, Tux said: Most of the changes in this one are for the dos version and were released as 0.96.6 for dos anyway, but : - fixed an amazing bug for pengo which was here since 0.43.2, that was in september 2005 !!! See the thread in the forum if you want details. - galaga will now display a message when loaded if it can't find anything for the explosion sample, you can ignore it, it's for info. - gui fixes : games states, transparency, length of game title + size at bottom of screen. - a new "color theme", it was just because I noticed the dos version had actually 3 color themes, but it was done simply by rotating the colors rgb values, here it's a little more involved. Anyway the red theme had been forgotten in the sdl versions... http://raine.1emulation.com/download/latest.html Hi! thanks, i will give some feedback about dos version. At least in my 4 Pentium DOS computers sound is broken, i have Pentium 1 mmx + CMI8330 (SB16 compatible) Cyrix MII 366 + SB16 Pentium Pro 200 + AWE32 Pentium 3 1ghz + AWE64 Sound blaster 16 sound ir garbled, and make emulation slow. SB 1-Pro is not working, silent this is last version with working sound https://raine.1emulation.com/archive/rained-0.91.9.7z this one have broken sound and is like the last one https://raine.1emulation.com/archive/rainead-0.91.9.7z thanks for your great work! Link to comment Share on other sites More sharing options...
Tux Posted January 25 Author Share Posted January 25 45 minutes ago, theelf01 said: Hi! thanks, i will give some feedback about dos version. At least in my 4 Pentium DOS computers sound is broken, i have Pentium 1 mmx + CMI8330 (SB16 compatible) Cyrix MII 366 + SB16 Pentium Pro 200 + AWE32 Pentium 3 1ghz + AWE64 Sound blaster 16 sound ir garbled, and make emulation slow. SB 1-Pro is not working, silent this is last version with working sound https://raine.1emulation.com/archive/rained-0.91.9.7z this one have broken sound and is like the last one https://raine.1emulation.com/archive/rainead-0.91.9.7z thanks for your great work! You pointed both time to 0.91.9 to be the last dos version with working sound, and then having broken sound. (ah ok, the 2nd link is for the ad version, sorry my bad). Well if I am not wrong this a was for allegro, if that's right then the last released binary (0.97.6) also uses allegro sound. Anyway this 0.91.9 is from 2020, you could have posted earlier... ! Well I had sb16 emulation working in pcem but it doesn't do any autodetection, it relies entirely on the BLASTER environment variable, if you set it badly, you don't hear a thing. It's a little strange you don't get any sound on a sb16, it's the base card for a lot of things, but if you double checked this blaster environment variable, there is not a lot more things I'll be able to do... ! Link to comment Share on other sites More sharing options...
Tux Posted January 25 Author Share Posted January 25 After testing : yeah I confirm, this ad version is for allegro sound, that's the same thing used in the latest 0.97.6 binary, both use correctly the sb16 in pcem for me. and when clearing the blaster environment variable (set blaster=), I still get sound with the allegro version, so it uses some autodetection if there is no blaster environment variable after all, but only silence with the seal version, which is the last one which worked for you. I can post the seal binary for the latest version if you want, I still have seal around here, but it has only SB and awe32 driver, nothing for sb16, plus no autodetection, seal is officially dead since the end of 1999, so it would be better if you managed to fix your sound with the allegro version ! Link to comment Share on other sites More sharing options...
theelf01 Posted January 26 Share Posted January 26 (edited) 3 hours ago, Tux said: After testing : yeah I confirm, this ad version is for allegro sound, that's the same thing used in the latest 0.97.6 binary, both use correctly the sb16 in pcem for me. thanks for reply! i confirm sound is not working good inSB 16 mode, and at all in SB1-PRO modes SB16 no PNP IRQ 5 & 7 AWE32 no PNP IRQ 5 & 7 AWE64 PNP IRQ 5 & 7 CMI8330 in SB16 mode distortioned bad sound, SB1-pro mode big noise, IRQ 5 and 7 ALS100 in SBpro mode work more or less good but with noise, IRQ 5 and 7 ESS AudioDrive (ES1868) same as ALS100, but this one is not PNP, no need to any software to initialize, IRQ 5 and 7 tested in P1mmx, Cyrix MII, PPRO and P3 machines All blaster enviroments are standar, and i initialize the pnp awe64 with unisound About SEAL, yes of course SB16 is better than just SB1, 16bits, 44khz etc and AWE32 never worked in old raine then was limited to old SB quality Anyways, i will ask for help in VOGONS forum, there many people have real hardware to test, i will return with feedback thanks Edited January 26 by theelf01 Link to comment Share on other sites More sharing options...
Tux Posted January 26 Author Share Posted January 26 Yeah that's strange, even though allegro had some astounding bugs I can't believe its sound system doesn't work correctly with the vanilla hardware, there's something off... Maybe they are still on the web too, a place to send some message ? Also be sure to test from the other thread : go to mode-x 320x240 (8 bpp, all mode-x are 8bpp), and then try to enable triple buffer, the advantage is that it can be tested on any vga card, no need for vesa3 for this. I get a black screen in pcem when doing this, but it might do something more on a normal pc. Maybe you should try some test programs from allegro4 to test sound... Quite a lot of people used this lib so I can't believe it couldn't work on the original hardware... edit : I found a related thread on their site there : https://www.allegro.cc/forums/thread/596505/0 it's not exactly your problem, it seems related to the sbpro 8 bits samples and doesn't affect sb16, but it's still a very buggy sound driver in allegro 4.2.2 (by the way the allegro in raine here is 4.2.3.1). Well, I'd say if you really want to go to the bottom of this, you'll have to test directly some allegro versions then, there is a sample program to play samples, hopefully it will be enough to check the quality of the sound, build some version and see what you get. The thread tracked the bug appearing in 4.1.15 apparently... ! Luckily allegro is quite fast to build, at least on a modern machine. I remember that at that time I had already some sb compatible card and it worked well for me at the time with raine... Each time I find such a big bug in allegro I am amazed, their documentation feels like it's an almost professional project, and then you find astounding bugs in it... an alternative would be to find another sound library, but testing a new sound driver in raine would take ages, so no thanks. Well I can also post the seal binary if you want it. Link to comment Share on other sites More sharing options...
_MADrigal Posted February 1 Share Posted February 1 Just read this from the latest version of MAME, released today: "The microcontroller program for Taito’s KiKi KaiKai was recently extracted. This contains a substantial amount of game logic, allowing the simulation code previously used by MAME to be retired and giving more confidence that the emulation is accurate." Question for Tux: would it be possible / a good idea/ do you have any interest to implement this in RAINE which, I presume, uses simulated logic for that MCU (and therefore not accurate)? Link to comment Share on other sites More sharing options...
Tux Posted February 1 Author Share Posted February 1 I don't know, maybe ? I mean, I never knew the mcu was used for any game logic in this game, it handles inputs and protection, it mainly makes life harder to emulate it, but it doesn't do magic. But never been a big fan of this one myself, so I can't say I know much about it. It was mainly the work from Kayamon, the crazy guy who made the 68705 mcu code in raine... ! One of his last comments in the driver is : changes/kayamon: 30/8/99: - added Knight Boy, dunno if it was worth it though. - NOTE: MCU is tested for KKK, seems to be 100%, so any problems are most likely due to the rest of the hardware instead. So emulation of the mcu was considered complete, and that's what I thought too... ! Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now