2.3 version

[Mr. Kibernetik]

New function will be implemented:
SCREEN_SCALE ()
returns screen scale. Non-Retina screens have screen scale 1. Retina screens have screen scale 2.

Command DRAW PIXEL will be screen scale-dependent to work properly on Retina and on non-Retins screens.

[Mr. Kibernetik]

Command DRAW IMAGE will be expanded to use parameter ANGLE:
DRAW IMAGE n$ AT x,y SCALE s ANGLE a
draws image with filename [n$] at coordinates [x,y] with scale value [s] and rotated clockwise at angle value [a]. Parameter SCALE can be omitted to use scale value 1. Parameter ANGLE can be omitted to use angle value 0. Valid image types are: JPG, PNG, BMP, GIF, TIF, ICO, CUR, XBM.

[Mr. Kibernetik]

Command DRAW PIXEL will be expanded to use parameter COLOR:
DRAW PIXEL x,y COLOR r,g,b
draws pixel at coordinates [x,y] with color [r,g,b]. Parameter COLOR can be omitted to use current draw color:
DRAW PIXEL x,y
This command is screen scale-dependent.

[Mr. Kibernetik]

New command will be implemented:
GET PIXEL x,y COLOR r,g,b
gets color of pixel at coordinates [x,y] to variables for red [r], green [g] and blue components. This command is screen scale-dependent.

Command DRAW PIXEL will be optimized for speed.

[Mr. Kibernetik]

New command will be implemented:
GET IMAGE n$ SIZE w,h
gets width and height of image [n$] to variables [w] and [h].

[Mr. Kibernetik]

New command will be implemented:
GET TOUCH n AS x,y
gets "x" and "y" coordinates of screen touch number [n] to variables [x] and [y]. If there is no active touch with this number, [x] and [y] variables get value -1.

[Dalede]

While talking about data statements. It would sure be nice to allow restore to restore to a specific label so that data statements could be grouped and reused when needed.

Dale

[Mr. Kibernetik]

While talking about data statements. It would sure be nice to allow restore to restore to a specific label so that data statements could be grouped and reused when needed.

Dale

Yes, currently I did not decide what is better - to use labels or to use counter to reference DATA. The situation is that FILE INPUT command works the same way as READ command, but in file data there are no labels as in code. And of course it will be good to have common solution to reference data both in DATA statement and in files. So maybe using counter seems be a good decision, but in files it is difficult to use counter because file data are not pre-read as DATA statement, so it could take a long time to process file to locate indexed data. Currently I am still thinking about how to solve this situation.

[Dalede]

I think of data statements are different files where the filename is the label. Of course these files are not as likely to be large but they are distinct none the less. For example a set of data statements might contain the days of the week while another might contain the months of the year and a third set may be totally unrelated.

Dale

[Mr. Kibernetik]

I think of data statements are different files where the filename is the label. Of course these files are not as likely to be large but they are distinct none the less. For example a set of data statements might contain the days of the week while another might contain the months of the year and a third set may be totally unrelated.

Dale

Yes, I got your idea. Files can be differentiated by name while in-code data cannot.

Now about DATA. What do you think, using data index (like tell current data index and set current data index) is better than just restoring to label?