GameR-Iot support

[Duhjoker]

If Rodot doesn't mind I would like to start a support thread here so we can keep any issues and fixes inline and in one place. This should also make it easier for new users to get a grasp on the different hardwares and libraries and keep the forum clean. Ok so let's start.......

GameR-Iot is your all in one Iot gaming gadget that does more than just game. The DIY libraries currently support teensy3.x and esp32 boards with more in development. With GameR-iot your not stuck with the same hardware choices. The TFT drivers cover a lot of different sized screens and MCU hardware isn't limited to just one option.



You can find the core libraries here.

https://github.com/Duhjoker

//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

Lets talk about our features. With Wifi connected there is no limit of what kind of Iot things you can create. Create a graphical user interface and use it as a smart device, bluetooth remote control or game controller. Its only limited to your imagination. The libraries are heavily Gamebuino influenced and set up to work like the gamebuino library but in color and a higher resolution. There are a ton of new graphics functions that will allow for some crazy cool displayed graphics but lets talk about the most important feature. Bitmaps!

The Gamebuino bitmap functions call for stacking bitmaps and using the grey scale feature to create sprites that have different shades of black and grey. Now you can do this the same way with the new libraries separating a color bitmap into separate colors then calling them in stacks but this takes a huge amount of space. We could also try to use SD which I cant get working as well. But if we could SD going, your sd card would be full of bitmaps to different games all in the root file as I understand it, making a huge mess.

We want to use Progmem or Flash space instead. The best reason for this is the framebuffer which works for progmem or flash and would be a whole new set of problems even if we could get the sd going. So how do we do this????????

We have a function called WriteRectNbpp() and it has sub functions like writeRect4bpp() and 2bpp and such. These functions can read a color index that the user creates and then uses the index to color the pixels in your bitmap. Now we can draw full color bitmaps and store them any where but mostly progmem and flash. Heres an example......

First lets declare our extra alphabetic integers to be used to name colors at the top of the sketch outside the loops like so.....

Code: Select all

///////////////////////////////////////////////////////////////////////////////
///////////////////////////Pixel Color Includes////////////////////////////////
///////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////////////////////
uint16_t palette[16];  // Should probably be 256, but I don't use many colors...
uint16_t pixel_data[2500];

//Extra integers for color palette
int a = 0xa; int b = 0xb; int c = 0xc;
int d = 0xd; int e = 0xe; int f = 0xf;


Now that we have that lets define our palette at the top of the void loop.......

Code: Select all

//////////////////////////////////////////////////////////////////////////////
///////////////////////////////Palette////////////////////////////////////////
//////////////////////////////////////////////////////////////////////////////
 palette[0] = 0;
       palette[1] = BLACK;
             palette[2] = BLUE;
                   palette[3] = BROWN;
                         palette[4] = DARKGREEN;
                              palette[5] = GREY;
                                    palette[6] = PINK;
                                          palette[7] = RED;
//////////////////////////////////////////////////////////////////////////////
//////////////////////////////////////////////////////////////////////////////                                               
                                           palette[8] = BEIGE;
                                     palette[9] = GREEN;
                               palette[a]= DARKGREY;
                         palette[b] = LIGHTGREY;
                   palette[c] = YELLOW;
             palette[d] = PURPLE;
       palette[e] = WHITE;
 palette[f] = ORANGE;


The colors are stored in the library so you just need to call the name of the color. So now lets look at a bitmap...

Code: Select all

