so heres what I'm facing. I want to create a level editor, like one of those 2d tile based ones, except I want it to be able to handle non-square collision maps. I don't want backgrounds to be restricted to being big 24x24 boxes or anything; I want to be able to do circles, triangles, etc. Non-regular shapes. But how in the crap could one go about creating a level editor that allows for collision detection like this? Especially if sprites were loaded from a sprite sheet, is there any way at runtime to create a collision map for each one, or would I be stuck having to use template shapes or would every single tile have to be an active object or what? Any thoughts?
You can always download my editor. Now if I understood this problem you need to create collision map. So you should need to use part 1. Then you need to make your own size tiles and draw then into tileset, then you use the tiles to add them into game. But this is pretty slow so you could just but there system like the shadows and lights, but with different sized objects.
I have proven new mathematic formula to be true...
Well a collision map wouldn't explicitly work. What I really need to do is have a collision map for *every single tile*, like an active object has. Like in a 32x32 active object, any transparent space will not register as a collision. If I had a tile that looked like this:
Then I'd want it to only have collisions with the player on the bottom left half, and nothing on the top right half. *HOW* I implement this isn't very particular; if it was actually a 32x32 pixel array for each tile saved in a magicdeque, that would be perfectly fine by me, I can program an engine that uses that as a collision map, but obviously that would be slow, clunky, and ridiculously sized, even with minimal amounts of objects.
Ideally, what I'd like to have is this: If I could draw say a slightly oblong circle in my sprite sheet, which would chop it into oh say a 4x4 set of 24x24 pixel tiles; a big square containing the circle shape, and then the player in the game could run around the circle. But with the tiles used as collision detection like a NORMAL engine, I'd only be able to make it so he could run around a giant cube, not around a giant circle.
So I can't just use normal tiles with a giant collision map, since each tile needs to have its own collision map. And I can think of several ways to do that, but none of them are any good.
I think the only possible way I can do this is to do what Derek did for Aquaria; pretty much recreate the MMF2 level editor. Make it use lists of objects instead of tiles, and display them the exact same way. Seems ridiculous, remaking what is already there, but oh well....
I'm confused
Background tiles don't have to be square, and can use fine collision detection the same as active objects.
You can always use two "layers" of tiles - one invisible and partially transparent tile, created as an obstacle, and a visible graphic tile set to "no effect on collisions".
Failing that, maybe use a big overlay for the collision detection, and paste tiles into it or draw circles etc.
Anyway, that probably didn't help at all, as I don't think I really understand the problem, but I tried...
Why don't u use actives, it's way more simpler... with a sprite sheet i don't think you can do what you want. unless you use just a few basic objects... like triangle left, triangle right, circle, box... then make 5 tabs of the spritesheet, each using the value of the needed collision(sprite sheet) you need. each tab executing different collision.
The best way is to use actives, and drop them as backdrops in editor. In my opinion. In that case you can't really use a spritesheet, unless you do it kinda funny.
If you use internal tiles you can easily get non box collisions. However if you want external tile sheets I'm not sure any of the objects that can paste images allow you to paste as anything other than a box collision.
One (pretty ridiculous) idea that springs to mind is using an external collision map with 1x1 size boxes.
I could ask phizzy if he has any ideas, he was going to work on a level editor with external tiles and collision maps.
someone should write an extension that allows for pasting external images with fine collision detection.
id do the collision masking. have a single color mask of each tile and paste it onto an overlay and do some rgb checking. mask is 255,0,255 then anything 255,0,255 is considered a collision. youre spiffy with mmf loops, im sure you could do that pretty fast.
You could use the overlay to create a single large collision mask for the level (by pasting parts of a spritesheet in another overlay, into it).
This could then be saved as a .png, and loaded into a picture object in the game itself (it does allow transparency and fine collision detection). I don't know how fast it would be with large, scrolling levels.
You'd then do the same thing for the tile graphics - ie. the part the player can see, but that doesn't affect collisions.
I believe this is like what Neonmonkey's editor does for the graphics part, if I remember correctly.
If you didn't want to have level files containing two .pngs, you could always generate them as temporary files, in the game itself instead of in the editor.
its an interesting idea sketchy, but I tried that exact method for screen rotation before I found the function on Ando's viewport object, and it runs faaaaar too slow no matter how you do it. Loading it in the game is another good idea, like if I put it offscreen and just used the "is (X,Y) transparent?" function or something. I also think the 1x1 array would work too slow too but if you do want to ask Phizzy andy, that would be excellent
I think overall I'll probably doing what Derek did for Aquaria; instead of saving backdrops as tiles & using an array, saving them as a list, and assembling it onscreen based on what is on the list; effectively programming quick backdrops & backdrops from scratch
I think the method he was going with was having internal active objects of varying shapes for the collisions, that would be invisible. Then the visible tiles would be created from external tilesheets but contain no collisions of their own.
And i assume they would be loaded from an array.
btw i knew the 1x1 array idea would be too slow, lol.
yes i considered that method, like don also pointed out, but that only works if you have predetermined shapes and it severely restricts what you *can* do. For example, attempting to make backgrounds in the shapes in this video would be utterly exhaustive, since I'd need to define like 300 active object collisions:
http://www.youtube.com/watch?v=2DMXwEkrRgY
I'm going to look into creating a list-based interface, but I'm not how sure an externally loaded one like that could be. It might restrict me into not being able to do off-screen collisions, etc.
Actually I'm kind of curious. In MMF2, active objects support being able to load animation frames at runtime from external sources. Is it possible that I could actually pre-load the obtuse artifacts, ie the backdrops instead of quick backdrops, by having a ton of different active objects that I cache the animations to from external sprite sheets, and use the normal "grid based" approach for everything else? O_o
Originally Posted by Pixelthief Actually I'm kind of curious. In MMF2, active objects support being able to load animation frames at runtime from external sources. Is it possible that I could actually pre-load the obtuse artifacts, ie the backdrops instead of quick backdrops, by having a ton of different active objects that I cache the animations to from external sprite sheets, and use the normal "grid based" approach for everything else? O_o
One way to find out: Try it. If you can do it, then it is possible.
Ok after some talk with Random I settled on using a method wherein the game pastes every single tile into the level as a backdrop via the Active Picture object; it uses the create backdrop function to both create the graphic AND collision map across the entire level, a method that might require 10000 backdrop objects per level. However, these are just backdrops not actives, and while they are restricted by the active object cap, I haven't noticed any slowdown and the whole level generation doesn't take more than a second or two.
If anyone has a reason why this wouldn't work, best tell me now!
Advertisement
Post Reply
Edited by Don Luciano
