libretro / px68k-libretro

Portable SHARP X68000 Emulator for Libretro
http://hissorii.blog45.fc2.com
GNU General Public License v2.0
47 stars 42 forks source link

Sprite drawing bug (upstream bug) #24

Open Tatsuya79 opened 7 years ago

Tatsuya79 commented 7 years ago

Not a libretro bug, it's present in both winx68k and px68k upstream. Referencing it here as there's no development going on upstream.

I saw it in several games but the one I can remember is Gardis Light 2.10 (not present in older versions), the one where you can choose between 3 characters.

The sprites aren't redrawn properly. Try jumping and you'll see the character staying in the air sometimes, while he should normally be on the ground. Same for swinging your sword: the last part of the sprite animation with sword in your hand stays on if you don't move.

XM6 Type G doesn't have this issue.

ghost commented 7 years ago

i cant seem to replicate this, though i havent really played past 3-4 change screens(why are px68k games seems hard?) is there specific stage, timing this occurs?

Tatsuya79 commented 7 years ago

It happens everywhere. You can stay on the 1st screen and just push the jump button sometimes without moving. Compare with previous version then if you don't understand what the issue is.

It's an easy game, I finished it twice already! But haven't managed to save my partner yet.

negativeExponent commented 1 month ago

was there a variant of Gardis without this sprite bug? or does all of them have it.

Tatsuya79 commented 1 month ago

I have 2 versions without the issue: "2.02" and "2.02 alt".

Then the version "2.10" with a 3rd character is the one with redraw bugs.

negativeExponent commented 1 month ago

thanks for the reply. ill see if theres anything i can do about it.

Tatsuya79 commented 1 month ago

I found another spot with this kind of sprite drawing issue.

In Etoile Princesse, 4th stage the fire mountain, the dragon boss at the end has its legs disappearing, following the movement of its head which is another sprite.

Etoile Princesse-240915-213819 Etoile Princesse-240915-213824

negativeExponent commented 1 month ago

can you post the savestate for this area? or probably the savefile/the romfile for the savedata?

Tatsuya79 commented 1 month ago

Savestate for px68k from this repo, game is the hdf version.

-removed-

negativeExponent commented 1 month ago

huh. the game is just reboots when loading the state. our games probably not compatible

Tatsuya79 commented 1 month ago

-removed-

If the savestate isn't working, the 2nd option in the menu is for loading the game at that stage.

https://youtu.be/QfoGhKFOxS4?t=325

negativeExponent commented 1 month ago

nope. nothing appears. i was expecting that to happen. but no save data is loaded

also, no fdd or hdd data is on the save state, just a portion used for buffer.

Tatsuya79 commented 1 month ago

I don't get it, you're not confusing px68k vs px68k_next paths or something like that? Also I shared all that with different caps that can cause issue in the names.

I tested again on the latest core from here an all is fine. I'm re-uploading everything here with better naming: -removed-

Or there's something between win/Linux compatibility? I'm on win10.

Ahh... or maybe doing the state while using run ahead caused this buffer/incomplete state ending up there? (updated the state with run ahead off)

negativeExponent commented 1 month ago

this works now. still stateloading reboots the game. win10/linux state incompatible?

can you see if this state1 file loads on the hdf you used in the last .zip?

Etoile Princesse.state1.zip

Tatsuya79 commented 1 month ago

It loads fine but after 2s it get stuck like that:

Etoile Princesse-240916-125838

negativeExponent commented 1 month ago

yeah... your state from windows works only in windows, my state from linux works only in linux. tested on Wine. has there been cross-platform incompatibility with states before? im using state module from beetle, was hoping both bigendian (if we can manage to have it tested) and cross-platform will not be an issue.

Tatsuya79 commented 1 month ago

Suggestions I can get:

are they compiled with all of the same settings?

LibretroAdmin commented 1 month ago

I just asked themaister. There is no cross-platform portability guaranteed with savestates through libretro. It's entirely up to the core to guarantee they are so.

You should prob look at other cores where we know savestates can work reliably cross-architecture/cross-platform and then see how they went about doing that.

negativeExponent commented 1 month ago

not a clue... as far as platform-specific code. issue probably are some of the callbacks, like IRQ refers to function addresses.

negativeExponent commented 1 month ago

wine appears to segfault when loading a state from linux. it shows some thing like this:

https://gist.githubusercontent.com/negativeExponent/c46caa70862ff030fed6b6ae307d28e5/raw/49094c84b0b10fc14c16a0e1ae507976f86dbbcb/gistfile1.txt

not sure how to understand that though. (im using my fork here, which has the same issue)

also adress error occurs in px68k when you wait awhile.

Tatsuya79 commented 1 month ago

Xer Shadow Tail 🌺 — Today at 12:59 It is probably long

negativeExponent commented 1 month ago

Xer Shadow Tail 🌺 — Today at 12:59 It is probably long

dunno if this was intended....

anyways can you test this on the same hdf file? state2

Etoile Princesse.state2.zip

Tatsuya79 commented 1 month ago

It's working. 👍

Above it was a suggestion I copied from discord where I copied your question. It was about compatibility problems caused by type "long".

negativeExponent commented 1 month ago

thanks for testing... and sorry for these irrelevant noise issue. the state cross-platform issue was nothing but because i was using a different IPL rom on my linux machine... mymistake...

as for this sprite draw bug, still not anywhere near or a fix.