[wip] Mixed screen mode


#1

I am currently working on a ‘mixed’ screen mode, I was wondering if people think I should submit it as an official mode once I’m finished.
Here is a screenshot of it working…

It’s not easy to tell, but the top 8 rows are mode1 (I think) 220x176x2bpp and the rest of the screen is mode64 (Is that it’s name?) wide pixel 110x176x4bpp. I have not added 110x88x8bpp yet, but that is on its way.
This has required new bitmap drawing routines and the user will have to know the bit depth of the portion of the screen they are drawing to. e.g.

drawBitmap(x, y, myImage, 4); // 4 is the bitdepth of the image.

The screen split can be on any of the 88 low resolution lines, and can even be have multiple sets of rows.
It uses the same size buffer as mode13 (110x88x8), so can theoretically replicate any screen mode that has that size (or smaller) buffer. So you can have the illusion of changing screen modes within your program.


Idea: Little Computer People For Pokitto
#2

Can each horizontal block have an own palette? Could I make e.g, several 220x176x2bpp mode blocks with own palettes? Like Amiga Copper bars :slight_smile:


#3

Possibly, it wasn’t a plan though.

I am having a little trouble with 8bit scanlines, Am I doing this right?

            for(x=0;x<220;){
                uint8_t t = *d++;
                uint32_t color = uint32_t(paletteptr[t])<<3; scanline[s++]=color; scanline[s]=color; x+=2;
            }

#4

Should the second scanline[s++] be like this also? Now the next iteration writes with the same index value s.


#5

Sorted it. The issue was more to do with the way I was detecting the scan lines (typo).


#6

hmmmmm, I’m starting to think that this idea is completely impossible :frowning:
I don’t think that the pixel layouts can be merged into a single buffer. Either that or my math skills are nowhere near up to the task.

[Edit] got everything sorted out. Just need to tidy it up and re-implement it into a newer pokittolib then PR it.


#7

OK, I currently have a different palette for each ‘mode’ That’s a total of 276. I am currently doing this by extending the mode13 palette, I don’t think it will effect any other modes. I’m just trying to come up with a nice demo to show it off.
Although, a lot of the gfx routines might be completely unusable in this mode.


#8

Here is a small update…
A test file, all it does right now is show a couple of images.

mixMode.bin (69.5 KB)

The demo is a little slow as it is redrawing the full screen twice each frame, Once for the 256 colour image, then again for the 4 colour image. This could easily be changed to only draw part of each image.


#9

That looks seriously sexy

Edit: I’d love to have “Pokitto Workbench” as a program, where you could arrange, set favourites etc for the game binaries. If I were to add that functionality to the loader, it would make the loader too big.

Clock and calculator obviously would also be needed. Analog clock.


#10

oh a windowing system, so want that even if its inpractical for the hardware.

looking good


#11

I would love to make the loader look better in some way. But I assume there’s almost no space for something like this in it’s place. Perhaps Pokitt-OS could be a stand alone app that could be loaded only if the user wants it?


#12

A windowing system would almost certainly be possible.
The diificult parts would be making it work on multiple screen modes and deciding how to best handle the memory allocation.

If the windows were specified at compile time then they could be statically allocated, but if dynamic features were needed (e.g. adding and removing controls/widgets at runtime) then dynamic allocation would be needed, and that would complicate matters.
It’s hard to judge whether dynamic allocation would use more or less memory.
On the one hand it means the data for a window is only loaded into RAM as and when it’s needed, but on the other hand there’s overhead involved in managing dynamic memory, and running out of memory at runtime is a more serious issue than not having enough memory at compile time

One way to do it would be to remove the loader GUI and change the functionality so that instead of activating the loader GUI, pressing C at the start instead looks for PokittOS on the SD card and loads it if it’s present (and if it isn’t, it frowns and continues with the game).

That would give people a bit more room for writing games and have PokittOS handle all the important stuff:

  • Selecting a game to load
  • Managing the ‘cookie’ system
  • SD card management (rename files, move files etc)
  • Setting the time and date (with a more friendly UI than the current one)
  • Maybe a small hex editor for editing game save files on the go?
  • @jonne’s calculator (and of course, it would have to support programmer operations like XOR, LSH, RSH, ROL and ROR)
  • Utilities to do stuff with hats (e.g. send and receive IR messages with an IR hat, edit wifi settings for a wifi hat, blink the LED on an LED hat :P)

A keyboard hat would really help here, but it’s not impossible to pull off without one.

Digital is superior :P


A somewhat unrelated anecdote:

Several years back when I was still a rookie programmer I was doing Lua programming with the Minecraft mod ComputerCraft.
I decided to try making my own GUI-based OS to replace the default OS (which was basically just a non-graphical terminal).

It was an interesting experiment.
I think I tried to go a bit OTT with it though.
Long story short, I tried to add a proper process and threading system after reading a book called “Operating Systems Demystified” (very good book,very interesting) and for whatever reason I put the project on hold and moved on to a different project.

I think I’ve still got most of the code lying around somewhere.


#13

I Think I have done a valid PR to get this added to pokittolib. It might be in a future update for all to use!


#14

You did a valid PR all right.

Your mixmode demo is too good for words. Makes me want that mouse-hat for Pokitto so bad.

mixmode.bin (55.6 KB)

1


#15

I’m half tempted to see if 110x88x16 and 220x176x2 would be worth doing as a second mixed mode using half the buffer size…