Making tiles and maps out of large images then reconstructing

[Brick Nash]

Thanks for the replies folks.

Because I don't have my own graphics right now I'm using some existing ones for the code to play about with. I have a mashup of some old beat em ups and I'm using backgrounds from the 1991 Amiga Final Fight (the palette of which I'm universally using and have remapped everything else to)

The Final Fight backgrounds are ideal as they are already 16 colour (15 minus the transparency) and were made for the Amiga. They also are made up of perfect 16x16 and 32x16 tiles too which are visible to the eye and I even have the tile sets themselves downloaded from Codetapper's site but again no way to actually reconstruct them except by hand. The full images are big though, even cutting them into their sub-stages gave some screen error messages when trying to import into TOME.

The plan right now is to have a look at idrougge's code plus analyse the Tile Maker code in TOME as that pretty much does half of what I'm wanting to do anyway and if (god willing) I can make head or tail of it I can add some sort of position analyser so that it will recall the places of the duplicates to rebuild a map. Might take me a million years though. In fact I'm wondering if Maptapper might be a decent tool somehow for doing this. I know it's Windows based but it does the same thing I think only in reverse.

If I'm honest having only been learing Amos for a week I think I may be out of my depth on this one but we'll see. I 'could' very well just do it by hand in TOME. It might take a few weeks of painstakingly piecing together the levels from the tiles by referencing the full images by eye but the mere thought fills me with dread and I can see it being very easy to lose your place

[Mrs Beanbag]

i found who made the map-chopper-upper, we were having some e-mail correspondence about it a few years ago when i was thinking of doing an Amiga port of Sonic the Hedgehog, it was Codetapper if you want to try messaging him about it. But it is PC software.

[Brick Nash]

Originally Posted by Mrs Beanbag

i found who made the map-chopper-upper, we were having some e-mail correspondence about it a few years ago when i was thinking of doing an Amiga port of Sonic the Hedgehog, it was Codetapper if you want to try messaging him about it. But it is PC software.

Thanks for the info, it seems Codetapper's the man to talk to about these things.

I'm thinking I'd probably better complete the manuals and learn about things like scrolling first and I'll probably just re-construct the levels by hand for now but I'll still need a slicer as I made some modifications to the graphics in the larger images.

I had a look around and I'm actually very surprised there's no real image slicing program out there even for windows it seems, although if I'm honest I didn't dig that deep.

Anyway thanks for the info, everyone's been very helpful!

[volvo_0ne]

EXACTLY how wide does your "level" need to be?

Because AMOS can load & display quite large screens using Screen Offset, (approx 1000 x 1000 px in Lowres) which would still display easily on a 2Mb Chipram system.

This is from a 2mb Chip +4mb A1200 standard config in WinUAE

The saved IFF is around 70kb at 1000 x 200 x 32 colours

Rem This bit opens a screen 1000 px wide & 200 px high x 32 colours

Screen Open 0,1000,200,32,Lowres : Rem open a 1000x200 screen 
Curs Off : Flash Off : Cls 0 : Rem Usual housekeeping.

For I=1 To 10000 : Rem plot 10000 random colour dots  
Ink Rnd(31)
   Plot Rnd(1000),Rnd(200)
Next I
Save Iff "ram:test.IFF" : Rem Save it to RAM: (or wherever)  


Rem This bit reloads, displays & scrolls it to the left. 

Load Iff "ram:test.iff",0 : Rem reload from RAM: (or wherever) 
For I=0 To 680-32 : Rem (depends on overscan)
   Screen Offset 0,I,0 : Rem Scroll the screen to the left
   Wait Vbl 
Next I
Rem finito!

[Brick Nash]

If we're talking the full sized image I just measured the first section of Level 1 (Or 1-3) in Final Fight and it clocked in at 1296 pixels. I think some of the later levels have even bigger sections but I won't be using them anyway.

I wasn't planning on just importing in a whole image as they are all made up of tiles anyway and it would be a bit of a waste and that's why I'm looking into this tile mapping business.

[volvo_0ne]

Originally Posted by Brick Nash

If we're talking the full sized image I just measured the first section of Level 1 (Or 1-3) in Final Fight and it clocked in at 1296 pixels. I think some of the later levels have even bigger sections but I won't be using them anyway.

I wasn't planning on just importing in a whole image as they are all made up of tiles anyway and it would be a bit of a waste and that's why I'm looking into this tile mapping business.

OK, Sorry, I thought you were working on an original project, rather than importing from existing graphics.

My mistake.

