Anobium, what has happened to the ili9341 include? It looks so different!
What happened to the draw commands, I can't find them.
Pset is still there.
Before I could mess with it for my own interests but now it's locked down.
Big downer because I was messing with the draw command and pset to wrap arond the graphics.
Think of asteroids game. The rocks went from either side of screen to other.
They were drawn. Changing the draw to check for it's link to pset but check for glcd display size is not an option with the latest ili9341 include.
Thoughts?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Silly me...it's all in glcd h. doh.
I was thinking of the draw command wrapping around.
I did post you a demo an animated drawn square and when it draws beyond the screen limits..
think it was for ssd or other oled. in glcd.h the results vary from different displays.
You, Evan ,has put much work into glcd and it makes gcb more worth using as all hard ware support that has been added.
Say I draw a square 16x16 pixels next to an edge of the display area and it's position is going to make it draw beyond the display area i want it to wrap around to the other side of the display.
It would be easy to check the draw and the pset values to check for screen area but would be slow checking every pixel.
I could use sprites for asteroids but same checking screen edges.
I find a worthwhile project difficult to find as everything has been done in China cheap.
I'll make my robot projects more brainy maybe and leave gcb linux alone :)
There's so many thing you can do with gcb...I do too many at once.
Last edit: stan cartwright 2019-11-17
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
So discussing drawing pixels beyond on X and Y extremes of GLCD display.
The handling of drawing pixels beyond on X and Y extremes of GLCD display is relatively simple. Each graphics controller handles this differently, so, the libraries pass the X, Y parameter to the graphics controller and the graphics controller has to handle. As each graphics controller treats the the drawing of a pixel beyond the XY extremes you will have to study the outcome per graphics controller.
We have implemented some protection on some graphics controller , as an option. GLCD_PROTECTOVERRUN simply do not draw beyond the extremes. Why some? These are double buffered GCLDs where the result of wrting to extremes will simply fail in a horrid way.
~~~
IFDEF GLCD_PROTECTOVERRUN
'anything off screen with be rejected
if GLCDX => SSD1331_GLCD_WIDTH OR GLCDY => SSD1331_GLCD_HEIGHT Then
exit sub
end if
#ENDIF
~~~
So, choose a graphics controller. Learn the library. And, it would be very simply to make any library wrap. Just create a local version of PSET in your user code, call that localPSET and map using #define PSET localPSET. The, take a copy of the PSET code and put within localPSET - then, hack away leaving the original library 'as is' (this ensure later versions of Great Cow BASIC does not overwrite your lovely changes).
Hope this helps.
Enjoy
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks Evan. It does help. #define PSET localPSET seems to be a method I have not tried.
You have done most includes for gcb in the last few years. Excellent work!
I asked for oled is pixel lit and you sorted it and you published a game I wrote that needed is pixel on/off.
In another project you showed a method for using xor plot when I asked you how. Nice one.
In arduino world there are many ili9341 inc file for that system by many users,just search.
In gcb ,you have kept it as only closed to other peoples code unless it's approved...which is best but not the norm for other systems which has you can use anyones include.
I AM NOT MOANING!
I can anly requote you as saying in your demise then there are backup files.
Where would gcb be without you?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
yes, for sure. Respect for all people who make gcb possible.
It's nice to use. Get things done. Thanks to every one.
Now back to coding..I luv it.
a Huge/h thank you
edit... I don't moan...do I :)
Last edit: stan cartwright 2019-11-18
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anobium, what has happened to the ili9341 include? It looks so different!
What happened to the draw commands, I can't find them.
Pset is still there.
Before I could mess with it for my own interests but now it's locked down.
Big downer because I was messing with the draw command and pset to wrap arond the graphics.
Think of asteroids game. The rocks went from either side of screen to other.
They were drawn. Changing the draw to check for it's link to pset but check for glcd display size is not an option with the latest ili9341 include.
Thoughts?
got an old one file to compare it with? are you using a new download of the installer? OS?
I have checked. There is way more in the ILI9341 driver. More support etc.
Have you reviewed the ILI9341 before? I checked back to 0.98.04 and the library looks good to me.
ReadPixel_ILI9341 exists...
So, are you looking at the correct .h file?
This looks different...or is it me?
Where is draw ?
As you say it has been updated...scripts?
Last edit: stan cartwright 2019-11-17
looks ok.
what are the draw commands? as they are typically shared across many libraries.
Silly me...it's all in glcd h. doh.
I was thinking of the draw command wrapping around.
I did post you a demo an animated drawn square and when it draws beyond the screen limits..
think it was for ssd or other oled. in glcd.h the results vary from different displays.
You, Evan ,has put much work into glcd and it makes gcb more worth using as all hard ware support that has been added.
Say I draw a square 16x16 pixels next to an edge of the display area and it's position is going to make it draw beyond the display area i want it to wrap around to the other side of the display.
It would be easy to check the draw and the pset values to check for screen area but would be slow checking every pixel.
I could use sprites for asteroids but same checking screen edges.
I find a worthwhile project difficult to find as everything has been done in China cheap.
I'll make my robot projects more brainy maybe and leave gcb linux alone :)
There's so many thing you can do with gcb...I do too many at once.
Last edit: stan cartwright 2019-11-17
So discussing drawing pixels beyond on X and Y extremes of GLCD display.
The handling of drawing pixels beyond on X and Y extremes of GLCD display is relatively simple. Each graphics controller handles this differently, so, the libraries pass the X, Y parameter to the graphics controller and the graphics controller has to handle. As each graphics controller treats the the drawing of a pixel beyond the XY extremes you will have to study the outcome per graphics controller.
We have implemented some protection on some graphics controller , as an option.
GLCD_PROTECTOVERRUNsimply do not draw beyond the extremes. Why some? These are double buffered GCLDs where the result of wrting to extremes will simply fail in a horrid way.~~~
IFDEF GLCD_PROTECTOVERRUN
#ENDIF
~~~
So, choose a graphics controller. Learn the library. And, it would be very simply to make any library wrap. Just create a local version of PSET in your user code, call that localPSET and map using
#define PSET localPSET. The, take a copy of the PSET code and put within localPSET - then, hack away leaving the original library 'as is' (this ensure later versions of Great Cow BASIC does not overwrite your lovely changes).Hope this helps.
Enjoy
Thanks Evan. It does help. #define PSET localPSET seems to be a method I have not tried.
You have done most includes for gcb in the last few years. Excellent work!
I asked for oled is pixel lit and you sorted it and you published a game I wrote that needed is pixel on/off.
In another project you showed a method for using xor plot when I asked you how. Nice one.
In arduino world there are many ili9341 inc file for that system by many users,just search.
In gcb ,you have kept it as only closed to other peoples code unless it's approved...which is best but not the norm for other systems which has you can use anyones include.
I AM NOT MOANING!
I can anly requote you as saying in your demise then there are backup files.
Where would gcb be without you?
Yep.... don't be moaning. LOL
My advice to adapt in the local user program unless the quality is good enough for inclusion in the main code base. This is a reasonable approach.
Re other approaches. They are as valid.
The thanks go to Hugh. Without his involvement we would stagnate. Huge thanks Hugh.
yes, for sure. Respect for all people who make gcb possible.
It's nice to use. Get things done. Thanks to every one.
Now back to coding..I luv it.
a Huge/h thank you
edit... I don't moan...do I :)
Last edit: stan cartwright 2019-11-18
I will try the method. I am just so inpressed what 4gig of ram upgrade can speed up stuff.
It's all experimental,