Segas32 sprite loading / bank issue

[mahoneyt944]

@grant2258 made this for the issue, seems it's only effecting a couple of them.

Games using 0x800000 REGION_GFX2 size:

• arescue
• holo
• radm
• radr
• sonicp
• Spidey (working)
• spideyj (working)

Oddly Spidey and spideyj are already working as is, but the others prefer the 0x1000000 loading.

Branch for testing: https://github.com/libretro/mame2003-plus-libretro/compare/master...Bank

Maybe a region length issue?

[mahoneyt944]

Think I found the issue. Let me see.

[mahoneyt944]

Still no luck but I found the commit where it changed https://github.com/mamedev/mame/commit/85c788bb9ab6127c51d0546c601b7b5860d4339a

[grant2258]

@grant2258 made this for the issue, seems it's only effecting a couple of them.

Not sure what you mean the pull request I had fixed this loading. The video code is all over the place some things need updated to be cherry picked properly and that's too time consuming .

Admittedly there was one changed I missed. As far as changing the code I think ill leave it because it seems to be based on multiple mame versions. Sonic works fine on the test core at mame0104u7 video updates as well. Ill try the video code at that point on plus and see how sonic acts. But the banking/rom loading was fixed in that pull req I think there has been a miss communication thats why I suggested to test the bank changes in that pull req.

for reference https://github.com/libretro/mame2003-plus-libretro/pull/1790#issuecomment-2232118757

[mahoneyt944]

The issue is that numbanks is set wrong using the latest video code in our core. It should be what I commented out which yields 8 for sonicp, the older code yields 2 for sonicp. Not sure why our core doesn't like this line. But that's all that's needed to make the latest romloading work with the latest video code. I think the issue is that spritebase is only filled up to 0x200000.

UINT8 numbanks = /*memory_region_length(REGION_GFX2) >> 20;*/ memory_region_length(REGION_GFX2) / 0x400000;

[grant2258]

Im well aware of the changes and the reason, however im not sure why your opening an issue on it considering the pr in question addressed it to use the new loading. If you want to change things in the code using different banking you need to address the romloads and other interactions with it. It was just something I told you was overlooked in the updates.

[mahoneyt944]

The goal wasn't just to use the new loading but also to use the newest banking, I'm trying to keep our video code, when possible, in line with current mame.

Current mame uses a required region ptr for this where we use spritebase pointer.

So the reason for this issue is to see if we can get our region pointer working properly with the latest video code. If not, I can divide numbanks by 4 for the time being. #1795

Segas32 was a pretty big over haul in this core. I tried to cover everything but could have missed things.

[grant2258]

@mahoneyt944 you need to adapt our core to the code clearly memory_region_length length is returning bytes you need adapt that as 8 bytes is 2 int32s. Im not sure where the issues is unless you need help with the conversion just divide memory region by 4.

[mahoneyt944]

For now I'm just using this so it's working, but I'll fix the pointer soon.

UINT8 numbanks = (memory_region_length(REGION_GFX2) >> 20)/4;

[grant2258]

@mahoneyt944 semantics are unimportant when you get the same result it you choose to divide with a shift just >>22 and you dont need the extra divide.

(memory_region_length(REGION_GFX2)   >>22 
(memory_region_length(REGION_GFX2) / 0x400000
(memory_region_length(REGION_GFX2) >> 20)/4

are all the same result

The pointers are done in 32 bit so you need >>20 or 0x100000 * bank

Its juts using shits vs * or / is personal preference Im still not sure what the issue is here, unless it was just the byte thing that was different throwing you off. If you need help with setting something can help just unsure where the issue your having is exactly.