• 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.


  • Content count

  • Joined

  • Last visited

Community Reputation

126 Neutral

About Caesar

  • Rank
  1. Hi, as a lot of you might not frequent the help wanted section, I'd like to draw your attention to a post from the help wanted section where we seek 3d artists for a World War I. aerial combat simulator. Feel free to visit the project webpage at http://urtax.ms.mff.cuni.cz/flyingsamurai. thanks
  2. I'm no expert, but how about some hashing maybe?
  3. Hi, I'm trying to simulate a soccer ball flight. I'd like to account for gravity and magnus force (I don't need to account for drag now). As far as I know, the Magnus force acts in a direction perpendicular to the direction of motion at every moment in time. Let's say there is only left/right spin on the ball generating the Magnus force. position += d * dt + cross(d, up) * some_appropriate_length; where d is the current direction vector, up is the up vector and some_appropriate_length is simply a length of the magnus force vector due to rpm and dt I believe. dt is the time step. Now, how would I go about a non-iterative function of time that would express the same stuff? The only idea I got was that since velocity is derivation of position and d * dt + cross(d, up) * some_appropriate_length; is my velocity, I could get the position by integrating (over dt I believe). The problem is I don't know how to integrate that cross product. I could try integrating the x, y, z separately, but then again I don't believe that would work (the values change, would I have to do a n-dimensional integral?). I'd also like to hear of any articles that also have some actual equations aside from principle discussion. I need that to be able to tell the rpm I need when I have an initial direction (velocity), a start point and a finish point (and don't take care of the altitude of the ball) (without using some kind of guessing, like bisection) thanks in advance
  4. Okay, that seems to work fine (and also is easier to understand). Thank you! As to my handling of gravity, the difference was that instead of changing the speed vector every iteration by the acceleration, I added (negative 9.81) the gravity acceleration multiplied by time since launch. v += a * dt; p += v * dt; vs. p += (v + a * t) * dt and I believe my mistake was that instead, I used p += v * dt + a * t which is wrong. Thanks for your help.
  5. hi, I've been trying to simulate a ballisti curve (want to simulate a ball). I have the elevation angle, the initial speed (in meters / second) and the initial position is 0, 0, 0. I have positive Z pointing up. int v = velocity; vector d = direction_from_elevation_angle(angle); vector position; vector gravity(0, 0, -9.81); int msec_since_start = 0; while(position.z >= 0.0) { time_delta = time_since_last_iteration(); msec_since_start += time_delta; position += direction * v * time_delta + gravity * msec_since_start; } but that somehow doesn't seem to work (I've tried it in C++... a mass point shot at 20 meters / s under 45 degrees hit the ground in less than 0.2 sec (rather messy code below). Any hints? I want to do it iteratively. Thanks for any hints. #include <stdio.h> #include <stdlib.h> #include <conio.h> float vx, vy, g, x, y, t; bool iterate(float t_delta) { t += t_delta; x += vx * t_delta; y += vy * t_delta - g * t; printf("t = %f: [%f;%f]\n", t, x, y); return y > 0; } int main() { x = 0, y = 0, vx = 0.707 * 20.0f, vy = 0.707 * 20.0, t = 0.0f, g = 9.81; while(y >= 0.0 && t < 10.0f) iterate(0.1f); getch(); return 0; }
  6. also, you might want to see this thread http://www.gamedev.net/community/forums/topic.asp?topic_id=298074 I had had improved my kd-tree (kind of an octree, but you don't divide in halves, but instead where you think it's going to help the most) by a huge factor thanks to those guys. Ie it really matters (in such a tight loop) where you position ifs, etc. Don't have the code anymore though
  7. Quote: if node is leaf: for all primitives: if ray intersects primitive: return true return false for eight child nodes: if child node and ray intersects child node's AABB: if ray intersects child node: return true return false First, it seems to me you are checking for ray/node collision twice, once against AABB and then against the node (presuming transformed BB). My opinion is you should keep the octree axis aligned and transform the ray instead (with the transformation inverse to that with which you'd transform the AABB). But maybe I got you wrong. Also, I assume you mean "for all primitives in that leaf".
  8. Hi I'm rendering a 3d model and only now noticed that the matrix I thought was perspective was ortho (I'm trying to do all the matrix calculations myself). Ever since, I've been trying to plug in a perspective projection matrix, only to always get a somehow distorted (stretched along z sometimes). I've tried using gluPerspective, which I think works (I'm so confused now :) ), but I can't figure out what matrix it uses. I've tried using projection matrix from Irrlicht and from Real Time Rendering book (page 65), no good. thanks
  9. Only now that I read Yann L's post I get it. I need to compare the loaded normal with the one I compute and see if they're the same or not and depending on that, rearrange the vertices to go CW/CCW (the way I want them) thanks guys
  10. Oh, I see. The problem is I'm loading files I've downloaded from the internet and some have the vertex order messed up (CW instead of CCW) (I compute the normals myself instead of loading them). Also, I believe that while you can tell whether the face is CW or CCW, it depends on the actual point of view and thereby you'd need to know whether a certain tri should be facing you or not when you're standing at some specific point in space. Or did I get it totally wrong?
  11. hi how do I learn whether the vertices in a face in a 3ds file are in CW or CCW order? I know there's a faceflag for each flag, but don't think that's what I'm looking for (I enable back face culling to see whether the object is CW or CCW, but they all have the flag set to 7 (decimal). Any idea where to look? (I'm looking at lib3ds now, but haven't found it yet)
  12. http://www.fortunecity.com/skyscraper/windows/364/bmpffrmt.html
  13. Well since this is a beginner forum, I guess you deserve a better explanation. These will be excerpts from my loader bool C3DSLoad::Load(const wchar *path, std::vector<CMesh> *out_mesh) { //open the file m_f = _wfopen(path, L"rb"); //is it a 3ds file? (TODO: some way to check the file's version?) //read the m_current_chunk_type and m_current_chunk_length member variables ReadChunkHeader(); if(m_current_chunk_type != MAGIC_CHUNK) return false; //remember at what position we should stop reading u32 chunk_end = m_current_chunk_length; //now we're past the "file header". Continue reading //chunks for as long as there's anything left (TODO: can there be two //editor chunks? doubt it, but would be nice to know) // because if we're at the last allowable position, we wouldn't //be able to read a full chunk header (only one byte left in the chunk, //that means no subchunks). That's why < is as good as <=. <= would be the //more intuitive choice, too lazy to change it now though while(ftell(m_f) < chunk_end) { ReadChunkHeader(); //read the chunk header switch(m_current_chunk_type) { case EDITOR_CHUNK:{ //the editor chunk, time to load the data we want ReadEditorChunk(); break; } default:{ //some other, unrecognized chunk, just skip it for now SkipChunk(); break; } } } //done reading, close the file fclose(m_f); this is the function I directly call when I want to load a 3ds. The whole file is a big chunk (MAGIC_CHUNK = 0x4d4d). First 2 bytes tell you the chunk id, the second 4 bytes tell you the chunk length (including the 6 bytes you've already read). The length of the 0x4d4d chunk is the same as the length of the file (simply because the chunk is the whole file). We'll be reading futher chunks INSIDE this chunk, that is right after the 0x4d4d header. Since the documentation says the EDITOR (0x3d3d) chunk is right inside the 4d4d chunk, we'll be watching for it. And skipping other chunks (default branch) since we don't want to read them (like 3d studio viewport settings etc). void C3DSLoad::ReadEditorChunk() { //calculate at what offset in the file the chunk ends u32 chunk_end = ftell(m_f) - 6 + m_current_chunk_length; //while there's anything left to read... while(ftell(m_f) < chunk_end ) { ReadChunkHeader(); switch(m_current_chunk_type){ case OBJECT_CHUNK:{ // read the object itself ReadObjectChunk(); break; } case MATERIAL_CHUNK:{ ReadMaterialChunk(); break; } default:{ //skip any chunks we don't recognize SkipChunk(); break; } }//end of switch }//end of while } Here's the function that reads a chunk's content. All of my chunk reading functions look like this. First you calculate the end of the chunk position within the file (where we are now, - 6 for the header, + chunk_length) and then we read/skip chunks (subchunks of editor chunk that is). void C3DSLoad::ReadObjectChunk() { u32 chunk_end = ftell(m_f) - 6 + m_current_chunk_length; ReadName(); while(ftell(m_f) < chunk_end ) { ReadChunkHeader(); switch(m_current_chunk_type) { case MESH_CHUNK:{ ReadMeshChunk(); break; } default:{ SkipChunk(); break; } }//end of switch } } One last snippet. Notice how we read a zero terminated string (ReadName) from the file at the beginning of this chunk (now that I think about it, it would probably be more intuitive to put it before ReadObjectChunk in previous snippet.) before reading further chunks (subchunks of the object chunk). the chunks are nested, hope you get the idea: (main chunk (editor chunk (object chunk (NAME mesh chunk), material chunk (..), ...etc))) the hierarchy is drawn in a chart in one of the files I linked to before (the 3ds spec file). Ask me here if you have any more questions and good luck.
  14. hi I've been trying to write a simple 3d engine. I have a scene manager that stores a tree of scene nodes. Each node has two matrices, one that stores it's transformation relative to it's parent and one that stores the absolute transformation. When I want the scene manager to draw the whole scene, it traverses the whole tree, multiplying the relative matrices together and storing the absolute matrices for each node (note: I guess there is a better way, but I figured I need to set up all lights before the geometry gets drawn and since the lights are also nodes, I need to get their transformations before traversing the tree a second time, drawing geometry). Now that I've gotten to the point where I want to implement a camera class (also a node), I'm quite not sure what to do. I have the absolute transformation of the camera (world space), but I guess that's not what I need. I guess what I need would be an inverse of that matrix, but I'm not sure and I don't want to implement matrix inversion algorithm unless I have to :) not to mention it maybe isn't the best method. Do I need that inverse, any ideas? PS: another way would be to not store relative transformation matrices and store the matrix in some kind of transformation batch that I could easily invert (I could traverse from the camera to the root, building the inverse matrix). That's work I'd rather spare. Whether this would be correct or not, I'm still curious about my original question. I've been looking at the Irrlicht engine as a reference throughout my efforts, but wasn't able to pick up where it does the transformations. thanks for any clarification :)
  15. and of course, watch for the end of the parent chunk when reading subchunks, since otherwise you could easily skip what is not a subchunk, but the chunk next to the parent chunk.