| |
alwyz
Registered: Dec 2011
Posts: 32 |
More Exomizer Corruption - Sprites
Has anyone else noticed Exomizer corrupting sprites in programs? Mostly wrong placement on screen or other abnormalities of that nature? I've had the problem with several programs over the past week. Tried with 2 different versions of exomizer as well, same issue.
Alwyz |
|
... 4 posts hidden. Click here to view all posts....
|
| |
tlr
Registered: Sep 2003
Posts: 1790 |
I assume you know this but: It's not suitable to use sledgehammer before exomizing. It should still work but the result is larger and you get slower decompression.
Could you post a sledged program that fails? |
| |
iAN CooG
Registered: May 2002
Posts: 3193 |
Don't blame the tools, blame your lack of inited zp and other lower mem areas you use in your code.
Every packer/cruncher use different memory locations during decrunch, of course, so expect fuckups if you use some locations assuming they are zeroed. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
martin has the right hint - almost :)
to get funny bugs like this you dont actually have to depack _over_ $d000. the depacker needs a couple bytes after the depacked program, so if you pack up to $cfff - the depacker will write into the sprite registers when i/o is enabled. |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Quote: martin has the right hint - almost :)
to get funny bugs like this you dont actually have to depack _over_ $d000. the depacker needs a couple bytes after the depacked program, so if you pack up to $cfff - the depacker will write into the sprite registers when i/o is enabled.
The exomizer sfx depacker depacks in reverse so in that case a couple of bytes _below_ the depacked binary are corrupted instead.
If you don't want to post a binary, PM it. Impossible to debug otherwise. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
oh, ok then. just some uninitialized memory in that case :) |
| |
alwyz
Registered: Dec 2011
Posts: 32 |
Thanks for the info everyone. Here's a link to a test .d64 with the following files for The Last V8 [pal/ntsc fix applied as well].
fullc770 - full file with title pic, trainer, and sledgehammer packed game. exe $c770
exomizer version and cruel crunch version.
the car sprite is corrupted on the exomizer version.
https://we.tl/LXBKZBFSj7
Seems strange to me, still, even with all the replies. But if anyone wants to take a look and see if they see anything obvious, im all ears. Still have lots of holes in my coding knowledge. |
| |
iAN CooG
Registered: May 2002
Posts: 3193 |
just clear tapebuffer at $334 and you're done. The game wrongly assumes it's zeroed, apparently. Exomizer uses it as scratchpad.
*=$c700
lda #0
ldx #$34
clnloop
sta $300,x
inx
bne clnloop
jmp $c770
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
the (tape) original probably CAN assume this =D |
| |
alwyz
Registered: Dec 2011
Posts: 32 |
Ahh fantastic thank you! |
| |
Martin Piper
Registered: Nov 2007
Posts: 722 |
I would just compress the whole memory from $200-$fff8 with zero data at $200-$3ff or whatever was needed. :) |
| Previous - 1 | 2 - Next |
