2.Basic drawBitmap example

Beginners Welcome! Tutorials & requests
27

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

28

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.

29

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.

30

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:

GreenStripeA.jpg3200×2400 1.64 MB
GreenStripeB.jpg3200×2400 1.55 MB

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.

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

31

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

1 Like
32

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 :grin:)

2 Likes
33

Excellent! How about a SID player with DMA :wink:

1 Like
34

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

1 Like
35

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

2 Likes
36

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)

1 Like
37

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

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

3 Likes
38

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

2 Likes
39

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

40

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

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

2 Likes
41

I think we definitely need somewhere to document the image formats.
Preferably both a custom page on the doxygen area and a thread here.
(Evidently I don’t know enough about the formats to contribute.)

Now that you’ve pointed out that link I do vaguely remember that discussion. So much has happened since then that it completely slipped my mind.

I very nearly suggested this in my last comment but decided not to mention it since I knew you were the img2pok author and you hadn’t been in the conversation until now. (And I was in a rush.)

A warning on pok2img would be an excellent idea since I suspect many people won’t stop to read the documentation, but they might stop if the image encoder tells them about the possible problems.

1 Like
42

Learned this the hard way when working on Blocky World a while back. Some of the GUI images had odd widths, and I had random black lines popping up all over the place. Kind of an annoying bug in PokittoLib, but not that hard to circumvent :slight_smile:

43

I am such an oldschool coder that the idea of using odd width bitmaps never crossed my mind.

I can hardly bring myself to use numbers that are not divisible by 8! Every time I see a base 10 number in code I get a little nauseous :wink:

5 Likes
44

Hey Guys.

Little Question :
Why is the background not fully blue? Is it because the png isn`t transparent?

45

In a word: yes.
This example doesn’t use a transparent bitmap.

46

Ah okay, thanks!

1 Like