Types¶

Data Types¶

VisualT’s public types are all prefixed with “VT”, to avoid potential collision.

typedef uint32_t VTChar¶

Represents a UTF8-encoded read-only codepoint.

Being a fully UTF8 compatible library, VisualT stores UTF8 encoded characters in 4 Bytes uint32_t variables.

This is what the API expects when passing a single UTF8-encoded codepoint. Like in vtFill() .

typedef struct VTObj VTObj¶

Represents a VisualT Object (it’s not a pointer! this is the real deal).

As you can see in the header file, the VTObj struct is defined in the public header. Why is that? C doesn’t have a proper information hiding system, with opaque pointers being the only means of hiding the data structure implementation. The trade-off is that the user loses the ability to define statically allocated Objects, and all memory management becomes inaccessible.

With the “in plain sight” approach, instead, the user can do whatever he wants with memory, as long as he fulfills the unspoken promise to ignore the implementation and work exclusively via API.

Input types¶

The following types are designed to make the API parameters consistent and easily recognizable. They come already equipped with const qualifiers, so they may not necessarily be the best option for representing data in your program, if you plan on doing more advanced manipulations. The only requirement is that the data structures are compatible, so that casts become essentially equivalent to “const cast” (pay attention to type compatibility, if you care about strict aliasing).

typedef uint8_t const *VTStr¶

A pointer to a UTF8-encoded read-only string.

It’s defined this way to enforce the requirement that char arrays (strings) must be equivalent to byte arrays.

This is what the API expects when passing an UTF8-encoded string. Like in vtSetText() .

typedef VTStr const *VTStrs¶

A pointer to a read-only VTStr .

This is what the API expects when passing an array of UTF8-encoded strings. Like in vtInitializeStrings() .

typedef int const (*VTSizes)[2]¶

A pointer to a read-only pair of positive integers.

This is what the API expects when passing an array containing multiple Sprite sizes. Like in vtInitializeBlank() .

typedef VTObj const *const *VTObjs¶

A pointer to a read-only pointer to read-only VTObj .

This is what the API expects when passing an array of pointers to Objects. Like in vtRender() .

enum VTDirection¶

This enumerator is meant to be used whenever the API expects a direction relative to a Sprite.

Sometimes directions can be combined with the bitwise or operator, e.g. VT_TOP | VT_LEFT

See: vtAlign()

Values:

enumerator VTLEFT¶

enumerator VTRIGHT¶

enumerator VTTOP¶

enumerator VTBOTTOM¶

enum VTSetTextMode¶

This enumerator is meant to be used with vtSetText() .

Values:

enumerator VTCROP¶

enumerator VTFIT¶

VTMV¶

This macro is a more semantic alternative to NULL in movement functions.

It resembles “MoVe only”, without being longer than the NULL keyword itself.

Literal Helper Macros¶

You can use the following macros to express literals more easily. They are not meant to cast already existing data; use normal casts if you need to do that.

When a literal helper macro can be used on a parameter, it will be indicated in parentheses. See the linked examples.

LTSTR¶

A helper macro to cast a literal string to VTStr .

See: vtSetText()

LTSTRS¶

A helper macro to cast a literal array of strings to VTStrs .

The main use case is when you want to initialize an Object from one or more literal strings.

See: vtInitializeStrings()

LTSIZES¶

A helper macro to cast a literal array of integer pairs to VTSizes .

The main use case is when you want to initialize a blank Object given its sprites sizes.

See: vtInitializeBlank()

LTOBJS¶

A helper macro to cast a literal array of pointers to Objects to VTObjs .

An example is when you want to render a group of Objects.

See: vtRender()

Note

There’s no macro to create a VTChar literally, because that would break the strict aliasing rule. You can use vtChar() instead.