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.
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.
).