Messages

31

TinyDuino Processors & TinyShields / Re: Tinyscreen buttons

« on: April 27, 2015, 04:23:53 AM »

One nifty trick: Store the button state in a char value, use the upper 4 bits for the previous state and the lower 4 bits for the current state, e.g.

Code: [Select]

unsigned char screenButtonState = 0;
void updateScreenButtonState() {
  screenButtonState = screenButtonState << 4 | display.getButtons();
}
This way you can detect if a button was just recently pressed down ((screenButtonState & (1|16)) == 1), just released ((screenButtonState & (1|16)) == 16) or is now pressed for more than one frame ((screenButtonState & (1|16)) == 17). I found that useful more than once - besides, it's very cheap as it involves only a few opcodes and cycles to handle.

32

TinyDuino Processors & TinyShields / Re: windows 8

« on: April 24, 2015, 05:06:55 AM »

For me it also didn't work right away - the driver installation chose com6 as emulated port. I was able to change it in the device manager and setting it to com1. After that, it worked for me.

33

TinyDuino Processors & TinyShields / Re: TinyScreen 8bit color issues

« on: April 17, 2015, 03:34:04 PM »

Thank you for your response.

Yes, the 16bit framebuffer implementation is my experiment to see if there are differences to the 8bit encoding, hence the conversion from 8bits.

I am currently not sure if I want to test true 16bit images in the framework I am working on. Memory consumption and overhead seem to be too costly.

34

TinyDuino Processors & TinyShields / Re: TinyScreen 8bit color issues

« on: April 17, 2015, 06:22:13 AM »

I did some more research and experiments.
Here's what I've found:

• The drawRect method with the 8bit color value is in deed flawed - I made some photos of comparing the original and the modified version - you can see how there are more color tones in the modified version in the attached picture.
• I've made a (slow) implementation for supporting writing a 16bit buffer. The 16bits are calculated from the 8bit values. Interestingly, the 16bit version with the conversion algorithm that I've used in the modified drawrect version yields pretty much exactly the same result as the 8bit writeBuffer method. There seem to be some slight differences, but I am not really sure if that's not just psychological . I still can't distinguish the colors that I see on my notebook display - I assume that they simply appear as too similar on the TinyScreen opposed to my Notebook display. So the 8bit write buffer color conversion is working as it should, so there seems to be no problem in the TinyScreen receiver function. I have also made a photo of a comparison between the 8bit and the 16bit version.

The modified writeBuffer method for 16bit support looks like this:

if (_bitDepth) {
      for(int j=0;j<count;j++) {
        uint8_t color = buffer[j];
        uint8_t r=(color&0x03);//two bits
        uint8_t g=(color>>2)&7;//three bits
        uint8_t b= color>>5;//three bits
        r = r<<1 | r << 3;
        g|= g<<3;
        b = b<<2 | b >> 1;
        // r: 5bits, g: 6bits, b:5bits
        uint16_t temp = r|g<<5|b<<11;
        SPDR=temp>>8;
        while (!(SPSR & _BV(SPIF)));
        SPDR=temp&0xff;
        while (!(SPSR & _BV(SPIF)));
      }
    } else {
      uint8_t temp;
      SPDR = buffer[0];
      for(int j=1;j<count;j++){
        temp=buffer[j];
        while (!(SPSR & _BV(SPIF)));
        SPDR=temp;
      }
      while (!(SPSR & _BV(SPIF)));
    }


The 16bit color format is 5-6-5 I've learned by playing around. Therefore I could make a 3-3-2 8bit format for comparison... however, I'd need to make some more changes to the existing code to try that out. As for using the 16bit writeBuffer function: I guess it could be implemented a bit more efficiently but even then, it would be simply too demanding for making games that require 20fps+. The current implementation runs at about 6fps... Maybe 10 could be achieved with some optimizations, but I think I won't go that way.

35

TinyDuino Processors & TinyShields / Re: TinyScreen 8bit color issues

« on: April 17, 2015, 04:00:08 AM »

Taking the code from the tinyscreen.cpp file and translating it to javascript (which works analogous):

function rgb(color)
{
   var r=(color&0x03)<<4;//two bits
   var g=(color&0x1C)<<1;//three bits
   var b=(color&0xE0)>>2;//three bits
   if(r&0x10)r|=0x0F;//carry lsb
   if(g&0x08)g|=0x07;//carry lsb
   if(b&0x08)b|=0x07;//carry lsb
   console.log(r,g,b);
}

Running it in Javascript reveals following mapping:

c = 0 => r = 0, g = 0, b = 0
c = 1 => r = 31, g = 0, b = 0
c = 2 => r = 32, g = 0, b = 0
c = 3 => r = 63, g = 0, b = 0

This is a bit unfortunate since this color difference is practically almost unnoticeable.

A better approach (and I think this is also a bit cheaper for the processor) is this:

function rgb(color)
{
   var r=(color&0x03);//two bits
   var g=(color>>2)&7;//three bits
   var b= color>>5;//three bits
   r|=r<<2|r<<4;//carry lsb
   g|=g<<3;
   b|=b<<3;
   console.log(r,g,b);
}

Basically the bits get just repeated until the 6 bits are full. This results in the following mapping:

1 => 21 0 0
2 => 42 0 0
3 => 63 0 0
4 => 0 9 0
5 => 21 9 0
6 => 42 9 0
7 => 63 9 0
8 => 0 18 0
9 => 21 18 0
10 => 42 18 0
11 => 63 18 0
12 => 0 27 0
13 => 21 27 0
14 => 42 27 0
15 => 63 27 0
16 => 0 36 0
17 => 21 36 0
18 => 42 36 0
19 => 63 36 0
20 => 0 45 0
21 => 21 45 0
22 => 42 45 0
23 => 63 45 0
24 => 0 54 0
25 => 21 54 0
26 => 42 54 0
27 => 63 54 0
28 => 0 63 0
29 => 21 63 0
30 => 42 63 0
31 => 63 63 0

So the gaps are now constant. Next I want to see how the writeBuffer function works and if it can be tweaked too.

36

TinyDuino Processors & TinyShields / TinyScreen 8bit color issues

« on: April 16, 2015, 07:05:13 PM »

I have noticed in a graphic rendering test that color values are "missing": While I send distinct byte values to the screen, these color differences are indistinguishable from certain other values (I should be able recognize different colors in those cases, I am quite sensitive to that).

So I started testing around using the drawRect function. This is not entirely representative for my case since I only use the writeBuffer function in the code where I noticed the missing colors.
However, if you try out the demo here: https://codebender.cc/sketch:105460, you should see that something is wrong: The screen is displaying two color rectangles. The lower one is using the full r-g-b variant API (16bit colors) to draw a rect with a red-green color gradient. The result is super smooth - as expected.
The upper area of the screen however is displaying the "color palette" that results from the 256 values in the 8bit color value. Each color entry is represented by a 4x4 sized rectangle with a black dot indicating that there's a rectangle with solid filling. Looking at those 256 different colors, it's quite obvious that there are only 3 distinct red colors (should be 4) and 5 green values instead of 8. More or less, there seem to be groups of 2 palette entries each that look the very same.

I am not sure if there's a bug in the tinyscreen.h library or something else, but something isn't working as expected at least.

On a side note: Why is the format actually using rgb 2-3-3 and not rgb 3-3-2? Usually the red and green channels have a higher resolution than the blue channel because the human eye is less sensitive to blue. (like shown here: http://en.wikipedia.org/wiki/Color_vision#/media/File:Eyesensitivity.svg).

37

TinyDuino Processors & TinyShields / Re: TinyScreen screenshotting?

« on: April 12, 2015, 01:56:23 PM »

But maybe another thing to bring up is what you'd use it for.

That's a good question - I want to have screenshots and maybe even gif animations for posting them online. Right now I take photos, but that is highly inconvenient.

Apart from that, it would also be useful for debugging.

I am working on a general purpose scanline rendering system where I send individual lines to the screen. I could duplicate that to the serial port as well. But then I need a protocol and a listener on the other side, etc. etc. So I was curious how you would others do that. For instance, I could also imagine that having a wifi board, you could simply send UDP packages to a host with each line as content and a small header to describe the data. I think personally I would prefer that since it's easier to interface that. I just don't have a wifi board (and don't know if that would be possible).

Another thing is that I am wary of spending flash memory to do that because I am operating on the limits of memory. So another consideration would be to minimize (software) overhead and use something much simpler. The serial library for instance is burning some kb just alone for itself. I don't know how a wifi shield library would impact the flash memory.

38

TinyDuino Processors & TinyShields / TinyScreen screenshotting?

« on: April 11, 2015, 01:47:45 PM »

What would be your preferred way to make screenshots of the content of the tinyscreen?

39

TinyDuino Processors & TinyShields / Re: Battery level readout?

« on: April 07, 2015, 02:22:34 PM »

Thank you - that's good to know... though I probably can't integrate it into my game since I am getting slowly low on remaining flash memory

40

TinyDuino Processors & TinyShields / Battery level readout?

« on: April 07, 2015, 04:21:54 AM »

Is it possible to read out the battery level of the lipo? Or what the power source is (battery/usb)?

41

TinyDuino Processors & TinyShields / Re: Tiny Screen Color Values

« on: April 07, 2015, 04:19:13 AM »

I created a small html/javascript page to have a colortable ready:
http://zetsgames.com/colortable.html

42

User Projects / Code Examples / Re: Games / community with the tiny screen and gamepad?

« on: April 06, 2015, 12:21:27 PM »

Ah, the space invaders game! Yeah, I was thinking to do something more simple than what I am tackling right now, but I had more ambitions. One of the things I worked out was a more generic rendering system with which I can draw rectangles / circles / triangles with. I can't draw many since I have to keep them in memory, but it gives me more flexibility. I am right now working out a UI system to allow me doing something in that world. I am bit shocked how much flash memory that is eating up though D:

43

User Projects / Code Examples / Re: My Little Pony ROBOTIC ears

« on: April 06, 2015, 12:14:56 PM »

Funny - My daughter would probably want one if i'd show here (I better not ).

44

User Projects / Code Examples / Games / community with the tiny screen and gamepad?

« on: April 02, 2015, 06:54:07 AM »

Hey there,
I am working on a 2d space game that utilizes the gamepad and I was wondering if there are others who work on other games as well. I couldn't find much. Is there a community or something alike for exchanging games and ideas?

If you have a tiny gamepad and a tinyscreen, you can give my code a try:
https://codebender.cc/sketch:98686

There's no gameplay yet, but you can fly a spaceship in front of a parallax starfield.

Any feedback is welcome!