Those two things aren’t mutually exclusive.
Some of my stylistic preferences also use less progmem and/or improve performance.
(As you’ve discovered.)
Others are just a more direct translation of what the compiler will generate anyway,
or just something I generally prefer.
(Pretty much every one of my stylistic preferences has a reason behind it.)
Sometimes it’s not about how clever the compiler is.
Sometimes the compiler is actually legally not allowed to make certain changes because they’d break certain guarantees that the language specification enforces.
(And if it broke them, it would be non-compliant.)
In this case,
texPtr++ has a significant side effect (i.e. it alters the value of
whereas in my version, everything on the right hand side of the
= has no side effects,
pgm_read_byte, which is implemented in assembly)
so the compiler has more flexibility with how it’s allowed to optimise the statements.
I tend to avoid post increment in general because of its weak ordering.
For an expression
x++, there are two parts:
x is incremented, and the original value of
x is produced.
There is no guarantee about the ordering of those events.
As a result there are a lot of expressions using post-increment that have undefined behaviour.
i = v[++i] is well-defined, but
i = v[i++] is undefined,
i = ++i + 1 iswell-defined but
i = i++ + 1 is undefined.
Rather than remembering what is and isn’t defined, I prefer to do
a = v[i]; ++i; because then there’s absolutely no ambiguity as to what’s actually happening.
Also in general I tend to write my code to have as few side effects as possible,
which is why I’ll typically introduce new (constant) variables rather than modifying old ones.
(This is actually similar to something the compiler does internally.)
If that’s the
DrawScaled function then you may have some clashes with some of my changes.
I don’t know if I’ll get chance to look today.