Need an example using tmx tilemap with C64

[cguardia]

Hi everyone,

I'm trying to use tilemaps with ugBasic on the C64 target, but I haven't been able to get it working correctly so far.

I'm using TILES to generate a `.tmx` file, and then loading it with something like this:

Code: Select all

basic
BITMAP ENABLE(16)

tilemap := LOAD TILEMAP("background-race.tmx") UNBANKED

EMPTYTILE = 6 

CLS

PUT TILEMAP tilemap

The problem is that the result is not displayed correctly. Sometimes I get something that looks like a zebra pattern, and other times the tiles seem to be drawn incorrectly or with the wrong data.

So I wanted to ask:

Is there any working example of using `.tmx` tilemaps specifically on C64?

Is there a recommended way to prepare/export the tilemap from TILES so that ugBasic can read it correctly?

Are there any C64-specific limitations I should take into account, such as bitmap mode, multicolor mode, tile size, charset limitations, number of colors, or banking?

Maybe I'm misunderstanding the expected format or video mode setup.

Any simple working example or guide would be really helpful.

Thanks!

[spotlessmind1975]

Hi cguardia, and welcome!

The problem is that the result is not displayed correctly. Sometimes I get something that looks like a zebra pattern, and other times the tiles seem to be drawn incorrectly or with the wrong data.

Color processing on the Commodore 64 must conform to the limitations of the vic2 chipset, which, in BITMAP ENABLE(16) mode, allows a maximum of four colors: two common to all 8x8 pixel cells, and two others tied to the specific 8x8 cell. When using the "tmx" LOAD TILEMAP mechanism, the compiler will implictly load the ATLAS images, attempting to optimize the palette used for all frames. This sometimes doesn't produce the desired result, especially if a frame of the tileset has just only one color, which the compiler might interpret as a "background color," resulting in a series of unpleasant side effects. There are several ways to work around this problem. For example, it's recommended to disable automatic palette calculation using the EXACT keyword. This should reduce, if not eliminate, the problems I described above.

The zebra pattern is supposed to be related to the fact that the screen needs to be cleared before being used, using the instruction CLS. It's possible to define an implicit screen clearing at program startup (DEFINE CLS IMPLICIT), but this would increase the program size, as ugBASIC wouldn't know which routine to use right away and would have to include them all.

This should be the correct version of the program:

Code: Select all

BITMAP ENABLE(16)
CLS : ' this clears the screen
tilemap := LOAD TILEMAP("background-race.tmx") EXACT UNBANKED
EMPTYTILE = 6 
CLS
PUT TILEMAP tilemap

Is there any working example of using `.tmx` tilemaps specifically on C64?

This example, found in the repository, should work: obviously, you need to add the EXACT command.

Is there a recommended way to prepare/export the tilemap from TILES so that ugBasic can read it correctly?

The compiler automatically converts bitmaps to ensure good rendering on the native version. However, some hardware limitations may require specific processing for graphics. For example, some tools offer the ability to draw within the limitations of the Vic-II video chipset, which should help produce graphics suitable for the Commodore 64.

Are there any C64-specific limitations I should take into account, such as bitmap mode, multicolor mode, tile size, charset limitations, number of colors, or banking?

Since you're using graphical TILEMAPs created with tools like "tiled," the only limitations are related to the memory resources required. The UNBANKED flag, applied when loading the image, causes the compiler to use resident memory, which on the Commodore 64 is about 50 KB minus the space occupied by the code. If you use the C64+REU compiler and type BANKED, the compiler will place the graphics data in REU memory, giving you access to much more memory (by default, 256 KB).

Of course, if you use Commodore's "text mode" instead of graphical one, things change significantly. The ugBASIC language doesn't force you to use one technique over another. Sure, some tools help make your software more "portable" but, if that's not your priority, you can leverage and optimize the code for a specific computer, as in this case.