///////////////////////////////Player/////////////////////////////////////////
////////////////////////////Paul Atreades/////////////////////////////////////
//////////////////////////////////////////////////////////////////////////////
//////////////////////////////////////////////////////////////////////////////
const byte paulfront[] = {
0x00,0x00,0x03,0x37,0x73,0x30,0x00,0x00,
0x00,0x00,0x37,0x33,0x33,0x73,0x00,0x00,
0x00,0x03,0x73,0x37,0x73,0x37,0x30,0x00,
0x00,0x73,0x76,0x63,0x36,0x67,0x37,0x00,
0x00,0x37,0x66,0x66,0x66,0x66,0x73,0x00,
0x01,0x63,0x63,0x36,0x63,0x36,0x36,0x10,
0x01,0x66,0x66,0x26,0x62,0x66,0x66,0x10,
0x00,0x11,0x66,0x26,0x62,0x66,0x11,0x00,
0x00,0x11,0x16,0x66,0x66,0x61,0x11,0x00,
0x01,0x66,0x11,0x66,0x66,0x11,0x66,0x10,
0x01,0x66,0x11,0x11,0x11,0x11,0x66,0x10,
0x00,0x11,0x12,0x21,0x12,0x21,0x11,0x00,
0x00,0x01,0x51,0x15,0x51,0x15,0x10,0x00,
0x00,0x01,0x52,0x21,0x12,0x25,0x10,0x00,
0x00,0x00,0x22,0x10,0x01,0x22,0x00,0x00,
0x00,0x00,0x11,0x10,0x01,0x11,0x00,0x00};


As with the OG functions the 0 bits will be transparent, the other integers stand for a specific color named in your custom palette. then we call it like so......

Code: Select all

 tft.writeRectNBPP(player_x, player_y,16,16,4,paulfrontw,palette);


I also fixed the tilemap to work with the new functions as well so its good to go.

//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

Lets talk about safety next. When using either one of the current boards with libraries you must remember to use only 3.7v lipos to power them with. Using more voltage can and will destroy your tft by overheating it which will damage your lipo, your tft, and your new MCU plus any plastic around it if using one of the cases Ive posted on thingiverse.

Do power the tfts LED pin using 3.7v volts and the rest of the power to the tft drawn from the MCUs 3.3v pins which are voltage outs. You will have to make and solder a couple pin relays to do this so you can have doubles or triple pins as needed for power wires. just remember to insulate them with shrink tube so they don't short.

/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
The readme files contain a full set of set up instructions to help you build your console assuming you are using the cases I developed but will work regardless.

Recommended hardware includes the following....

board====== Teensy3.x or ESP32
tft========= Any tft that uses ili9341 drivers
battery===== 3.7v @ 1500mah
12x======== Tactile switches 6x6x3mm
charger=====tp4056 5v lipo charger Do Not play and charge at the same time this will cause the safety warnings I mentioned above. I haven't worked that out just yet.
wiring====== I use DuPont coated wire jumpers but they are hell to solder, Servo wires work best and solder easily.
shrink tube====== Lots!

////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

As of this moment we do not have any kind of boot loader for the Teensy to load games from the sd card but there is a way to do so for esp32. check out this link.....

https://github.com/CCHS-Melbourne/iotuz-esp32-hardware

It will require some extra programing but it does load games and other apps.

////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
Other features still in development include poptext which we hope to have soon, the titlescreen and a keyboard. Feel free to contribute and of course credit goes to where it came from.

Please post any questions about the hardware and libraries only. please leave any gaming and c++ inquiries to programming questions so we can keep the forum clean and keep track of any changes to the libraries or the hardwares.

[Duhjoker]

My RPG game was starting to get a lil big and since I the T3 library works well enough I decided to fire up the esp32 and give it some support. I've made numerous bug fixes to the library. Threw out the old button scheme and now bounce can be used for button commands. It's simple enough to use and examples for the library are listed as Dune games in the repository.

I have one problem with the library. When I drew up the transparent pixels bit of code I did some thing to not just give the bitmaps clear pixels but shift the colors as well when using the frameBuffer. I don't even remember how I fixed it to begin with. But some how I got it right for the non frameBuffer code.

Other than that I'm really digging the esp32 set up. It's very responsive and quick with the graphics. Y'all need any support just let me know.

If you are wanting to join the face book group for direct support please send me a message via Facebook messenger that you are friending me or what ever for that reason. I don't usually friend people I don't know so just let me know.

