Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

8 Neutral

About midn

  • Rank

Personal Information

  • Interests

Recent Profile Visitors

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

  1. midn

    [GLM] Mouse click to create ray.

    It's GLM's documentation that's misleading. The program now works without issues.
  2. midn

    [GLM] Mouse click to create ray.

    Fixed the issue. And, as ALWAYS it's the stupidest issues you can't even imagine. Check the unProject documentation: The second argument? That's the modelview matrix, not just the view matrix! So I just ended up passing the inverse of the view matrix there, and it works fantastically now.
  3. midn

    [GLM] Mouse click to create ray.

    The Y translation making it incorrect? That was a non-issue, I was inverting the mouse's Y coordinate twice, durr. But rotation in the view matrix is still making it incorrect, said rotation (on any axis) also seems to be exaggerated, as if it's scaled up.
  4. midn

    [GLM] Mouse click to create ray.

    As I said, I can guarantee the mouse position is correct, that's not the issue. I apparently have passed a few wrong arguments to glm::unProject, here is the updated code: glm::vec3 direction = glm::unProject(glm::vec3{ev.cursor.x, 480 - ev.cursor.y, 1}, glm::mat4{1}, game::camera->projection * game::camera->transform, glm::vec4{0, 480, 640, -480}); direction = glm::normalize(direction - glm::vec3{game::camera->transform[3]}); And now it works for almost all cases. It starts to break if there's any Y translation, or any rotation at all, or if I perform glm::translate and glm::rotate in the wrong order. Those values seem to be always exaggerated too much for seemingly no reason.
  5. midn

    [GLM] Mouse click to create ray.

    I tried using glm::unProject instead, but issues still exist: glm::vec3 direction = glm::normalize(glm::unProject(glm::vec3{ev.cursor.x * 2 / 640.f - 1, 1 - ev.cursor.y * 2 / 480.f, 1}, game::camera->transform, game::camera->projection, glm::vec4{0, 0, 640, 480}));
  6. What am I doing wrong when trying to calculate a ray from the camera? glm::vec4 mouseClip = {ev.cursor.x * 2 / 640.f - 1, 1 - ev.cursor.y * 2 / 480.f, 0, 1}; glm::mat4 inv = glm::inverse(game::camera->projection * game::camera->transform); glm::vec4 p = inv * mouseClip; p.x /= p.w; p.y /= p.w; p.z /= p.w; glm::vec3 direction = glm::normalize(glm::vec3{p}); I can guarantee that mouseClip's x and y is correct (from [-1, -1] to [1, 1]). glm::vec3 intPos, intNor; if(glm::intersectRaySphere(glm::vec3{game::camera->transform[3]}, direction, glm::vec3{0, 0, 0}, 1, intPos, intNor)) { printf("intersect\n"); } intersectRaySphere does as it says, here is it's documentation. Problem is that.. well.. basically everything is off. There is nothing I can accurately describe, it seems as if the camera's transformation is always exaggerated. I know this is all very vague, please ask questions if you have any.
  7. I am already using ticks, that's what I meant by fixed timestep. I seemed to have a brainderp, though, didn't think to use it for the animation system. I'll message back if I have even more problems.
  8. There is no waiting system in the engine, and said waiting system could have the exact same problems.
  9. This is the first game of mine where animations were strongly linked to the game logic (not code-wise, I meant it's as hints to the player), and I have realized that I've been doing animations wrong this whole time, for my code before was (in pseudo-pseudo-code): Rect Animation::update(float delta) { if(playing) { frame = fmodf(frames + frame + delta * fps, frames); } return /* calculate sprite in spritesheet with `frame`. */; } Now, some would probably immediately realize that `delta` here is imprecise. At, say, a framerate of 60fps, delta would equal `0.016667`. In one real second that would all add up to `1.00002`, not `1`! I thought about calculating the frame number with something more stable, such as `SDL_GetTicks()` in SDL2, but doing it this way makes pausing the animation more difficult (Unless I'm wrong here, which I hope in this case). Another question, since animations are important for gameplay, and thus they must be synchronized, I thought about setting animation delta to the game timestep (1 / 60 in this case), would that be a good idea or would that be noticeable?
  10. I'm doing it like it was done for Donkey Kong: Country, which is why there's a palette.
  11. Since I'm not a good 2D artist (learning sloowly with low motivation but that's a different topic) here's what the current art process is: Model a thing in Blender. Render it in a low resolution. Using ImageMagick apply a color palette. The palette is I think the SNES palette that I took from Wikipedia and cropped a little bit. There's a problem though, below is a screenshot of the game. Excuse the size :P. It's extremely dark, I can't say if it can be passed off as just a "style" but it's even a bit hard on my eyes. And see the background, the black with green spots? That's supposed to be tall grass, but the palette reduces detail until it just looks like overly peppered lettuce. The white rectangles will be ladder sprites, it's unfinished at the moment.
  12. If you're comfortable with only supporting Theora files, you could try out TheoraPlay which is a simple wrapper around libtheora and libvorbis. I can give you the class I wrote to further simplify the player. On another note, I hope GL4 is not your minimum..
  13. midn

    Game initialization.

    Using static variables doesn't imply that they must have a lifetime longer than main.
  14. midn

    Game engine for a 10 years old

    Definitely something with a larger focus on programming. The age here isn't the problem, making games with things like Scratch wouldn't teach a 30-year old on how they work. Game Maker I'd recommend a lot, it's programming language, while horribly designed, is great as a first language. Although, I'd also recommend starting programming from scratch completely, and to forget gamedev for now. You could try teaching Lua, then move on to Love2D. After that you can make the leap to C and then onto C++.
  15. midn

    looking for 3D rendering middleware

    99% that this issue was fixed in 2017. And it may not be updated, but there isn't a reason to as it works fine, and it is still maintained, support still exists.
  • 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!