I’ll just leave this here: another option for ESP32 is TinyGo:

• https://medium.com/vacatronics/lets-go-embedded-with-esp32-cb6bb3043bd0
• https://tinygo.org/docs/concepts/faq/what-about-esp8266-esp32/
• And of course https://tinygo.org/docs/concepts/faq/why-go-instead-of-rust/ has actually the obvious 2 sides of the coin.

Time to look at the ESP32-CAM to create a Software Defined Block solution again. This time I can use it at home first, then apply to Randall.

This was the rationale behind the ESP32-CAM Grade Crossing controller.

Coding the ESP32 as I wanted in C++ was a bit of PITA and thus I started looking at alternatives, namely Rust would seem appropriate for that task. There’s now more embedded Rust for ESP32 than 2 years ago so that’s good.

OTOH a goal would be to use OpenCV and I don’t think there’s a good solution there. Preliminary research shows either OpenCV-for-Rust /or/ OpenCV-for-ESP32, but not sure there are libs for OpenCV-for-Rust-for-ESP32 yet.

Also to be honest, I’m not a big fan of Rust. I’m not super familiar with Rust so that may cause more problems than it would solve. “What would I expect from Rust” is the essential question. The answer is clear pointers/memory ownership especially in the context of multi-threading. From my cursory trying of Rust, it does solve the problem of “clarifying” at compile phase that memory management is sound. The syntax is a pile of crap, though.

I tried tmux a while ago, and didn’t like it, can’t remember why. Time to look at it again.

Let’s try it:

$ sudo apt install tmux

That does also require a few libs, libjpeg, lua (?!), etc.

Now the test is that I’m going to run Screen from Portal, and then inside I have Tmux on PiR.

[pir] $ tmux

[pir] $ tmux a  | attach  |  attach-session                # equivalent to -r -d

[pir] $ tmux list-sessions

Tmux has “windows” and “panes”: a window contains 1 or more panes.

Contrary to screen, “split” creates a new “pane” with its own shell. I don’t see how to “bring” a different window pane into the current one like I do with screen.

Contrary to screen, re-attaching preserves the split panes in a window.

https://tmuxcheatsheet.com/

Nesting screen in tmux in screen:

• I have this setup: screen > tmux > screen. I know 😕
• Ctrl-a + key for the first screen
• Ctrl-b + key for the first tmux.
• Ctrl-a + a + key does send to the 2nd screen

That actually works well, and it’s better than nesting 3 screen sessions inside each other.

https://love2d.org/ -- open source 2d game framework over Lua

https://luajit.org/

Another site online mentioned the use of cocos2d which is not very interesting.

Nerdkill needs to be updated to satisfy the Play store requirements.

I started an “N2” branch in the Nerdkill Android repo, simply rebuilding the existing Android source under a modern AS / gradle project. This should be considered 90% done. The only known issues are:

1. As for Asqare, I had to implement a “canvas zoom” in the rendering engine to simulate a smaller screen. This results in the desired pixelated look.
2. The weapon / cartouche area is 50% height. Probably needs to be adjusted by the canvas zoom or similar. [⇒ FIXED]
3. Lack of default Android menu. In Asqare, I fixed that by adding the window nav bar and populating a menu icon. I can do the same here, or I can just add a 3-dot menu icon in the intro screen. [⇒ Not Needed]

I’m likely going to just fix issue #2 (or maybe even not) and release the game as-is to meet the store requirements to avoid delisting. That’s the “immediate band-aid” strategy. [⇒ DONE, submitted to the store]

But a bit more long term, I’ve been wanting to put out a Godot-based game, and after contemplating doing that for Asqare, I’ll use Nerdkill instead. After all that’s the core leitmotif of the project, to be a test bed for platform adoptance.

Thinking of using D3 for learning how to use it, and RPisicine could be a good candidate for that. It’s a React app so how do we integrate them?

Many D3 tutorials: https://www.google.com/search?q=d3+js+tutorial

With React, apparently an obvious complexity is that they both manipulate the DOM, so need to use state/useEffects to combine them. This has more details:

https://www.pluralsight.com/guides/using-d3.js-inside-a-react-app 

https://blog.griddynamics.com/using-d3-js-with-react-js-an-8-step-comprehensive-manual/

There are some wrappers to help with that:

https://react-d3-library.github.io/

In npm https://www.npmjs.com/search?q=react%20d3, projects fall under 2 categories: “generic d3-in-react” libraries, and dedicated graphic components.

Current waypoint management needs some improvements:

• Compass screen
• Label Target waypoint (saved name)
• Display save name, truncate as needed.
• Menu save if new, vs edit if saved.
• Waypoint screen
• Label list as "saved Waypoints"
• Change selected buttons as row below text field.
• Separate the delete button
• "Set target" button to match the compass screen, with same icon.
• Share to map on this screen
• A more menu with 3 dot icon
• Export all (use a simple JSON)
• Import from JSON

In the latest version of Android Studio, the emulator shows up in a pane in the IDE. This is annoying and absolutely unusable on a small laptop screen. How do I get rid of that and have a separate window as usual?

To get rid of that: AS > File > Settings > Tools > Emulator > uncheck “Launch in a tool window”.

Also keep creating the AVD with the “Cold Boot” setting instead of “Quick Boot”. Most of the time the emulator starts “unpowered” in quick boot, nothing on screen, and no idea on how to fix it.

If I had to rebuild Asqare today, which framework would I choose?

Clearly I would use an existing one instead of rolling my own. There are lots of choices out there.

• Godot is one obvious choice. It’s even officially listed in the Using a game engine on Android guide.
• libGDX is another obvious choice for something lower level. It’s not a “full stack” game engine, yet it’s a good foundation for someone to roll their own renderer.

For Jump!, the idea was to use scenes to implement everything in Godot. It’s a Godot thing, which just happens to export to Android. Some functionality can be provided by plugins, such as the screen sharing/export provided by GodotShare.aar → this is done by generating an “aar” library, and making it available to Godot..

For something like Asqare, the native Android implementation has some advantages as the gameplay screen is a view in an actual activity. It would be nice to know how to implement that level of integration using Godot. E.g. ideally a scene is just one view, or maybe one fragment, which is controlled by an otherwise “pure” Android app. That is, I want the reverse: instead of adding android library functionality to Godot, I’d like Godot to generate a library that I integrate in an external android app. This mode doesn’t quite seem supported but this seems the closer we can get:

https://docs.godotengine.org/en/3.5/tutorials/export/android_custom_build.html# 

The obvious cons here is that this implies we now have to deal with two tools/frameworks and they might have incompatible release schedules or requirements.

Generally speaking for all these small games, there’s a strong desire to reorganize them in a clear MVP or MVC pattern -- model-view-presenter or model-view-controller. MVC makes the most sense here: the model is the core gameplay, which can be coded in a separate library (e.g. an aar import), the view is an android skeleton and/or godot, and the presenter is godot.

It’s worth pointing out that games like Asqare and even Nerdkill are already architectured like that.

In a sense that seems to run contrary to the default Godot game implementation: Godot naturally tends to architecture a game around its scene graph as being the directing entity. The scene graph is the model. Furthermore entities in the scene graph embed part of their own logic such as collision and event handling.

In the Asqare case, that’s not incompatible with the MVC pattern: the “core” Asqare  game can be modeled as a board representation (an array of e.g. integers) and a function computing the name board state as well as a list of view updates. The presenter part in Godot would basically map each board cell to a sprite entity. Updates are actions like select (implemented as blinking or rotating a sprite), vanish, or animate an entry. This is the way the game is currently implemented in its Java micro “game engine”, even though it’s all hard coded functions and nothing is really generic.

From that description, it does read like using Godot for Asqare would be a bit of a stretch actually:

• Godot drives the android app creation, instead of being an embedded view/fragment.
• Godot strives to be the model with its scene graph.

The only benefit of using Godot is to use it as an animation engine (and without having to learn a new one). That’s more or less what using libGDX would do.

I should make the point that Nerdkill on Godot does make a lot of sense. The “scene graph is the model” works fine for Nerdkill.

But what about Asqare. If not Godot, then what?

What do I want, ideally?

• Some kind of scene graph thingy.
• An animation engine with some basic effects.
• Optional: 3d support with an orthographic top view. Would allow to draw elements in Blender and animate them without having to render them to static image maps
• The cons of that is the added complexity of a 3d GL view.

What if we took a different approach? Kotling game engines:

• MiniGDX: https://gamefromscratch.com/minigdx-kotlin-game-development-framework/
• Besides the name, this has no affiliation with libGDX. It uses ljgl and al.
• This is just a one-person game engine with no pedigree and no support team.
• Same person has contributed to libKTX.
• libGDX is well known and documented.
• Does both 2d and 3d.
• https://libgdx.com/wiki/jvm-langs/using-libgdx-with-kotlin
• https://libktx.github.io/
• Korge: https://korge.org/ 
• https://gamefromscratch.com/korge-engine-kotlin-powered-open-source-game-engine/
• Korge is a set of libraries + some IJ plugin.
• It focuses on 2d.
• Kotlin-is-fabulous indoctrination is a cons.
• That Flutter-simple-game thing?
• Meh to Dart.
• No desire to use it long term.
• Android Jetpack Compose?

In my case, looking at the long-term, say I update an app next in 5-10 years:

• The IDE project may be obsolete. E.g. some of my projects still use Eclipse.
• The project configuration may be obsolete, even if the IDE is still the same.
• Example: gradle groovy now vs maybe gradle kotlin later.
• Who knows about stuff from e.g. Godot?
• The language could become obsolete.
• Example: go1 projects not compatible with go1.5, etc.
• C# has the same issue. I expect Kotlin to have the same issue.
• Java has this “legacy” thinking model which saves it for now.
• Who knows about GDScript?
• Library support for Android and older API models changes.
• Compat library is min 14 these days.
• A lot of stuff at G is min 21.

Having an app/game that depends on e.g. Godot + Android means to have to deal with all that, times 2, for each platform, plus their intersection.

I found the sources for both under the old Autosettings project.

Back then I was using branches, instead of placing such projects in their own repository.

I should move them under their own git repo under bitbucket/ralfoide.

Flashlight matters; Brighteriffic not so much yet I may update it if it isn’t too cumbersome.

In both cases it makes sense to duplicate the autosettings repo entirely to preserve history, and limit it to these app folders only.

<fork autosettings repo>

$ git clone git@bitbucket.org:ralfoide/brighteriffic.git

$ git filter-branch --prune-empty --index-filter 'git rm  --ignore-unmatch --cached -r AlarmTest branches Flashlight wiki distrib/[aAfqtT]* trunk/AutoSettings trunk/TimerifficTest'

$ git push --force