Tile/Sprite Editor

[SlithyMatt]

I am working on a tile/sprite editor that's going to occupy a bank of the X16 ROM in a future release. I just made the first alpha release on GitHub:

https://github.com/SlithyMatt/x16-tile- ... ag/v0.0.1a

Please read the release notes to see what features have been implemented, as this is still far from feature complete, but you do have the ability to load, edit and save tile assets of any color depth up to 32x32 in size.
I'd really appreciate anyone who is willing to test it even at this very early stage. If you find a bug with something that's supposed to be working according to the release notes, please file an issue on the GitHub repo. Thanks!

[Daedalus]

Of course I had to try it right away! Tile and sprite editing is near and dear to me.

It loads! And it loads the CHASVALT tiles. But it throws a "file error 2" and the red activity "led" on the emulator blinks. I tried selecting colors from the palette and changing the image, but it keeps using the wrong color. Swapping foreground and background works, though. Also, there is no apparent way to save anything.

Perhaps I should read the release notes again. Oh, and it says to report issues to the github... I'll write up a more through review of everything I see and send that there.

[SlithyMatt]

You will get the file error the first time you run it, as TILES.BIN doesn't exist yet. You shouldn't see it past then.

As for colors, the tile visualization currently only supports palette offset zero, so selecting color indices over 15 will only work for 256-color tiles. If you select a higher index for a lower color depth, it will be the modulo value for that bits-per-pixel setting.

For example:
Color index 31 will be interpreted as follows:
2 colors (1bpp): 1
4 colors (2bpp): 3
16 colors (4bpp): 15
256 colors (8bpp): 31

In a future release, I will probably force these modulos when you change the color depth.

[Daedalus]

Ah! Reading the docs for the win... The S key saves. That helps.

Yup, the error goes away as soon as TILES.BIN exists. But... TILES.BIN is twice as big as it should be. Looking at the file in a hex editor, it's clear that the data is all there, but then random data fills the other half of the file.

Colors are fine, I was clicking all over the palette. If you constrain yourself to palette index 0, it works fine.

Other than that, I'm not finding any problems with the currently supported features.

[SlithyMatt]

Yep, like I say in the release notes, the maximum size tile set will be saved. In a later release, you'll be able to specify the size of your tileset.

[Daedalus]

I had seen that in the notes, but the notes also said the maximum size was 100K (It was a bit vague, to be fair.) The file was precisely twice as big as it needed to be, so I thought it looked like a bug.

Ooo! Tell me if you've heard this one!
An optimist sees a file that's twice as big as it needs to be, and says "That file is half full!"
A pessimist sees a file that twice as big as it needs to be and says "That file is half empty!"
An engineer sees the same file and says "That file is twice as big as it needs to be."

[Edmond D]

Ooo! Tell me if you've heard this one!
An optimist sees a file that's twice as big as it needs to be, and says "That file is half full!"
A pessimist sees a file that twice as big as it needs to be and says "That file is half empty!"
An engineer sees the same file and says "That file is twice as big as it needs to be."

No, new to me and quite humorous! Add the following:

Programmers will sit down to write code in their favourite language, with their favourite compiler, on their for preferred OS & platform based on some solution they've done before to ensure the file is created exactly the right size. The resulting errors and limitations of their code will fill a bug database, delay the release, and spark many online debates with others who have solved the issue using a different algorithm, language, compiler, platform, ect....

Finally, users won't notice the extra size and won't care because storage is so cheap these days!

If you read the above and take me seriously, please don't!

[SlithyMatt]

the notes also said the maximum size was 100K (It was a bit vague, to be fair.)

The reason for the (roughly) 100k maximum is the layout of VRAM for this application. It won't be able to create tilesets that are larger than that -- but that is a pretty enormous tileset, so hopefully that's not a problem! The user will be able to create multiple tilesets of the same color depth and dimension in case it needs to be bigger, and they could be loaded contiguously in VRAM for the target application.

One selectable tile set size is implemented, then the resulting tile assets file will be exactly the size it needs to be, even if the user hasn't defined all the tiles yet. There will also be metadata so that when you load an existing tilesets, you know how big it's supposed to be, and not just based on the size of the file you opened. So right now, you can open a small tilesets, and then just add to it as much as you want up to that 100k limit and whatever you don't define will just be garbage for now. Once the set size feature is implemented, you'll be able to load these oversized sets you saved before and rightsize them when you set the correct size and save again.

[SlithyMatt]

Alpha 0.0.2 now available:
https://github.com/SlithyMatt/x16-tile- ... ag/v0.0.2a

The big new thing is the ability to edit palettes and select palette offsets for tile visualization. This is still not feature-complete, so please check the release notes to see what should be implemented. Thanks!

[SlithyMatt]

New alpha release ready for test: https://github.com/SlithyMatt/x16-tile- ... ag/v0.0.3a

Please read the release notes to see what has been implemented so far.