• Create Account

# joekarl

Member Since 11 Aug 2010
Offline Last Active Nov 05 2015 04:39 PM

### In Topic: Collision detection in a tight maze

23 October 2015 - 05:09 PM

@MarekKnows yeah this is what I ended up doing. Works well enough for the enemy movement and makes the code super clean. Using ascii for the tilemap so a little different but same concept.

### In Topic: Sequential vs Simultaneous collision detection

23 October 2015 - 05:03 PM

Also once you resolved one pair or group this can potentially create new collision events which need to be considered as well while progressing in time.

So I go through, calculate all of the potential collisions, find the first one, resolve it. Because it can create new collisions after the resolution I should re-calculate all collisions from that point forward, go resolve the first one, and then repeat this process for the rest of the step ya?

### In Topic: Collision detection in a tight maze

21 October 2015 - 04:55 PM

I guess the 0 wall thickness thing is more for the tilemap approach as there's no physics object per wall, the wall is more of just for display instead of actually impeding the players motion which is governed by the tilemap. I guess I was being a bit hasty in thinking the wall collision version had to have a 0 thickness wall.

Got some prototype stuff up and running with the tilemap setup. Basic idea is the enemies pick a tile adjacent to their current tile that they want to go to (so long as it won't go through a wall) and then travel to that tile. Once there they decide to go to another tile. Rinse, repeat.

https://youtu.be/-Lh3mQhsS08

### In Topic: Interpolating color across a polygon

12 October 2012 - 02:18 PM

Okay, so I'm doing some clipping to cut down on the surface area that I'm actually drawing. Right now thats being done before I'm rasterizing the polygon which is resulting in non-triangle polygons when I get to rasterization. So how should I go about avoiding those 4+ vertice polygons?

### In Topic: Handling polygons in multiple nodes of an Octree

18 January 2012 - 07:39 PM

I suppose I should be looking into loose octrees as opposed to straight octrees.

So how do you order the polygons that reside in a parent node when you go to render the polygons? It seems there's still going to be ordering issues with the polygons in the parent and its child nodes. Is that where you punt and create a z-buffer for just that node in the octree and use that to order the pixels in those nodes? Seems like that wouldn't work well for really large polygons like a floor, but that could be a know limitation and the floor could be constructed of lots of smaller polygons.

PARTNERS