Jump to content
IGNORED

graphics suddenly glitch


Recommended Posts

I spent some time coding some extra things into the "combat" airplane demo today.

 

I got to the point where, even though the compile message is telling me I have space left (over 3,500 bytes in the main area), if I add any code, the first graphics that I load in the program, become intermittently corrupted when I display them. The video attached shows what I mean, a few seconds in, at certain sprite frames, I get random pixel at the bottom of the sprite frame. In the vid the sprites are the same but with a different palette. I changed the load order (as i've prepared some additional airplane graphics) and it happens no matter which sprite I load first. (i'm trying to load things optimally). The code I added sits alone and isn't called anywhere. As I said, I can even delete the code and place it somewhere else, isolated, and the the same result.

 

The piece of code I added is nothing to do with the main loop and just controls some menu items on the title page.  I tried just adding any piece of code and got the same result, corruption on the first sprite in graphics block zero. If I remove the code the corruption goes away again.

 

I'm using a regular 48KB cart setting with no bankswitching 

 

If I add dmahole calls through out the code, it also goes away, which makes me think my program body is somehow "leaking" into graphics block zero causing the corruption even though I have 3,532 bytes left in the main area. Block0 has 0 bytes, block 1 has 48 bytes, block 2 has 256 bytes and block 3 has 1680 bytes.

 

As I said, I can work around it and I have dmahole 0,1 and 2 currently not being used so 12,228 bytes to use up but it struck me as odd to behave that way.

 

I'm not sure if i'm doing something obviously wrong and any pointers or advice would be appreciated.

 

 

Edited by Muddyfunster
Link to comment
Share on other sites

The 7800 doesn't implement dma holes for ROM below 8000, and it needs dma holes (or alternatively rom with all zeros in non-sprite areas) for displaying sprites that move vertically smoothly. So if you have sprite graphics below 8000, then your program code can show up during vertical sprite movement. That's my best guess as to what's happening here, without more info.

 

If you have the 48k rom stuffed with graphics, try putting charactersets first in the ROM. Characters don't need DMA holes, since they don't move vertically in sub-zone sized movements. Double-check the compilation messages to make sure the sprites aren't below 8000.

 

Link to comment
Share on other sites

As a suggestion perhaps check to make sure you're actually returning properly from all routines.  If moving code around makes it go away this might be the cause. Essentially look for places where a return isn't being done as intended so extra code gets done that might not actually do anything useful beyond waste time until it eventually hits a completely unrelated return.

 

I'd take a close look at where you're plotting the sprites though. The errors seem to pop up regularly based on the Y coordinate so might have a zone issue?  Do you mess with lockzone/unlockzone while plotting?

 

 

 

  • Like 1
Link to comment
Share on other sites

Thanks for the suggestions Mord.

 

I had a line by line run though, all the returns seems to be present and in the right places, no slip-through's to unintended code.

 

The code block I moved is simply a menu control block on the titlepage and it doesn't matter where I put it, the problem stays, so it's seeming more to do with the overall size and code going in certain memory locations. I also tried removing it and replacing it with dummy code to flash the screen and it's definitely not being executed and the problem remains.

 

Zone issue was not one i'd considered. I'm not using any lockzone or unlock zones when plotting (not got that advanced yet! :) ). The glitching does only happen on vertical movement as @RevEng noted.  if I plot the sprite and rotate through the same angles but without moving it, no glitch.

 

 

Link to comment
Share on other sites

Ok, it's probably going to be easiest if you share code, either here or PM. I still think it's related to dma holes, based on your earlier description, so it looks like either they haven't been enabled correctly or somehow have been disabled.

Link to comment
Share on other sites

58 minutes ago, RevEng said:

Ok, it's probably going to be easiest if you share code, either here or PM. I still think it's related to dma holes, based on your earlier description, so it looks like either they haven't been enabled correctly or somehow have been disabled.

Thanks @RevEng, appreciate your help. I'll shoot it over to you later.

Link to comment
Share on other sites

Ok, I had a look at Muddyfunster's code, and know the cause of the issue. It is the fact that Maria doesn't implement DMA Holes below $8000, which is a problem for vertically moving sprites that are also stored at $8000, not just those below $8000 as I originally stated. In this case, if Maria doesn't see zeroes from $6000-$7fff (assuming zoneheight=16) it will copy over whatever is stored in that area (code or non sprite-data) when a sprite is positioned lower than the beginning of a zone.

 

I should have clued into this earlier, but I've never had a game with sprite data all the way from the back of the rom to $8000, so it's always just been a theoretic sort of knowledge, rather than something I've personally dealt with.

 

Anyway, the workaround would either be to only use non-sprite graphics at $8000 and below (not an option here) or to use 7800basic DMA holes to ensure the area from $6000-$7fff remains empty.

  • Like 2
  • Thanks 1
Link to comment
Share on other sites

1 hour ago, SmittyB said:

Another mystery solved. That's useful to know seeing as while it makes perfect sense it's a problem without an immediately obvious solution if someone doesn't know the signs.

Yeah, agreed. I'll add a note somewhere in the 7800basic manual, probably under incgraphic, to highlight it.

  • Like 1
Link to comment
Share on other sites

6 hours ago, RevEng said:

Ok, I had a look at Muddyfunster's code, and know the cause of the issue. It is the fact that Maria doesn't implement DMA Holes below $8000, which is a problem for vertically moving sprites that are also stored at $8000, not just those below $8000 as I originally stated. In this case, if Maria doesn't see zeroes from $6000-$7fff (assuming zoneheight=16) it will copy over whatever is stored in that area (code or non sprite-data) when a sprite is positioned lower than the beginning of a zone.

 

I should have clued into this earlier, but I've never had a game with sprite data all the way from the back of the rom to $8000, so it's always just been a theoretic sort of knowledge, rather than something I've personally dealt with.

 

Anyway, the workaround would either be to only use non-sprite graphics at $8000 and below (not an option here) or to use 7800basic DMA holes to ensure the area from $6000-$7fff remains empty.

Thanks @RevEng appreciate review.

 

I do have some graphics that I load with incbanner for the titlescreen and if I load those first at $8000 the problem seems to be solved. Plan b would be use the DMA holes as you noted :)

 

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...