Mainly because it would be easier to tweak my image generator tool to output the correct frame format than it would be to make it create arrays of pointers to images.
Besides which, it would be nice to have this documented,
the doxygen documentation makes no mention of it.
void Display::drawBitmap(int16_t x, int16_t y, const uint8_t* bitmap, uint8_t frame)
{
int16_t w = *bitmap;
int16_t h = *(bitmap + 1);
uint8_t framew = *(bitmap+2);
bitmap = bitmap + 3; //add an offset to the pointer to start after the width and height
There is a cursor, but it’s a bit hard to spot because the rectangle drawing function doesn’t work correctly.
The arrow keys move the cursor.
A and B increment and decrement the frame index.
It should make each tile cycle through the various frames of the image,
but instead it seems to be scrolling a single 16 pixel row each time.
And even then the tiles don’t seem to be drawing correctly.
A 2D array wouldn’t allow the width and height of the frames to be ‘baked’ into the image data so they’d have to be passed to drawBitmap which limits the code’s flexibility slightly.
(Though admittedly it would possibly work out slightly cheaper than the array of pointers approach depending on the circumstances.)
Yeah. I’m sure somone (I think it was @sbmrgd?) was supposed to have made a PR to fix that at some point, but maybe I’m misremembering?
Maybe it got talked about but never happened?
Or maybe it’s fixed in PokittoLib and not PokittoIO?
The .gif is a bit overkill, I would have trusted the code in your first comment. :P
(Though I prefer &Images::tiles[3 + (index * imageWidth)], and I’d wrap it in a function to be safe.)
It somewhat baffles me why the function isn’t implemented like this.
I could imagine that there might be faster ways, but working is better than not working.
I wonder if this works for multiple modes/bpps…
I’m tempted to suggest changing the function to use this as a solution, but I don’t currently have the time to dedicate to properly testing it for other screen modes.
Plus it would mean getting rid of that third ‘parameter’, which I’d really like to do, but that sort of change warrants some discussion about the possible implications of such a change.
If the function’s always been broken then it’s no big deal,
but if the function does actually work somehow and there’s a game using it somewhere then that game’s going to break.
Why not use the regular draw function and separate out width and height and data. BaseDrawBitmap(x,y, width, height, data)
Then your frame funtion can pull these apart and use an pointer offset, would even add vertical scrolling if wanted.
Seems the documentations out of date and the library hacked together.
The documentation has always been a bit of a problem.
Writing documentation is a lot of effort, it’s really boring and its rare for people to get recognition for it because people tend to take good documentation for granted, so it’s fallen to the wayside.
There have been a few discussions of making a reboot of the library but nobody’s got round to it.
I actually wrote a prototype myself a while back but I didn’t get it to the point where it was actually working.
I was mainly focusing on the API, how it should look and what it should include.
Sorry dint really understand the code, so would be simpler to wrap that in a function and reduce redundant code?
Is there any bounty on the API or documentation rewrite?
Please add this as documentation comments in the file. you might forget or someone 12 months later will be confused and would have to go digging thru this forum, is exhausting…
Unsure, my pokitto’s speakers is not working and the usb plug fell out. Any compensation would be nice…
Ah, thank you, I knew it was something along those lines.
If the issue’s still open maybe I (or someone else) ought to dive in and fix it some time?
Part of the reason I’m reluctant to make changes to the library is because there’s no consensus about style and I have a habit of drastically redecorating code when I edit it and people don’t always take too kindly to it.
For example I favour tabs and allman style over spaces and K&R style,
and I have a laundry list of style rules that I try to adhere to.
Such as
Always leave a space around binary operators
It makes them more obvious and more readable
Always use explicit round brackets on subexpressions
To make the order of evaluation (partially) unambigous
Declare a variable at the latest possible moment
Means there’s less variables to think about at once
Often results in smaller code for various reasons
Try to keep variables immutable where possible
Makes the code easier to follow
Sometimes produces smaller code
Never use C-style casting, always use C++-style casting
C-style casting is more likely to introduce bugs
C-style casting is harder to search for
C++-style casting makes dangerous operations more obvious
Et cetera et cetera…
Which file?
I do try to comment my code anyway.
Or at least the code I publish and intend for people to read and learn from.
For example in Physix.
Report that to @jonne immediately.
That’s definitely not supposed to happen.