|
You're rebuilding the rotation matrix from scratch, so any kind of lock would be avoided. The same input will always give the same output.
|
#
?
Mar 2, 2010 06:56
|
|
|
|
| # ? May 12, 2024 05:44 |
|
|
Fecotourist posted:If the axes are fixed, you get gimbal lock, don't you? If you want to use "flight sim" style controls and still try to stabilize towards the horizon level, then apply a bias roll to tilt the camera's side vector towards the horizon plane if the user isn't providing much or any input.
|
|
#
?
Mar 4, 2010 05:46
|
|
|
OneEightHundred posted:Yes, though ultimately you need to decide what camera system to use. The typical pitch/yaw type camera system is the one I've described, the one Strumpy's using is a "flight simulator" style system where you can roll the camera via just pitch/yaw because the yaw plane (i.e. the "horizon") will rotate as you pitch. Or more obviously, you can yaw by rolling, pitching upward, and then rolling back to level again. Yea. My controller is designed for a space game so 'horizon' is quite arbitrary. Looking at it all I'm thinking that the unwanted roll is manageable. I've played with a few other things over the past few days (GPU perlin noise for my planet shader ect it's tres awesome). I'll get back to doing game code eventually, I always get distracted with tech! quote:Track the total rotation on each axis separately and apply them to a base value instead of the current rotation. Thanks for the help OneEightHundred. I really dislike camera systems and have avoided them most of my professional career.
|
|
#
?
Mar 4, 2010 06:17
|
|
|
Strumpy posted:Yea. My controller is designed for a space game so 'horizon' is quite arbitrary. Looking at it all I'm thinking that the unwanted roll is manageable. I've played with a few other things over the past few days (GPU perlin noise for my planet shader ect it's tres awesome). I'll get back to doing game code eventually, I always get distracted with tech! quote:Won't this have issues when you do a complete 180 roll around the forward axis? Input will come out the 'wrong' way along some axis?
|
|
#
?
Mar 5, 2010 01:15
|
|
|
Okay so on a whim I want to make a top-down, realtime, action RPG in XNA. Nothing fancy at all, just have a 2D guy sprite run around, swing a sword, kill a green guy sprite who might be an orc or something I am terrible at art. So I got the movement and everything down fine, but then I realized that I have no idea what to do for attacking and such, since everything else I've programmed involved bullets and those are easy. Like, I don't even know what to do when the attack button is pressed. Does the player go through an 'attack' animation that includes the sword he is holding? If so, I do I declare that -this- part of the animation (the swordy part) will damage the monster? I assume there aren't any surefire answers for this, but does anyone have a tutorial to point me towards? drat this visual media and all its kookiness. Morpheus fucked around with this message at 04:30 on Mar 8, 2010 |
|
#
?
Mar 8, 2010 04:26
|
|
|
Morpheus posted:Does the player go through an 'attack' animation that includes the sword he is holding? If so, I do I declare that -this- part of the animation (the swordy part) will damage the monster? More or less. You'd have a keyframe which you decide is the moment the attack happens, and at that moment you'd determine which, if any, mob is under attack and deliver the damage. A lot of games fake melee attacks by firing an invisible short-range projectile, if that helps.
|
|
#
?
Mar 8, 2010 04:31
|
|
|
haveblue posted:More or less. You'd have a keyframe which you decide is the moment the attack happens, and at that moment you'd determine which, if any, mob is under attack and deliver the damage. Ah, makes sense, I was thinking something like that was the case (the keyframe). So I guess each Update, if the player/enemy is in the ATTACK state, then the class would check its animation, ask if the currentFrame = frameOfAttack, and if so, do the calculations and stuff then to see if any foes are in the attack 'area', huh? Or something like that... Excellent, surprised I didn't realize that myself.
|
|
#
?
Mar 8, 2010 04:39
|
|
|
Crossposting from the making games megathread, but if any of you have premium Creators Club membership, I have a game in playtest at the moment, would appreciate some feedback. Cheers, http://forums.xna.com/forums/p/49151/295291.aspx#295291
|
|
#
?
Mar 8, 2010 23:47
|
|
|
Da Gaspodin posted:I should probably post this here as well: The MK-ULTRA mind fighting idea is loving sick. If you pushed that idea further with a bigger project I'd pay to play that poo poo. Might come from my background as a videogamer, and my college days as an acid head...but I think Its a kick rear end idea. (side note/cross post, if anyone needs music or illustrations contact me, zach. spradlin@ gmail. com - my brother is a ridiculous musician and we both are pretty good illustrators, while my GF is a fantastic illustrator)
|
|
#
?
Mar 9, 2010 18:32
|
|
|
Does anyone have any recommendations for 2d physics with XNA? I think someone here recommended Farseer, but it doesn't seem to get updated very often. It's a shame that there is no direct implementation of Box2D 
|
|
#
?
Mar 10, 2010 18:06
|
|
|
Hanpan posted:Does anyone have any recommendations for 2d physics with XNA? I think someone here recommended Farseer, but it doesn't seem to get updated very often. It's a shame that there is no direct implementation of Box2D http://code.google.com/p/box2dx/ ?
|
|
#
?
Mar 10, 2010 22:56
|
|
|
Hanpan posted:Does anyone have any recommendations for 2d physics with XNA? I think someone here recommended Farseer, but it doesn't seem to get updated very often. It's a shame that there is no direct implementation of Box2D Yeah, farseer isn't updated often, but it is a Box2D port in progress.
|
|
#
?
Mar 11, 2010 02:30
|
|
|
XNAnimation is a real pain in the rear end.
Trevor Gottitall fucked around with this message at 02:00 on Feb 6, 2017 |
|
#
?
Mar 11, 2010 08:38
|
|
|
Scaevolus posted:http://code.google.com/p/box2dx/ ? Awesome, I'll give this a go. For basic 2D platformer physics, do you think this might be a bit overkill?
|
|
#
?
Mar 14, 2010 11:54
|
|
|
Hanpan posted:Awesome, I'll give this a go. For basic 2D platformer physics, do you think this might be a bit overkill? Not really. Box2D is simple to integrate, and scales down well (cheap for simple usage with few/simple objects and few contact points). The latter is pretty much true for all physics engines. Edit: Well, that's true for the C++ version at least, but I'll assume the same holds true for the C# version. Vinterstum fucked around with this message at 04:02 on Mar 15, 2010 |
|
#
?
Mar 15, 2010 03:59
|
|
|
Hanpan posted:Awesome, I'll give this a go. For basic 2D platformer physics, do you think this might be a bit overkill? I recently wrote a little tutorial for platformer movement using box2D on my blog. Hopefully you can get some use out of it.
|
|
#
?
Mar 15, 2010 05:09
|
|
|
I have a quick 3D question. Using OpenGL and GLUT, I've created a window with a colored sphere in the middle using the glutSolidSphere function. The function by default draws the sphere at origin, but I want to know, how do I specify that I want the sphere to be drawn at another position?
|
|
#
?
Mar 15, 2010 05:38
|
|
|
Stavros posted:I have a quick 3D question. You will want to use a transformation, in this case a translation. Use glTranslatef or something similar. Keep in mind that this modifies whichever matrix stack you have active, so you may want to wrap your calls in calls to glPushMatrix and glPopMatrix.
|
|
#
?
Mar 15, 2010 06:02
|
|
|
Dransparency posted:You will want to use a transformation, in this case a translation. Use glTranslatef or something similar. Keep in mind that this modifies whichever matrix stack you have active, so you may want to wrap your calls in calls to glPushMatrix and glPopMatrix. Ok I'll try this, thank you.
|
|
#
?
Mar 15, 2010 06:08
|
|
|
I just spent a couple hours banging out a quick diamond-square generator to build heightmaps, and I'm pleasantly surprised at how well it works. I've gone ahead and written a quick box filter to smooth out the heightmap, which is a nice touch. I've taken care of filtering out areas of all white/all black by preventing values greater than 1 or less than 0 for the height. I'd like to eventually use these terrains for a game like Tropico. Only, everything I'm reading online about XNA suggests that just building vertex/index buffers out of these heightmaps is an inefficient use of resources. (Obviously, rendering every heightmap every frame is going to chew up resources.) My thought was to break up each heightmap into smaller patches, and produce smaller LoDs for each one, then determine which LoD to render by the distance to the camera. Is this a decent way to do this for a hobby type game? Is there a better approach? I want to have an arbitrary world size some time down the line, so I'm trying to plan for managing loading and unloading groups of these patches from the hard drive so I can roll around all over Mars or something.
|
|
#
?
Mar 17, 2010 07:33
|
|
|
Pfhreak posted:My thought was to break up each heightmap into smaller patches, and produce smaller LoDs for each one, then determine which LoD to render by the distance to the camera. Is this a decent way to do this for a hobby type game? Is there a better approach? I want to have an arbitrary world size some time down the line, so I'm trying to plan for managing loading and unloading groups of these patches from the hard drive so I can roll around all over Mars or something. The only tricky part is that you have to heal the seams between low-resolution and higher-resolution blocks by drawing the low-resolution blocks first and then linearly interpolating between the low-resolution points on the edges to force the higher-resolution points on the same edge to match up. I'd be interested to see whatever solution you end up using if you don't mind posting it in this thread when you have something working.
|
|
#
?
Mar 17, 2010 17:10
|
|
|
Pfhreak posted:I just spent a couple hours banging out a quick diamond-square generator to build heightmaps, and I'm pleasantly surprised at how well it works. I've gone ahead and written a quick box filter to smooth out the heightmap, which is a nice touch. That algo's known as "geomipmapping" and is probably the most common technique for terrain in modern game engines. Wiki has an article on it. Another option is clipmapping (paper here). Most other terrain algos you'll find when googling (like ROAM) aren't used anymore because they aren't GPU-friendly. Both geomipmapping and clipmapping can use static geometry buffers and sample the heightmap texture directly in the vertex shader. Keep in mind when doing terrain that an inefficient LOD algo can actually lower your framerate on modern GPUs so you may want to benchmark against a naive implementation.
|
|
#
?
Mar 17, 2010 23:59
|
|
|
Does anyone have any experience with collision detection? I'm using GJK to determine if two objects collide and then ray tracing out of the Minkowski Difference of the two shapes to get the penetration depth and normal. I now realize that I need to get the faces that are in contact because the normal can be from either shape when I only want the contact normal from one specific shape. Does anyone have an idea on the most efficient way to do that? Redo the same ray trace except on only the shape I want?
|
|
#
?
Mar 18, 2010 01:39
|
|
|
Any of you devs maintain blogs about what you are learning? It's pretty interesting, as a hobbyist, to read about what actual devs are doing/learning.
|
|
#
?
Mar 21, 2010 19:10
|
|
|
FreakyZoid posted:Crossposting from the making games megathread, but if any of you have premium Creators Club membership, I have a game in playtest at the moment, would appreciate some feedback. Cheers, I get a server error when I try that link.
|
|
#
?
Mar 21, 2010 19:25
|
|
|
You will do now - games only stay active for about a week or so when they're in playtest. I'll have a new version up in a few days I think. Cheers for looking though,
|
|
#
?
Mar 21, 2010 19:31
|
|
|
Can anyone recommend good sources (websites/books) that deal with networking, with a focus on networking for games? And/or perhaps recommend a good c++ library for doing such things?
|
|
#
?
Mar 21, 2010 20:11
|
|
|
HicRic posted:Can anyone recommend good sources (websites/books) that deal with networking, with a focus on networking for games? And/or perhaps recommend a good c++ library for doing such things? I've used Raknet in the past with great success. It abstracts most of the networking code away, which may or may not be something you are interested in. It has a lot more than simple networking though, so it may be more than you need.
|
|
#
?
Mar 21, 2010 20:37
|
|
|
So I'm doing a top-down 2D game at the moment, and have recently started on some basic enemy AI. I've done pathfinding before, A* and whatnot, but never in a situation with a map that doesn't have a grid laid out (done pathfinding in roguelikes mostly). Would it be better to simply restrict my map to a grid (ie a chest/wall/door etc is the size of one cell), or is there a better way to do this?
|
|
#
?
Mar 21, 2010 21:38
|
|
|
Morpheus posted:So I'm doing a top-down 2D game at the moment, and have recently started on some basic enemy AI. I've done pathfinding before, A* and whatnot, but never in a situation with a map that doesn't have a grid laid out (done pathfinding in roguelikes mostly). Would it be better to simply restrict my map to a grid (ie a chest/wall/door etc is the size of one cell), or is there a better way to do this? You can do pathfinding in the same way as you have done before, but with a much higher level of granularity - the (x,y) co-ordinate system is a grid and either a pixel is traversable or it isn't, so you can just represent this in your A* implementation. The reason why you might not want to do this is that A* will start to get very expensive the more routes of investigation it has, and having it consider paths on a pixel-by-pixel basis gives it a lot of stuff to consider (depending on the size of your world) - so you might want to think about splitting your world up into a grid of chunks of pixels, and then maybe look into finding a nice heuristic to speed things up.
|
|
#
?
Mar 21, 2010 21:59
|
|
|
ping posted:You can do pathfinding in the same way as you have done before, but with a much higher level of granularity - the (x,y) co-ordinate system is a grid and either a pixel is traversable or it isn't, so you can just represent this in your A* implementation. The reason why you might not want to do this is that A* will start to get very expensive the more routes of investigation it has, and having it consider paths on a pixel-by-pixel basis gives it a lot of stuff to consider (depending on the size of your world) - so you might want to think about splitting your world up into a grid of chunks of pixels, and then maybe look into finding a nice heuristic to speed things up. Yeah I was just thinking of splitting my world into a grid of, say, 50 pixels for each cell, and then using clearance-based pathfinding to make my way around, loading in the clearance levels when the map loads. That way I can have objects whose sizes are multiples of 50 use the grid to make their way around, and since they're limited by their range of sight (or sound), I should have a somewhat-fixed distance in which to do A* to avoid high costs. Hopefully. Going to have to play with some heuristics though. I'll use Manhattan as a placeholder for now.
|
|
#
?
Mar 21, 2010 22:15
|
|
|
Depending on how your data is organized, you could use BSP to create a graph to traverse.
|
|
#
?
Mar 21, 2010 22:16
|
|
|
I always though this powerpoint on L4D AI had some interesting insights. You'd have to figure out how to build your own navmesh though.
Pfhreak fucked around with this message at 22:38 on Mar 21, 2010 |
|
#
?
Mar 21, 2010 22:36
|
|
|
Pfhreak posted:You'd have to figure out how to build your own navmesh though. That's actually exactly what BSP would help you with.
|
|
#
?
Mar 21, 2010 23:00
|
|
|
Avenging Dentist posted:That's actually exactly what BSP would help you with. Yes, yes it would. Somehow I totally missed that post.
|
|
#
?
Mar 21, 2010 23:58
|
|
|
Haven't used it myself, but Recast is a navmesh generation library that looks interesting.
|
|
#
?
Mar 22, 2010 00:21
|
|
|
I'm not entirely sure, but aren't navmeshes best used for 3D maps, where it isn't feasible to make a 'grid' layout? Or perhaps the article I read merely said that it's preferable to other options, when using 3D.
Morpheus fucked around with this message at 00:38 on Mar 22, 2010 |
|
#
?
Mar 22, 2010 00:34
|
|
|
Pfhreak posted:I've used Raknet in the past with great success. It abstracts most of the networking code away, which may or may not be something you are interested in. It has a lot more than simple networking though, so it may be more than you need. I'm interested in using a high level library and learning more about it at a low level too, really. Attack it from both sides and see what I pick up. I'll check out Raknet, cheers.
|
|
#
?
Mar 22, 2010 00:45
|
|
|
Morpheus posted:I'm not entirely sure, but aren't navmeshes best used for 3D maps, where it isn't feasible to make a 'grid' layout? Or perhaps the article I read merely said that it's preferable to other options, when using 3D. If you think about it, a grid is a navmash, just a really naive one. Each part of the mesh connects with 4 (or 8) neighbors. In a 1x1 pixel grid, this results in a LOT of space that doesn't need to be individual nodes. For example, let's say your game has nice big rectangular bridges, maybe 20x50 pixels. That's 100 pixels and 100 entries in your pathfinding algorithm. If you generate just one quad that sits on top of that bridge, it drops to 100 pixels, but only 1 entry in your pathfinding algorithm. The enemy unit is free to wander around anywhere inside that quad, because we know the entire center area is free. If a unit wants to move across the bridge, the number of nodes they have to expand is two orders of magnitude fewer. You can generate the navmesh pretty easily using BSP or a quadtree. Imagine your empty pristine world has 1 navigable quad, so all your entities are free to just cruise about. When the player drops in a structure, the bsp/quadtree adjusts whatever the smallest subtree they have is to accommodate the change. Now, all that being said, I've never actually built anything like that, so I can't point you to good how-to type resources.
|
|
#
?
Mar 22, 2010 01:34
|
|
|
|
| # ? May 12, 2024 05:44 |
|
|
For a 2D topdown game with irregular geometry I would use a quadtree instead of a grid. The world's still divided up into squares, but only to the extent that's needed to accurately represent the collision geometry. So you can get pixel accuracy where needed without needing to store a pixel-level grid for the entire world. It's also easy to dynamically add and remove geometry. There's no reason to use a navmesh for a 2D game. The only reason for using one is to allow layered geometry in levels (rooms on top of other rooms, bridges, etc.) and it is significantly more complex, which is one reason most early 3D games simply didn't allow layered geometry.
|
|
#
?
Mar 22, 2010 03:05
|
|