Making tiles and maps out of large images then reconstructing
 

Hey folks,

I've reached that stage where I'd like to try to get a scrolling background into my game and I have some cool beat 'em up backgrounds downloaded that I'd like to use that are made up of tiles.

Thing is I'm not sure how to go about this and am wondering if there is a program for this job, one that will analyse a large picture then chop out all the tiles and remember their positions (including multiples) of the large picture for reconstructing later within a game.

I tried TOME and I can indeed load a large image to be chopped up and I can save the tiles but I found no way of reconstructing them into the background except by hand.

Am I missing something? I read the tutorial but I couldn't see anything about reconstructing once the tiles had been extracted......

.......or am I thinking that this job is easier than it probably is in reality?

Thanks folks!

I wrote my own program on PC to do this and I doubt the Amiga has the CPU power to do but only with a small picture. ps TOME is a piece of shit write your own map editor - obviously your have to write your own code to display the map.If you think theres a way to magically cut up a image and display it for you theres not.

No I didn't think anything was magical. I'm new to this and was just inquiring to see if there were any options.

I think it would be a good exercise for you to make your own tiles grabber and map editor. You can then reuse the same routines in your game, so it's not a waste and a learning experience.
I posted some routines here which you can use for inspiration: http://eab.abime.net/showthread.php?t=80646

Wonderful, thank you.

Yes I was thinking the same thing. It's great getting into all the nitty gritty of vintage game making and I like the DIY attitude associated with it.

Sorry as far as I know there are no good tools to do this on any platform but I might be wrong if anyone knows let me know and I would have thought building a game on any platform is the same? If there are tools to do it on other platforms theres no reason the data couldnt be imported to another platform.

Please tell me about the process on other platforms - I might be cynical but I suspect some of the coders of retro style games for android etc check such boards as this using the info and putting nothing back.

and im serious if you know about making games on other platforms please tell me :) I might have to start a new thread.

It's cool. I don't mind having a bash it writing one but I've only been learning Amos for a week and it's a bit intimidating.

The theory seems straightforward though- Scan an image file in blocks of 16x16 or 32x16/32x32 etc. and then save one of each but plot the positions of duplicates and save the data for reconstruction later.

Putting it into practice is another thing though......:banghead

Basically youve got it :) and with idrougge's example your laughing the principal is the same of course in any language.

Haha, thanks for the vote of confidence. :) I'm looking at the code right now....and it's still intimidating!!!

I'll need to really study it as my use of efficient syntax is very limited right now and just general knowledge of the Amiga. Things I know nothing about like how to recognise file types for import, the analysing and slicing routine itself, how the map data is stored and of course...the GUI (If I decided to use one)

Scary stuff. Well for me anyway! :laughing

in your week of learning youve wrapped your head around the whole process - stay cool:cool

yes that is how tile maps work... if you are just drawing your entire level as a huge image, tile maps are kind of redundant really. The way it generally works is you draw your tiles first, then you construct your level out of them.

It is possible to do what you suggest with some PC software (i don't remember who wrote one now...) but TOME will certainly not do it, it will just apply a grid to the supplied image and every single grid square will be another tile, without checking for duplicates. The whole point of tile maps is that you can construct a huge level out of only a small set of graphical components.

I used TOME for many years prior to writing my own map editor. It does the job, granted it doesn't do it very well but it does it.

I think the Amiga should be able to cope with processing a large image into a tile map in this way, i would pre-process the image using a hashing function on each tile. A simple Pearson hash should suffice.

The thing I dont like about TOME is the extras like the scrolling commands etc there all software scrolling -why? also the GUI is horribe TAME or MapyMap are much better.

to split a large image up into tiles would take a lot of memory for a big image and a lot of processing time, and checking each one on Amiga would be very slow.

To be honest I dont really like coding on Amiga I just do it some times for a bit of fun qnd try to make my code poratable - what I find really annoying is people trying to guess how I did things - he used tome No he used backbone No etc and this is after ive explained to them how its done??? so I probably will use Blitz in future as no part of my code is Amos only.

it really doesn't need to use much more memory than the original image and the gathered tiles, and it is a linear-time problem, there is no complex calculation involved really. The bigger the image, the longer it will take, obviously, but an image twice as big should only take twice as long.

AMOS has some very useful image compression commands - PACK, SPACK and UNPACK. This apparently splits up an image into tile-like "strips" of optimal height, that it works out. I'm not exactly sure of the internal details, but as a problem it is not a million miles away from what we're suggesting.

If you use the right data structures, i think this can be made fast-enough for images several screens big.

I cant draw to save my life, so my main interest has been using existing maps from Amiga and console games, when you look at the size of these maps there very large - so big memory requirement to load the image in and lots of processing time to compaire each tile once split, I dont know anything about amos compression routines but a doubt amos could even load the image with its 1024*1024 screen size, we are talking very big images, to compress the image is the same process as spliting it and comparing creating the map - this is a type of compression in a way - again the amiga would struggle a 486 would probably take a long time to compress it.

of course we dont even need to display the picture - but our input is a large PNG or BMP this is a big file - jpeg probably to many errors to be accurate creating to many tiles.

Pixels? And in how many colours? An image that size in 16 colours would take up 512kb, indeed a large image for the original A1000 or A500 but not a problem for an A500+, A600 or A1200, especially with Fast RAM, it could be done. Anyway for Brick Nash's particular problem, even TOME can load the image so that is definitely not a problem.

Like all these things amiga can do it but we're talking about comparing 4000 16*16 tiles - PC is quicker.
and if you decrease the colour depth you could create errors.

of course PC is quicker... but i don't know what you mean by "decreasing the colour depth", on the Amiga it is perfectly common for games backgrounds to use 16 colours, the graphics would be drawn in 16 colours in the first place. i'm not talking about using the Amiga to create PC games, that would be strange.

ok final post - when you download a map from the internet like I put in my earlier post theres no point introducing errors just keep the original colour depth,scan it generate your map and tile set - then decrease the colour depth if you want to use it on amiga :)

i feel this is getting confusingly tangential.

Brick Nash wants to be able to create a large image on the Amiga and turn it into a tile set and map.

i think i know how to write this. However, i have too many other fish to fry at the moment. But if anyone else wants to try i can point them in the right direction.