Sounds like you're thinking that I'm accusing you of being mistaken in your findings, that's definitely not the case. It's just that in your initial post you said the error appeared to stem from a lack of image complexity in a compressed, mostly single-color splash screen, and that adding a bit of visual complexity seemed to solve the issue. As I'm intending to use PX9 for compressing and storing relatively dense spritesheets, it doesn't seem like the issue should crop up. I'll try and adapt the new version for string capability just in case, though.
@JadeLombax, sorry no not at all. The new post is entirely new train of thought. I realize it was worded poorly. Disregarding entropy issues, I am seeing an effect where a properly compressed image seems to improperly decompress using the same string in the same cart just a few lines later, but if I save the string to a file and copy it into another cart, it works fine. I am asking a new question, if this weird behavior makes any sense to you, or despite thinking I was being thorough, I have some mistake in my test that I'm not seeing. Again I'm not challenging anything, just that you implemented/use the str version, and I'm seeing this weird behavior with the string version, so I reached out for your opinion/crosscheck.
Okay, I think I might know what the problem is. The string encoder outputs full 8-bit strings, which include 'puny font mode' characters, and unfortunately you have to press ctrl+p to enter puny font mode' before pasting them or they'll incorrectly show up as normal letters. Have you been doing that?
@JadeLombax I just wasn't thinking straight. PX9_COMP returns a string with escaped characters, which have to be pasted into the code as a literal in order for them to be processed correctly. I was taking the string result from PX9_COMP, as a live variable in running code, and directly shoving it back into PX9_DECOMP, and was confused by the garbled output.
<<< entire page of crap deleted that doesn't matter anymore >>>
Here is a demo cart fwiw:
Sorry for going down a rabbit-hole for a useless use-case side effect and adding pages to the BBS thread.
Well, it's not useless if it helps someone else avoid a similar problem in the future.🙂
Here now, this is not good. I tried Px9 to compress some test pictures to see how it would do and BOY did it fail on one of them !
Also these are findings AFTER I wrote my own compressor, mind you, not before. I just wanted to try out @zep's brainchild and compare it with the one I wrote.
The import is standard, 128x128 single color, font I doodled up along with ZEP's own characters >128 and <32.
I can post mine which does work but I really don't wanna do that cause this is ZEP's post. I'd be more interested in seeing it work for Px9.
. . .
Update 12-19-22. It works in a version someone ELSE posted. So I guess I have to say, do not use the cart that is listed directly at the top as it has not been updated yet.
Further I have not found a version that saves to string AND still correctly decompresses my test image, so if there isn't one, that means I have written the only one.
And I would like that very much not to be the case as I want @zep to be able to own this.
Also, @freds72 replied to this comment, not in this thread, but this ONE:
Why did he ? I don't know. Yes that is confusing.
[Please log in to post a comment]