f8k8

Members
  • Content count

    372
  • Joined

  • Last visited

Community Reputation

171 Neutral

About f8k8

  • Rank
    Member
  1. I'm trying to get my head around row/column major matrices and row/column vectors. Mostly, I'm using the following for reference: [url="http://www.j3d.org/matrix_faq/matrfaq_latest.html"]http://www.j3d.org/matrix_faq/matrfaq_latest.html[/url] So, trying to write a 4x4 matrix class, I have a class with an array of values: float m_Values[16]; Now, I'm going to be using column vectors, so: [b]1) Am I right in saying the following:[/b] Multiplication should be written like so: Matrix * Vector Combining rotation matrices should be written (for example): Projection * View * World [b]2) Row/Column major matrices refers to the order the data is stored in memory, NOT whether or not the translation component should be down the right hand side / along the bottom.[/b] The translation is down the right hand side of the matrix when using column vectors, and across the bottom when using row vectors. Is this correct? [b]3) OpenGL uses column vectors, and uses column major matrices, and we want to upload the matrices to OpenGL using [/b][b]glUniformMatrix4fv[/b] I'm pretty sure this is right, so does that mean that the translation component should be in m_Values[12], m_Values[13] and m_Values[14]? [b]4) When multiplying two matrices together, the operator* should have something like the following[/b] final.m_Values[0] = (this.m_Values[0] * other.m_Values[0]) + (this.m_Values[1] * other.m_Values[4]) + (this.m_Values[2] * other.m_Values[8]) + (this.m_Values[3] * other.m_Values[12]); final.m_Values[1] = (this.m_Values[0] * other.m_Values[1]) + (this.m_Values[1] * other.m_Values[5]) + (this.m_Values[2] * other.m_Values[9]) + (this.m_Values[3] * other.m_Values[13]); final.m_Values[2] = (this.m_Values[0] * other.m_Values[2]) + (this.m_Values[1] * other.m_Values[6]) + (this.m_Values[2] * other.m_Values[10]) + (this.m_Values[3] * other.m_Values[14]); I'm not sure if this order is right, or if I need to multiply a different way because the matrices are stored in column major order in memory. Can anyone clarify if this is the right way or not? [b]5) The Matrix Quaternion FAQ I linked to at the top seems to be using column vectors, so vectors are multiplied on the right, as shown in Q13 of the FAQ. Q35 appears to suggest that matrices should be multiplied the other way though.[/b] Q35 states that in order to get an X rotation, followed by a Y rotation, followed by a Z rotation, you multiply: M = X.Y.Z But I thought that, because it is using column vectors, the first transformation should be at the right hand side. I.e.: M = Z.Y.X In fact, looking at the function calls listed at the start of Q36, it seems to be multiplying in the order I'd think was correct (i.e. Z * Y * X), but still goes on to state that M = X.Y.Z. Are Qs 35 & 36 wrong, or is it just a difference in notation for multiplying matrices instead of vectors (as Q13 says that V' = M.V, which seems like the right way round to me). Or is it just that I'm very confused? ;) Hopefully someone can help me out on this, it would be very useful. Thanks
  2. Iphone swipe direction

    Your question was answered in your previous post here: http://www.gamedev.net/community/forums/topic.asp?topic_id=582925 Alternatively, you could use the UISwipeGestureRecognizer class: http://developer.apple.com/library/ios/#documentation/UIKit/Reference/UISwipeGestureRecognizer_Class/Reference/Reference.html
  3. Maybe something similar to ->, but perhaps the other way, e.g.: int Value = <-PointerToValue; Dunno though, I haven't really thought too much about it :)
  4. If you can wait until C#4.0 is out, you can do it in that with the dynamic object type: http://en.wikipedia.org/wiki/C_Sharp_4.0#Dynamic_member_lookup
  5. What is your processor & version of windows? Also, have you tried the web setup?
  6. I'm trying to encode two signed shorts into an unsigned int, with the line below: uint Encoded = (uint)GridXPos | ((uint)GridYPos << 16); But the compiler is giving me a warning of: Bitwise-or operator used on a sign extended operand; consider casting to a smaller unsigned type first. Maybe my brain hasn't woken up yet, but I can't figure out what the correct way to do this would be. I'm pretty sure the above line is OK, and if I try something like this: uint Encoded = (uint)((ushort)GridXPos | ((ushort)GridYPos << 16)); I get the same warning. What's the correct way to cast this?
  7. Thanks, that looks like it'll work. To get it to handle the triangular pieces, I think subdividing each tile into a 2x2, with the triangular parts being represented like: |-/ -> SS |/ S Then skipping two squares at a time when searching for an object (to ensure that the edge starts on a tile boundary, and not half way into a tile), and moving 1 square at a time when tracing the edge, then removing every other vertex from the traced edge list would give me smooth 45 degree edges on the triangles. I think this should work anyway :)
  8. I don't want the bounding box, I want to combine the geometry into one object. E.g. S S S SSSS Would create an L shaped object (Where each S is a square tile)
  9. I'm looking for an algorithm to combine tiles into a solid piece of geometry. The tiles are all the same size and are either square or a corner piece (right angle triangle taking up one half of the area of a square, if you get what I mean), and are placed on a regular grid. What I'd like is to get the corner vertices of the geometry that wraps a set of connected tiles. Any ideas what to search for, or does anyone know of any algorithms? Thanks.
  10. As people have said, your class needs be copyable as well, so you should be using some kind of smart pointer if you don't want to copy around the memory, or you should be copying the memory in the copy constructor / assignment operator. Either method will fix your bug.
  11. Definitely sounds like someone is catching a NullReferenceException and assuming it's being caused by a failed allocation, so they're throwing an OutOfMemoryException. Bad form. :)
  12. You should definitely upgrade. Visual C++ 6 is well known for being non-standards compliant (meaning code you write in VC6 may not work at all on other compilers, or you may have to include some nasty workarounds to get stuff that should compile to work in 6), and the latest versions will be able to produce far better optimized code, as well as having much better debugging tools. Really, there are no reasons not to upgrade.
  13. First, you should upgrade from Visual Studio 6.0. It is an old, very non-standards compliant compiler, and you can get Visual Studio Express editions for free, which are much better. I'd stick with PNG, as anything that supports them will no doubt support 32-bit PNGs, whereas BMPs are generally 24-bit, so certain packages might get rid of your alpha channel if you use them. How are you loading in the PNGs? Usually there'll be a method for saving out files in whatever library you're using to read them in. Or you could use an open source library, like libpng. EDIT: Sorry, didn't read about the no platform sdk or extra libraries, though you are using DirectX, which is a library. How are you loading in the PNGs? If you're using the D3DX extensions, you could use D3DXSaveTextureToFile to save them out. If not, you've already written code to handle reading of PNGs, so just do the reverse to save them out.
  14. strange thread error

    I think Hodgman is correct here. What is likely happening is this: 1) Your "thread" instance is constructed 2) The Start() function is called, which in turn calls _beginthreadex to create a thread 3) Your "thread" instance loses scope and is destroyed (most likely an error in debug as the memory will be cleared out and so the VTABLE is zeroed, hence the pure virtual function call error) 4) The thread scheduler then begins your thread, which tries to call the virtual function, the entry for which is now 0 (i.e. a pure virtual function call). The reason you're probably not seeing it in release is that the memory will not be getting zeroed by the runtime, but is still unallocated, so even though it appears to work, it's actually very dangerous. The solution here is to ensure that the thread has completed before the "thread" instance is destroyed (which can be done in the destructor).