I struggled a bit with figuring out waht the Pokitto equivalent of certain Arduboy functions were.
E.g. not having to call Display::clear() or Display::update() and Buttons::pressed behaving differently to what I was expecting and some of the functions documented in the doxygen aparently not existing (e.g. Buttons::bHeld()).
Also drawRect and fillRect donāt appear to be functioning properly in HiRes mode for some reason, hence the .bin is in lowres mode.
(Iāll file a bug report tomorrow.)
My mistake. The bug was with my code.
I forgot that 220 and 176 end up being negative when cast to int8_t.
Once Iād figured out what was what though, itās not too dissimilar from the original.
Later on Iām going to trying increasing the size of the fixed points to see if the ARM chip gets on better with values closer to its native word size.
@sbmrgd has informed me that Physix wasnāt compiling for PokittoSim due to some issues with random,
so Iāve gone through and made sure the v0.1.1 release compiles for PokittoSim.
(Iāve also removed the debug counter that I forgot to remove before.)
Also fixed the highres issue for v0.1.2, which should be the last version for a while.
I donāt have anything set up for recording on computer and itās a bit too dark for my video camera,
but I can dump some screencaps from the simulator.
PokittoSimulator.h
#define SCREENCAPTURE 0 // nonzero = the nth frame will be written to disk
#define MAKE_GIF 0 // nonzero = make a gif using ImageMagick Convert
I tweaked the code to not dump the stuff in my C drive though, and then assembled the frames via command line instead of letting the simulator do it though.
Itās given me some ideas for improving that aspect of the simulator though,
e.g. dumping the files relative to the executable.
Honestly, I have no idea.
The Arduboy version that itās adapted from runs fine and thatās got an ATMega32u4.
But this demo doesnāt really push the boat out in regards to physics.
Thereās no collision testing (other than cheap hacks to stop the blocks falling offscreen) or collision resolution, which are usually two of the more expensive things.
Maybe Iāll come back at a later point to add collisions and then see how far it can be pushed.
I made a PR for āputting the files near the executableā like I mentioned earlier:
@Pharap can you add FixedPoints library to PokittoLib?
Right now thereās a FixMath lib but maybe yours can fit better our needs.
Why not integrate some already existent library to do this? Maybe https://github.com/ginsweater/gif-h ? In that way it will be consistent on all develop platform. We could bind a key (F8) to toogle GIF recording on the output build directory.
I was originally going to create a non-Arduino version designed to work in any C++11 environment,
but it got put on the back-burner.
If I put it into the library, Iād have trouble updating it, and there might be issues with breaking changes that Iāve got planned for FixedPoints.
(I donāt know if milestones are publicly visible, but hereās the 2.0.0 milestone.)
So basically: maybe at some point, but not yet, and if I can find the time to start work on the general C++ edition, that version should work for Pokitto anyway.
Perhaps. The two reasons I suggested a script rather than a library are because a script would be less effort and it would allow for better customisation.
If we used that library you linked to, Iād recommend rewriting some of it so it uses new and delete instead of malloc and free and doesnāt use deprecated headers (i.e. make it use #include <cstdlib> instead of #include <stdlib.h>).
Though that particular library is a very minimalist approach and doesnāt provide the range of options that doing commandline ffmpeg would allow.