Generate xml DAT messes up video #1856
Comments
|
Well if i could help ya big man i would but not using this core personally means im snookered ;) |
|
All you need to to is add machine reset when the dat is finished. You might get away with expanding the original machine driver as well instead of a reset. If you want to debug it youll need to go over the constructor of the driver it was never intended to be called while a game is running. |
|
I don't see why creating this file should affect the current game while it's in a pause_action unless it's changing driver properties while it executes? Maybe that's the case here? I thought it was just checking for properties not applying them. Info.c should probably execute itself in a sandbox like environment situation if that's the case. |
|
anything using expand_machine_driver causes it. A reset after should reset any possible demons changed, you would have to debug the expand constructed and the video update is int called during pause now. So you can rule that one out it nothing to do with the pause this will likely still happen before you pause changes. Its worth noting I done a fix very early on in that affected dats by the samples s by disabling optimizations on the samples code. It only happened on 64bit when creating the dat as some games crashed back then not just distort gfx. I see someones changed the code so not sure what changed or is some games still crash as its removed. You could try a push - pop optimizations the function that use expand_machine_driver because there is more of them now than there used to be. update creating the dat calls the games video_update a few times |
That has to be what's effecting wrestwar |
|
Has no ill effects unless you call using expand_machine_driver() youll need to trace it or simple reset after the dat creation |
|
Interesting, I'll peak through that then |
|
So when it uses
Resetting the core in RA does not fix wrestwar. It needs a full reboot. But I still think sandboxing expand_machine_driver() or another underlying issues would just allow everything to work without the need to reset. |
|
reset works fine from the menu or in the code. Not sure where the issue is to be honest would need need to debug it with gdb to trace it properly. You need to see whats calling video code calling the video update in the dat creation that the first point you need to debug and its not expand machine calling it. You might need to make the dat creation a pause action as well could be that simple. |
|
It's already in a pause action, since the mame menu is open. |
|
Well clearly somethings calling it INFO] [Environ]: SET_MESSAGE: Generating XML DAT |
|
That's probably updatescreen() which is what pause action uses. I don't think that's the issue though, to verify use the commit that blacks the menu screen instead of drawing mame2003-plus-libretro/src/mame.c Line 1185 in 5f5e325 |
|
Either way the pre pause changes ran the video update like we currently are and its only causing issues when he expand is called so its something in there that's causing the issue that hasn't changed. The code is probably called regardless the way the menu imposes over game screen. This isint a new issue it will be on the pre pause code you added as well. |
|
Yeah it's definitely an old bug I actually noticed this bug when all the system16 updates were happening but wasn't too concerned then. Would be nice to fix it though. |
|
The code was meant to run from the command line so its probably something initializing differently. Personally if it bothers you id say go for fixing it. When I make a dat I usually quitting to use the dat anyway. |
|
@mahoneyt944 @arcadez2003 @grant2258 Hope all is well. I have been poking at MAME AND N64 Emulation fix ups over the last several weeks. One thing that is quite interesting related to how "RetroArch" and any given Core works is how it maintains "temporary memory". This can be a double edged sword at times. On lower spec, an exploit I arrived at to instantly clear memory from RetroArch/Core was simply to go into RetroArch Settings, Video, Output, and toggle SRGB On/Off. That INSTANTLY clears memory, exploit wise. So, for kicks, what I would try to do is this...try the dat, try srgb toggle. It will either clear memory and allow you to resume game...OR, clear memory and force close the game. For N64, as an example, I could play first stage of StarFox 64. Once you beat it and get to the overhead galaxy map...the game will lose FPS and slow to a crawl, if you have lower RAM systems. BUT, if you get into RetroArch soon enough, do the SRGB toggle, it will bypass the crash. This crash occurs due to dynamic recompiler halting emulation, and the recalculating of data on the fly worsening the already preexisting memory leak that is omni present on dynarec driven platforms. I took this one step further, debug test wise...Say, for example, I load TWO completely different variants of N64 emulation, that both utilize "vertex, etc, shaders", albeit in different ways...One instance of the "shader" usage will corrupt the graphics within the other variation. SO, if I load test game 1 on ONE Core, then another...graphics may be fine on FIRST, then corrupt on SECOND. BUT, if I srgb toggle, and clear the memory...the remnants of that shader usage will be gone. And, upon reloading SECOND, graphics will be back to normal, as they should. Latest state of N64 emulation is more approachable to those on PC/Android, and 64 BIT architectures, than 32 bit that can't get past 2.0 GLES, like most of the Mini Classics. So, I have been fixing up things in my own fork for those platforms. Thus far, I have gotten cheats working, turbo boost AKA frame skip, and some other fix ups related to framebuffer usage, etc, as well as addressing the memory leak issues, so that SRGB toggle does NOT need to be used. But, in any case, this sort of information could parlay into active state of said game, or clearing of memory (which may or may not cause graphical glitches). We've already seen what happens when we create a save state in a MAME 2003 game, then try to resume it...It has some humorous results, at times! I am just curious how the srgb toggle would affect things as far as trying to get back to said game after the dat creation. Maybe a verbose log (whilst doing srgb toggle) could give better sense of exactly where things are "corrupting", on the resume state, emulation wise. Also, since some of you are wresting fans...have any of you checked out the documentary series on Vince McMahon, as of yet? My video will showcase ThunderBlade, as well as my WIP N64 fixed up core, which I had some creative ideas with...I opted to do a "debug" sort of build variant, where games like Beetle Adventure Racing and select others can easily pull up debug menus, to mess with. I love the debug menu, particularly, for Beetle Adventure, as you can alter a lot of perimeters, down to even increasing the "speed" of the car models. This I will show in my video, too. Anyways, hope all is well! P.S.: One other thing I altered recently in my FBNEO fork, which I am not we can do same way here was "ignore crc checksum", which makes it so you can essentially take a rom hack and rename it to identical name as the rom it is a hack of, and it "should theoretically" load. It has been quite cool for me just outright loading rom hacks, that arent even supported by FBNEO. Curious if we could do a similar instance in 2003? Just outright ignore CRC checksum as a Core Option, possibly. There are SOOOO many rom hacks, and this would be a bit more attractive than having a mess of unnecessary crc checksums and alt rom names, for those select people, who are niche enough to really embrace every single little rom hack. Maybe, another issue in 2003, that relates to potential changes that might even further spruce up the already awesome 2003, along with the aforementioned CRC checksum ignore possibility. Ultimately, about anything I have ever been able to imagine, you guys have been able to make possible:) |
|
You can do this in mame2003 already, as long as the modified rom file is named the same as the original it's replacing. it will load by name even when the checksum is different. I'll try your toggle suggestion as well. |
|
@mahoneyt944 - So the generated DAT will use the CRC for verification when building a set but when launching a game it doesn't validate the ROMs (just the name)? I could see that as a double edge sword. To many people grab whatever ROM they can find and download it without knowledge of ROM management and don't understand why it doesn't work. On the other hand KMFD makes a interesting point of a endless sea of CRCs. I like the toggle suggestion (defaulted on), then only "advanced users" can delve into ROM hacking variations for some fun without a lot of hassle of CRCs. I would hope most to be using the same ROMs (CRCs) when reporting an issue about a game that you guys would expect them to be using or I might be misunderstanding it too. |
|
It always looks for the crc first, but if its not available it checks if the filename exists and tries to load that. It will still send a warning flag if it didn't load by crc. This is how it's always been as far as I know. |
|
Yeah seems fine to me. |
|
Ok, I always thought it "enforced" correct CRC's but it's more of a check it sounds like? So then by proxy the core will already allow hacked ROMs? Basically, it already can do what KMFD is wanting it to do or am I still missing it? Sorry guys if so... I've always been a fan of ROM management... loved when Grant implemented the DAT feature. Hey Mark, hello, I hope all is well! It's good to see you occasionally! :) |
As long as the hacked rom uses the same rom loading structure as the original (same number of files) and the files share the same name, yes. If the hacked rom has new roms then no. An example of this would be umk3p, where I believe 4 new roms are added with this hack on top of modifying some of the originals. So mame wouldn't know to look for the new roms since the original rom loading would not have those, but it would look for the modified ones, assuming they still share the same name. |
|
@mahoneyt944 - Ah, ok... thanks... just one question what would would a toggle button be used for if it can already essentially do it? I get the extraneous ROM's in a zip and the core not knowing what to do with them. I might be over thinking it but if a ROM can load with or without the correct CRC already, by name. Also, I know I've renamed every ROM file in a game zip to garbage literally 1, 2, 3, etc. (but all the correct CRC's existed in the zip) and it worked just fine too. |
|
Idk that we need a toggle since it does this already |
|
@Wilstorm there is a separate mechanism that, if the individual rom is not found by name, it will search the romset zip contents by CRC so that if it's named incorrectly it may still be found by MAME. This is from memory so I don't have a link to the code. But I think this is accurate |
|
@mahoneyt944 @markwkidd - Thanks guys for explaining it! Ah, that makes sense now. I think you have working well that gamers using 2003+ have the best of both worlds. They are able to use core verified ROMs as well as hacks! |
While playing wrestwar, I generated a DAT file and when I returned to the game the graphics were messed up. I generate lot of these regularly so something with this game and some others in the driver in particular have this issue for me. Can anyone replicate this issue?
The text was updated successfully, but these errors were encountered: