• Advertisement


  • Content count

  • Joined

  • Last visited

Community Reputation

2095 Excellent

About jyk

  • Rank

Personal Information

  • Interests
  1. It's probably the forward vector you want to negate, rather than the target point. If you're using a 'look at' function that takes a position and a target point, you should be able to compute the adjusted target point as follows (pseudocode): [code]vector3 forward = target - position; vector3 adjusted_target = position - forward;[/code]
  2. Stack Overflow? (Operator Overloading)

    [quote name='coderWalker' timestamp='1308334641' post='4824547'] again using just a plain char* because I cannot afford any overhead.[/quote] The only way I can see use of std::vector adding any overhead would be if, for some reason, accessing the vector data via the [] operator were slower than accessing a raw array. However, I wouldn't assume that would be the case; if you have your optimization settings set appropriately (including the relevant preprocessor definitions if you're using MSVC), I would expect vector::operator[]() to be plenty fast. (But, you can always profile to find out for sure.) On the other hand, *not* using an RAII container can add a fair amount of development overhead in terms of coding, testing, debugging, and maintenance. (For example, you now have to worry about the 'rule of three', exception safety, and so on.) Note that I'm not advocating for any particular approach here; I'm just suggesting that making assumptions when it comes to performance and optimization can sometimes result in doing extra work for little or no gain.
  3. Questions about Blender Game Engine

    [quote name='daedalus316' timestamp='1308337186' post='4824563'] i would try mocking it up but i would think that it would require scripting experience which i still need to gain.[/quote] Sure, it'll most likely require programming regardless of which engine you use. But, if you already have some experience with Python (which was the impression I got from your earlier post), that should give you a good head start irrespective of which language or engine you use. (And, you can always learn as you go, of course.)
  4. Questions about Blender Game Engine

    [quote name='daedalus316' timestamp='1308333638' post='4824542'] Ok... does anyone know any good scripting tutorials for BGE or Unity so i can get to know thier full power.[/quote] I don't have any particular suggestions for BGE, but a search for 'bge tutorial' turns up some promising-looking links. For Unity, try searching the forums over there for 'javascript tutorial, 'unityscript tutorial', and even just 'tutorial', and you should find links to the resources that are most often suggested to beginning users. [quote]Also, jyk, if you could really make a mock- up it would be frickin' AWESOME! [/quote] Well, by "I'd just try mocking up the basics of your game", I just meant, "If I were you, I'd just try mocking up the basics of your game" :) Anyway, the point is that a little experimentation will probably answer most of your questions fairly quickly.
  5. Box2d object x y location

    [quote name='bluwind' timestamp='1308291174' post='4824364'] That would be the top left buddy[/quote] I don't believe that's correct - what leads you to believe the position of a body corresponds to the top left? Generally, there will be two things associated with a body: a shape (or shapes), and a visual representation. It's common for these to match (roughly, at least), but they don't have to. Regarding the shape, IIRC, there are a few options available, such as circles and convex polygons. Generally, the position will correspond to the center of the shape (more or less), although you could probably create an 'off-center' polygon where the position corresponded to some other point. Regarding the visual, you can position the visual wherever you want with respect to the position of the body. Typically though, the positioning of the visual will roughly match that of the shape or shapes associated with the body.
  6. Questions about Blender Game Engine

    [quote name='daedalus316' timestamp='1308318799' post='4824455'] my main issue with the Unity navigation was that it was hard to move things around and get them to come together. it took me a long time to move the camera to view my scene and in the end i ended up just copying one objects location and pasting that into the camera and then modifying the location.[/quote] Whatever problems you ran into, I'm sure they could be worked out. Just as an example, if you select an object in the hierarchy, then move the mouse over the scene view and press 'F', the camera will automatically focus on the selected object (this is one way to quickly bring the scene into focus if for some reason the camera has gotten moved out of position.) Anyway, I think if you spent a little more time with it you'd find that scene navigation in Unity is fairly straightforward. But, since you like the Blender interface and you like Python (Unity supports Boo, but it's not quite the same language), I'd maybe just try mocking up the basics of your game in BGE and see how it goes. Both Unity (the free version) and Blender are free, of course, so there's nothing stopping you from trying both and seeing which one will be more suitable for what you want to do. Sorry I can't comment on BGE more directly, but I've only used it a little. Maybe someone who's used it more extensively will be able to provide a more in-depth answer to your question. [Edit: See above:)]
  7. Lag Issues with Current Engine

    I don't have an immediate answer, other than to mention that this very topic has received extensive discussion in some recent similar threads, so if you could locate those threads I'd imagine you'd find some useful tips. (Unfortunately I don't have any links handy, but searches for terms such as 'minecraft' and 'voxel grid' might turn them up. For what it's worth, I think one of the threads was in Game Programming sometime in the last month or so.)
  8. Questions about Blender Game Engine

    [quote name='daedalus316' timestamp='1308223166' post='4824029'] Recently me and some friends have decided to make a game. Unity 3D was recommended by a lot of people so I tried it out. However i found it really difficult to navigate the scenes and also I have read that JavaScript is very bug prone for beginners.[/quote] I've only played around with the BGE a little, so I hesitate to comment on it directly. Regarding UnityScript (aka Unity JavaScript) being bug-prone, I think I can guess why one might say that, but it needn't be a deterrent, I don't think. First of all, there are two other languages to choose from (C# and Boo) and C# at least (I haven't used Boo) doesn't incorporate the features that sometimes trip people up in UnityScript. Also, by placing '#pragma strict' at the top of each UnityScript source file, you can catch a lot of common errors, which should help as well. As for navigating the scenes, if you're having problems with the interface, you can always ask here or on the Unity forums for help. (The scene interface is fairly straightforward, so I imagine whatever problem you're running into, someone or other could probably provide some tips that would help.)
  9. OpenGL for Eclipse C++ Help

    If you create a single source file with a main() function only, and then include gl.h, does that work? Or do you get a similar error?
  10. [quote name='prodeezy' timestamp='1308206267' post='4823957'] What is your opinion on Quake engine development (Q3/Q4)?[/quote] I'm not sure how appropriate the Q3 engine would be for getting something up and running quickly (it might or might not be suitable, depending on what type of game you wanted to make). I'm not familiar with Q4, but my guess would be that the same would hold true for it as well.
  11. std::map and shaders...

    [quote name='Kian' timestamp='1308222777' post='4824026'] jyk is saying that if you use enums as identifiers, then if you create a new shader you have to recompile the program. This is true, but I don't think it's very different from how your implementation with maps works (unless you are grabbing the name of each shader from an external resource like a text file).[/quote] Yeah, I'm not sure how the OP is doing it, but typically the resources that needed to be loaded would be determined at run time as well. (For example, you might simply load all the resources in a specified directory.)
  12. I'm not sure what you're doing there, but I can tell you that you don't need all that complexity (you should be able to apply the transforms you want using only rotations about the cardinal axes).
  13. [quote name='prodeezy' timestamp='1308176256' post='4823826'] - Ogre: a full fledged game engine.[/quote] Ogre is a rendering engine only, not a game engine (AFAIK, at least). It can certainly be combined with other libraries though (e.g Bullet for physics, etc.) in order to create a framework for a game. Based on what you've said though, it sounds like an integrated engine such as Unity or Shiva might be more appropriate for what you want to do. (You might have to pick up a new language, depending, but if you're comfortable with C++ that shouldn't be an obstacle.)
  14. [quote name='Sepiantum' timestamp='1308197115' post='4823919'] As suggested in the title, I have up, right, and look vectors and I want to figure out the angles of rotation in the x, y, and z axis. Any ideas on how to do this? [/quote] Sounds like what you're looking for is a matrix-to-Euler-angles conversion. The process would be: 1. Create a matrix from your basis vectors by loading them into the rows or columns of the matrix (depending on notational convention). 2. Extract the Euler angles from the matrix. Of course you could compute the angles directly from the basis vectors, but it'd be exactly the same thing. (The reason I mention the matrix extraction is that many math libraries already have matrix-to-Euler conversion functions.) Also, keep in mind that there's a variety of different ways Euler conversions can be performed, and any sample code you find could be dependent on axis order, vector notation convention, and/or matrix layout, so to get the desired results you'll need to make sure to get the conventions right.
  15. std::map and shaders...

    [quote name='Kian' timestamp='1308195655' post='4823913'] It may be a bit too much work to get this working after you solved the issue with maps, but it may also simplify things in the future if instead of using a map with a string for the technique name mapping to a certain shader, you use a vector to store the shaders and use enums to identify the different shaders. It's fairly extensible, in that you can just add an enum when you want to create a new shader, and it would provide faster access (since you go straight to your shader instead of searching the map for it). And you don't have to handle iterators or strings. [/quote] This is just IMO, but using enums to identify shaders (or any resource, for that matter) doesn't seem like a particularly good idea. In general, data should be, well, data (you shouldn't have to recompile your program every time you add a new resource).
  • Advertisement