Distort Maps With Collisions

The title says it all..

It would be very, very, very, very, very .. (999 very) .. useful..

Hmm, a very tricky algorithm to write... might be slow to process too...

Cough ......custom collision masks.

Cough ......custom collision masks.

I believe the idea he's getting at is that you can animate distort maps and therefor having a distort map with collisions would then mean an animated custom collision, practically, I'm fairly certain you cannot animate collision masks (unless i've been gone too long and you can now)

Here is a question. If you use 3d mesh - that is, it spans multiple Z - how would you do 3d collision detection? It'd be very tricky, no doubt.

I've never said I want animated collision detection. I just need polygonal collision detection, it's not so difficult for the programmers that made this entire app with even SHADERS!! Anyway, i'm already tired of this topic, I'll just stop asking for this feature..

p.s.: I've never seen a modern 2d engine without the possibility to draw textured polygonal shapes.

I could name many, but it's beside the point, I guess. It's not crucial to 99% of games people are going to develop, and using utilitarian principles to create a program when you're doing it for free and for everyone means prioritising.

It's a very difficult and specialised feature and not likely to be considered before 2.0.

not before 2.0? I think the polygon drawing is at the basics of an engine..

It's a 2D sprite-based game creation tool. The fact that there are any polygon mesh features at all is already more than you would expect.

If you really want polygonal collisions, perhaps you should check out one of the many freely available 3D engines that you can find on the web.

You can kick and scream all you like, but it's probably not going to happen: firstly, sprites and mesh distortion are made of textured polygons, therefore there is already a way to display textured polygons as you wish. Further, the collisions algorithm would be, as I said, a tricky and time-consuming thing to program. Of course it's possible, but the collisions engine is a highly optimized and low-level MMX based bitmask generator and tester, and would be difficult to adapt. In the same time it would take to do that, we could've done several things useful to 10x as many users. Therefore, it just doesn't make sense to implement it right now.

Then why don't make a function on sprite meshes that "rasterize" the mesh and transform it directly in a sprite? That would be easy and simple.

They already make something that does that, its called Photoshop.

Ok then, make a 40 mb map with Photoshop, then load it as a 7000x5000 sprite! You are very brilliant!

Then why don't make a function on sprite meshes that "rasterize" the mesh and transform it directly in a sprite? That would be easy and simple.

There are technical reasons why this is a bad idea, essentially that's a massive hack. It would consume additional VRAM, and involve slow transmissions from GPU to CPU over an already bottlenecked bridge. People would complain that it's slow, and there are further technical issues relating to bounding box complications making it not a simple implementation even for that hack.

Ok then, make a 40 mb map with Photoshop, then load it as a 7000x5000 sprite! You are very brilliant!

So a screen grab will somehow magically use less vram?

I dont see why this is so hard to understand, you make lots of little sprites, then import them into the program, and place them where you want them.

Edit:

Yeah what Ashley said.