Problems with sprites

Hmm, when I try to export the header [Download .h file] with piskel I get in the .js console:

TypeError: i[1] is undefined

Browser is firefox 63.0

Edit: with chromium 69.0.3497.92 with imported .piskel I get:

Uncaught TypeError: Cannot read property 'getColors' of undefined
    at a.MiscExportController.onDownloadCFileClick_
1 Like

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.

EDIT:

Why is it taking palettes[1] and not palettes[0]?

EDIT:

@dreamer I have a temporary workaround:

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

image

  1. Click ā€œmanage this paletteā€

image

  1. In the window that pops up click ā€œsaveā€. This will make a new clone of the default palette:

  1. Now if you look in the palette list, you should see the cloned palette:

  1. Now the export should work.

Fantastic! totally works for both browsers :slight_smile:

1 Like

Glad to hear, anyway we should fix this ASAP :slight_smile:

@dreamer and @drummyfish

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.

1 Like

Yes, you are correct

1 Like

Iā€™m now struggling to include the generated .h file.

Should I put this in the lib/ dir? After including the header it is not found.

What toolchain? mbed online / Platformio / embitz?

Oh, sorry. Platformio. Calling the icon test I just get: src/main.cpp:3:10: fatal error: test.h: No such file or directory

Do you include the file like this:

#include <yourheader.h>

or like this:

#include "yourheader.h"

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.

1 Like

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.

1 Like

Copy paste your code (or the part where you draw) and your My_settings.h here

Iā€™m just doing the basic tutorial still:

  #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;
  }
#ifndef MY_SETTINGS_H
#define MY_SETTINGS_H

#define PROJ_HIRES 1            //1 = high resolution (220x176) , 0 = low resolution fast mode (110x88)
#define PROJ_ENABLE_SOUND 0     // 0 = all sound functions disabled

#endif

With for instance this file: http://mrtoasted.com/~dreamer/test2.h

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:

1 Like

Today I Learned!

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]

1 Like

Thereā€™s an overload for drawBitmap that accepts a frame argument:
http://pokitto.com/api/class_pokitto_1_1_display.html#a28671631d3b26c1bcaf076f352406657

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.

So

const char image[] =
{
	// Width, Height, 3rd thing
	16, 16, 16,
	
	// Frame 0
	/* frame 0 data... */
	
	// Frame 1
	/* frame 1 data... */
};

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

Ok, so what is the simplest way to iterate over these frames?
I saw there is a setFrameRate() for the core, is this related?

The default export from piskel does not include this third value by the way.

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.

E.g.

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

if(frameCounter < maxFrame)
	++frameCounter;
else
	frameCounter = minFrame;

Sort of.

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.