Hello! Some questions for a game- C64

[avazquez]

Hi
I am very excited about the project! I want to support and use it!
So I decided to make a simple game , but have found some issues.

1) No Arctan ? Sorry I am no math expert but how then do we get the angle between two points ?
2) I see FLOAT discussed and in examples, but where are the docs ?
3) How do I make a CHAR with option explicit?
4) Where are CSPRITES documented ?
5) I get "Too many colors" when loading/translating images. I can see why, but where are the docs on conversion conventions?

Thanks for your help

[spotlessmind1975]

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!

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

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

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?

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).

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.

[avazquez]

These are great answers , thanks so much -!
I will keep working on these -

[spotlessmind1975]

Hi avazquez!

4) Where are CSPRITES documented ?

I'm happy to let you know that I just wrote a short guide on how to use SPRITE, CSPRITE and MSPRITE in ugBASIC.

The guide can be consulted here.

I hope it can be useful to you!