[Brick Nash]

Eventually I will be using my own graphics but that comes quite easy to me and I'm a musician also so sound is no problem too and I figured instead of messing around with the cosmetics I'll use some pre-existing graphics from games I know inside out just to get on with practising coding with, which I think is a more important use of time.

I have a few Double Dragon and Final Fight images downloaded but I went with Amiga Final Fight's graphics as they came pretty much ready made in terms of palette.

[Codetapper]

Years ago I made a rather crude utility that does exactly this. Given any picture (eg. full map rips from HOL or MAME etc), it will work out the unique tiles (you determine the size) and it outputs the tiles and map. The map allows several formats (plain text, c, ASM, binary, byte/word/longword encoded, little/big endian etc) and it even has an option to output an overlay layer that shows tiles that are only used a few times.

The last feature is useful when you want to encode a map as bytes but find there are say 260 unique tiles - it will highlight tiles that are ripe for substituting with another to keep it to 256 or lower. Email me some details and example maps if you want me to send you some sample data to see if it's going to do what you need.

In the zone is an example file Sonic_Level_1.zip containing sample data. The Rygar level 1 map was done with the same util.

[ReadOnlyCat]

Originally Posted by Codetapper

Years ago I made a rather crude utility that does exactly this. Given any picture (eg. full map rips from HOL or MAME etc), it will work out the unique tiles (you determine the size) and it outputs the tiles and map. The map allows several formats (plain text, c, ASM, binary, byte/word/longword encoded, little/big endian etc) and it even has an option to output an overlay layer that shows tiles that are only used a few times.

The last feature is useful when you want to encode a map as bytes but find there are say 260 unique tiles - it will highlight tiles that are ripe for substituting with another to keep it to 256 or lower. Email me some details and example maps if you want me to send you some sample data to see if it's going to do what you need.

In the zone is an example file Sonic_Level_1.zip containing sample data. The Rygar level 1 map was done with the same util.

Great effort, as usual!
Do you have any plans to publish this tool in one form or another?

Also, I thought its algorithm could be used in MapTapper to extract tiles from the screen buffer then attempt to find the source tiles in memory. Most of the time this is not needed but maybe in some cases this would simplify the search for tile data. Actually maybe MapTapper already does this?

(Sorry for the off-topic.)

[Codetapper]

Originally Posted by ReadOnlyCat

Also, I thought its algorithm could be used in MapTapper to extract tiles from the screen buffer then attempt to find the source tiles in memory. Most of the time this is not needed but maybe in some cases this would simplify the search for tile data. Actually maybe MapTapper already does this?

Indeed it already does. Have a look at some of the Maptapper tutorials that demonstrate tile and then map ripping based on a screenshot.

And I may put the "big picture to map" feature into Maptapper too at some point. The tool as it presently stands is a little rough around the edges as I made it quickly just for my own use but if you need it and can live with it, I can send you it.

[Brick Nash]

Originally Posted by Codetapper

Years ago I made a rather crude utility that does exactly this. Given any picture (eg. full map rips from HOL or MAME etc), it will work out the unique tiles (you determine the size) and it outputs the tiles and map. The map allows several formats (plain text, c, ASM, binary, byte/word/longword encoded, little/big endian etc) and it even has an option to output an overlay layer that shows tiles that are only used a few times.

The last feature is useful when you want to encode a map as bytes but find there are say 260 unique tiles - it will highlight tiles that are ripe for substituting with another to keep it to 256 or lower. Email me some details and example maps if you want me to send you some sample data to see if it's going to do what you need.

In the zone is an example file Sonic_Level_1.zip containing sample data. The Rygar level 1 map was done with the same util.

This sounds ideal!

The background I'm using I actually got from the rips section of your site but it's just the first third of the first level that I'm using for test purposes but I'll email you some details of what I'm trying to do which is pretty much just a generic scrolling brawler.

