Jump to content
  • Advertisement

ValMan

Member
  • Content Count

    270
  • Joined

  • Last visited

Community Reputation

466 Neutral

About ValMan

  • Rank
    Member
  1. ValMan

    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.
  2. ValMan

    First release!

    I had to install OpenAL, but after that worked fine. Very fast performance, high quality display. Got a message box (but only after quitting): --------------------------- Terminating editor, following errors occurred --------------------------- shaders/nimrod_lightshader0.vert - shaders/nimrod_lightshader0.fragValidation failed! - Different sampler types for same sample texture unit in fragment shader shaders/nimrod_lightshader1.vert - shaders/nimrod_lightshader1.fragValidation failed! - Different sampler types for same sample texture unit in fragment shader shaders/nimrod_lightshader2.vert - shaders/nimrod_lightshader2.fragValidation failed! - Different sampler types for same sample texture unit in fragment shader shaders/nimrod_lightshader3.vert - shaders/nimrod_lightshader3.fragValidation failed! - Different sampler types for same sample texture unit in fragment shader shaders/nimrod_lightshader4.vert - shaders/nimrod_lightshader4.fragValidation failed! - Different sampler types for same sample texture unit in fragment shader shaders/nimrod_lightshader0_bi.vert - shaders/nimrod_lightshader0_bi.fragValidation failed! - Different sampler types for same sample texture unit in fragment shader shaders/nimrod_lightshader1_bi.vert - shaders/nimrod_lightshader1_bi.fragValidation failed! - Different sampler types for same sample texture unit in fragment shader shaders/nimrod_lightshader2_bi.vert - shaders/nimrod_lightshader2_bi.fragValidation failed! - Different sampler types for same sample texture unit in fragment shader shaders/nimrod_lightshader3_bi.vert - shaders/nimrod_lightshader3_bi.fragValidation failed! - Different sampler types for same sample texture unit in fragment shader shaders/nimrod_lightshader4_bi.vert - shaders/nimrod_lightshader4_bi.fragValidation failed! - Different sampler types for same sample texture unit in fragment shader My specs are: Intel Celeron 2.26 Ghz 1.5 GB RAM GeCube Radeon X1550 (driver ver 8.530.0.0) WinXP SP2
  3. ValMan

    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. ValMan

    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. ValMan

    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. ValMan

    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.
  7. ValMan

    Ready to rock

    I was one of those people who downloaded your game to test it out (I've been reading your journal for a while so I was pleasantly surprised to hear this baby is out). The first time I downloaded it, it wouldn't run because the d3dx dll was missing. I didn't feel like downloading the DLL from Microsoft because it usually comes with a huge installer and it's impossible to find, and I didn't want to go to dllfiles because they are known to have bad versions. So I deleted the whole thing. Now I decided to re-download it, and got the DLL. It works. Well done graphics and effects as well as music. I couldn't figure out how to get out of Credits screen so I closed down the program in Task Manager, but it never crashed by itself.
  8. ValMan

    dammit

    Are you planning to continue work on Invasion: Fall of Man?
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!