# ValMan

Member

270

466 Neutral

• Rank
Member
1. ## First release!

I've been meaning to ask this, but how do I place the tree sprite on the map? I managed to place land/grass tiles and the small plants, but the tree doesn't show up in the texture browser. I messed around with the Build and Actor tabs, and I managed to create an actor using the tree texture, but when placed on the map, the actor showed up as a traced box, without the texture.

3. ## Art Issue, Camera, GUI

Crashed on startup :( Error: Tried to execute code at 0x00000000, called from 004051e8() Assuming you can believe the call stack, since you didn't attach any debug info. Log contains same info as already mentioned (LoadTexture/invalid enumerant). I can upload crash dump if you are interested.
4. ## Pod Collisions

I got interested in your problem after reading and thought about it. Here's what I came up with: 1. For each type of tile, store its convex hull as an array of 4 lines. In terms of storage you could do this by having a "tile template" file that specifies the bitmap the tile will display and include the convex hull info. The best way to represent a 2D line is by using 1 point that lies on the line plus line's normal (the vector that points in the direction of line's positive halfspace). This representation is most optimal for collision detection. You can reduce the memory this will take by storing only 4 normals (2 floats for each), and then assuming that the first and the second line's point is the tile's top left corner and the third and fourth line's point is the tile's bottom right corner. So for a simple square tile, you would store: [0] = ( -1.0, 0.0) // left edge - normal points left (implicit point is tile top left) [1] = ( 0.0, -1.0) // top edge - normal points up (implicit point is tile top left) [2] = ( 1.0, 0.0) // right edge - normal points right (implicit point is tile bottom right) [3] = ( 0.0, 1.0) // bottom edge - normal points down (implicit point is tile bottom right) Notice that all normals are pointing "out" of the tile (away from center). 2. When doing collision detection: For each tile that pod overlays, Calculate 4 lines that define that tile's convex hull by using the stored normals and calculating the points based on current tile's AABB min & max (top left & bottom right). Thus, "decompressing" the hull info to prepare for collision testing. Then for each "decompressed" hull line, check if the line faces toward the pod or away from pod. If it faces away, you can early-out of collision detection. This will prevent testing collision against the sides of tiles that face away from the pod and are not a part of the complex shape that defines pod's "immediate environment" that it's inside of. To do this, you would probably take the dot product of the line's normal versus the vector difference of line's point and pod's center point (pod.center - line.point). If the dot product is negative or [close to] zero, the normal points away from the pod, so it would be on the "other side" of the tile. If on the other hand the result is positive, you proceed to test collision. You can work out the specifics, but it sounds about right. To test collision, you would reuse the projection you just did. Compare the dot product result (if positive and non-zero) to the pod's radius. If less than radius, flag collision. The last part is moving the pod out of intersection after detecting collision. To do this, keep a list of separation vectors and add to it every time a collision is detected. To calculate the separation vector from each collision, take the normal of the line that the pod collided with and multiply it by the penetration (the difference between pod's radius and the distance to the line's point along line's normal (that would be the dot product you took earlier). Don't do any separation just yet - only store those penetration vectors. Once you finish testing against all close-by tiles, loop through the list of penetration vectors and choose the smallest one, or use some kind of biasing algorithm (based on pod's velocity) to choose one. The biasing algorithm way would work best if your pod sometimes has velocity with a magnitude that exceeds the size of a tile in your world.
5. ## All work and no play

So, looks like you are opting out of alpha blending for sprites? This may not be so noticeable on the foliage, but less chaotic sprites will suffer from highly visible pixelated edges. I am mentioning this after I saw the black border on your player sprite, which likely resulted from selecting a black matte for conversion to a palletized format. In my engine, I am drawing all tiles with alpha blending turned off (optionally) because it's stupid to waste GPU power to fill the whole screen and perform a blending operation for each opaque pixel. However, having to switch a render state such as alpha blending on and off will break the rendering batch (at the very least), so for cases where slow down caused by switching state is greater than slowdown caused by blending, alpha blending can be left on (for instance, if number of tiles on screen is below threshold). Then I just draw all sprites with alpha blending enabled - seeing as how I am designing my engine mostly to handle 32bit sprites with lots of transparent areas, any sorting and state switching here would just slow it down without a good excuse. Well, and last but not least - in my experience, poor performance drawing many objects on screen at once usually comes from either too much state switching (like switching a texture) or too much overdraw. Submitting lots of verts using the same texture and not drawing any pixel more than required usually results in acceptable performance (assuming other things like vertex cache optimization have also been considered). I am mentioning this as a possible argument in favor of using real 3D models instead of pre-rendered sprites.
6. ## Walking cycle

Walking animation is done in two stages. Stage one is roughing out the animation with main keyframes (called pose-to-pose), stage two is tweaking in-between keyframes. It looks like you executed stage one pretty well - the 4 main walking frames look good and in their place. Frame 1 should be both feet spread and on the ground, frame 2 is standing on one foot and second foot bent at an angle with sole slightly behind the other foot, frame 3 is once again both feet stepped down but with the other foot forward, frame 4 is like frame 2 but with feet switched, then loop to 1. Once the keyframes for all bones are set on those 4 frames, you did a simple interpolation (by spacing out the keyframes) and let Max do the curves for you. Now you need to tweak in-betweens to raise his feet higher in transition from both feet on the ground to one foot on the ground and back, and to make his center-of-weight change its pitch and roll angles in response to step-downs. When the character steps down on a foot, the pelvis should change its roll angle to tilt the character (very slightly) in the direction of that foot. It looks like what you actually did is change the yaw angle on the chest in response to moving the arms - I suggest toning down the yaw angle animation and animating pelvis roll angle more. Also when the character steps down, he should bend spine and neck very slightly down/forward, and then raise them back up when shifting weight over the next foot. Pelvis should also sink slightly during step-down, but it looks like you already have that going. Perhaps tweak it a little to make it stronger. Well, and then there is foot-kick. You may notice when you walk that just before you step on a foot, it is rotated with toes pointing slightly down because that's the position the foot assumed after being lifted off the ground. So just before you step on that foot, you quickly rotate it to a horizontal position (maybe even slightly upwards). This whole deal ends up looking like a kick, so it's called a foot-kick. The last thing to mention is the elbow-lock and knee-lock. Your knee locks when you step off one foot and shift your weight onto another foot. Same with the elbow, when you move your arms in response to walking - when the upper arm is rotated backwards, the lower arm is also rotated backwards and the elbow gets locked when the two arm bones are at 180 degree to each other. Then the arm starts moving forward again - upper arm rotates forward as does the lower arm and the elbow unlocks. It looks like you do have knee-locks but they are a little weak (you don't clearly see when the knee locks - looks too smooth). It also looks like you don't have the elbow-locks yet: there is no lower arm movement (or not much), only the upper arm rotates.