Proposal for possible API overhaul

[adekto]

#this is a discussion for advanced pokitto users, beginners please skip this it will literally make 0 sence.

it looks like especially beginners are hitting all our little api quirks.
we got some unsatisfactory designs in place and maybe we should address them right but at the same time make it easyer to see whats going on.

one of the things i is buffer refresh and automatic redrawing of the buffer (and how to disable it). its nice for the specific modes but might it be easer if the user had direct control over this? it be easer for people to understand and implement custom modes like for example having a buffered low res screen section and a direct mode gui in higher resolution font.

i think we can break down the buffers into 4 types: 1bpp, 2bpp, 4bpp, 8bpp they could be any size and are in essence a sprite your drawing to. most of the current modes fall in these 4. currently these sprites aren’t interpretable (you cant use a 2bpp sprite on a 4bpp buffer)

another thing i found very limiting is the transparency (getInvisibleColor) can only be 1 color of the pallet
to enable cooler effects my suggestion is a uint16_t bitflag.

i might be wrong on these these are just ideas atm

[Pharap]

I moved this over to Pokitto Software since it’s not really about C++,
it’s about the Pokitto Lib.

(I had a hard time deciding where to place it though. Maybe we’re missing a ‘Pokitto Lib’ category or ‘Pokitto Lib Feature Requests’ category?)

[adekto]

Yes sorry I was also thinking that but it is related to c++ as well

[adekto]

Here’s a rough concept for a one fits most drawbitmap

Game.display.draw(x, y, Sprite[index], bitflag);
Idea to bitflag the Sprite type to any type buffer
Mode1bpp mode2bpp mode4bpp mode8bpp
B1100 0000

Fliphorizontal B0010 0000
Flipvertical B0001 0000

Rotate90 B0000 1000
Rotate180 B0000 0100
Rotate270. B0000 1100

[spinal]

It would be nice to use different bitmap formats in different screen modes. e.g. 2bpp sprites in 8bpp mode etc.

[adekto]

lower bit compatibility is really a must, though im not sure what the best approach is for the colours
some sort of offset maybe?

i also found that the fill-rectangle is terrible slow and i might have an idea on how to speed it up

[adekto]

im just going to put my ideas i have back here heres some context:

[Suggestion]Future of PokittoLib - v2.0

That's what I mean by a 'memory limit'. Trying to use all screen modes at once would chew up a large chunk of memory and not leave much left for the actual game. Either way, @adekto you have your answer. When I said about templates for screen modes, I was thinking of something like: // ScreenMode.h // Could be uint8_t if we'll never have more than 255 modes enum class ScreenModeType : uint16_t { LowRes, HiRes, Mode13, Mode14, Mode15, }; template< ScreenModeType > class ScreenMode;…

a thing that poped up is giving more control over to be more performant
one thing that bugs me is the screen clear wich currently you disable with setting if(game.update(true)){

i feel it be more apt to have it off by default most games repaint the buffer with tiles anyway and we gain slight performance and if you want to clear the screen you can do it manually when you want

this could also apply for the draw modes letting the user draw it when they want with even additional options like position

heres a mockup hello world

#include "PokittoX.h"
PokittoX::Core game;

int main(){
  game.init(220,176, BUFFER_4BPP); //initialise with buffer size and draw mode
  while(game.isRunning()){
      if(game.update()){ //might be able to get rid of this
            game.graphics.clear(0); //clear buffer with color index
            //your game here


            game.graphics.display4bppBuffer(); //manualy draw the buffer could have optional variables like screen offset position
          }
   }
}

###aditional redesign possibility:
looking at the lcd driver it has a mode that could help with having multiple draw modes on the same screen or only updating a segment of the screen realy fast, the only trouble is that its only in portrait
this means all our sprites have to be rotated 90° wen generating them and the cordinate start from the bottom left (reminds me of opengl a bit) for example derectbitmap could become way faster with this instead of sending pixel one at a time it can stream the hole sprite in one go

the api could account for this odd coordinate system but this adds a little additional calculation on each sprite which although small is technically lost processing

[adekto]

propebly ignore this post as im extreamly tiered and dont know what im typing

ech of these could be any dimension up to 220x176 and have the double pixel as an option instead of a separate mode
i would like to mention theres no difference between a sprite and a buffer apart from that a sprite is constant in flash and a buffer is variable in ram
1bpp 2 color, specific use to store fonts and potential extra function of a mask
2bpp 4 color, usefull for colorised fonts and tiles (need to find a good way to remap the colors from 4pallet to 16pallet, to reindex to higher buffers)
4bpp 16 color, most commen for sprites and main screen buffer
8bpp 256 color, mainly used for “shader” effects but could also be used as a small pallet compositor buffer for tiles

these all need to be backwards compliant (example: 8bpp buffer needs to be able to add a 1bpp sprite, this may couse some large complex code)
not sure how to aproch this
``game.graphics.draw(x,y,sprite, spriteBPP)
the aditional mask buffer is also a chalenge, since its 1bpp i think we can get away as a screen mask
drawing to the mask could be a flag in draw game.graphics.draw(x,y,sprite, bpp | mask | fliped)