| |
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 |
|
| |
Martin Piper
Registered: Nov 2007
Posts: 722 |
Are you decompressing over $d000 without having IO disabled? |
| |
alwyz
Registered: Dec 2011
Posts: 32 |
Well, that depends. Yes and no.
I am looking for a trend here, and it seems be happening to programs I've packed first with sledgehammer. The sledgehammer version runs fine, and compressing with cruel crunch 3.6 after sledgehammer doesn't give me any problems. But compression with exomizer after sledgehammer gives the weird sprite bugs. It's happened with 2 different programs (I've only tested this with 2 programs), but both have exhibited this sprite issue in different ways, and sledgehammer first seems to be the commonality between both. |
| |
oziphantom
Registered: Oct 2014
Posts: 490 |
Are the sprites off by 2 bytes, if so then its exomiser either stripping a prg header when it shouldn't or not when it should are you using the right mode for what sledgehammer puts out? |
| |
Fred
Registered: Feb 2003
Posts: 285 |
It might be that your programs have unsaved memory and are expecting certain values at some memory locations which are used by the exomizer decruncher. This can cause weird behavior. You cannot blame exomizer for this.
Just check after unpack if the result is the same as before you packed with exomizer. If it is the same then you know it is a memory init problem and not exomizer. Make sure your programs init all memory locations before using it (including sprite data) and make sure all memory areas that are used are saved and then pack with exomizer. |
| |
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. |
... 4 posts hidden. Click here to view all posts....
|
| Previous - 1 | 2 - Next |
