Jump to content
  • Advertisement

MarkK.

GDNet+
  • Content Count

    570
  • Joined

  • Last visited

  • Days Won

    3

MarkK. last won the day on May 4

MarkK. had the most liked content!

Community Reputation

2499 Excellent

7 Followers

About MarkK.

  • Rank
    Advanced Member

Personal Information

Social

  • Twitter
    goliathForge
  • Github
    MarkKughler

Recent Profile Visitors

16387 profile views
  1. MarkK.

    Boom

  2. That's the way this goes... I think you should have a circle(sprite?) that bounces off the left and right edges of the screen and what you define as ground. After that, wire together a relationship between your sprite character and the circle thing. You know, throw a little Pong at it... it could be a side quest. PongRPG..could be a thing.
  3. You can tell the difference between the 'engine programmers' and 'game programmers'

  4. That was my take away from the GDC16 talk as well. Jump with predefined start and end location. I tried this out on the gd.net side scrolling game challenge. The idea is interesting but harder to work with than an impulse/gravity technique. The advantages in my eyes were improved prediction and a guarantee of an ending position somewhere precisely. Neat.
  5. This [gamedev.se] discussion touches on that and an access optimization. I'm making assumptions in monogame. SharpDx I've not touched.
  6. I'm not saying the previously mentioned is your problem, but clearly you are missing the suggestion that the keyword -Texture in the sampler_state block will probably not be valid in shader model 4 as you define in your technique pass. reference: https://docs.microsoft.com/en-us/windows/win32/direct3dhlsl/dx-graphics-hlsl-to-sample If the api you are using is d3d9, try vs_4_0_level_9_1 perhaps. This is what my declaration looks like (monogame) texture ModelTexture; sampler2D TextureSampler = sampler_state { Texture = (ModelTexture); MagFilter = Linear; MinFilter = Linear; AddressU = Clamp; AddressV = Clamp; };
  7. That is what I'm looking at as well. This doc.microsoft talks about shader model changes. sampler_state{Texture= is a d3d9 keyword only. Surely not sm4.0 is a similar discussion I believe.
  8. My apologies for the double post, but I have just had to go through this with a Collada importer. There are similar aspects with .obj in that separate indices lists into vertex attributes are involved. What I did was rebuild my indices based on if a position/uv pair exists. If not, I add this by duplicating the position and pairing with the new texcoord. I ignore normals and simply rebuild them which is a separate op. class IndexedModel { public: std::vector<glm::vec3> positions; std::vector<glm::vec2> texCoords; std::vector<glm::vec3> normals; std::vector<unsigned int> indices; void CalcNormals(); }; /* glm::ivec3 DAEModel::indices DAEModel::indices.x = position indices DAEModel::indices.y = normal indices DAEModel::indices.z = texcoord indices */ IndexedModel DAEModel::ToIndexedModel() { IndexedModel im; // hardware format container // track found position-uv pairs from indices std::vector<std::pair<int, int>> vuv; for (auto ind = indices.begin(); ind != indices.end(); ind++) { int i = 0; bool found = false; for(auto ip : vuv) { // comparing index (int) pairs instead of vec(float, float, float) values if ((ip.first == ind->x) && (ip.second == ind->z)) { im.indices.push_back(i); // reuse this index found = true; break; } i++; } if(!found) { // make new (position-uv) and index it. vuv.push_back(std::make_pair(ind->x, ind->z)); im.indices.push_back(i); im.positions.push_back(vertices[ind->x]); im.texCoords.push_back(uvs[ind->z] * glm::vec2(1.f, -1.f)); } } // flip winding order for (int i = 0; i < im.indices.size(); i += 3) { int temp = im.indices[i]; im.indices[i] = im.indices[i+2]; im.indices[i+2] = temp; } // recalculate normals im.normals.resize(im.positions.size()); im.CalcNormals(); return im; }
  9. Agreed. This feels much better, with the start of logical groupings. Emphasis could be put back on managing state as @Prototype suggests with the onGround variable. One design here would be a controller(manager) for your objects that makes per frame pre-defined checks. Another design would be the object adjusts state based on it's own data (closer to what you seem to be trying to do). As your game systems mature, it becomes a mix. Although I understand that, case in point is currently a logic error, I though it might be positive to lean the discussion to overall design first instead of our pattern of one little piece missing. I also like that @phil67rpg is trying to make better descriptions. During your posts, spend some more time on expressing your things as @Rutin suggests. A lot more words. Don't worry if what you write is wrong. I think that would do two things. One, you may answer your own question in the process of trying to describe it completely (at which point the programmer in you can bloom) or the other, where we'll see where you are failing quicker. With that said, the glut thing...I can understand the draw to this being also from the era. A few great frameworks (like the old F. Luna stuff) used it and probably survived time to be picked up again and again. I didn't because I was anti-everything back then but have tried more than a handful of the options. GLFW I liked, but I timed it against a raw OGL startup and doing input handling with the same ~80,000 vertices or so test (hmp...something) and it was measurably working harder (~15-20+%) somewhere in GLFW. Easy to get up and going with. SFML was okay, I'm not sure I gave it a fair chance. Currently I'm using SDL which is interesting if you like gluing together libraries as I do. Those are my C++ choices. For C#, I reach for monogame or Unity for fun. GoDot is the next on my list but runs funny on my (much) older system, so that fun is waiting for an upgrade. edit;p I thought I might add one last thing...perhaps you might consider tracking your distance off the ground and doing a hard reaction/reset crossing zero..that might be interesting info. Also when i jump, all I do is give my object thing an impulse. (in whatever direction) fire it. forget it. All my dynamic objects, all the time, have a downward attraction. The fight then becomes when you are on the ground (falling through or wiggle with extreme purpose or better yet, do nothing at all) Then again...a dozen more approaches are valid. if (button == GLUT_LEFT_BUTTON && state == GLUT_DOWN && key_jump == false && onGround == true) // <-- and allow this state { // fire the jump impulse action here and forget it key_jump = true; }
  10. Go back to page one and two of this thread and review the suggestions on processing your .obj data to align with the format the renderer expects. (.obj format stores separate attribute indices lists, while the renderer wants a single indices list) For example again, uv seams with adjacent connected faces will require generating duplicate vertices if attributes for that position are not similar within a tolerance. (float comparisons)
  11. tldr; How do you add UV or normal indices to the IBO? You don't. All attribute arrays must have the same ordering. nice. very good. I suspect what has changed is, using only index 0, 3 and 6 per face input. I would suggest to go back to this statement from @bioglaze. What needs to happen now is to rebuild the vert/(uv)/normal arrays and indices. Currently, from these lists, there is not an association with each other. Meaning the vertex at slot n does not automatically mean the uv at slot n are related. Same with the normal list at slot n does not automatically mean it's associated with the vertex at slot n. After load, you need to rebuild the lists per face making a "close enough" comparison from the face list. The problem is a uv seam will force duplicate vertices that may not be in the .obj file lists but is required because the rendering api expects only one list of indices. Vertices with the same exact position, but uv or normal may be different. This explains what @bioglaze is suggesting when mentioning the lists are of same length after processing. Another way to look at it would be, rearrange the lists so that a single index list can be used that correctly points into all array lists.
  12. MarkK.

    Project - NubDevice

  13. MarkK.

    NubDevice

    Nub does not mean noob. If you are using 'nub' to mean this, sorry, that is considered umm....wrong. At the Hanger. We're doing this.
  14. MarkK.

    Just another space shooter

    NVidia GeForce 260M
  15. MarkK.

    jump code

    do you? are you sure? what if your object (that isn't grounded to something) have a constant gravity concept applied all the time? what would the next problem be? Fighting with the jump action. People try more power and move into a vector space instead of pixel space. Quick to get to an apex, slower to pick up speed on the way back down...those types of things. But if we must, state is a bool. It can either be on or not. you don't need the second conditional if you are managing state with some common sense.
  • 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!