• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.

WhatEver

Members
  • Content count

    561
  • Joined

  • Last visited

Community Reputation

125 Neutral

About WhatEver

  • Rank
    Advanced Member
  1. Ha, so much has changed since I last wrote an OpenGL program! Thanks for the clarification and insight into the latest generation of graphics acceleration.
  2. Never mind, it just sunk in. It doesn't seem like that would be the reasons for being so slow, but I don't really understand the hardware.   What's the bind-less function thing you're talking about?
  3. I'm a little confused. Is glBindTexture still slow, but not for the reason I thought, and it's been replaced by a different function: a bindless function?
  4. I've been looking all over the place for an answer to this question and I'm only getting bits and pieces of the answer. I learned the hard way a long time ago that calling glBindTexture is relatively slow; I found out from a friend of mine that it was because I was binding the texture every time I drew a triangle lol! The simple fact is that calling glBindTexture comes at a price, and minimizing calls is always the best choice!   Anyway, there's a reason it's slower than most other function calls that change the opengl states, and I'm looking for the technical answer.   So far, with my limited understanding of hardware in general, the main reason I think it's slow is because every time you call glBindTexture, the hardware copies the texture from Texture RAM into the Texture Cache because the Cache is faster to read from. Although the copy is fast in it's own right, copying larger textures should take longer than smaller textures, and if done enough times no matter the size of the texture, will become a performance bottleneck.   Yes/No? Is there more to it than that?
  5. OpenGL

    You're getting what looks like z fighting. In your case, turning on back face culling should fix it. If not, look at the model and make sure you don't have double sided polygons. If you do delete the polygons you can't see, or never will see.
  6. I guess so. I have never scaled my camera before...but I do remember having problems with lighting when my objects are scaled. My shaders perform lighting in object space, so I have to multiply the lights by the inverse of the object world matrix. I pretty much get how the invert matrix works then, but what about the transpose matrix? I get it when it has to do with rotations, but other than that, I'm clueless. Here's the source code that creates my textureMat for shadowing (it's the same as the one in the OpenGL SuperBible but with my functions) S3Dmat16f textureMat; s3dMatIdentity16f(textureMat); s3dMatTranslate16f(textureMat, 0.5f, 0.5f, 0.5f); s3dMatScale16f(textureMat, 0.5f, 0.5f, 0.5f); s3dMatMultiply16x16f(textureMat, projection, textureMat); s3dMatMultiply16x16f(textureMat, modelView, textureMat); s3dMatTranspose16f(textureMat); glTexGenfv(GL_S, GL_EYE_PLANE, &textureMat[0]); glTexGenfv(GL_T, GL_EYE_PLANE, &textureMat[4]); glTexGenfv(GL_R, GL_EYE_PLANE, &textureMat[8]); glTexGenfv(GL_Q, GL_EYE_PLANE, &textureMat[12]); I understand that S, T, R, and Q are holding the results of the textureMat. But what exactly is going on? I was under the impression that the textureMat would need to be inverted not transposed so that S, T, R, and Q would be brought into texture space.
  7. I'm a little confused by the difference between inverting a matrix versus transposing a matrix. I invert my camera matrix to bring objects into camera space, and transpose my texture matrix to be used for my shadow maps. The two function that I have that invert and transpose matrices are similar, and that's what is confusing me. The xyz rotation axis are being transposed in both, but the forth column, and position, are treated differetly. I guess I understand why the invert function I have works, but I don't understand what the 4x4 transpose is doing with the 4th column and position data. Invert function: b[0]=a[0]; b[1]=a[4]; b[2]=a[8]; b[3]=0.0f; b[4]=a[1]; b[5]=a[5]; b[6]=a[9]; b[7]=0.0f; b[8]=a[2]; b[9]=a[6]; b[10]=a[10]; b[11]=0.0f; b[12]=-(a[12]*a[0])-(a[13]*a[1])-(a[14]*a[2]); b[13]=-(a[12]*a[4])-(a[13]*a[5])-(a[14]*a[6]); b[14]=-(a[12]*a[8])-(a[13]*a[9])-(a[14]*a[10]); b[15]=1.0f; Transpose function: temp[0]=m[0]; temp[1]=m[4]; temp[2]=m[8]; temp[3]=m[12]; temp[4]=m[1]; temp[5]=m[5]; temp[6]=m[9]; temp[7]=m[13]; temp[8]=m[2]; temp[9]=m[6]; temp[10]=m[10]; temp[11]=m[14]; temp[12]=m[3]; temp[13]=m[7]; temp[14]=m[11]; temp[15]=m[15]; -WhatEver
  8. That's a good idea SiCrane, but my boss won't let me do that because their big thing is to conserve memory along with quick load times. Thank you everyone for your help. Because of the nature of how the rotations work, I can at least keep acurate rotations around the z, simply because it is the last to rotate in both orders and therefore not scewed.
  9. I forgot to mention that I don't care about perfect precision.
  10. edit: Key frames can contain values beyond the range of 0-360 degrees, so I need to preserve degrees that are beyond the 0-360 degree limit. I'm trying to export key frames from AfterEffects to Lightwave, the only problem is that AfterEffects rotates in xyz order, and LightWave rotates in yxz order. The only method that I am aware of that will convert from one order of angles to another is a two part process. These are the steps I am taking to convert from xyz order to yxz order 1. rotate a matrix in x, y and z order 2. extract the angles in y, x and z order But when I do this, I lose any angle that goes outside of the 0 - 180 degree range. So is it not possible? Am I using the wrong method for converting keyframes from one rotation system to another? I'm beginning to think it is not possible. Because like you said, I lose that rotation value once the conversion has been made.
  11. That makes total sense, but here is my theory. If I have the variable that rotated the matrix, I know the exact rotation of the matrix. So what I am essentially trying to do is convert from xyz rotation to yxz rotation and since I currently have the angles from the xyz rotation, shouldn't I be able to use the xyz rotations to modify the yxz rotations in conjunction with the matrix?
  12. Mike, maybe that was a bad example. Let's say I rotate 385 degrees. I don't want to retrieve a value that is restricted to a number that falls between 0 and 90 degrees, I want it to return 385 degrees.
  13. I just ran some more tests, and it looks like I can get a number aproximatly between -1.57 to 1.57, which ends up being 180 degrees. I still need it to give me a larger range than that, if it is even possible. The variables r0, r1, and r2 was my attempt at determining how many times a full rotation occurred, and then I was adding it to the rotations after they were converted to a different order. Here's my source code (updated to reflect what does work -- but not to the degree I need it to work, pun not intended :)): CMNvoid aeAnglesToLwAngles() { CMNKeyIterator i0, i1, i2; CMNKey *k0, *k1, *k2; CMNint r0, r1, r2; EulerAngles outAngs, inAngs; HMatrix R; k0 = Channels[3].getFirstKey( i0 ); k1 = Channels[4].getFirstKey( i1 ); k2 = Channels[5].getFirstKey( i2 ); while( k0 || k1 || k2 ) { inAngs.x = inAngs.y = inAngs.z = 0.0f; inAngs.w = EulOrdXYZr; r0 = r1 = r2 = 0; if(k0) { inAngs.x = k0->Value; r0 = k0->Value / CMN_PI; } if(k1) { inAngs.y = k1->Value; r1 = k1->Value / CMN_PI; } if(k2) { inAngs.z = k2->Value; r2 = k2->Value / CMN_PI; } Eul_ToHMatrix(inAngs, R); outAngs = Eul_FromHMatrix(R, EulOrdYXZr); //if(k0) { k0->Value = outAngs.y + (r0 * CMN_PI); } //if(k1) { k1->Value = outAngs.x + (r1 * CMN_PI); } if(k2) { k2->Value = outAngs.z + (r2 * CMN_PI); } if(k0) { k0->Value = outAngs.y; } if(k1) { k1->Value = outAngs.x; } //if(k2) { k2->Value = outAngs.z; } if(k0) { k0 = Channels[3].getNextKey( i0 ); } if(k1) { k1 = Channels[4].getNextKey( i1 ); } if(k2) { k2 = Channels[5].getNextKey( i2 ); } } } [Edited by - WhatEver on August 26, 2008 6:59:00 PM]
  14. I looked around all over the place to find out how to extract euler angles from a matrix, and I found it. Yippeee right? Nope, I'm dealing with sort of a more unique problem. Apparently, and this makes sense, you can only extract angles that are limited to 0 and 89 degrees. Here is the problem I am posed with: 1. Rotate a matrix around it's axes 360 degrees 2. Extract x rotation from matrix I end up with 0 degrees. I need it to give me 360 degrees. I am writing a plugin for AfterEffects that will export animations to LightWave. If I have a AfterEffects layer rotating around it's axes 4 times, then I need to be able to convert that rotation from xyz order (AfterEffects) to yxz order (LightWave). Actually, all these numbers are in radians in my source code, but I am calling them degrees here for simplicity. Any help would be appreciated. Thank you.
  15. Thanks for your input deathkrush! Ok, I did some experimenting and discovered that TEXCOORD6 and TEXCOORD7 are the same as TANGENT and BINORMAL, so glClientActiveTexture works fine for now.