Would the output file be compatible for use with Amos? (I'm still a bit inexperienced to know what works with what!)

Seriously though this sounds like a fantastic tool that seems to fill a gap in a market. I'd be perfectly happy to pay money for an official version too, just so you know. I'll check out that Sonic file right away too so thanks for that example!

[idrougge]

Any output format is compatible since AMOS doesn't have any built-in level formats. You will always need to roll your own map loader routine.

[Brick Nash]

Originally Posted by idrougge

Any output format is compatible since AMOS doesn't have any built-in level formats. You will always need to roll your own map loader routine.

That's cool, I'm just glad I have the data at hand. It's great that Amos can accept ASM data, I just need to bone down and find a way to code it in but that's up to me to put in the work.

By the way, Codetapper's tool is amazing. Loads huge images, slices and saves all the map data and a tileset all within a few seconds. Would be great for folk doing ports that have the backgrounds but not the tiles.

[Mrs Beanbag]

"ASM data" presumably means a list of dc.b statements. While you could import that into AMOS of course, it would be better just to import raw byte data.

Personally i load my data into an AMOS data bank, which can be saved and loaded using the native AMOS load/save commands, and is very convenient.

[Brick Nash]

Originally Posted by Mrs Beanbag

"ASM data" presumably means a list of dc.b statements. While you could import that into AMOS of course, it would be better just to import raw byte data.

Personally i load my data into an AMOS data bank, which can be saved and loaded using the native AMOS load/save commands, and is very convenient.

Sorry to sound like a complete noob idiot but how exactly would I go about doing that?

And you are 100% correct, the output data is dc.b/w/l statements plus I think maybe some palette info at the end but I'm not sure. In fact there are two windows, one with the statements and another which looks like some sort of tile tally or audit.

Either way it's pretty cool!

[Mrs Beanbag]

using AMOS "Bload" command you can load arbitrary binary files into memory. You can load into a bank or into a memory address. You have to reserve the bank first, and make sure it's big enough to load the file in (otherwise unspecified bad things will happen).

if you want to automatically load a file of any length you can get the length of the file (this is quite obtuse but it's what you've got to do, unless you need your data in Chip RAM in which case you can cheat and use the Track Load instruction! It's for Tracker mods, but it doesn't check!):

Open In 1,"MyFile.txt"
LENGTH=Lof(1)
Close 1

Then reserve the bank and load the data:

Reserve as Data BANKNUMBER, LENGTH
Bload "MyFile.map", BANKNUMBER

Then you can change the bank name by

Poke$ start(BANKNUMBER)-8,"BANKNAME"

(substitute your own values for BANKNUMBER and BANKNAME there, bearing in mind the name MUST be 8 characters, pad with spaces if it is shorter) this way you can call it "Tile Map" or somesuch and see what it is when you Listbank.

Data banks will be saved along with your program, just like your Sprite and Icon banks, music banks, packed pictures &c.

Use Peek/Poke for reading/modifying the map data.

[volvo_0ne]

You learn something every day....

I never knew the Poke$ command even existed

[Brick Nash]

Originally Posted by Mrs Beanbag

using AMOS "Bload" command you can load arbitrary binary files into memory. You can load into a bank or into a memory address. You have to reserve the bank first, and make sure it's big enough to load the file in (otherwise unspecified bad things will happen).

if you want to automatically load a file of any length you can get the length of the file (this is quite obtuse but it's what you've got to do, unless you need your data in Chip RAM in which case you can cheat and use the Track Load instruction! It's for Tracker mods, but it doesn't check!):

Open In 1,"MyFile.txt"
LENGTH=Lof(1)
Close 1

Then reserve the bank and load the data:

Reserve as Data BANKNUMBER, LENGTH
Bload "MyFile.map", BANKNUMBER

Then you can change the bank name by

Poke$ start(BANKNUMBER)-8,"BANKNAME"

(substitute your own values for BANKNUMBER and BANKNAME there, bearing in mind the name MUST be 8 characters, pad with spaces if it is shorter) this way you can call it "Tile Map" or somesuch and see what it is when you Listbank.

Data banks will be saved along with your program, just like your Sprite and Icon banks, music banks, packed pictures &c.

Use Peek/Poke for reading/modifying the map data.

Such amazing and helpful information, thank you so much. In fact thank you to everyone who's helped me over the last week. Such a a brilliant, friendly and patient forum.

I take it I can just copy the asm info from the output into a text file and go from there with these instructions?

[Mrs Beanbag]

the appendices are the best part of the AMOSPro manual!

Originally Posted by Brick Nash

I take it I can just copy the asm info from the output into a text file and go from there with these instructions?

It would be better to export your map data as "byte encoded" (or "word encoded" if there are more than 256 tiles, in which case use Deek/Doke to read and write the data...). Getting AMOS to parse ASM source code would be far more effort than it's worth! (Unless you mean actually assembling the code, in which case you could load it with the AMOS Pload command... but that would be weird... or would it?)

[Brick Nash]

Again sorry for being 'that guy' but how would I export it byte encoded? Do you mean from Codetapper's program or just do it by other means.

I guess I have some reading to do!:S

Again many thanks for the info!