The Great PokittoLib Cleanup of 2020

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.

Here is the pull request.

Contains breaking changes.

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

  • :white_check_mark: Finish Tilemap support for Tiles-And-Sprites (TAS) Mode
  • :white_check_mark: FemtoIDE: Automatically update projects to C++17
  • :white_check_mark: Make Micropython buildable again
  • Switch to TAS Mode in Micropython :arrow_left:
  • Merge PFFS and SDFS :x: False alarm, will revisit this later
  • Fix Mode 64 :white_check_mark:
3 Likes

Thanks for a big big contribution Felipe!

I am going to be testing your master for a while today before I merge the PR.

1 Like

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.

1 Like

You’re welcome, though it’s more deletion than contribution. :stuck_out_tongue_closed_eyes:

Thanks! I wouldn’t be able to test everything myself.

Tiles-And-Sprites

Inline variables. But the bump was primarily to force one update now, instead of bumping to 14 now and to 17 later.

I probably wouldn’t have guessed that.

Typically ‘and’ isn’t included as part of an acryonym (with a small number of exceptions, like RADAR).

Ah, I must have neglected to open one of the larger diffs.

It’s a shame we have to put up with the macro casing on those.
Hopefully we can migrate away from that later.

Nice to finally see a bit of constexpr though.

Updated the PR, all the asm files were missing because they were gitignored. :laughing:

3 Likes

I am not sure what’s going in here, but i hope it’s not like: New firmware and you are lucky if the old stuff works anymore?!

1 Like

What is this? Do you have some sample code showing this in action?? Do I need to update my ‘tiles’ tutorial???

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

2 Likes

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.

1 Like

Thanks for the explanation.
Well, yes the term „firmware“ might be wrong

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.

1 Like

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.

2 Likes

@FManga , began testing the overhaul PR

Femto

  • 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

this is a reported bug in GCC :slight_smile:

https://bugs.launchpad.net/gcc-arm-embedded/+bug/1810274

FIX for the OBJCPY problem (hex file build on EmBitz)

save arm-none-eabi-objcopy.exe from old \EmBitz\1.11\share\em_armgcc and put it in place of \EmBitz\1.11\share\em_armgcc\arm-none-eabi-objcopy.exe

EmBitz builds OK!

2 Likes

I’ll make the next FemtoIDE release automatically change the -std=c++14 flag into -std=c++17.

3 Likes

Very happy with results so far, got EmBitz to build with not big hurdles

1 Like

After trying FManga PR
I did have the same problems as @jonne.

Screen Modes

  • 1 OK
  • 2 OK
  • 13 OK
  • 15 OK
  • 4 (gamebuino) broken
  • 64 broken (never used by any games)

MicroPython broken

EmBitz

works after some hacks (i did’t replace any files just modify the settings)

  • Add the assembly files (Pokitto/POKITTO_HW/asm) under Project | Add files.
  • Change the compiler to femto compiler under Settings | Tools | Toolchain exutables.
  • Add -std=c++17 to c++ flags under Project | Build options| Compiler settings.
  • Uncheck Generate hex file under Project | Properties | Build targets.
  • Change the Post-build steps to
arm-none-eabi-objcopy.exe .\build\$(TARGET_OUTPUT_BASENAME).elf -O binary .\build\$(TARGET_OUTPUT_BASENAME).bin
.\build\lpcrc .\build\$(TARGET_OUTPUT_BASENAME).bin

under Project | Build Options | Pre/post build steps.

2 Likes

Mode 4? What mode 4?
giphy

Edit: Added a to-do list to the first post, so I don’t forget anything.

2 Likes

Found it in the wiki

Updated the Wiki, I’ll add TAS Mode to it when it’s merged.

1 Like