It sure would be nice to have a fast tiles-and-sprites screen mode… but we already have way too many modes. So, in the process of adding a new mode, I took the opportunity to clean up the existing modes and remove the unused ones.
I figured that, if we’re going to break stuff, might as well do it at once instead of making it a long, slow, painful process.
While the PR has already been merged, there is still work to be done.
TO-DO LIST
Finish Tilemap support for Tiles-And-Sprites (TAS) Mode
And for those of us who aren’t good at guessing acronyms, was ist ‘TAS’?
Removing max and min might break a few games, but I’m glad that’s finally going.
Now if only we could make ‘fake avr’ opt-in rather than opt-out…
I couldn’t spot anything offhand that would make this require C++17 specifically,
C++11 and C++14 should work as well.
That’s an observation, not a complaint.
With C++17 we can start using if constexpr instead of the dreaded preprocessor.
Also std::optional, std::any, std::variant and std::string_view should make life easier,
not to mention std::size and structured binding declarations.
No, we are streamlining the library which is used to create new games. Old games will work as usual. This concerns mostly the people involved in updating the PokittoLib and tools used for programming
It might affect people who compile from source because some backwards compatibility might be broken,
but precompiled .bins won’t be affected because the hardware hasn’t changed,
and older versions of the library are always available through the commit history.
I’m not even sure if the Pokitto has ‘firmware’ as such.
I think this is more like an option. It is a special screen mode that uses very little ram so you can use 220x176 / 256 color mode and still have a plenty of ram to play with. But there are limitations on how you can draw on the screen.
Not yet, still working on the Tilemap class that will be specific to this mode. Hopefully, it will be compatible with your tutorial, no need to change anything.
Hello CPP fails fix:
replace -std=c++14 with -std=c++17 in project.json
Hello Java builds OK
Hello MicroPython fails no fix yet
EmBitz
… in progress
requires deselecting GNU C++ 14 from options and passing -std=c++17 in Build options / C++ flags / others
requires copying newer version of GCC from Femto to EmBitz
– from: \IDE-windows-v0.1.5\windows\arm
– to: \EmBitz\1.11\share\em_armgcc
But still fails to create hex file (problem with objcopy, investigating)
arm-none-eabi-objcopy.exe: .\build\hello.hex 64-bit address 0x4b4fa300000000 out of range for Intel Hex file
arm-none-eabi-objcopy.exe:.\build\hello.hex: bad value
Finish Tilemap support for Tiles-And-Sprites (TAS) Mode
