Nice!

What is going on with the topmost pixel row and the far right column of those images.

It seems to be a very specific CEmu bug where if I click 'Copy PNG' then directly paste to Imgur, it messes up the image. If I use 'Save PNG' or I paste to a different application like Paint then it looks normal. I can make a CEmu issue. The photos don't have that artifact on the actual calculator.

Honestly was not expecting to see any more progress on this project, but it's nice to see it return! I'm particularly impressed by that panning and zooming.

You probably only want to compress the image data, as if there are any header strings that you're using you'd need to do some magic to detect them otherwise (which is an issue that I ran into with VYSION 2 at one point).

I'm still a bit concerned about the image size here--it looks like you should expect the average 320x240 image to be ~50k if it's compressed? Let's just hope no one wants to put more than one of those super high-definition images on the calc...

Anyway, keep up the good work! I'm particularly excited to see the space efficiency of those compressed 16bpp images once you get them working.

Thankfully Tari made a converter using Rust for any modern web browser! I've confirmed it works with the v0.0.1-Alpha!
Topic: https://www.cemetech.net/forum/viewtopic.php?p=301001
Website: https://taricorp.gitlab.io/hdpictureconverter-rs/

Yep saw it very excited to use it even though I'm on windows thanks for the work on this program. I really enjoy your channel and your programs. Anyways this is cool.

I pushed another pre-release which includes zx0 support! It's not quite as exciting as zx7 since it just barely improves the compressed size of my test image. However, it's still significantly better than no compression! I feel the program is stable enough and feature rich enough to become a beta you can Download! (You will need to update the converter as well).


click for full size: no compression, zx7, zx0

I've added multi-core support to the converter so the program will launch multiple instances of convimg and complete conversion significantly faster than before! However, the stability has degraded. The resizing options may not work and if convimg fails the converter just freezes. I have some ideas on how to fix this but I may not have time for a while. I needed to release something to accompany the viewer so I've pushed out another Alpha to Download.

I've updated my converter to use compression as well, so it will work with the most recent viewer (and not any older ones).

Since you've been changing the data format (just adding compression) and offering things as some kind of release, I'd strongly recommend changing the image headers so images made for old versions of the viewer can't be misinterpreted- I'd expect attempting to interpret uncompressed data as compressed data could lead to very bad behavior.

I worked a bit more on this to fix a bug TIny reported. You can no longer zoom in or out too far! Even if you somehow manage to still do that, the program should gracefully quit rather than crash.

I also added drawing interrupts so if you press a key while the image is drawing, it will immediately stop drawing and do the button you pressed. This makes the program feel so much more responsive especially for large images! It's not perfect, sometimes it won't accept the key press and will only stop drawing. I'll look into it more in the future but it works well enough for now.


I noticed a bug that worries me but I'm not sure how to approach. When I zoom in, sometimes I'll see small artifacts in the picture as if the pixel is using the wrong palette value. If I zoom in further, the artifacts disappear. Here's an example if you look in the circled area, you'll see red pixels where there shouldn't be any red.

What would cause such an artifact? I suspect it may be a result of gfx_ScaleSprite() but I will need to test more to verify. Are there any specific tests I could do to diagnose this?

No new release for now but you can give my debug version a try if you want!

Hmmm it could be gfx_ScaleSprite leaving artifacts or it could be the image convertor itself "convimg" that comes with the toolchain.

I believe that since the dog image hasn't been "optimized" / limited to 255 colors. There would be some color differences when zooming in.

I think you should at try limiting how many palette colors in the images using in a photo editor then convert the image again. I think this should solve the issue for now.

I don't believe the issue lies with convimg because the artifacts only exist at certain zoom levels. I'll make an issue for now and look closer at it later.

Apparently the bug TIny reported was due to the calculator trying to display a sub-image that was larger than the dimensions of the screen. I've added a check for that so the bug should actually be fixed now

I took some advice from a long time ago and made the program only clip sub-images that are on the edge of the screen. Unfortunately while it's a good idea, even with large images it only improved render speed by about 1% since the majority of the time is spent decompressing the image. Maybe I could look into caching some sub-images after they are initially compressed. While the first draw of the image would still be slow, subsequent draws for zooming and panning would be significantly faster.