Calculator graphics drawing benchmark

[robve]

DavidM,

Nice results for the HP 50g! Thanks for contributing!

(01-29-2022 04:36 PM)DavidM Wrote:  

Quote:...including dashed lines if that speeds up the algorithm. ... If anyone finds a faster way to run these programs, then let us know.

Reading the above led me to believe that it would be acceptable to change the approach a bit for a more optimized method that reduces some of the overhead of the brute-force algorithm. The following builds a complete row and column using the standard LINE commands, then draws those lines in stepwise fashion both horizontally and vertically with a random offset as per the standard algorithm. If this is an inappropriate optimization, let me know and I'll edit it out of this post for consistency with the other programs:

As long as the S=4 Hitomezashi-based algorithm draws (dashed) lines with random offsets then it's benchmarking properly. If a dashed line drawing feature exists, then by all means use it. Also the line drawing order does not matter, even though it may no longer produce the eye-pleasing horizontal wave/weave effect.

I don't closely follow the logic of the second version, but from your explanation and by perusing the code it appears to place a dashed line in some PICT memory (like a sprite?) to redraw copies of it at random offsets? Don't want to be a PitA, but sprite drawing is different and isn't benchmarked. Still, I feel strongly that this method should be included in the performance table somehow, but perhaps in a separate benchmark table that allows memory copy/sprite/blitting operations to speed up line drawing (per line) for all calculators that support such features. That's just my opinion, not sure what others think is most fair?

- Rob