Sorry, am only on tabletā¦ @jonne seems like this line. Looks like it requires a palette thatās missing. Iāll take a closer look when Iām on PC.
Make sure there is only one palette (the default one, named Current colors. It should be the case if youāre getting the error. If there are more, delete them.)
Click āmanage this paletteā
In the window that pops up click āsaveā. This will make a new clone of the default palette:
Point 2.3.2 about using palette #1 (not palette #0 aka current colors) and the reason explained also (palette #0 - current colors will not save user defined, but unused colors of the palette). This is a feature in Piskel.
Hmm I see, it makes sense, but @jonne shouldnāt you add some kind of pop up window that will say whatās going on, instead of just failing silently? That tutorial is long and some people who feel confident will skip it and then fail at this, and if they donāt know about the JS console, they wonāt even know somethingās failing.
Put the header in src with your code and include it as #include "test.h". lib is designed for external libraries that arenāt registered with PlatformIOās system.
Ok derp. Somehow I equated āheaderā with ālibraryā and assumed it should go there.
Now Iām trying to display an image at either 220x176 or 110x88 pix.
With the lower res at 16 bit color it works, but the higher resolution the 2 halves of the image look jumbled together and everything is grey-scale.
#include "Pokitto.h"
#include "test2.h"
Pokitto::Core mygame;
int main () {
mygame.begin();
mygame.display.load565Palette(test2_pal); //load the palette for the image
mygame.display.bgcolor=0;
while (mygame.isRunning()) {
if (mygame.update()) {
mygame.display.drawBitmap(0,0,test2);
}
}
return 0;
}
When you say either 220x176 or 110x88, are you sure youāre using 16-colour modes for both of those and not accidentally using a 4-colour mode for either?
The 16-colour modes and the 4-colour modes expect images in different formats, and image halves looking jumbled sounds like a typical case of mixing the modes up.
Thereās a reference for the capabilities of the different modes here:
See, I had no idea about these screenmodes, since this was not mentioned in this tutorial.
I will play with this a bit so see how I can make my piskel-animation work.
For the animation you just import the same header and do the same drawBitmap() ?
[Edit: nope. @jonne said it was simple so I must be missing something]
The bitmap has to be in a particular format though.
It needs to have the width, the height and some third value (that I still donāt quite understand) at the beginning, and then the data for all the frames.
(We could really do with improving the library documentation,
but I keep putting it off because Iād really love to redesign the library with C++11 in mind.)
It would depend entirely on what kind of animation you want to do.
The frame system is designed to be flexible, so people can (for example) choose the order that frames are displayed in.
If you just want to loop through a set number of frames every frame then the easiest way is to just maintain a counter variable, increment it each frame/update and loop it back around if it goes too high.
That sets the number of frame updates that happen per second.
Not animation frames, but the frames that are actually drawn to the screen (i.e. what the screen displays is āa frameā, and it draws a certain number of those per second - the number of frames per second is the frame rate).
Its relation to your animation speed is reflected by how you choose to do the animation.
Using the simple method I demonstrated, your image will change frame at the same rate as the frame rate.
Substituting the width worked for me.
I havenāt got round to asking what itās actually for, so hopefully someone else will chime in and explain that.