2.Basic drawBitmap example

[Pharap]

Sorry in advance for the double post.

---

So there is still something wrong in the background that is causing purple to be displayed when using 0 and 1?

I found your problem.
This tutorial isn’t in sync with the github repo.

The repo lists the palette as:

const uint16_t pokitto_icon_pal[] = {
27973,63519,4195,28185,57210,13092,33972,54611,23545,
};

Hence magenta is indeed at index 1.
There’s some other issues with the version on the repo that I’m currently looking into fixing.

---

@jonne

There’s two issues with the repo version

1. I can see that the repo version is using bgcolor as if it were a function.
2. There’s a line of green down the side of the Pokitto sprite

I’ve made a fork with an edit that fixes the first issue, but I’m not sure what the problem is with the second issue.

(Also, is the sprite’s background supposed to be transparent or not?)

[jonne]

I also find this fascinating. Thanks @Pharap for looking into it.

At the moment I’m kind of busy improving the sound (sorry @Rakkachi )!

[Rakkachi]

no prob, i like the sound to improve as well.

[Rakkachi]

Thanks, that does indeed seem to be part of the issue.

Had also made a mistake myself.
I had a made a copy of the tutorial and used this in a selfmade icon:

//Total colors 7
const uint16_t pokitto_icon_pal[] = {
63519,65535,31,65504,0,63488,33792,

obviously color 0 (63519) and color 1(65535) are almost the same so in my cloned version of the program i did not see the difference.

[Pharap]

There’s no rush to get it sorted, I can probably figure out the rest with a bit of time.

I tried regenerating the sprite data with img2pok and moving the sprite and both cases came out with the green strip, so it’s either a bug in img2pok or a bug in the bitmap drawing code.

I think it’s the latter.

---

I’m not sure if I’m doing something wrong or not but it seems that when altering the source code of the library itself, the changes don’t carry through to the examples.

I added a return; to the top of the drawBitmap function, but the Pokitto sprite is still drawing.

---

P.S. Nice oscilloscope.

[carbonacat]

Makes me think, could it be realistic to make a small oscilloscope hat? haha

[Pharap]

I tried to fix the issue but I’m struggling to understand the bitmap code.

Does anyone else get an issue with having a green stripe along the right side of the sprite?
(Using a fresh copy of the Pokitto lib obtained from the master branch, after ammeding bgcolor(1) to bgcolor = 1. My fork fixing that typo can be found here.)

[Hanski]

I have not noticed that kind of bug. Is there something particular you are struggling with. The 4bpp code is heavily optimized which makes it a bit hard to understand.

[jonne]

I tried to fix the issue but I’m struggling to understand the bitmap code.

If you make a short example code that produces the issue we can look at it together. The 4bpp code was a real pain to get working with bitmaps of varying widths, screen edge clipping etc. because its all done by bitshifting. There may well be a special situation still where there is an issue.

[Pharap]

It’s exactly the same bitmap example, the only code change I made was to make the background index 1 (magenta) instead of 0 (green).
In which case the result was this:

I tried some actual games and they didn’t have any issue (though they were ones I had lying around so they’re probably out of date or built with an older version of the library, I’ll grab some fresh copies later to check if nobody else can reproduce this).

---

Here’s a list of the exact steps I made to reach this.
(Bear in mind I’m on a Windows 8.1 system.)

1. Download a fresh copy of the PokittoLib (the master branch, as zip).
2. Open EmBitz.
3. Close all other projects.
4. Open the recently downloaded copy of PokittoLib.
5. Open bitmap.cpp.
6. Change mygame.display.bgcolor=0; to mygame.display.bgcolor=1;.
7. Build > Select target > Bitmap.
8. Build > Clean target.
9. Build > Build target.
10. Find the build folder.
11. Connect the Pokitto.
12. Turn the Pokitto on.
13. Put the Pokitto into CRP DISABLD mode.
14. Delete firmware.bin.
15. Copy build/bitmap.bin to the CRP DISABLD drive.
16. Wait for the copy to finish.
17. Eject the Pokitto.
18. Wait for the Pokitto to disconnect.
19. Turn the Pokitto on and off again.

---

@Hanski

The 4bpp code is heavily optimized which makes it a bit hard to understand.

That’s one of the reasons I gave up looking.
By the time I’ve understood it, someone who already knows how it works could probably have spotted the problem or realised it’s not even in the drawBitmapData function.
I’m fine with shifting and masking, but I don’t know why the odd and even pixel starting lines are treated differently and there’s quite a bit of code to get through.
(Also there’s some other practices I’m not used to, like variables being declared before the scope they’re needed in.)

[Hanski]

@jonne: if you busy I can look at this.

[jonne]

Thanks Hanski!

I am very busy, improving the sound and other things. I am now succesfully transferring data to screen buffer using DMA. So first application of DMA on Pokitto is working, and it means lots of interesting stuff we could do (for example screen scrolling with DMA )

[Hanski]

Excellent! How about a SID player with DMA

[jonne]

Excellent! How about a SID player with DMA

Transferring sound via DMA is actually the reason why I am doing this. Now fingers crossed it works.

[Hanski]

The problem is that the bitmap width is not dividable by 2, it is 35 pixels.

[Hanski]

Here is the fixed image and the header. I added one “empty” row to the right side so that the width is now 36 pixels.
pokitto_icon.zip (1.1 KB)

[jonne]

Thanks @Hanski. Fixed in both PokittoLib on Github and mbed online.

So lesson of the day: "make your bitmap widths divisible by two!"

[Pharap]

The problem is that the bitmap width is not dividable by 2, it is 35 pixels.

So lesson of the day: “make your bitmap widths divisible by two!”

I wasn’t aware that was an issue, so that’s good to know
(There’s probably a way to account for that. Not that it’s particularly important at the moment.)

Is that restriction documented anywhere?
(Come to think of it, I haven’t actually seen/found any documention for the image formats.)

At least now that the cause is clear, it’ll make the issue easier to spot in future (e.g. if someone makes a post saying “there’s an oddly coloured line next to my sprite”).

[Hanski]

This tutorial is one good place to document it Another place is the doxygen API documentation.

[HomineLudens]

Now that @Hanski point it out, it come to mind that this issue already happens:

How to use Bitmap (BMP)?

Your paddle image is 5X20 pixel. Can you try with an image 4X20?
Maybe there’s some problem with odd pixels.

As you said it seems that every odd number makes this green column. Do you know a way to fix this?

Maybe I could add a warning in img2pok when user try to load odd width images?