Jump to content

Tux

Ultra Members
  • Posts

    1,100
  • Joined

  • Last visited

  • Days Won

    226

Tux last won the day on June 19

Tux had the most liked content!

1 Follower

About Tux

  • Birthday August 18

Profile Information

  • Gender
    Male
  • Location
    Nantes, France

Recent Profile Visitors

6,844 profile views

Tux's Achievements

Experienced

Experienced (11/14)

  • Posting Machine Rare
  • Dedicated Rare
  • Very Popular Rare
  • Conversation Starter Rare
  • First Post Rare

Recent Badges

487

Reputation

  1. Tux

    Raine 0.96.9 : hotfix !

    No didn't know it. It looks less innovative than sfz3mix though, a lot like the zillions of clones of sf2... but yeah maybe it could be an idea to try to add it...
  2. Tux

    Raine 0.96.9 : hotfix !

    And from Luca (Zzap!raine editor for now) : sfz3mix ceases to be a clone since it completely replaces all the roms, it's an independent rom now. And from some other user on github : the sound driver saved in the config file never appears in the sound dialog when you launch raine, except if it's the 1st sound driver. It's a bug, the dialog is not properly initialized. I also added an error message when you change the driver in the gui, the change doesn't return an error, but the driver remains the same anyway, in this case you must do the change before starting any game.
  3. Tux

    Raine 0.96.9 : hotfix !

    For the green ball : I checked your save, yous see this ball only in the 1 few frames during the stage introduction, if you want to spend hours debugging a video bug for something which happens only during a few seconds, be my guest ! 1) focus lost : nice finding, it was during the transition to sdl2, many things to fix at the same time, I started this one but never finished it ! Luckily finishing it was very easy, it's fixed. It's still surprising this was never reported earlier, this change is from November 2021, so this must be used by nobody... ! 2) it's the default in the sdl test programs which use the joystick/controller, I copied without trying to understand. Cases where you use 2 programs at the same time which use the same controller are rather rare normally. But so it's not a problem, I just changed the setting from 1 to 0, 1 line change. 3) after a break and some testing in windows : actually the maximized status of the window was not tracked at all, I didn't even think about it, because you see normal people use fullscreen for what you did, not a window with decorations, but yeah I know, you are different ! (yeah I am sure it's because you love to switch from one emulator to another even on a tv !). Ok, so I added the tracking of maximized/restore status which obliges to change quite a few things, and while I was at it the position of the window is now tracked in real time, previously it was just asked when the program exited. I removed a hack about window position for linux in the process, normally it shouldn't be necessary anymore... let's hope for the best ! A particularity : it tries to save the status of the window before it was maximized, which means that if you maximize your window, quit to save the configuration, then run the program on another screen, you should be able to leave maximized state and find your previous saved position ! 4) Ah, I didn't notice that either, it's a function which is almost never used, and probably not used at all by most users. Actually even if it looks like a separate program, it's just another window, you can open multiple windows with an sdl2 program, but this particular one didn't allow the window to close, yeah. I don't know why they did that in the 1st place, but anyway ok I added the ability to close to exit earlier ! And I don't plan a release before this week-end !
  4. I don't really see what these 2 things have in common ! Plus here this was a bug from the patch author, not the rom authors, so it would be highly unlikely to be found elsewhere ! I didn't remember the bug but I remembered the video and remembered my reply at the time, it didn't change !
  5. kof94te is at version 1.3.0, out of beta, including the patch for this problem. By the way he could confirm the problem happens only on raine, not on the original hardware, so maybe 1 day I'll have to change the way sprites are drawn. But for now it allows me to do things faster for sure, so everything is good. I can keep the patch in the source since it checks the contents of the rom before patching it, so it doesn't try to patch 1.3.0, just tested with the a95 patch. This is the end of this problem then !
  6. Tux

    Raine 0.96.9 : hotfix !

    congratulations for the time you spent doing all these screenshots and saves, you should really learn to compile so that you could try these alignment issues yourself, because you never see the end of it ! Clearly all this comes from the resolution change in this game. Now the screens to be able to check relative alignment of layers are very rare, even more so when you talk about vertical alignment ! Yeah I missed scroll1, maybe I didn't want to see it at the time, the text layer for the 1st screens, the horizontal alignment is easy, but there might be some vertical alignment too about this and in this case it might affect other layers too... The sodom stage is the worst, this stage is done by pieces of layers stuck together everywhere ! Anyway not sure at all we'll see the end of it before long... You fix 1 screen and then you notice that it breaks another one ! Too bad there's no screen to check these alignment in the test mode, there is one but it's done only to align the crt monitor screen image, I guess it didn't make much sense to align layers on the original hardware back then... !
  7. And I got my testing from ffman1985 here, so this function is actually called to display the player name on the player selection screen, so if you disable it this way, you don't see the player name. So the correct fix becomes : - dpoke $2be018 $303c for patch a4 - dpoke $2be018-$20 $303c for patch a5 At least I was right not to hurry this fix yesterday, it really needed more time ! And the guy from the kof94te project just replied to say he is out of town for now but will merge the fix as soon as possible, cool so maybe the fix won't even be necessary here for the next version then!
  8. Actually if you want to test that on 0.96.9, it's easy to do and it would be useful : after loading kof94 with one of the ips patches loaded open the console and type : - for a94 : dpoke $2bd8ea $4e75 - for a95 : dpoke $2bd8ca $4e75 I know it fixes this bug but I can't be sure it doesn't affect anything else... Yeah you can't copy and paste to the console yet, you'll need to copy this manually. edit : fixed the offsets in the console, it's $2xxxxx and not $1xxxxx... !
  9. For info the crazy idea of ffman1985 worked, so I made a patch for the ips patch. The problem started to appear in their 1.1.9 version actually so it's not exactly recent. It looks like a bug and not something wanted, it's a function which is supposed to erase some characters and actually enables a column of sprites which should stay disabled. The patch is committed to git, it's actually very short, it works with the latest 1.3.0b0 version.
  10. Mainly because I broke the top of the main menu in the previous version ! 1 line fix, but an important one... !!! Anyway except this one I manage to fix some alignment issues in sfz3mix (16 pixels on the right for scrll2, scroll3 and the sprites, I can't say I had a lot of time to test it, but it looks better). And a fix for a mer-curious crash, see his thread for the details, it was probably specific to ssrpg, but it obliged to change the way samples were handled ! I hope there won't be another critical bug in this one because I plan to cool down for a few days after this ! http://raine.1emulation.com/download/latest.html
  11. And it was again a bug which looked like nothing and was after all critical, this time a race condition on the sdl_sound sample when using this game this way. For some reason it didn't happen with the bin files, maybe because operations on these files are quicker. Anyway I had to move all the operations on this sample outside the callback, which is the opposite of what we did with sdl1... ! Normally it's safer this way, and your crash is finally gone. I started by updating sdl_sound, but it was not the cause, I'll keep the sdl_sound update anyway (for flac, ogg and mp3). Hoping that it didn't break anything else, I tested an sound association in kof97 and everything seems fine (uses the same method, an sdl_sound sample).
  12. Well you found again something very very specific here ! I can't explain this quickly but I'll try to be clear : mame and raine code to draw sprites are very different, because here I based the source on another emu, not mame. In the end we use some very different method, mame updates the screen for every scanline, and depending if the scanline is odd or even it accesses 2 lists of sprites then it checks if they are on the scanline it tries to update and draws them in this case. On the other hand in raine I try to update the screen in 1 go, exception when there are raster interrupts, some games having 1 for each scanline, in this case I am obliged too to update for every scanline, but since most of the time it's everything in 1 go, I don't care at all about these 2 lists, and so far everything worked fine, I just browse the main list of sprites without even looking at these. But apparently this hack is the 1st thing I see using these 2 lists to blacklist some sprites from what is to be drawn on screen, never seen that happening anywhere else ! If you load your state without applying the ips hack, you'll see that actually the affected screen doesn't exist in the original rom, it's skipped completely ! So... it would mean changing the whole way sprites are drawn with the potential to affect all neocd and neogeo games just for something which lasts a few seconds only, because after that we are back to the screen which is in the original rom and the problem is gone. So for now I would say that I prefer to ignore the problem. ffman1985 says we could maybe find where the hack modifies the list of sprites to update it so that the whole list is cleared in this new screen. Well I might wait a bit to see if we can come to something using this method, but otherwise I'll just ignore that for now.
  13. ok apparently scroll2, scroll3 and the sprites should all move 16 pixels to the right, it happens in all the screens. Scroll1 seems unaffected but it's an 8x8 layer so this might be why, all the others are at least 16x16, scroll3 32x32.
  14. 2) really maximum annoy system here, it's indeed because of the move of the ips function, I had thought I had taken care of this part but I have been too fast, it's a tricky part where you must be super careful or you do this kind of mistake. Super annoying, really ! It's a 1 line fix, but without this one you loose "play game" and "game options" in most games, I guess I'll have to release a quick fix binary because of this stupid line. 3) still can't do, I even tested with the win version. I don't know which version I have, it's the original untouched with the bin files for audio tracks, I guess I decided to keep it this way because it's a rare format. Anyway : loading your state from the main menu of the game, pressing turbo until reaching the continue menu, pressing quit to title, pressing 1 so fast that you don't even see the white title appearing (tried also after the title has appeared), reaching the main menu, everything is normal and sound is working. 4) very unlikely, it's related to the timers usually and when it happens it's baked into the save, I guess this save was done at a bad moment, but I can't guess which one. Raine has gone a long way to improve this kind of reliability when restoring sound, but there are obviously still cases where it's broken. I have taken the time to check the restoration of timers here, everything seems fine, so no idea what's going on. From the sound of it it sounds like something bad is looping, maybe a bad bank ? But the banks are supposed to be saved and restored here, so no idea. Anyway you seem to think it's an easy problem, it's not, it's a very complex one.
×
×
  • Create New...