The cursed frames

I'll ask this here because I can't really see the question as a "basic" one.


I was including my latest animation to my hack (thanks to vladikcomper whose answer in the basic q&a thread gave me this idea), when I ran into an unexpected, yet not all new, problem.


It's a problem I've noticed twice, the first time with my shields, the second time now with this animation for Sonic.


One frame, and only that one, appears garbled in game. For the shields, it was frame number 58 (all numbers in hex), the garbled tiles were tiles 353 to 358, and for Sonic, it was frame C5, the garbled tiles being CA7 to CAB.


A part of the sprite shows correctly, even a part of the piece is correct (I'm using sonmaped vocabulary here). When I duplicate the sprite but not the tiles (ie only a new entry in mappings and dplc), the problem is still visible. But when I duplicate the sprite and tiles (ie new tiles, mappings and dplc), the sprite looks good in game. Therefore my conclusion about the problem being related to the tiles.


Of course, this is a convenient workaround. I only had to add a few tiles to the files each time to make that visual glitch disappear. But the problem remains unsolved, and it probably means something isn't working properly.


Any idea?

 

Can I have a screenshot?

 

I agree, could we have a screenshot?


I have a theory of what your problem might be, but the chances are (without actually seeing what it is) it's something different.

 

Here you are:





Weird, I thought there were 5 broken tiles, not 7 :/


Anyway, as you can see only a few tiles in the piece (ie the 'sprite' from the vdp's standpoint if I'm not mistaken) are broken. It looks like something else is being loaded instead, maybe some mappings, though that doesn't make much more sense to me :/


note: the sprite is mirrored on this picture


edit:I forgot I edited some frames in the meantime, which is probably why there's a difference between the amounts of broken tiles.

 

I was trying a new object I'm currently adding, when I saw the bug again. The code of the new object is very short, so it probably shifted the data by a few dozens of bytes at most, and another frame got corrupted instead.


It really looks like there's a problem with some addresses for tiles. So I moved all the uncompressed art data to the end of the file, and the sprites show correctly (I couldn't check all of them, but the formerly broken ones are now ok), which is good news, but I may have broken something else. <_<


So it doesn't look to be related to a relative address, but to the absolute address instead, which doesn't help me much as I really can't see where the problem could lie. The absolute address for Sonic's broken frame was around 3Fxxx (approximately 3FDDC I think) and for the shield it was around DFxxx (that one is much harder to find precisely).


I really don't understand how the program can suddenly jump to a wrong address, or load corrupted data in such a specific way.

 

I heard that moving the mappings after the art will fix that issue....

 

There's a unsaved Pattern Load Cues. I had the same problem a bit ago. I solved by save the PLC after save mappings and tiles in Knuckles.

 

Thanks for your answers.


@Irixion:


Do you know if it "really" fixes it or only hides the problem?


@eduardoknuckles:


So, by placing the mappings first , then the tiles and finally the dplc in the file, everything should be fine (forever)? I mean, the problem never came back in your hack?


For now, I have the art at the very bottom of the file, with an align 8000 before them. There doesn't look to be any problem, but I'll run some tests with those solutions when I'll have enough time.


If someone has a theory about the reason why it happens, from a technical standpoint, I'd be happy to know. I'm more annoyed by not knowing what's going on than by the resulting glitch on screen itself.

 

Today I made some changes to the engine (loading 256 blocks from rom for all levels), and the problem happened again (with one frame of the golden shield).


Fine before, wrong after, considering the changes to the code are minimal, I moved around the now uncompressed 256 block data. Moving them to the end of the rom changed the appearance of the glitch (though it was still on the same frame). It looks like adding an align $8000 after each file once again hid the problem, without solving it, of course.


Could the program mistakenly read some data from the block maps instead of the uncompressed art? I don't understand why nor how it can happen, but I can't really imagine another reason. :\

 

I'm not writing anything in those areas of the vram, they're a sacred sanctuary.


All the sprites are well within the limits of the available space for Sonic and shields.


The "graphics" (if I can call them graphics) are placed correctly in the vram, either in the space reserved for Sonic or the shields depending on the case. It only happens to load the wrong data in the right place, which is why I don't understand the problem. :/


But they look like mappings and layout data, indeed, and probably are.

 

*Bump*


Sorry I'm late, I almost forgot about this, put "align $20000" before the inclusion of the art, data that's DMA transfered has to be within a 20000 memory bank.

 

That's a very good thing to know.


As a corollary, I guess that "$20000 bytes" limit means no uncompressed art file (the ones being DMA transfered) should be bigger than 128kB. It seems to be good to keep in mind as well (my Sonic art file is 118kB big).


I suppose that's why S3K has separate art for "extras" and "snowboarding".


Anyway, thanks for the explanation and fixes


(btw, is there a way to turn the topic into a question to highlight the solution?)