has anyone used these modes?
MODE_NOBUFFER
MODE_ARDUBOY_16COLOR
MODE_HI_MONOCHROME
MODE_HI_GRAYSCALE
MODE_GAMEBOY //outside of gameboy port
MODE_UZEBOX
MODE_LAMENES
MODE_256_COLOR
MIXMODE
MODE14
MODE_TILED_1BIT
MODE_TILED_8BIT
has anyone used these modes?
MODE_NOBUFFER
MODE_ARDUBOY_16COLOR
MODE_HI_MONOCHROME
MODE_HI_GRAYSCALE
MODE_GAMEBOY //outside of gameboy port
MODE_UZEBOX
MODE_LAMENES
MODE_256_COLOR
MIXMODE
MODE14
MODE_TILED_1BIT
MODE_TILED_8BIT
Is anyone else having issues with hi-res modes not working?
In hardware also?
mode 15 seems to work OK on hardware, but mode 1 appears low-res on both.
Have you got some demo code?
I tried using TASMODE for a normal game as I wanted 220x176, 256 colour. The transparency did not seem to work but did when I reverted to Mode13.
Does TASMODE support transparency or am I just doing it wrong (my first assumption)?
Transparency only work with colour index 0, this is done for speed I believe.
Oh OK ⌠thanks, I had my transparency set as 255. Will have to change my palette up a bit as zero is black and I think I will need that!
So ⌠after a lot of trying, I cannot figure TASMODE out when using it as a simple 256colour 220x176. Things do not render correctly (things on the left hand side of the screen simply do not render at all!).
Is there a âstandardâ 256 colour 220x176 mode?
220 * 176 = 38,720
and the Pokitto has 36KB of RAM (i.e. 36,864 bytes),
so there wouldnât be enough bytes for a full frame buffer.
Yep ⌠you are absolutely correct. I saw TAS mode and thought it was possible without doing the math.
TAS mode works because itâs splitting the screen up into tiles, hence it doesnât use a full screen buffer despite using 256 colours and filling a full screen.
To use it as if it were a âstandardâ mode youâd have to have enough repetition in your image that you could represent your image using tiles.
Depending on what youâre trying to do there might be another approach you could try. Though ultimately youâre probably either going to have to sacrifice some precision or do some direct drawing (which I suspect will have to be reasonably fast to avoid tearing).
I found that frustrating as well, so I started implementing what I call a strip-buffer 8bit mode, where the whole screen is split into X pieces (Iâm currently using 11).
Itâs kind of an intermediary between TAS and a full-screen buffer and it combines both sides perks and issues:
In any case, itâs more complex than both Screen Buffer and TAS. Iâm using it because itâs definitely worth it in my case (3D iso stuff having a lot of vertical/slanted things, âŚ), but there is a high mental cost whenever I need to render stuff. Grouping things together for example is welcomed (e.g. your character needs 5 sprites, youâre asking yourself âis at least part of the character visible on this specific part of the screen?â)
Funnily enough, I can easily make a split-screen game with this but I havenât found yet an application to that
Surely it ought to be possible to statically allocate it by declaring it as a global rather than a local?
Just to note: this can be sped up by using some kind of space partitioning in the game world, or by simply sorting objects by their y coordinate, and then either by their x coordinate or their âzâ coordinate if thereâs zome kind of depth to take into account, like the UI being drawn on top of the monsters.
That way you could do something like this:
std::size_t objectIndex = 0;
// Go through all the strips
for(std::uint8_t y = 0; y < 176; y += stripSize)
{
std::uint8_t yEnd = (y + stripSize);
std::size_t nextObjectIndex = ~0;
// Draw all objects within the current strip
while(objects[objectIndex].y < yEnd)
{
auto & object = objects[objectIndex];
draw(object);
// This is needed for when objects overlap two strips,
// otherwise you only draw half an object
if(((object.y + object.height) >= yEnd) && (nextObjectIndex > objectIndex))
nextObjectIndex = objectIndex;
++objectIndex;
}
if(nextObjectIndex < objectIndex)
objectIndex = nextObjectIndex;
}
This assumes an âobjectâ will overlap two strips at most. If your objects overlap three strips, youâll probably need to maintain a âredraw listâ of objects you need to redraw in the next strip. Either that or you need to dynamically move the objects in the obejct list around as you draw, which could get awkward.
It is, but flushing to the LCD generally happens when the stack is empty, so itâs better than allocating statically and having all that memory be permanently unavailable.
@FManga explained it all. I did initially consider allocating a global and use a union
or std::variant
so I could reuse that memory for other, temporary calculation. Then I remembered that it was exactly what the Stack was meant to and in a much, much easier way than with a union/variant.
Thatâs also what is doing TAS by the way - the 220+ bytes linebuffer exists only when TAS is doing its stuff. I didnât take out this buffer-on-the-stack out of nowhere @FManga did
Also, I agree there are numerous opportunities for optimizations. But as you can see, compared to the ScreenBuffer itâs far from being straightforwardâŚ
Iâm definitely going to use a lot of these opportunities in any case; only as theyâre optimizations theyâll be relevant only when I got the more important stuff done first and when I can easily and properly measure how good they might be