- Forum
- Lounge
- Platformer
- Page 2
Platformer
Pages: 12
It can't be a good idea to use the same method for checking for existence of collisions and where they happen, considering the probability that a line collides with player. If there are quick coarse filters, they should be abused.
But there comes a point where additional filters don't improve performance.
The way I have my system set up, in a 256x256 pixel sector, there are maybe 3 to 4 wall lines you'll need to check against on average. Often less. More than 6 lines in one sector would be extremely unlikely.
So the question now is.... is it really worth it to add a medium range filter to cut those 4 possible lines down to 2? Even if that does add a performance increase (which I'm not sure it would), it adds a lot of complication to the code.
The way I have my system set up, in a 256x256 pixel sector, there are maybe 3 to 4 wall lines you'll need to check against on average. Often less. More than 6 lines in one sector would be extremely unlikely.
So the question now is.... is it really worth it to add a medium range filter to cut those 4 possible lines down to 2? Even if that does add a performance increase (which I'm not sure it would), it adds a lot of complication to the code.
Last edited on
3-4? I expected more. Well, keep this in mind if you ever decide to model smooth curves :D.
What do you do if lines / polygons end up in multiple sectors? Are they in all of them then? I suppose it's fine to check collision against the same line multiple times (I'd guess that remembering which lines were already checked would be too costly for a relatively rare occasion)...
Can your lines generate any effects upon collision (like, damaging the player or somethign the like)?
Can your lines generate any effects upon collision (like, damaging the player or somethign the like)?
| What do you do if lines / polygons end up in multiple sectors? Are they in all of them then? I suppose it's fine to check collision against the same line multiple times (I'd guess that remembering which lines were already checked would be too costly for a relatively rare occasion)... |
Yeah, he just puts the same line in multiple sectors.
Here's something I've been playing with for a while-> http://tinypic.com/r/hwg4r8/5 (video)
It's supposed to be a terraria [1] clone. I'm using the jmonkey engine [2] for this, mainly for portability. I'm doing it just for fun, but I'll try to create something of commercial level. So far, I've implemented basic map editing, player movement (and collision detection / resolution), and fluid simulation. That last one is what I'll be talking about in this post.
I wanted to make it realistic but keep it simple at the same time, so I stayed away from methods involving strange physics formulas that make you have nightmares. The first thing that got my attention was some guy's blog entry [3]. However, it wasn't enough. As he states...
However, right below that, he also says...
That [4] was the second thing that got my attention. I liked the teleport solution that guy used for the U shaped tube problem and I decided to do something similar.
So, every water tile, when spawned, lies inside its own so called water pool. When water tiles come together, they are put in the same water pool. When they move away from each other, they are put in distinct water pools again. Now, apart from the typical moves a water tile makes (e.g. move down if there's empty space), each water pool is iterated over and water tiles in high positions teleport to empty space near water tiles (of the same water pool) in low positions.
It works pretty well, but I find it a bit expensive. I don't know if it's able to handle a world with thousands or tens of thousands of water tiles :/ The complexity is O(n log n) (n -> number of water tiles), but I process every water tile several times. Any thoughts?
[1] http://www.terraria.org/
[2] http://jmonkeyengine.com/
[3] http://w-shadow.com/blog/2009/09/01/simple-fluid-simulation/
[4] http://www.gamasutra.com/view/feature/3549/interview_the_making_of_dwarf_.php?page=9
It's supposed to be a terraria [1] clone. I'm using the jmonkey engine [2] for this, mainly for portability. I'm doing it just for fun, but I'll try to create something of commercial level. So far, I've implemented basic map editing, player movement (and collision detection / resolution), and fluid simulation. That last one is what I'll be talking about in this post.
I wanted to make it realistic but keep it simple at the same time, so I stayed away from methods involving strange physics formulas that make you have nightmares. The first thing that got my attention was some guy's blog entry [3]. However, it wasn't enough. As he states...
| CA-based algorithms have both advantages and disadvantages. On the one hand, they’re relatively fast and the simulation quality is often good enough for games and software toys. On the other, they can produce behaviour that is very unrealistic - for example, water falling into a basin will form a little "hill" and spread out slowly, instead of near-instantly as real water would. Whether this is an acceptable downside depends on your application. |
However, right below that, he also says...
| For a different take on simulating fluid dynamics with cellular automata, check out this interview with the author of Dwarf Fortress. |
That [4] was the second thing that got my attention. I liked the teleport solution that guy used for the U shaped tube problem and I decided to do something similar.
So, every water tile, when spawned, lies inside its own so called water pool. When water tiles come together, they are put in the same water pool. When they move away from each other, they are put in distinct water pools again. Now, apart from the typical moves a water tile makes (e.g. move down if there's empty space), each water pool is iterated over and water tiles in high positions teleport to empty space near water tiles (of the same water pool) in low positions.
It works pretty well, but I find it a bit expensive. I don't know if it's able to handle a world with thousands or tens of thousands of water tiles :/ The complexity is O(n log n) (n -> number of water tiles), but I process every water tile several times. Any thoughts?
[1] http://www.terraria.org/
[2] http://jmonkeyengine.com/
[3] http://w-shadow.com/blog/2009/09/01/simple-fluid-simulation/
[4] http://www.gamasutra.com/view/feature/3549/interview_the_making_of_dwarf_.php?page=9
Last edited on
A little off topic, but Terraria looks stupidly awesome for being in development for just a little over a year. Where's the catch?
closed account (1yR4jE8b)
THere is none reallly, it's overall a pretty stupidly awesome game. Lots of love went into the game.
Topic archived. No new replies allowed.
Pages: 12