Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Occasional Corrupt Map Tiles #1

Closed
DonaldHays opened this issue Jan 26, 2017 · 2 comments

Comments

Projects
None yet
2 participants
@DonaldHays
Copy link

commented Jan 26, 2017

I'm not programming using this engine myself, but there's a visual issue I've seen in Super Princess' 2092 Exodus and Luna, so I suspect it's a bug in the engine, and so I thought I would file a ticket.

Sometimes when scrolling the engine appears to incorrectly decode or assign a map tile, resulting in a corrupt appearance. The tile remains in its incorrect state as long as it remains on-screen. If I scroll the tile off-screen and then back on-screen the issue goes away. Unfortunately, I don't have a reliable way to force the issue to happen. It just happens somewhat rarely seemingly at random.

I have attached photos of the bug expressing twice in Luna. Look towards the top-left corner. Again, I saw the issue once or twice in Super Princess' 2092 Exodus, but I lack any screenshots of the issue there.

zgb_1
zgb_2

@DonaldHays

This comment has been minimized.

Copy link
Author

commented Jan 26, 2017

Because the first two shots appeared to show palette-decode errors, here's another shot where the tile data is definitely wrong. Look at the mountain to the right of the hero. When I scroll that off and back on it fixes to a continuous upward slope.

img_0520

@Zal0

This comment has been minimized.

Copy link
Owner

commented Jul 21, 2017

So after a bit of investigation I found out the function set_bkg_tiles can fail writing into vram sometimes because of the vblank interruption that I am using. I have coded a new function SetTile faster than set_bkg for one tile and that also checks out on exit if the stat_reg marks vram in modes 0 or 1 (writable) and otherwise it tries it again.
(more info here)

Changes are in this commit

@Zal0 Zal0 closed this Jul 21, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.