Hi
avazquez, and
welcome to the forum! 
First of all, I'm very happy that you like the project, and I hope I can answer all your questions in a helpful way!
avazquez wrote: ↑Wed Jun 26, 2024 5:38 am
1) No Arctan ? Sorry I am no math expert but how then do we get the angle between two points ?
In general, therefore not strictly linked to ugBASIC but more to the field of 8-bit computers, the calculations of trigonometric functions (and their inverses) are very burdensome for these processors. It follows that, I repeat in general, one should avoid calculating operations and rely on the fact that the set of possible positions is countable (discrete set) and, therefore, provide approximation mechanisms that do not make use of them.
Unfortunately this is not always possible, so in fact sometimes it is unavoidable to have to use inverse trigonometric functions. I am not there at the moment but I have already entered a ticket for the implementation of the
ATAN function soon:
Add support for ATAN instruction #794
avazquez wrote: ↑Wed Jun 26, 2024 5:38 am
2) I see FLOAT discussed and in examples, but where are the docs ?
As I wrote in the previous answer, even simple floating point calculations are quite demanding for 8-bit processors. So much so that, by design, ugBASIC is an "integer BASIC" that is, it is a BASIC in which the primary data is the integer data. This makes it very different from most BASIC, where the primary data type is
FLOAT. Furthermore, the
FLOAT type was only added recently.
These things have a number of important consequences.
First, since it is not the main data type, you need to pay attention to assignments and calculations. In general, the "right hand" rule applies: the data type is established by the data type arrived at on the right side of the assignment (or expression). Unless, of course, they are all defined before being used (and that is the best option).
Secondly, if you use
FLOAT variables as parameters of BASIC calls, they are implicitly transformed into integer types (with implicit, but not necessarily correct in terms of program logic, overflow handling).
Thirdly, direct comparison between
FLOAT and
INTEGER is not possible, at least not yet. I have opened a ticket for a future implementation:
Add support for direct comparison INT vs FLOAT #777
Finally, the documentation is indeed lacking, and for this point I have added a ticket for the relevant integration:
Add manual for FLOAT data type management #795
avazquez wrote: ↑Wed Jun 26, 2024 5:38 am
3) How do I make a CHAR with option explicit?
I'm sorry but I didn't quite understand the question: what do you mean by "make a CHAR"? Define a variable that contains a single character?
avazquez wrote: ↑Wed Jun 26, 2024 5:38 am
4) Where are CSPRITES documented ?
Again, the documentation is quite lacking at the moment and I have added a ticket to improve it:
Add documentation on SPRITE, CSPRITE and MSPRITE #796
If you have any specific questions, I can try to answer them here in the meantime. Please note that ugBASIC has three types of sprites:
SPRITE,
CSPRITE and
MSPRITE (the latter only in beta). The main difference is that
SPRITE is the hardware one (therefore it suffers from the limitations of the video chipset).
CSPRITE is a "composite" sprite, i.e. it is born from the superposition of hardware sprites (therefore it allows you to overcome the limits in the number of colors at the cost of a smaller number of sprites). Finally,
MSPRITE is a "multiplexed" sprite, that is, it is a sprite that has higher resolution and color limits, but only works on particular hardware (such as the VIC-II). All sprites can be defined starting from an image loaded via
LOAD IMAGE, simply using this image as a parameter.
In this repository you can find some examples.
Note that ugBASIC is an isomorphic language and does not provide abstractions. Therefore the format in which the images are loaded must coincide with what the sprite instruction expects for the given target chipset. It will therefore be necessary to think about different resources, for example, between the VIC-II (from the Commodore 64) and the TMS9918 (from the ColecoVision).
avazquez wrote: ↑Wed Jun 26, 2024 5:38 am
5) I get "Too many colors" when loading/translating images. I can see why, but where are the docs on conversion conventions?
Actually, there is no documentation of this kind because the conversion convention changes based on a certain number of parameters, such as the target or the graphics mode.
In the case of the VIC-II, the convention is quite simple: for graphics modes (bitmap) the maximum number of colors is always 16, regardless of the selected resolution. At this point, during the conversion, a matching is made between the color of the default palette inside the VIC-II compared to the selected color: therefore, in the end, there can be even less than 16 shades. Finally, they are stored in the memory, adhering to the limit imposed by the chipset (therefore: 2 colors for 8x8 or 2+2 colors for 4x8, depending).
If you use the IDE you can find out which conversion has been adopted by requesting to generate additional information (the icon is at the bottom right) and then clicking on Resources tab. Please note: this currently only works with the main (non-beta) version of ugBASIC.