That is how it worked on C64. It has even dedicated char codes for changing the color
Thought char-gfx was very rarely used in the game UI. C64 games implemented own UI by using bitmap graphics (not very re-usable!)
The most extensive usage of char based UI, that I have seen, was Borland Turbo Pascal for Dos! It implemented the whole windowing system using it.
It’s like a neon bar is glowing on the screen. The effect is very nice.
I will re-draw the icons as soon as I get back home (1h or so). Will have them done today
EDIT: …and done.
@jonne Here are the SD icons redrawn in 8x8 grid. I tried to reuse the same “characters” as much as I could (not sure if you needed it this way). This is how they all fit together:
The first four tiles (left top & bottom and middle top & bottom) in each icon are always the same. The top right is always different and bottom right is only different in ? and text file icons.
The faces are aligned so you can call them at the same X and Y+4 as the sd card (assuming that black will be transparent)
Here’s the tileset in 1x1 ratio
If you need any changes, let me know. I will grab some food and check the forum in an hour or so
This is exactly right, thanks @VonBednar
I love how all of these tests are on incomplete Pokitto units… It would be nice to see a completed console doing something though
Yes I think its bad PR for me to use an open prototype, I’ve thought about that also. Scares people away.
Another thing I should invest in is a camera that is not a 1.2 megapixel potato.
No actually I have a good camera. Its just the hassle of setting it up etc. I should have a photo-corner with fixed lights etc.
Quick sketch of the prompt box. @spinal 's little pixel Pokitto keeps on getting on the camera.
I would like to use the same widgets (list) as much as possible in the UI because then there is no code duplication = least amount of memory used.
Looking really good. I can;t wait until we all get to try it out
Loving this! Freaking awesome!
Just a question:
Using EmBitz will be possible to debug and develop using the same pokitto lib as the Code::Blocks project?
If so, do we need special hardware to debug?
Are there benefits against using the simulator solution?
I suppose I’ve ended with 3 questions…
I was sure I had to buy 2 pokitto
Anyway can the a option be added to my pokitto to share the same shipping cost?
Let me see if that is possible.
Loader is now jumping cleanly between 2 programs. This means the MCU shuts down cleanly and jumps to the new program cleanly and runs it 100% correct. This means we can have many resident programs at the same time that can all control LCD, read SD, read buttons, make sound etc. It’s very very nice. Video coming later
Some day I will tell you exactly what happened but good grief there was some nasty nasty stuff on the way. I had to learn to debug with multiple symbol files from gdb command line among other things. I found a mistake in the cmsis_nvic initialization that was done by ARMmbed themselves.
The bootloader in Pokitto is pushing the boundary of whats been done on the Cortex-M0+.
SS PokittoLoader going where no one has gone before
Captain Jonne leading the way
I need feedback / graphical testing / ideas
I am thinking about something like this. The idea is that each game (if the author has supplied it) has an embedded icon of 32x32 pixels at 16 colors. This icon & basic info “pops up” in the file loader windows as you scroll down the files.
The reason for this size (32x32) is that I can then put the icon of the current program into the EEPROM and use it in the start menu even when SD card is not present (its a bit complicated but anyways). Also included is the name of the game and 1 byte for the “game style” (action / puzzle etc)
Do you “get” this idea or should I think about another kind of UI?
I do not have any improvent ideas, but to me that looks very nice! Definitely better with screenshots than without.
It looks good to me.
Would it be a fixed palette, or a custom one per icon?