I have a new Windows 10 Laptop and I hate it. One thing I have noticed is that things compiled on it are a little off … let me explain.
I copied the entire Arduino/libraries directory from my old machine to the new one.
I copied my ProjectABE installation from my old machine to the new.
I installed a new version of VSCode and the Arduino plugin.
I have fetched the latest code of my Blackjack game from GitHub onto both machines.
If I compile a HEX on the old machine and execute it within ProjectABE on either machine it works fines.
If I compile the same HEX on the new machine and execute it within ProjectABE it works on both machines however there are graphics glitches that I cannot explain as shown below:
Note the ellipses that are on the right hand side of the graphics. They appear as vertical lines when in fact the code is rendering a simple pixel using the following code:
Ah … my old machine is running 1.8.5 and the new 1.8.6
I have tried compiling the same code on 1.8.6 and 1.8.7 and both exhibit the problem on the new machine.
I then downgraded the machine to 1.8.5 and everything works properly.
I was aware that there were some issue with 1.8.6 but I thought people were unable to compile some programs. I never expected the issue to manifest itself in a subtle graphics error.
The drawPixel() code is assembly - I wonder if this is contributing to the issue? I also noticed that a few fillRect() calls were giving trouble elsewhere in the program and they use drawFastVLine() which in turn calls drawPixel().
I might flag @MLXXXp into this thread as he may know why the drawPixel() function might be programmatic. (I am assuming that the assembler is his code, maybe not).
A couple of weeks ago I looked into the drawPixel (and optimized the C bit a bit) as I noticed the compiler didn’t optimize out an unused pointer (didn’t solve that though)
@filmote if you zip up your project I’ll have a go and compare at it.
In case anyones wondering what’s optimized. I got rid of the else case and used a different masking technique (It will be featured in the next homemade package update)
The compiler somehow decides to store bitshift_left array in ram rather then in progmem. But since the drawPixel assembly code reads from progmem, ‘random’ bitmask data is used instead.
I think the problem arises here
I don’t know if it’s an actual compiler glitch or incorrect use of C(++) @Pharap any ideas?
Now I think about it, I’m not sure the bsl variable is actually needed anyway.
Registers are values, not references, so copying the value of bitshift_left straight to z should have had the same effect without needing the intermediary variable.
The compiler will start to complain about it being read only and ‘+z’ is used.
I found a little more about the glitch. It looks like the compiler optimized out bitshift_left and uses BIT_SHIFT instead which used in Ardbitmap and stored in ram.
Edit:
Okay my idea works the bit conversion code takes the same number of cycles, 1 instruction more but doesn’t need the byte array, saving 6 bytes.
//bit = 1 << (y & 7)
"ldi %[bit], 1 \n" bit = 1;
"sbrc %[y], 1 \n" if (y & _BV(1)) bit = 4;
"ldi %[bit], 4 \n"
"sbrc %[y], 0 \n" if (y & _BV(0)) bit = bit << 1;
"lsl %[bit] \n"
"sbrc %[y], 2 \n" if (y & _BV(2)) bit = (bit << 4) | (bit >> 4);
"swap %[bit] \n"
Can you create a GitHub PR for this? I’ll then apply it and make a new release.
If you don’t want to do a PR you can raise an issue with the code included. Or, I can just pull it from here. I can then apply your code and credit you.