Tft espi boy using esp32

its only letting me post in help sections so i will post a query at the bottom which should qualify. other than that its a project thread

well some one said you would love to see me try to cobble together this in another thread. i warn you image updates will be infrequent maybe 1 new one every 2 weeks. i have to get some one else to snap a pic and send it to me. long story. however i do have one from when i started working on something similar. its the hardware assembled minus battery so its usb only right now . it will deviate from arduboy after i resolve some things with base line implimentation of 4 color and masking but for now its arduboy advance. 160 x 120 screen pixels transposed onto a 320 x 240 screen so it takes up full screen. the pic im posting is from the 128 x 90 test. the first test

its a sparkfun thing plus esp32 edition with a ili9341 screen a analog 4 buttons and a atmega 328p acting as i2c master who does controller interpreter to spit out 3 ints. i intend to have it toggle between reading input & sending ints as 1 set and streaming wav files from the sd card but havent done it yet. why is the esp32 slave? its so it never wastes time asking for instructions with a request its told and the update to the i2c is just slapped in the main loop

it functions as a arduboy right now however its using hartmann1301 ps2 controller repo from github to work as its one of 3 esp32 compliant libraries. sifting through arduboy i find most of it is redundant screen instructions that you find in all display libraries for arduino pretty much with a few exceptions

the baseline test is the following arduboy raycaster. its just lodes raycaster carried out until textures are applied. with a few modifications you can get something that looks like catacombs of the damned because north south wall is defined. links to the appropriate libraries and sketch

the raycaster is selected because 1) it works and 2) its got almost nothing calling arduboy in the sketch. the line draws and a screen blank and push to display and thats it. most of the code is C that was used in old pc games and its not long. less than 250 lines of code

now for my contribution. 4 colors on screen and you can call it from the game sketch. hartmanns 4 color system takes the 1 bit screen and depending on how the pixels are laid out changes it to 2 extra values not embeded in the code at a lower level. you can never call draw with lightgrey from the game. it says this pixel is white it was previously black and the pixel to the right is black so your dark grey.

so 0 is black and 1 is white normally. to increase the color range you have to increase the bit count per pixel. so i made duplicate chunks of code to have 2 pointers for current and 2 for next pixel reading vertical lines. i also bloated the array for the screen buffer and cut 2 copies of buffers from the code. removing almost all of what hartmann had there for the display file

currently i have a partial result which does technically display multiple colors but im not sure if its reading it the same way. in the original if you changed the 565 code behind the name of the color in tft espi (which hartmans uses) it changed the color of white and or black. this is spitting out literal white black light gray dark gray so idk if its even using tfte spi anymore

how to change the array from static to dynamic to free up static ram when the array is used in a .h file would be helpful . i find little in regards to this and it assumes you run all your code from the main . the esp32 doe not have all its ram in a single slab and the alleged limit of 160 kb per dynamic and static is not true. it seems the biggest slice is around 96 kb for either so to double buffer i have to mirror the array so 1 is static and the other is dynamic. if the array exceeds the slab it throws a error. that is also why the screen is 160 x 120

1 Like

in luck my father snapped some pics of the pseudo catacombs of the damned adjustment to the 250 line of code with it still 1 bit but 160 x 120 but 2 times pixel size. im to ashamed of the 4 color right now . until i can figure out how to make it use the colors from tft espi this will have to do. the second pic is to show how the thing is arranged

the arrangement is to allow the thing plus on the front without making it thicker and the face buttons reach about the right height so that when a piece of acrylic is used as the face plate the plastic button tops dont have to be super tall... also they hide some diodes and a resistor that are beneath to hold 4 pins low

took longer than expected . i wasted time trying to vectorize graphics which going from wall to making floor with the wall as a reference you need to find a perpendicular angle and then everything else is either the same again or a reference for length which turns into a angry mess of code

my current method for drawing the 2d arrays to screen can be used for sprites as well and only needs 1 instance to draw and use masking. no 2 sets of sprites. you just drop any number in the int array that isnt 1 or 0 and it wont draw. the down side is that i have to manually do all this. no application to transfer image to array. also it doesnt use any fancy stuff that the aplication uses for length information so its 1 for 1 pixel to int position

since the 250ish line of code raycaster is lodes raycaster im not sure why on git hub the guy credited thew wrong person or if that is lodes github account he is crediting ... i used both vertical and horizontal floor code (not at the same time obviously. horizontal is faster but you may find odd rotation) and redid the wall code to process x y like lodes which its lacking the texture code. im not a fan of stdint. math is math why do i need fancy math. i dont. the answer is that if the texture is already a 2d int array you dont need stdint ever. also lodes code directly has odd things that may be part of a old build that are not needed. i stripped these out. playerPos is never used. its made to be 0.0 and then never changed again. 0.0 is subtracted... why? i removed and it ran better. also the vertical code doesnt run as fast but its because despite drawing less its doing the texture info different. i hope this isnt sideways... i will edit if its sideways. other things must stay like 2+height... what ever. calculating 1 time for a new int or float any time its used 2 times in a forloop is a good idea to so i did it

to do on my catacombs of the damned upgrade port to my arduboy advance (none of johns code used because his math is to hard to read but concept. can you make a good raycaster game on a microcontroller)

  1. made 2 times line thickness textures to swap outt at specified distance or greater so that lines are still visible

  2. make the cell x y in front of the door texture cell xy active so it instances another wolrd map. when that is done we are elderscrolls noa

  3. make a 32 x 64 sprite array thats animated to rotate. 32 frames are needed for smooth rotation. but you can mirror is identical. the arch is mirrored on 2 axis. left to right and front to back. this means it needs to be animated for only 8 frames and here is the best part it doesnt even need to be mirrored front to back its just the same thing. this would sit where the ceiling lamps sit in the sprite example but only between wall segments

animating enemies and clutter. shooting for melee combat like oblivion or condemned but will probably have a caster class at character select. ima go bug some other people with this. also i cleaned up hartmans code of anything that wasnt being used by the esp32 so no oled code or pins code

1 Like

This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.