Problems with sprites

and this all runs inside the

if (mygame.update()) {
...
}

?

Yes.

Here’s an example:

#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;

	// Pretend there are 4 frames
	constexpr std::uint32_t minFrame = 0;
	constexpr std::uint32_t maxFrame = 3;
	std::uint32_t frameCounter = minFrame;

	while (mygame.isRunning())
	{
		if (mygame.update())
		{ 
			if(frameCounter < maxFrame)
				++frameCounter;
			else
				frameCounter = minFrame;
				
			mygame.display.drawBitmap(0, 0, test2, frameCounter);
		}   
	}
	return 0;
}

(Note that I haven’t tested this compiles, so there may be some syntax errors or something.)

I was trying to do something similar like that but it didn’t work.

With your constexpr lines I get a:

src/main.cpp:12:2: error: 'constexpr' was not declared in this scope

Which compiler are you using? Mbed online? Change constexpr to const.
(I keep forgetting not everyone is set up to use C++11.)

I’m still using platformio as that is the only usable toolchain for me.

Using

const std::uint32_t minFrame = 0;

I get

src/main.cpp:12:13: error: 'uint32_t' in namespace 'std' does not name a type

Then you don’t have your project set up to use C++11, which is understandable.

May as well just change constexpr to const for now.

Oh, I forgot std::uint32_t is a C++11 thing. Use uint32_t instead.


If you want to get C++11 working (I highly recommend it, it makes using C++ much easier) then you have to edit:
.platformio/packages/framework-mbed/platformio/variants/LPC11U68/LPC11U68.json

Edit the file to use:

 "cxx": [
            "-std=c++11", 
            "-fno-rtti", 
            "-Wvla"
        ], 

And then edit the platformio.ini in your project to use:

; PlatformIO Project Configuration File
;
;   Build options: build flags, source filter
;   Upload options: custom upload port, speed and extra flags
;   Library options: dependencies, extra library storages
;   Advanced options: extra scripting
;
; Please visit documentation for the other options and examples
; http://docs.platformio.org/page/projectconf.html

[env:lpc11u68]
platform = nxplpc
board = lpc11u68
framework = mbed
build_flags =
  -DPOKITTO_PIO_BUILD
  -Isrc
  -std=c++11
extra_scripts = pre:pokitto_pre.py

Thnx, but I’ll stick to the ‘default’ environment for now.

It compiles, and I almost have some sort of blinking animation, just that only half the frame is drawn and frames seem to be ‘sliding’ over each other.

A clear tutorial on how to get a piskel animated gif to display on the pokitto would still be really great :eyes:

That sounds like either a mode mismatch or possibly that third thingy isn’t correct.

It would be.
Unfortunately I won’t be the one to write it because I have no experience with using Piskel.
(I dislike browser-based tools so I wrote my own image converter.)

Understood.

Mode is correct. If I don’t give any frame argument I get the 1st frame perfectly on the screen.
When I manually set a frame only 1/3 of the frame is drawn.

I tried setting some value (you mentioned the frame width) as this third thing but then it breaks:

src/tester.h:373:1: error: too many initializers for 'const uint8_t [38722] {aka const unsigned char [38722]}'

[Edit: ok I have to increment the total bitmap to accomodate this number.

However the ‘animation’ only seems to shift the frame up and down a bit (or something)

Ah, I think I know what’s wrong.

Can you post your image header file?
It’ll be easier to demonstrate the fix manually.

Ok: http://mrtoasted.com/~dreamer/tester.h

It’s a little trinket for a friend’s wedding :slight_smile:

Sorry for the delay in replying, my internet has been misbehaving today - up and down every other minute.

(Which annoyingly affects my compiles as well, because the Pokitto script can’t check the compile script is up to date if there’s no internet.)


I’ve established the problem.

As suspected, your image data is in 16-colour format, not 4-colour format, which is why it’s coming out weird and why the animation isn’t working.

I figured this out with a bit of maths.
The image size should be ((width * height * frameCount) / (8 / bitsPerPixel)) + headerBytes.
If it was 4 colour (2 bits per pixel) it would have been ((220 * 176 * 2) / (8 / 2)) + 3 = 19363.
If it was 16 colour (4 bits per pixel) it would have been ((220 * 176 * 2) / (8 / 4)) + 3 = 38723.
After I corrected the number of header bytes, I tested the size of the image array (using static_assert) and it was in fact 38723 bytes.

Since I didn’t have the source image to generate a 4-colour version, I changed the screenmode to Mode 15 (220x176, 16 colour).
It’s slower than 4-colour mode, but at the moment you won’t notice that because you’ve just got a 2-frame animation.

I compiled it and got it working, here’s the files I used:

I didn’t check if C++98/C++03 mode works, so you might get a syntax error. Hopefully you won’t though.

Also I removed the array size between the brackets, which lets the compiler infer the size, and then I added the third argument, for which I duplicated the width (220).

Well of course I want to add more frames at some point. This is just a test.
And I’m already using the mode-15, otherwise I wouldn’t see anything at all.

Can you explain a bit what is happening here now in your gist?

Also, getting compile error:

src/main.cpp:8:14: error: expected constructor, destructor, or type conversion before '(' token

I forgot to remove my testing code.
(No point for guessing it uses C++11 features.)

Also I didn’t realise it had generated two .txt files as well.
Gist’s upload mechanism can be screwy at times.

I’ve removed the testing code and the two .txt files.
it should work fine now.

Ah I see.

Well now I just see the animation ‘jump’ up and down 2 lines.

Is that not what it’s supposed to do?

1 Like

Eh, nope.
This header: http://mrtoasted.com/~dreamer/tester.h
Should be equal to this gif: http://mrtoasted.com/~dreamer/tester.gif

But instead of showing the 2nd frame, it looks like the 1st frame is just doing this ‘line jump’ thing.

1 Like

@sbmrgd has brought something to my attention that implies there might be a bug in the library with that overload of drawBitmap.

Regardless of what the issue actually is, here’s a workaround for you:

The images are stored as-is and there’s an array that gathers them all.

Simply tack on the rest of your frames to the tester.h file, giving them appropriate names (tester2, tester3 etc), then add them to the array and remember to increase the maxFrame number.

I’ve tested to make sure it works:
WeddingThing.bin (74.3 KB)

@dreamer

Something caught my attention in your tester file. Is it really so, that Piskel outputs the following:


/* Piskel data for "tester" */
static const uint8_t tester[] = {
220,176,220,

… because that second 220 is definitely not supposed to be there

Edit, just tried it myself with a 220x176 image

It outputs the dimensions (first 2 bytes) correctly.

So it seems maybe you have somehow copy pasted the output in a weird way

#ifndef NEW_PISKEL_H
#define NEW_PISKEL_H

#include <stdint.h>

#define NEW_PISKEL_FRAME_COUNT 1
#define NEW_PISKEL_FRAME_WIDTH 220
#define NEW_PISKEL_FRAME_HEIGHT 176
#define NEW_PISKEL_COLOR_BITS 4

/* 16-bit (565 rgb) palette data for "New Piskel" */
static const uint16_t new_piskel_pal[] = { 
0xf800, 0x7e3, 0x1f, 
};

/* Piskel data for "New Piskel" */
static const uint8_t new_piskel[19362] = {
220,176,
//frame 0 
0x11,0x11,0x11,0x11,0x11,0x00,