I can't believe Clickteam never thought to incorporate this into their application! This is a very useful and time saving mechanic that allows us to build tile sets from one huge sprite and select portions of a background/backdrop soooo much more easily!
I have my ground sprites that was given to me as one huge sprite, and to clone and crop each and every individual sprite is way too time consuming...
Does anyone else feel my pain as well? Or is there an extension or separate method of using tilesets into MMF2 the same way Game Maker does that I am not aware about?
Hi J.C
On a active object doubleclick it
At top left there is a "Import" select the picture and set spritesheet to the size example 32x32
And import as animation. select how many frames you want to Import.
DONE!
Originally Posted by LordHannu Hi J.C
On a active object doubleclick it
At top left there is a "Import" select the picture and set spritesheet to the size example 32x32
And import as animation. select how many frames you want to Import.
DONE!
Huh...so that's how it's done...kind of.
You forgot to mention exporting the frames as well, which does work, but it a tad bit time consuming to make multiple backdrop objects out of, if only there were a way to place all those exported sprites into the frame at once...
On the same topic, sorta... Is there any way to do this through events when running the game?
It would save some time to have the game automatically update from the tileset.png file rather than me having to go in and repeat this process at (currently) three different places every time I change some small detail.
Originally Posted by Wilderness (Ultra Soft) On the same topic, sorta... Is there any way to do this through events when running the game?
There are a couple of ways to achieve this.
The best way I think is to build your own editor and use the active backdrop object to cut tiles from an external image and paste them into the frame via events. You'll need to build an editor to make this easier, and have the editor save the position data about each tile to a file.
You can organize the tile data any way you want. You can use the array object, or the ini object, and I think there is even a binary data object.
This is a little advanced though if you don't come from a programming background already.
Another way to semi-automate loading in external images would be to number them, and then import them as an animation each time you make a change. I've done this to load in bitmap fonts and such, but also tile based games that use a single active to represent all of the different tiles.
Originally Posted by UrbanMonkAnother way to semi-automate loading in external images would be to number them, and then import them as an animation each time you make a change. I've done this to load in bitmap fonts and such, but also tile based games that use a single active to represent all of the different tiles.
This is what I do currently... There's no way to do this completely automatic through events? This way is fine, just thought it'd be simpler.
So, I've got this method that I use that might be what you're looking for. I've never been quite sure how to explain it, but I'll try to at least outline the theory.
This method involves the Text Blitter object. I don't think this object is available in all of the export modes, so use it only if it suits your needs.
So, the Text Blitter, when you place it in an application, looks something like this:
It displays text, of course. But it doesn't use a font. Instead, it draws from an image that it's got stored. You can access and change that image, which, by default, will look like this:
But what would happen if we replaced that default text image with tile graphics? Something like, say, this?
The image is a different dimension, of course, and the tiles are a different size (the Text Blitter's default is 8x8, this one is 16x16), but there are ways to change those in the object.
So, after doing that, it displays its little default message as before, except now it looks like this:
So it's displaying the tileset as distinct tiles! That's a start.
What we do then is change that default message. We need to cover the entire visible screen with tiles. At this point, it doesn't matter what tiles they ARE, so long as the coverage is complete.
After adding some repeating garbage, I got this:
Now, here's where it gets tricky. You see, the Text Blitter has this function called "Callback", where you can tell each individual character (or tile, in this case), to take on its own properties. In this case, we're going to create a simple array, and then tell the individual tiles to alter their graphics by taking their position in the row and their row number, and then referencing whatever value is stored in the resulting spot in the array.
Throw in a quick means to manipulate the array's values with the mouse, aaaand....
Tile-based graphics!
Doing something like this has a lot of benefits, as you can alter the tiles or the graphics on the fly. It allows for some pretty huge levels, speedy movement and layering, the ability to quickly change/reference the level data, animating tiles, etc. All those fun 8-/16-bit video game tricks.
You will run into a number of hurdles, though. For one thing, the Text Blitter doesn't include collision data, so you'll have to work out how to make objects collide with the data stored in your level array. Which is doable.
And you'll also need to work out scrolling and camera movement, but that shouldn't be a huge deal.
And then there's the matter of spawning/despawning sprites on the go, referencing the level data and managing when things should appear. Which is kind of a monster to take care of, but still possible.
You can take a look a this Ludum Dare base I put together if you want to see it in action.
It's serviceable, but kind of a mess. It's got leftover bits in it from several Ludum Dares.
But it's got a neat little built-in editor and everything (press enter to use it).
But it's also not commented at all. So it may be a little unintuitive.
Fifth, this same functionality can be accomplished using the active picture object minus all the hacking to make it work.
Just use the action "Create Backdrop Object", and it'll let you blit a tile from a tile sheet and paste it in the frame. You can paste them on different layers. You can also remove them using the "Delete created backdrop" action that's part of CF itself.
Plus it also supports collisions!
Two other useful objects are the surface object and the animated picture object.
Yeah, I'm guessing most people either use the Surface Object or else do the pasting to the background thing. And the usefulness of having your tiles in a single object like the Text Blitter method kinda lost its advantage once layers became a thing.
But I'll still stand by my Text Blitter. It still has a lot of useful properties. Like, if you want to make a field of spinning Mario coins, you could make them all through level data, animate them by altering the image source index, and collect them by comparing an object's collision value, all without having to deal with a single coin as an active object.
With a bit of creativity, it should only need to be as large as the screen. You could use offsets to determine what it's displaying at each tile, based on the source array from fifths example. Then you would only be limited to the array size in terms of performance. I'm out of practice as I haven't used a clickteam product in years, but something like that should be feasible.
Yeah, the Text Blitter object itself is really lightweight. You can have a whole bunch of them on screen displaying from different data sources, and you shouldn't notice any performance hit. I used to use several of them in layers to get parallax, back before layers were a thing. You can also stack a whole bunch of 'em to get a sort of depth thing going. It's a pretty versatile object.
But you WILL eventually hit some limitations.
First off, each object can only display 1024 characters, including newline characters (if you have any) and the end-of-line character. But if you really need to, say, cover a large-resolution screen with really small tiles, you could always use multiple objects to do so.
If you end up doing really complex calculations in the callback functions and have a lot of tiles to deal with, you will eventually see some loss of frames. That's something I'm kinda running into right now with BirdyWorld.
It used to be that you couldn't load an external image into the object (like, to load a new tileset) without massive, inexplicable slowdown, but I don't think that's the case any more. Either something was changed since MMF1.5, or else it only occurred on really old computers.
What I used to do (like in Nothing, and any of the games that used the same engine) was just make the tileset source image really tall, and just jump to new sections to change the tileset.
Advertisement
Post Reply
Edited by J.C
Thanks for the answer.