Edit::

Fixed the last of the bugs with the esp32 library. The color shift problem mentioned above has been fixed as well. Enjoy!

[Duhjoker]

I wanted to talk about the tilemap functions real quick.

When I first started actually building a game using the library, I wanted this huge overworld to explore but the tilemap can only print out a map at 256x256 tiles. so I made this change to the function to be able to do larger maps......

Code: Select all

void Grafx_esp::drawTilemap(int x, int y, const uint16_t *tilemap, const uint8_t **spritesheet, uint16_t dx, uint16_t dy, uint16_t dw, uint16_t dh, uint16_t * palette){
   //uint8_t tilemap_width = pgm_read_byte(tilemap);
   //uint8_t tilemap_height = pgm_read_byte(tilemap + 1);
   //uint8_t tile_width = pgm_read_byte(tilemap + 2);
   //uint8_t tile_height = pgm_read_byte(tilemap + 3);
   //tilemap += 4; // now the first tile is at tilemap
 uint16_t tilemap_width = pgm_read_byte(tilemap)* 256 + pgm_read_byte(tilemap + 1);
 uint16_t tilemap_height = pgm_read_byte(tilemap + 2)* 256 + pgm_read_byte(tilemap + 3);
 uint16_t tile_width = pgm_read_byte(tilemap + 4);
 uint16_t tile_height = pgm_read_byte(tilemap + 5);
 tilemap += 6; // now the first tile is at tilemap



   uint16_t ddw = dw + dx;
   uint16_t ddh = dh + dy;
   uint16_t maxDdx = (dw - x + tile_width - 1) / tile_width;
   uint16_t maxDdy = (dh - y + tile_height - 1) / tile_height;
   if (tilemap_width < maxDdx){
      maxDdx = tilemap_width;
   }
   if (tilemap_height < maxDdy){
      maxDdy = tilemap_height;
   }
   int16_t startDdx = (-x) / tile_width;
   int16_t startDdy = (-y) / tile_height;
   if (startDdx < 0){
      startDdx = 0;
   }
   if (startDdy < 0){
      startDdy = 0;
   }
   if (flagcollision)numcolision = 0;                                 //Line 735 - clear numcolision - ADD by Summoner123

   for (uint16_t ddy = startDdy; ddy < maxDdy; ddy++){
      for (uint16_t ddx = startDdx; ddx < maxDdx; ddx++){
         int16_t drawX = ddx*tile_width + x + dx;
         int16_t drawY = ddy*tile_height + y + dy;
         uint16_t tile = pgm_read_byte(tilemap + ddy*tilemap_width + ddx);
         if (drawX >= dx && drawY >= dy && drawX <= (ddw - tile_width) && drawY <= (ddh - tile_height)){
            writeRectNBPP(drawX, drawY,tile_width, tile_height, 4, spritesheet[tile], palette );
            if (flagcollision){
               solid[numcolision].x = drawX;                     //Save X coordinate      - ADD by Summoner123
               solid[numcolision].y = drawY;                     //Save Y coordinate      - ADD by Summoner123
               solid[numcolision].spritecol = spritesheet[tile]; //Save Sprite of tile    - ADD by Summoner123
               numcolision++;                                    //Increment numcolision  - ADD by Summoner123
            }
         }
         else{ // we need to draw a partial bitmap
            writeRect4BPPtm(drawX, drawY, tile_width, tile_height, spritesheet[tile], dx, dy, dw, dh, palette);
         }
      }
   }
}


the two five line code snippets at the top are what was changed. I left the original in case some one wants to switch back to the old way.

so now in order to use it we need a lil math. so say the map is 308x308. the compiler wont like 308,308, because of thye offset so intead we go........

1,152,1,152,

this reads out as 256=1, 152=the amount of tiles across or down after 256. if you want to use less than then just use 0, then the size w and 0 size h