I am new to this type of panel and found it quite interesting. I was looking for a medium sized panel that was restive touch. Also wanted to interface it to a microcontroller that was not an Arduino model.
I read the chat about a Yahtzee game was hooked on trying it out.
I found out quickly that it was not going to work on my display since I only had 480x272 and it was built for 800x480. Most of the design was done as an image and placed as the background.
So I set out to build my own version to fit my screen and also get use to how this new display works. What a great challenge!
First I found that the events can not run any of the script commands and only the basic logic instructions. So you can in-bed a line drawing command to place it on the screen. You can send these command form another device but not in-bed them in the unit.
So all the items have to be built using Paintbrush and imported into the studio tool. This turned out to be not to bad and the font generation tools was nice but I found the rendered fonts to be poorly spaced and some letters truncated. I guess I need to use a different font maybe.
At first placing item on the screen seem confusing and not vary accurate but after seeing that everything is an object and has attributes that can be easily adjust to where you want it I was very happy with the out come.
Digging around to find the documentation was somewhat confusing since they seem to be in different places with different links. After a while you build up links that get you to where you need to go.
I found that the language offered a lot of power and worked nicely. Although some of its short coming got to be interesting as to how to work around them. For example in a FOR loop you can add a value to the starting item but not to the ending item. Also if your use to spacing things out don't. Everything needs to be next to each other. Face it, it saves space.
The original Yahtzee game used default variable names so it took a little to understand what they were being used for. Actually I didn't bother after a while since I understood how the game worked anyway.
Anyway after a couple of days I was done and liked they way it turned out. Got the old creative juices running again. It also can be adopted to other size screens since all of the elements are now movable.
Also the game uses about a fourth of the memory.
Good to get your creative juices flowing. But just a few points for correctness.
The actual original was made for the TJC3224T022_011 2.2" at 320x240
- it was made with version 0.34/0.35 Nextion Editor - code was never posted
- it used my games.zi font for the dice.
Back then, there was no b[.id] array so lines of code was crazy
Logic for 3-of-a-Kind was 305 lines, Short Straight 365 lines.
In total 2225 lines of code were used. 888 bytes of sram.
When user indev2 discovered the b[.id] array this meant a mass shortening of code.
with the b[.id] array, the code lines were reduced to just 545 lines.
The spurred the Yahtzee Tutorial to showcase the b[.id] array capabilities.
The Original Tutorial was made for the 3.5" Enhanced model at 480x320 (not 800x480)
Creating a Yahtzee Game within Nextion Logic
Original still uses 1/2 the memory (at 466 bytes) when compared to 945 bytes
Original had 20 numbers almost 2 columns (except for roll), two rows of 5 pictures
and two hotspots these were default named, but 15 variables - none were default
TFT size is comprised of picture/font resources + firmware + components & code.
The Enhanced K series Nextions will have ~125K for firmware - T series ~69K
The background image does indeed account for 307,200 bytes (320x480x2)
On 16MB (4.3T) and 32MB (3.5K) devices, shortage of resource space less concern
The main reason to put a layout in a graphic (besides looks) is to save sram usage
Static items in a background resource uses 5 bytes sram total, components is sram++ each.
If it is never changing, it is certainly an option to save the sram for more important items.
Back in v0.35, .bco .pco .font .xcen .ycen .txt-maxl and .txt formed a Text Component
- a text component used fewer resources and was much quicker running component
Now in recent versions, it has been bloated: line wrap, centering, passwords, 3D styling
- certainly way more processing used to render simple text
As such, embedding into the background when static improves performance.
I am not certain of your statement
First I found that the events can not run any of the script commands and only the basic
logic instructions. So you can in-bed a line drawing command to place it on the screen.
You can send these command form another device but not in-bed them in the unit
Any valid Nextion Instruction from the Nextion Instruction Set can be in Nextion events.
What do you mean by script commands that can not be used?
Code Spacing is as it is because of the interpreted nature of the Nextion HMI project
- before the space is command after a space is parameters
- such small firmware 4.6K on the T series, will not be able to parse whitespace and then
determine if it is a legitimate command/parameter separator or a beautification whitespace
Also for links - the most important links are found from the Nextion Editor Help Menu
- Help Menuitem in Help Menu launches browser to Nextion HMI Solutions page
- here you find the datasheets for the models
- Link to the Nextion Instruction Set
- Link to the Nextion Editor Quick Start Guide
- Test Report and Certificate
- 3D printing bezel files
- Tools, Tips, Tricks and How-TOs
- and main links to other important infos.
Fonts can be an issue, a font editor can help remove annoying pixels
- fonts are mono-bit 1/2-of-height fix width - best results from fixed width like Consolas
But as you have discovered, the Nextion is a very capable serial device
- pretty amazing how much functionality is squeezed into a 64K flash/8K sram MCU
PS: I have isolated the 0x1A errors on throw, sometimes elusive in for-loop b[.id] calcs.
In your throw's sys1 for-loop, you have sys1<6, as there are five dice, this should be sys1<5
Sorry, New to this language as I was trying to imbed a line drawing command into an event and it gave me an error. So I assumed it didn't allow that. I think I used spaces between the variables and this is what was giving me the error.
Correct on the throws number. I kept forgetting there are only 5 dice and 6 numbers. My bad.
The debug feature is nice that you see what is working without having to load it up each time you develop something new.
I also found an error. I was playing around with global variable and found that I could not do addition on the to portion of the for statement so I had to build two more variables to hold the ending values. So in the 3 of a kind event I miss typed a variable name.
The line that reads: for(sys1=sys0+1;sys1<diceoffset.val;sys1++) should be: for(sys1=sys0+1;sys1<diceoffsete.val;sys1++)
Sorry I didn't see the original version of this game. I will have to look that up. Sure glade I didn't have to do it that way.
So if it is a valid Nextion command, it can be inside the event code
Valid commands, less multiline block (for, if, while) can be over serial - and debug input
Debug can test almost all, less dim, baud, and eeprom / gpio (must be on device)
GUI drawing example - place hotspot m0 on blank white page
Global variables (besides system variables) may need pagename prefix if on another page
But the +10 creates compound statement in an evaluation - can not do complex
The Nextion is interpreted simplex statement, there is no order of operations
- we can bend this on assignments, but not in Nextion compares
- the error in the embedded integer world is when we try to bend it
so we have to be pleased with gaining a shortcut, but we broke the rule.
see Nextion Instruction Set for if statement - remark #3 and #6.
Again, for all this functionality to be inside 64K of flash and 8K sram .. amazing
In the thread Tools, Tips, Tricks and HowTOs
you'll find Tic Tac Toe and Mastermind (Piano and TiltBox require Enhanced)