Thanks. I can get this rendering, but it crashes for me once I get playing - usually on the transition between the 1st and 2nd hole. Sometimes when I take the first shot, sometimes I can get a shot into the 2nd hole.
For now I’ll just enjoy the non-FX version.
Oof that SH1106 isn’t easy to talk to the fact we get it working at all is kinda a miracle.
That sounds like it could be a stack overflow… the stack has been getting really close to bss_end lately and maybe slight differences in your build pushed it over the edge. Try the updated versions – I reduced the size of the vertex/face cache in the pipeline to buy another 100 bytes or so (though still large enough to hold the meshes of all levels so far).
That’s likely the case the SH1106 implementation takes up more ram.
Brilliant 
It’s working great. Thanks @brow1067
I do have one really minor rendering issue to sort out (last column of 8 pixels in bottom row is black - no big deal, but I’ll try to figure out why).
I got the missing pixel column issue fixed by adding another call to Arduboy2Base::display() at the bottom without clearing the buffer.
Not sure why this works or if there are any adverse effects, though.
FX::display(CLEAR_BUFFER);
FX::readDataBytes(get_hole_fx_addr(leveli), &buf[0], 1024);
levelext = fxlevel.ext;
Arduboy2Base::display();That is strange… random idea, maybe then replacing FX::display with this would work:
FX::enableOLED();
Arduboy2Base::display();
Arduboy2Base::SPItransfer(buf[1023]);
FX::disableOLED();
Well, was worth a shot. Brace yourself 
I have added the FX version to the cart!
I’d like to recreate and into it. What steps did you make to build that version?
As expected the extra byte written causes a display shift. The SH1106 display code resets only the high colum address (high 4 bits) so each display call shiftrs the positiob by one for 16 frames then ‘resets’ to column 0
Sure. I’ll get you a hex with the issues today at some point. I’m happy to help any way I can. I also checked, and this issue (last column, last row, missing) occurs on Lode Runner FX as well on my display - I hadn’t noticed since there’s very little visually going on in that column.
EDIT: PM sent
EDIT 2: Here’s the source I’m building from:
#if ARDUGOLF_FX
#ifdef OLED_SH1106
FX::display(CLEAR_BUFFER);
FX::readDataBytes(get_hole_fx_addr(leveli), &buf[0], 1024);
#else
FX::displayPrefetch(get_hole_fx_addr(leveli), &buf[0], 1024, false);
#endif
levelext = fxlevel.ext;
#ifdef OLED_SH1106
Arduboy2Base::display(); // comment this out to recreate issue
#endif
#else
Arduboy2Base::display(CLEAR_BUFFER);
#endif
This displays correctly, but only with the second call Arduboy2Base::display() after the FX rendering. For the hex I sent you, I commented this line out to recreate the issue
The problem was as I expected:
The SH1106 display code ends while the last display byte has not been fully transfered.
Due to code inlinement the display was disabled immediately after the display code causing the display to ignore the last transfer.
@clintonium-119 workaround works because Arduboy2Base::display() is also used by FX::display(). When the function is used more than once it is no longer inlined but called, the return of the function causes a long enough delay to fix the timing issue.
I’ve fixed the issue and updated the homemade package to version 1.3.4
@brow1067 Let me know if you’d like me to open a PR for adding the SH1106 support. Either way, though. I’m good to host my own fork, as this is the only changed section:
#ifdef OLED_SH1106
FX::display(CLEAR_BUFFER);
FX::readDataBytes(get_hole_fx_addr(leveli), &buf[0], 1024);
#else
FX::displayPrefetch(get_hole_fx_addr(leveli), &buf[0], 1024, false);
#endif
btw I noticed div_frac_s wasn’t inlined. If you simplify it to the follwing it will. You may not expect it but It also save a few bytes.
static inline int16_t div_frac_s(int16_t x)
{
return x >> FB_FRAC_BITS;
}
That’s totally fine, please do!
Drat, hah! Thanks for the tip! I guess I should’ve just checked to see whether signed right shifts were arithmetic on avr.
Sorry for reviving old topic but I had some troubles compiling this game and I really want it to be in my collection. I used arduino ide to make game compatible with alternate wiring then I built hex and bin files. Everything seemed normal until this point but when I try to boot game on my arduino it just freezes until I reset it. I can’t play the game.
This might be a issue about FX data because for ide to saw fx datas I had to move 3 files (levels folder, fxdata.h and fxdata.txt) and it gave me two bin files. I used fxdata.bin in my flashcard image. Other was fxdata-data.bin and that didn’t work either
What should I do?
Try using the fxdata.bin and fxsave.bin from the repository. If that doesn’t work, you can try compiling the non-FX version by changing the lines at the top of game.hpp from
#ifndef ARDUGOLF_FX
#define ARDUGOLF_FX 1
#endif
to
#ifndef ARDUGOLF_FX
#define ARDUGOLF_FX 0
#endif
The non-FX version pretty much has the same features as the FX version currently. They both have the default course, but the FX version stores it on the flash chip and has all of the infrastructure to add more courses. I just haven’t gotten around to making any more yet, though I’d like to eventually.
Gave the same result, freezes my arduboy and nothing happens after that
But I tried this and now I am able to run non-fx version. Thank you.
If you do, please consider making a build for alternate wiring, I’d love more levels
Btw I am surprised how smooth this game runs, much better than I expected. You did a good job on rendering
The problem is, I don’t have a homemade Arduboy (yet!) so I have no way of testing builds for nonstandard configs before releasing.
Maybe it would be a good option to add different displays (SSD1309 and SH1106) and alternate wiring support to the debugger. I’d probably need help from the community to do that though, to verify the functionality is correct.