Constructing a level editor with collision mapping

I'm having a problem right now that isn't too easy to address inside the confines of MMF2; I want to create a level editor & tile based engine for my project, a simple enough task, but I want it to be able to handle collision mapping for each tile, instead of being a simple "This entire square is either an obstactle or not"; for example, creating ramps, circles, etc. In essence, I'd like to create something that allows me to the same controls over a collision map that say the built-in background objects would have. Ideally I'd like to be able to simply chop squares out of a tileset and paste them to the screen like the text blitter does, but at the same time, allow for collisions only on the non-transparent parts of these images, not just the whole box.

Now I've been poring over various ideas for this, but many of them, and the main idea I've had so far is to use a normal tile-based text blitter engine for the main base, and have Active Objects that serve as backdrops created at runtime, cached with the images loaded externally. Is there any better way to do this? I noticed Fifth did something similar for his game "Nothing", where it was a text blitter engine that somehow handled ramps and rocks and stuff that were not aligned with the grid.

Knytt Stories doe's this, PM Nifflas.

hrmm well ill be damned
knytt stories DOES use an engine that can do ramps, but he never uses them in almost any of the levels; he uses a picture object to paste to the frame as backdrop, and this works for the map at runtime, but the problem is that it would never work for a scrolling engine I think; you can update a text blitter every frame, but you can't draw 100+ tiles via pasting without some slowdown. hrmm.

have you tried the collision mask expression?

problem is that it only works for layer 1 iirc

I solved it for my level editor by having all the tiles as animation frames in an active object, which is then used like a brush to stamp the tiles into the background (similar to the picture object approach). This allowed for ramps and everything and worked well with scrolling. Now with HWA it's very fast.

hrmm thats tempting to eschew a text-blitter setup, but wouldn't it take a ridiculously long time to create a full level out of say 24x24 pixel objects? I mean if they were all drawn onto the frame at the start, you'd be looking at adding over 10000 backdrops... Seems a little heavy

eh I tested it a little, and it appears that every single backdrop that is added at runtime counts towards the active object maximum, and thus there is the same lag applied when you have 1000+ of them


HOWEVER, what you said might come in handy; I could stamp via brush the 'backdrops', and have a text blitter for the 'quick backdrops' and use a function for finding if a location is an obstactle or not. Seems marginally more efficient than having a bunch of the brush objects

Well my editor allowed tiles of all sizes (as long as they're a multiple of the grid). You can even overlap them as you see fit (as the editor saves the order in which they are created).
So you could fill the background with a few very big tiles and then add the level + detail with smaller ones.

hrmm well theres no reason to restrict them to the grid then, if you are doing a list-based map instead of an array based map, is there? and wouldn't your larger tiles have to be saved as larger images, which would consume extra size?

I'm a little hesitant, since that approach uses an almost ridiculous amount of backdrop objects, but I tested it out with 10000 added backdrops and there was no lag while scrolling.... It seems like I could simply use the array based method and place each tile right out of an active picture object holding the spritesheet as a brush, and simply set the maximum number of objects for the frame to something astronomical like 999999. But something seems fishy about the whole prospect. When I use a text blitter approach, I only have to draw what is on screen, and with this, I know backdrops only render while in the visible play window, but wouldn't they need waaaaay too much storage if the game saves the image of each backdrop individually?

No, I only restricted tiles to the grid, because then it allows to make levels REALLY FAST, and everything kinda fits together.

Larger tiles take extra space, yeah. But it also looks nicer, cause you have some variety in the background ;)

If you have so many objects, collision detection might become a bit slow when you have more moving objects later, I think. So if you paste the stuff into the background, you get that performance back.
MMF stores the size of the frame in buffer anyway, no matter if you paste something into it or not. You can calculate the memory it takes yourself - 3 colors (24bit), +4 bits for collision mask I think, multiplied by frame size.

If you paste into background as obsticle then even if you scroll away from that area and come back it stays there and does not get erased, see the phizix examples.

Add backdrop will stay, paste into background will be erased when you scroll.

yes, but my concern is that there will be a performance drop if I have to use the add backdrop function 10000+ times. Like Random says, it probably won't matter for the collision mask in taking up any extra processing, but the game might have difficulty tracking the sheer number of objects. Having 10000+ created backdrops and 400+ active objects? :X

Make a test application?

well that took less than 5 minutes, I'm just afraid problems will exist down the road when I try to apply more complicated things to it

Make bigger backdrop tiles, so you have less objects.

but then I'm trading off file size -_- Luckily that engine works better in big open environments, like if it took place in space, so I can have a minimal amount of game devoted to the collision mask; it could be a few big sphere in an open space, instead of a completely filled in building or something


that leaves me one more question. Is there any reliable way to display objects in a layer BEHIND backdrops? Because if I wanted to create a parallax background in this game, I'd either have to

A) Find a way to display oh say a text blitter behind the backdrops

or

B) Use this backdrop pasting method ONLY for the collision map, not actually doing the games graphics, and run over the game a SECOND time with a text blitter displaying the exact same tiles, and another behind that for the parallax background.

^seems rather dumb, but it would work

Does filesize really matter that much? A 128x128 tile is just 48kb.. plus MMF is compressing it (unless it's external, in which case you can use a compressed format).

Just put a text blitter on a layer behind the "game layer" and you can have parallaxing.

Maybe I'm not understanding layers, how do you do that? I can't seem to put text blitter behind backdrops even if its in a different layer

1)Ctrl+K
2)new layer
3)drag the text blitter in it
4)drag the layer so it is lower than the one withthe backdrops in it.
5)???
6)Profit

danke good sir

Ah, you didn't know about layers. Now this should make things a lot easier.

My game has 1000+ active that are pasted into background at start of frame after being looped into the phizix extension, and when I scroll they don't get erased. If I have to make a dang example to show you I will!

Please do show me an example. I just tried it and Pasted backdrops doesn't stay whey they scroll outside the window.

He's probably using Add Backdrop without knowing the difference. Seriously, that can't possibly be :P
(HWA, maybe? But I don't think it even supports pasting)

Yah I usually do all my stuff in TGF, so that newfangled layers bit is greek to me. But I'd be looking at 15000+ added backdrops, not 1000; a 4000x4000 level would take up 15625 tiles of 32x32 size, though I most like would have tons of 'transparent' space that isn't filled in, which is my saving grace.