I try over again to make my code faster/more better. I noticed ssd1306 sprite solution in demos on github and that the code didn't use pset as posted in the forum but that E.Venn was using a copy of pset directly. The code looked complicated and unfamiliar.
So I did the same with a ili9341 display but not checked with a pin on/off and scope but works and must be faster than using pset..that is more than call and return code maybe?
Point is GCB is fast but some things can be faster. If I didn't use gcb style I'd not be popular but the ssd1306 sprite demo is contradict to method recommended in forum. Here's my sprite code for ili9341. Any code changes to make faster welcome...it's not bad at 1 pixel movement. https://www.youtube.com/watch?v=lbLb4_nMuIs
To me,this is simple style but gcb demos seem sort of obfuscated.
I don't look at the assemler code to see if my basic is optimum, I wouldn't havr a clue but some insights would be useful..like in code below- is
px=sprite_x+sprite_pixel_in_row
SetAddressWindow_ILI9341 ( px, py, px, py ) ;set x,y plot
better than
SetAddressWindow_ILI9341 (sprite_x+sprite_pixel_in_row , py,sprite_x+sprite_pixel_in_row , py )
In the code I posted for this device previously I did recommend that you investigate use of SetAddressWindow_ILI9341 (sprite_x+sprite_pixel_in_row , py,sprite_x+sprite_pixel_in_row , py ) as this may improve performance - I am guessing that you are asking for me.....
A few pointer that come to me.
1. Create a memory map (an array) of the position of the array and only update the display when movement has occurred relative to a scan rate. This means only update the screen to inform the user of movement. There is a term for this but it is early for me.
2. Only update the screen when you know the background requires updating - you did this.
3. Resolve the SetAddressWindow_ILI9341 and stream the pixel updates with a single SetAddressWindow_ILI9341 command. This means studying the datasheet to figure out how you set a window and data stream is formatted, vertical then horizontal, left to right etc. But, you lovely table may need changing to support a data stream method. The data stream method means you set the set the address window and just send data, all the data without set sending the address window.
4. Change the colour scheme. To just send bytes? This is may not be practical.
Some thoughts before I have my coffee.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The display data sheet is beyond my understanding. I have no digital electronic qualifications.
The display seems more suited to a chip with DMA for fast graphics. SPI must slow it compared to displays with 40 pins.
The gcb include is brill and makes the display easy to use,thanks for your effort and time writing it as all your glcd for other devices. I know it can be time consuming.
I notice you spend effort tweaking code to optimise the compiled code. I try just different ways to get a result by different basic ways but without looking at the assembler output not sure which method is quickest. I'm just experimenting/getting to know gcb.
My sprite code is best I can think of apart from using and changing sprite_x instead of for sprite_pixel_in_row.
Wrap around sprite works but erasing didn't. There was too much testing. The screen in not like a block of screen ram of old.
There is a box type write pixels/ram and other clever stuff but not useful for need as what data stream to send from sprite shape data.
I could set an address window but a rectangular height width sprite I'd need to send non lit pixels as background which look poor when sprites overlap.
I'll be back.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I try over again to make my code faster/more better. I noticed ssd1306 sprite solution in demos on github and that the code didn't use pset as posted in the forum but that E.Venn was using a copy of pset directly. The code looked complicated and unfamiliar.
So I did the same with a ili9341 display but not checked with a pin on/off and scope but works and must be faster than using pset..that is more than call and return code maybe?
Point is GCB is fast but some things can be faster. If I didn't use gcb style I'd not be popular but the ssd1306 sprite demo is contradict to method recommended in forum. Here's my sprite code for ili9341. Any code changes to make faster welcome...it's not bad at 1 pixel movement. https://www.youtube.com/watch?v=lbLb4_nMuIs
To me,this is simple style but gcb demos seem sort of obfuscated.
I don't look at the assemler code to see if my basic is optimum, I wouldn't havr a clue but some insights would be useful..like in code below- is
px=sprite_x+sprite_pixel_in_row
SetAddressWindow_ILI9341 ( px, py, px, py ) ;set x,y plot
better than
SetAddressWindow_ILI9341 (sprite_x+sprite_pixel_in_row , py,sprite_x+sprite_pixel_in_row , py )
In the code I posted for this device previously I did recommend that you investigate use of
SetAddressWindow_ILI9341 (sprite_x+sprite_pixel_in_row , py,sprite_x+sprite_pixel_in_row , py )as this may improve performance - I am guessing that you are asking for me.....A few pointer that come to me.
1. Create a memory map (an array) of the position of the array and only update the display when movement has occurred relative to a scan rate. This means only update the screen to inform the user of movement. There is a term for this but it is early for me.
2. Only update the screen when you know the background requires updating - you did this.
3. Resolve the SetAddressWindow_ILI9341 and stream the pixel updates with a single SetAddressWindow_ILI9341 command. This means studying the datasheet to figure out how you set a window and data stream is formatted, vertical then horizontal, left to right etc. But, you lovely table may need changing to support a data stream method. The data stream method means you set the set the address window and just send data, all the data without set sending the address window.
4. Change the colour scheme. To just send bytes? This is may not be practical.
Some thoughts before I have my coffee.
The display data sheet is beyond my understanding. I have no digital electronic qualifications.
The display seems more suited to a chip with DMA for fast graphics. SPI must slow it compared to displays with 40 pins.
The gcb include is brill and makes the display easy to use,thanks for your effort and time writing it as all your glcd for other devices. I know it can be time consuming.
I notice you spend effort tweaking code to optimise the compiled code. I try just different ways to get a result by different basic ways but without looking at the assembler output not sure which method is quickest. I'm just experimenting/getting to know gcb.
My sprite code is best I can think of apart from using and changing sprite_x instead of for sprite_pixel_in_row.
Wrap around sprite works but erasing didn't. There was too much testing. The screen in not like a block of screen ram of old.
There is a box type write pixels/ram and other clever stuff but not useful for need as what data stream to send from sprite shape data.
I could set an address window but a rectangular height width sprite I'd need to send non lit pixels as background which look poor when sprites overlap.
I'll be back.