Jump to content
  • Advertisement

gzboli

Member
  • Content Count

    44
  • Joined

  • Last visited

Community Reputation

122 Neutral

About gzboli

  • Rank
    Member
  1. I think the velocity adjustment is reasonable (should move the circle perpendicular to the other?). Do you have any other code that separates the circles before the next update? An important step in collision resolution is to remove the intersection by backing up one or both objects until they are no longer colliding. This, along with the re-calculated velocity, should prevent the circles from sliding on each other. You also mentioned this is for steering behavior. Playing around with the circle radii could be helpful. Imagine you have a 5m radius circle but you do a steering-collision-check using a 8m radius... The circle will steer away 3m in advance.
  2. gzboli

    Raw Input and Key Combinations

    Quote:The last key-down event is reported continuously, until it is released. Key-release events from keys other than the last-key-pressed are sent once while the last-key-pressed remains down. I haven't used the rawinput api but it sounds like you are guaranteed (per key) at least one keydown message and exactly one release message. As oler1s said, to get the functionality you want you'll need to keep track of which keys are pressed. To reiterate: you shouldn't be using the MsgProc to directly move the camera because you are only given the last key pressed. Just record when keys are pressed and when they are released. Somewhere else in your main loop you can apply the key state to the camera. Tracking key states gives you information about all keys whereas depending on the current rawinput poll only gives you information about one key.
  3. gzboli

    Raw Input and Key Combinations

    A simple way to approach this is to give the camera a vector which can represent multiple key inputs. Something like: Camera::Move(Vector2 v); Then in your input code you can accumulate different buttons being pressed into a vector. For example if 'W' and 'A' are pressed your vector would be Vector2(-g_Camera_Movement_Speed, g_Camera_Movement_Speed) which will move the camera forward and to the left. In your 'if' statements, instead of directly moving the camera you would adjust the vector. ex, 'A' again: camVec.x -= g_Camera_Movement_Speed; At some point in your main loop you would call Camera::Move using camVec. There are other considerations based on how often you receive input messages and whether or not there are KEYDOWN/KEYUP pairs.
  4. You have a typo where an 'x' should be a 'y'. Also, to have this line animate you will need to draw each iteration over multiple frames... Unless OnDraw is doing something magical I don't know about.
  5. I'm not a collada expert, but... Quote:Original post by NumberXaero is the skin info unique to this specific animation data, or is it unique to the model data? ... So does that mean for every animation you will have unique skin data (bind pose matrix, weights, inv bind matrix), animation data and a pre transformed mesh copy My understanding is that the skin info represents the time when the vertices are bound to the skeleton. The skin data will appear to be unique to the model if neither the mesh is reskinned, nor the bind pose is altered for different animations. I think the BSM moves the vertices from world space to object space. The invBind matrices are then defined in that space (bringing a vertex from object space into the joint's space). If the model has multiple skin groups (materials, etc) then the BSM is likely different for each group even if they are bound to the same skeleton. I used the (BSM * v) exclusively for animated models. Which it sounds like you are already doing? Good luck, collada threw me some curveballs when I used it.
  6. gzboli

    Invalid call with D3DXCreateMesh

    I think you are running into a problem with this (from the docs): "pDeclaration : This parameter must map directly to a flexible vertex format (FVF)." I haven't used a FVF in a long while. IIRC, a FVF can only have one stream and the vertex data has to be arranged in a specific order. You should look into turning on the D3D Debug runtimes and see what the output window complains about. I'm fairly certain about the one stream though, since an ID3DXMesh only handles one vertex buffer.
  7. d3dx9.h I think you also need to link with d3dx9.lib (release) or d3dx9d.lib (debug).
  8. gzboli

    Welding Algorithm

    How about using some simple sorts? - sort on X axis - find sublists of vertices with the same X-value - sort each sublist on Y axis - find sublists of vertices from the X-sublists with the same Y-value - sort each sub-sublist on Z axis Each time the sublists are generated you are closing in on the duplicate vertices. Each consecutive sort should take significantly less time than the first as the sublists will be a tiny fraction of the number of verts.
  9. gzboli

    Meshes that need to change shape

    Quote:Original post by BattleMetalChris I know that it's expensive to create or change vertex buffers Changing a dynamic vertex buffer isn't too slow, especially with the proper locking method (discard is fast). If it does become a bottleneck there are remedies like double buffering the VB. If you used DrawPrimitiveUP, it probably wouldn't be your bottleneck :)
  10. From what I can tell, the while loop is to move down the current[1] puyo... But it fails in the case where the double-puyo is vertical because the current[0] has not yet been placed in the puyolist so current[1] falls through current[0]. The checks need to occur such that you check the lower puyo's collision first and place it in the list then do the other puyo. The lower puyo could be either current[0] OR current[1]. I think the way I would address it is: (1) Select the lowest puyo, handle and place it. (2) Select the other puyo, handle and place it. (3) Make some functions to make the code more legible and reusable. Something like: //implemented elsewhere bool CanMoveDown(Puyo& p); void MoveDown(Puyo& p); void PlaceInPuyoList(Puyo& p); ... //Select the lower puyo into puyoA, the other into puyoB. int index = (current[0].y < current[1].y)? 0 : 1; Puyo& puyoA = current[index]; Puyo& puyoB = current[(index + 1) % 2]; while(CanMoveDown(puyoA)) MoveDown(puyoA); PlaceInPuyoList(puyoA); while(CanMoveDown(puyoB)) MoveDown(puyoB); PlaceInPuyoList(puyoB);
  11. Quote:what might be causing this? The doodads are writing to the Z Buffer, and the player is then being culled in the Z Test. The reason the player is culled and not the doodads is because the player is drawn after the doodads, I presume. If you switch the rendering order you should see the doodads being clipped. Quote:how I can fix it? The simplest way is to sort and draw all billboards from back to front. I would also suggest disabling Z testing if all of your objects are 2D, which will avoid doodads at the same Z depth from culling each other. GraphicsDevice->SetRenderState(D3DRS_ZENABLE, D3DZB_FALSE);
  12. Ultimately you want the player input response to be quick, which will mean cutting a run cycle short. Interpolation is a quick fix for a lot of problems, and a good fit if it's your first go at skeletal animation.
  13. I have always done keyframes per skeleton, for no particular reason. The per joint method appears to save on memory. However, it may increase polling time as the list of frames has to be searched... Unless you can provide hints like a frame to start searching at. I think if you want to do more interesting coding and experiment a little, go with the per joint. If you want to just get it implemented and work on other things, go for per skeleton.
  14. gzboli

    trail implement

    Quote:but it is not smooth when sword changing position quickly. To address this specifically... If a sword swing takes 1/2 of a second and the game is running at 30 fps then that swing only lasts 15 frames. If you are generating only one new point per frame for the trail then it may look jagged. Have you tried you taking multiple, interpolated samples each frame?
  15. Quote: This brings me one think..The GetBackBuffer returns the pointer to the backbuffer right? I mean, its not a COPY of the backbuffer( since you use it on UpdateSurface to present a scene )...so should I release it ? Right, GetBackBuffer increments the reference count on the backbuffer surface and returns you a pointer to the surface. You should call release on it when you are finished with it (likely at app closing). The Release method on all D3D objects decrements the reference count, and when the count is zero D3D will free the memory. This applies to many D3D objects. For example if you have a texture and use GetSurfaceLevel, you will need to call Release on that surface pointer, though the actual surface won't be destroyed via that call (it is still part of the texture).
  • Advertisement
×

Important Information

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

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!