Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

5 Neutral

About midn

  • Rank

Personal Information

  • Interests
  1. 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++.
  2. 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.
  3. I mean.. it works, but the entire game in general is extremely buggy. I don't even know what is causing this. This thread's issue is solved, though, so thanks!
  4. midn

    looking for 3D rendering middleware

    How did Horde3D not compile? I use it for most of my 3D projects and it works perfectly, it's a quick "cmake ./" followed by "sudo make install". One tiny thing I did not like about it was that it places it's shared libraries in /usr/local/lib, where G++ does not usually look for, I had to copy paste it myself to /usr/lib.
  5. Quick question that I didn't think of: How would I know which edge was hit?
  6. I'd be doing that probably at most around ~30 times per frame, so I don't think I'd need to optimize it further. Thank you, I'll test it when I have the time! I don't actually need the smaller angle, I need one of the angles to calculate the direction in which the ray will bounce (according to physical laws), so any angle's fine (if I'm on the right track).
  7. I can't explain it in words, because I don't know the terminology, but I have drawn a gimp diagram where the black rectangles are AABBs and red lines are rays.
  8. I have modified the HitBoundingBox algorithm that can be found on some sources (link) to suit my structs and API: Point rayaabbintersection(Point minB, Point maxB, Point origin, Point dir) { char inside = TRUE; char quadrant[2]; register int i; int whichPlane; double maxT[2]; double candidatePlane[2]; /* Find candidate planes; this loop can be avoided if rays cast all from the eye(assume perpsective view) */ for (i=0; i<2; i++) if(origin.arr[i] < minB.arr[i]) { quadrant[i] = LEFT; candidatePlane[i] = minB.arr[i]; inside = FALSE; }else if (origin.arr[i] > maxB.arr[i]) { quadrant[i] = RIGHT; candidatePlane[i] = maxB.arr[i]; inside = FALSE; }else { quadrant[i] = MIDDLE; } /* Ray origin inside bounding box */ if(inside) { return origin; } /* Calculate T distances to candidate planes */ for (i = 0; i < 2; i++) if (quadrant[i] != MIDDLE && dir.arr[i] !=0.) maxT[i] = (candidatePlane[i] - origin.arr[i]) / dir.arr[i]; else maxT[i] = -1.; /* Get largest of the maxT's for final choice of intersection */ whichPlane = 0; for (i = 1; i < 2; i++) if (maxT[whichPlane] < maxT[i]) whichPlane = i; float coord[2]; /* Check final candidate actually inside box */ if (maxT[whichPlane] < 0.) return (Point) {.x = NAN, .y = NAN}; for (i = 0; i < 2; i++) if (whichPlane != i) { coord[i] = origin.arr[i] + maxT[whichPlane] * dir.arr[i]; if (coord[i] < minB.arr[i] || coord[i] > maxB.arr[i]) return (Point) {.x = NAN, .y = NAN}; } else { coord[i] = candidatePlane[i]; } return (Point) {.x = coord[0], .y = coord[1]}; /* ray hits box */ } Excuse the bad code, it's a copy paste of the original with a few changes :P. The reason for all those iterations over i is because the original was designed allow technically any amount of dimensions. Anyway, I'm terribly bad at geometry, does anyone know how I can get the angle of the intersection?
  9. This will be a 2D, sandbox, story-based game with 3D rendered graphics (like that of Donkey Kong: Country or Platypus). Here's a reference picture: The game has a very cartoon art style (again, like Platypus, search it for a rough example of what the style would be, pretty much clay, except Platypus were made from real photographs), most of the details are completely unnecessary, for example all of those "tubes" are unneeded, I have no idea what the suit is holding in that stock picture but that's also unnecessary. Honestly all I need is the suit, gloves, and helmet, and maybe the belt. Contact me (via PMs) if you want a GIF of the gameplay, but don't expect good graphics, for obvious reasons . If interested, you can do all of the models, but this is only the one I really need, preferably in Blender, or at least in a common file format so that I can it rig afterwards. Expect absolutely no pay, as this is a completely free game.
  10. Because the screenshot actually uses an atlas that is almost identical to the one I'm showing in the above post. The only difference is the A, but both had the same issue. Also, can you elaborate on your suggestion? I'm not getting it.
  11. I have a texture atlas with two blocks: And I want to use this texture for my blocks. I don't want each block to use the entire texture, just a part of it, to make the world look bigger, which is why I would've used something like this for the vertex shader: v_uv = a_position; Unfortunately since this isn't a single texture, but an atlas, I had to improvise: v_uv = vec2(0.5 * a_blocktype + mod(a_position.x, 0.5), -a_position.y * 0.5); And this kinda works, except that it causes this bleeding: (notice how there's these spots next to each A. The same problem exists for the other block type). I then tried adding space between the tiles in the atlas, except now there are just black lines.
  12. Yes, that was it, thanks!
  13. Simple problem compared to what is usually posted around here, but I'm trying to draw a rotated textured rectangle in my sprite batch: if(sprt->tex != tex) { flush(); sprt->tex = tex; } glm::vec2 oldHsize = hsize; hsize.x = oldHsize.x * cos(angle) - oldHsize.y * sin(angle); hsize.y = oldHsize.x * sin(angle) + oldHsize.y * cos(angle); data.push_back({{pos.x - hsize.x, pos.y - hsize.y}, {0, 1}}); data.push_back({{pos.x + hsize.x, pos.y - hsize.y}, {1, 1}}); data.push_back({{pos.x - hsize.x, pos.y + hsize.y}, {0, 0}}); data.push_back({{pos.x + hsize.x, pos.y - hsize.y}, {1, 1}}); data.push_back({{pos.x - hsize.x, pos.y + hsize.y}, {0, 0}}); data.push_back({{pos.x + hsize.x, pos.y + hsize.y}, {1, 0}}); } hsize is half the size of the sprite being drawn. But it seems to draw it completely incorrectly. If I slowly increase the value of angle, here's what it looks like (in the attachments). 2019-01-01_18-07-35.mp4
  • 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!