How to load CHR files(tileset) in tUME?

How to load CHR files(tileset) in tUME?
by Nadia on 2010-06-24 (#63309)

I have recently downloaded a copy of tUME. I tried creating a few maps with it and it worked.
But there's a catch! tUME expects the tileset to be in .LBM format. I have no idea about this format. I have so far dealt with only .CHR files.

Are there any tools for conversion between .CHR and .LBM?

..and 1 more thing. The tUME download link on main page of NesDev is not working.

Cheers.

Re: How to load CHR files(tileset) in tUME?
by dr_sloppy on 2010-06-27 (#63406)

Unless I'm absolutely mistaken, the LBM format is simply that of old Deluxe Paint. That format was widely in use back in the Amiga days.
I don't know nawt about the mentioned CHR format or even what format(s) you convert from ->CHR. IIRC, LBM and PCX are easily convertible against eachother.

Re: How to load CHR files(tileset) in tUME?
by Nadia on 2010-06-27 (#63415)

dr_sloppy wrote:

As far as I know .CHR format is used by most of the Nes emulators and tile\level editors to keep the background and sprite tileset.

Anyways, tUME apparantly does not have a feature to create tiles\tilesets. Is there a tool( other than deluxe paint) which can handle .LBM file and have facilities to convert between common image formats like .bmp, .lbm .iff etc.
My system has windows Vista and I face a lot of problems running primitive DOS applications on it. So what I am looking for is a windows based application.

Re: How to load CHR files(tileset) in tUME?
by tokumaru on 2010-06-27 (#63416)

Nadia wrote:

My system has windows Vista and I face a lot of problems running primitive DOS applications on it.

If you can't find Windows programs, you can always run DOS programs using DOSBox.

Re: How to load CHR files(tileset) in tUME?
by Nadia on 2010-06-27 (#63417)

tokumaru wrote:

Nadia wrote:

My system has windows Vista and I face a lot of problems running primitive DOS applications on it.

If you can't find Windows programs, you can always run DOS programs using DOSBox.

I am using YY Chr for updating tileset(s). If there's a windows based level editor then it will be easier to switch between yy chr and it. Also copy pasting from yy chr will become easier.

I have tried MappyWin32 but it stores the level-map in its own format. I will have to write custom programs to convert the output files from Mappywin32 to the format I want.

Re: How to load CHR files(tileset) in tUME?
by tokumaru on 2010-06-28 (#63419)

Nadia wrote:

I have tried MappyWin32 but it stores the level-map in its own format. I will have to write custom programs to convert the output files from Mappywin32 to the format I want.

Doesn't every generic level editor work like that though?

Re: How to load CHR files(tileset) in tUME?
by dr_sloppy on 2010-06-28 (#63420)

Nadia wrote:

Is there a tool( other than deluxe paint) which can handle .LBM file and have facilities to convert between common image formats like .bmp, .lbm .iff etc.

Paintshop Pro (version 4.x at least); Just open the source image and save as a new file in the desired format. Without checking, I'm fairly sure that Gimp suffice also.

Re: How to load CHR files(tileset) in tUME?
by tepples on 2010-06-28 (#63424)

Nadia wrote:

Is there a tool( other than deluxe paint) which can handle .LBM file and have facilities to convert between common image formats like .bmp, .lbm .iff etc.

I believe any Allegro-based can convert IFF/LBM. But nowadays I'm using PNG with a Python-based PNG to CHR converter.

Quote:

My system has windows Vista and I face a lot of problems running primitive DOS applications on it. So what I am looking for is a windows based application.

This includes Windows-based command-line apps, correct? If so, I have a couple programs that you might be able to use, but you will probably have to install Python 2.6 first.

Re: How to load CHR files(tileset) in tUME?
by Nadia on 2010-06-28 (#63431)

tokumaru wrote:

Nadia wrote:

I have tried MappyWin32 but it stores the level-map in its own format. I will have to write custom programs to convert the output files from Mappywin32 to the format I want.

Doesn't every generic level editor work like that though?

I have created a 16x16 metatile level with only 1 room(i.e. 256 tiles). The whole room is filled only with 1 type of tile.
The resultant .map file has the below contents:

10 00 00 00 10 00 00 00 0b 00 00 00 0b 00 00 00 0b 00 00 00 0b 00 00 00 0b 00 00 00 0b 00 00 00 0b 00 00 00 0b 00 00 00 0b 00 00 00 0b 00 00 00 0b 00 00 00 0b 00 00 00 0b 00 00 00 0b 00 00 00
.......
and so on
.......
.......
.......

$0b is the tile index of the tile I have filled the room with. I was expecting the .map file to have only tile index $0b but as we can see there are a number of $00 bytes also. I have no idea what they are for.

by tokumaru on 2010-06-28 (#63432)

The editor is probably using 32-bit values for everything (first the dimensions of the map - $10 x $10 - and then the metatiles), even though you only want 8 bits. The 0s are probably the 24 bits you are not using.

An existing editor will hardly output data in a format that's ready to be included in the ROM, most of the time you have to code a converter/plugin/whatever. Or maybe somewhere in the program you can configure it to use 8-bit values?

by Nadia on 2010-06-29 (#63497)

tokumaru wrote:
The editor is probably using 32-bit values for everything (first the dimensions of the map - $10 x $10 - and then the metatiles), even though you only want 8 bits. The 0s are probably the 24 bits you are not using.

An existing editor will hardly output data in a format that's ready to be included in the ROM, most of the time you have to code a converter/plugin/whatever. Or maybe somewhere in the program you can configure it to use 8-bit values?

Thanks for the hint.
I will now write a routine that will convert the 32 bit values into 1 byte ones.

by Nadia on 2010-07-04 (#63712)

Tile studio!

Apparantly, it can do everything I need: like tileset design, level map, collision map and attributes\pallettes.

I now look for a compression decompression routine.