Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

  • Days Won


JoeJ last won the day on October 8

JoeJ had the most liked content!

Community Reputation

3128 Excellent


About JoeJ

  • Rank

Personal Information

  • Role
  • Interests

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. JoeJ

    Fractals in games

    Reminds me about kkrieger - all procedural, entire game in 96 kb:
  2. JoeJ

    Github and Viruses

    Yeah, people mostly avoid uploading executables or dlls. So no virueses, but a lot of fun to build all those dependencies yourself.
  3. This. Still no feedback - ist your jump working now or not? And... well, you have a hard time learning programming, but you don't give up. Because you really want to create the game of your dreams. Fine. And now you ask others what to add to this game?
  4. Here is Prototypes solution (page 2): Here is mine (page 3 - not using GLUT but easy for you to do so): Both should work, but it was you who gave no feedback on this. Did you try? Did it work? (I had to zoom out a lot to see the jump working - you may need to tweak velocity and gravity until it behaves like you want.)
  5. Ther is some option in Visual Studio, and enabling it lists how inclusion dependencies are resolved, so while compiling it prints all header files in order, and from that you can see unnecessary cycles or something. Helps to fix it. I think it's this option: A helpful work around is to make certain files compile faster by using debug build, even if release build is selected. snippet from @Hodgman #if defined _MSC_VER #define MAKE_DEBUGGABLE __pragma(optimize("", off)) #elif defined __clang__ #define MAKE_DEBUGGABLE _Pragma ("clang optimize off") #else #define MAKE_DEBUGGABLE #endif With this included, just add MAKE_DEBUGGABLE on top of your slowly compiling files (before or after the includes matters ofc.) Very helpful also in case debug builds run too slow to be useful.
  6. ---- Proposal: Please do Pong or Pacman first. Here physics are very simple, and it sould be much easier to figure out what problems are caused by logic / math bugs on your side, or unecpected timing issues coming from GLUT. It seems actually there is too much uncertainty to progress and learn. With Pong working, you can come back to the jump'n'run game and continue.
  7. ... yeah Phil, although two people posted two working solutions you would only need to copy (IIRC Prototype and me), you 'fall back' to using an anlytical closed form approach to calculate jump trajectory. As said earlier, such approach will fail if other objects collide with the player while jumping for example, because the closed form math has no konwledge of the changes caused by such unexpected events. Believe me, closed form is a dead end here. Closed form analytics are good to do things like predicting where the jumping player will land most likely, or to calculate launch angle for a catapult to hit a target. Any kind of control problems. But not here. For game physics simulation you want to use integration as you did before already. It deals with collisions, moving platforms, unecpected events etc. in a simple, doable way. (The reason your character jumps only once seems you do not set time to zero when starting the next jump. The closed form formula assumes zero as the starting time of the jump.)
  8. JoeJ

    3D smooth voxel terrain LOD on GPU

    Yeah thanks, this is what i have expected (also with edges as shown in the paper). Notice Half-Edge will not work easily for this, because usually a vertex points only to a single polygon.
  9. JoeJ

    3D smooth voxel terrain LOD on GPU

    Do you guys know any resources on how such non-manifold cases look like, or how they can be fixed? I have just tried it (https://github.com/mikolalysenko/mikolalysenko.github.com/blob/master/Isosurface/js/surfacenets.js), and i like the resulting quads will cause less sharp angled triangles than marching cubes. I need this so solvers behave well. But manifold is more important, although things like self intersections would be ok.
  10. JoeJ

    3D smooth voxel terrain LOD on GPU

    Yes, but depends on what physics you need. If it's just enemies / vehicles but no box stacks, LOD could work. Also you could replace physics simulation with procedural animation at the distance.
  11. Haha, yeah... maybe i should try this - never did Sounds your game is top down / 2D. I remember nice tutorials about visibility by clipping, for both AI but also to cast shadows. So maybe shadows could be a useful search term as well.
  12. JoeJ

    3D smooth voxel terrain LOD on GPU

    Probably a missunderstanding on my side - because you metioned LOD i assumed you want more details near the player and less at the distance. So if the player would move around, the terrain would change and a resting stack of boxes could fall over for example. I did not mean the transition issues like gaps and discontinuities that often arise in LOD terrain approaches. A compromise might be to only detect contacts on GPU and send them to PhysX used by Unity, but that's still difficult and likely messes with contact caching the engine uses internally. So i would stick at your idea to download geometry. (Be sure to observe performance cost of submitting new gemetry to physics - usually this involves building an acceleration structure if it's not just a height map, so another reason to use low poly meshes.) I rough idea of mine - not sure if this ever has been used for games. I talked about it recently in a PM, copy paste: So the idea is, if you have a maze, put water to the target until it flows out at the source, and then just follow the path where height of water increases the most.
  13. Yes, but do not confuse colors and normals. The color gradient is a result of interpolated normals and using them for shading to get the color. (So dpending on shading, there may be other unknown factors that affect colors and how smooth they change over the surface) Finally it's also worth to know that even if normals form a nice gradient over a single triangle, the gradient (or slope, or derivative) itself is not continuous accross edges. Se even with interpolation and per pixel shading the tessellation can become visible unfortunately (would be too expensive to fix).
  14. Most triangle meshes are a discrete approximation of a continuous, curved surface, so interpolated normals are just a visual trick to make them appear smooth and curvy again.
  15. JoeJ

    3D smooth voxel terrain LOD on GPU

    While reading this, i noticed it's a similar approach to the method from @spacerat from my first post. Which made me aware of this: IIRC, Spacerat used indexed meshes, and eventually this also leads to a simpler edge collapse function. (You should look up his code to compare) The thing is, researchers working on geometry processing will just use Half-Edge for everything because it can do everything and they have thier frameworks. (I think Leif Kobbelt also worked on https://www.openmesh.org/ which is a Half-Edge library) I don't think Half-Edge is necessarily the best chioce for simplification in a game. (Although physics engines use it too for collision detection... really not sure)
  • 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!