You can configure the LCD to draw by rows instead of columns:
write_command(0x03);
write_data(0x1038);
2 Likes
I can’t seem to make it work with the same code i had using the row-advance code you sent, would you be so kind to review this and tell me if it looks right?
write_command_16(0x21); write_data_16(renderInfo.bufferStartX);// move to x lcd coord
write_command_16(0x20); write_data_16(renderInfo.bufferStartY);// move to y lcd coord
write_command(0x22); // ready to send pixels
CLR_CS_SET_CD_RD_WR;
setup_data_16(color);CLR_WR;SET_WR;// send pixel to lcd and move to the next
Edit: when am I supposed to call write_command(0x03); write_data(0x1038); ? I’m using it on init.
never mind, I was just testing on a very dark pixel, sorry, seems to work.
1 Like
thanks to all the advice here I got to 40fps, sprites can be flipped and moved around, palette colors can be rearranged on the fly for each tile drawn, python scripts taking care of maps and palette generation, it’s super easy to make 16 color games with this thing.
Time to leave the geekery behind and make some games : )
(still need to find some time to upload it on github!)
The final apis will be made of roughly 20 functions only, there’s no classes and I could completely remove the use of pointers from the interface by using indexes for maps and image data, with zero impact on performance.
Maybe this could be a good way for people to start with pokitto without extensive knowledge of c++ and without having to first digest the granular modes offered by the original pokittolib?
EDIT: there might be some overlap with the new java apis in that regard, might be worth having a discussion about that once I manage to finish these apis.
6 Likes
That’s not necesarily a good thing.
There may be other ways as well, but it depends what the API currently looks like.
True, without a class, people will have to type namespace::function(), which might be disorienting for people that are not used to c++.
Then again, having a class with static members only so that people won’t have to learn the meaning of :: is probably just as weird.
I think I’ll drop the case of trying to be as inclusive as possible to people that don’t know c++, no much point in pretending a language isn’t what it isn’t.
We have java and python as higher level languages.
That’s not quite what I meant.
What I mean is that there are some things that can be done better with classes than other alternatives.
I can’t really make any concrete evaluations until it’s all uploaded to GitHub, so forgive my vagueness.
Some people get the idea that “classes are expensive/evil/some other ridiculous negative connotation” into their heads, so I’m wary of the fact that you said “there’s no classes” as if that was inherantly a positive thing.
For what it’s worth,
if it were up to me static member functions wouldn’t even be accessible on objects through ..
I’m not even sure what the rationale behind it is.
One of the things I’d change about the PokittoLib is make the empty classes uninstantiable so people learn to use :: instead of creating objects and then using ..
That said, there is one advantage of having static functions on classes rather than using namespaces.
Type aliases are more flexible than namespace aliases, which makes API substitution easier.
Specifically type aliases can be used with templates or nested inside other classes, whilst namespace aliases can only exist at namespace scope and can’t be used with templates.
I think you’re talking about generic design, but I’d never argue pro/against classes, it wouldn’t make any sense, especially in this thread.
The context here was inclusiveness of people not familiar with c++, and that’s why I also had second thoughts because the namespace syntax :: is probably even more confusing than a class with static members.
Generic patterns talk is a tricky subject and very dependent on the context, lets keep this thread about ways to make pokitto as easy and straight forward for newcomers as possible…so we get to play more games on it : D
Ok, here’s a concrete example using the last version of this API that I’m aware of.
void loadPalette(const uint8_t * p) expects p to point to RGB triples, but the API doesn’t make that very obvious.
If the API introduced a struct like:
struct RGB
{
uint8_t red;
uint8_t green;
uint8_t blue;
};
Then loadPalette could change to void loadPalette(const RGB * palette) and the resulting code would be easier for the end user to make sense of and much less error prone.
This is what I mean by “there are some things that can be done better with classes than other alternatives”.
(structs are classes for the record, despite how sometimes people will say ‘struct’ to mean a ‘plain old data’ class.)
You can always wrap a complicated inferace in a simpler interface if need be,
usually with minimal performance problems, so generally that sort of thing isn’t an issue.
For example, if you have an API where the memory allocation is up to the end user, it’s simple to write a wrapper API that handles all the allocation (e.g. using dynamic allocation) to make it easier to use without penalising the people who can make use of the more advanced features.
I have no clue what you mean by ‘generic patterns talk’.
Got you now, yes those apis I posted are full of ambiguous/unsafe cases that will need to be addressed. Best way I know to go about this is to first make at least one game and see how things shape up from real use, then if this stuff turns out to be of general interest we can consolidate the interface.