• 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

1132 Excellent

About SuperVGA

  • Rank
    Advanced Member
  1. Do you really need a global, unique id  here ? What's wrong with a 32bit or 64bit application unique id ? It would be a lot faster and would make it even more useful in combination with a hashmap. Looks a little bit like over-engineering to me   Thanks for your input. Yeah, I have been over-engineering. It's probably because I've become so accustomed to these 128bit guids at work that I feel like I should be using those too. But you're absolutely right - less will definitely suffice. I'll moderate this, and overhaul this communicator thing with hashmaps and shorter uids. I only want them to be unique application-wide, after all. 
  2. I currently have  std::map<const guid, CommWrapper >* comm_table;   where guid  struct guid  {   unsigned char d[16];      // Less-comparer for std::map with GUID keys   bool operator<(const guid& rhs) const   {    for(unsigned c = 0; 16 != c; ++c)    {     if(d[c] == rhs.d[c]) {   continue;     }     return d[c] < rhs.d[c];    }    return false;   }   };   But it seems to be way slower than the approach i took before, where i just based the (gu)id on the index the pointer had in a std::vector. for instance truck would be in comm_table[5], and thus its id would be 5.   But I kinda like the idea of using some big, fancy guids. It's just really slow for autonomous inter-instance communication, and I'm wondering if I'm doing it right. Perhaps there's no reason to go this way at all.   Or am i just using a wrong collection?
  3. Wow, the article describes one technique. I wouldn't call it modern, either.   You could explain GPU raycasting, polygon aided raycasting, different approaches to approximate or truncate isosurfaces, so why is MC getting all the love?   And I'd mention metaballs in connection with explaining scalar field polygonization, but perhaps that's just me. Also, here the scalar field is described as "our voxels" - I'd say it's a bit more than that.
  4. I'm back! Thanks Funkymunky, that did in fact help. I ended up understanding it, but before I sat down to rewrite some things, I discovered that I would eventually have to deal with a patented approach, a Geoclipmaps apparently is.   So I went back to sort of a compromise. I do classic LOD chunks now, but baked into a single mesh, where every verex has its fp LOD value set as one of its attributes. The cool thing about this is that i can use euclidean distances rather than manhattan or chessboard distances, and that I get a seamless result, as I lerp the LOD values downward towards the next chunk (which requires it's sample LOD to match its mesh density or be coarser.)   I now have [attachment=19009:standardlod.png]   ... And I'm now at the point where I'm actually considering applying a modulo equal to the highest density -quads, rather than using modulo of a chunk size. (here, the chunk size is constant, only the density changes) This causes obvious but smooth vertex scaling in the distance, which I actually like. Viewing with the wireframe on also makes it more obvious.   I think I've managed to do a fair settlement, but you're welcome to input on the approach, of course! :)
  5. Ah, the only thing I meant by slide was the movement relative to the eye, before the modulo bit resets the positions of the vertices. I see how that was a weird term to use.   I've read so much and re-coded so much of this that I think I need to take a break. All this talk about grids is weird, when they are not really complete. I somehow fail to comprehend why I should use an odd number of cells in the "grids". Also, is it supposed to be the innermost grid that's 2^n -1, or the surrounding ones?   Anyways, thanks for trying to help out. I thought I got it, but it appears that I didn't really do it how it's supposed to be done. And now I'm sorta stubborn to learn the "right" way. :)
  6. Hi Funkymunky! Thanks for responding. Yes - those are the ones I'm talking about. The way you do it, do these triangles that connect the two LOD levels maintain size, and therefore overlap either the inner LOD area, or the outer one, as the camera pans across the landscape?   Because with how I do it, letting the innermost slide to a max of 0.25 (as the innermost quads are 0.25 in width and height), and letting the next layers slide by 0.5, 1.0 etc in each direction, there is at most a gap or an overlap between two LOD levels of the inner quad size. And this means that the gaps are often narrower. But I see your point. Just as how I've mapped it down, there's still something I need to figure out.... Huh. - Could it be that I'm fitting the inner part of the coarser LOD to the finer? This means having fewer vertices to move around than if I used the outermost triangles of the finer LOD level...   I keep my LOD value for the vertices in the texcoords, but it seems we do just about the same thing with regards to picking the applicable level.
  7. Hi Guys! Been a while! My project sees constant changes, and it really helps that I learned to stick to stuff. That said, I often see myself rewriting a module or replacing it with others. Feels clean.   I've tried to grasp the principle of Geoclipmapping. Following various articles, but mostly the one from GPU gems 2 (see, I even used the colours :P) I get that all the vertices should move relative to the camera movement, and thus represent static points in the world. While I'm mostly successful at this, the "rings" that represent the overlap between the detail levels cause me some headaches. (They're the ones on the picture which fades to a darker colour on the inside) [attachment=18917:geoclipmaps.png]   I've done it so that these rings will snap to the same points where the outer vertices on the ring within are. That means that these in-between rings scale a bit, and that the quads in the corners have issues snapping to the inside.   The individual rings are each offset with eye.xy modulo size (where size is the size of an individual quad in that ring) - when I look at these isolated, they move seamlessly, so I think I got those right. But I can't wrap my head around how the ones on the inside can stay without being distorted a bit. And how to do the corners at all.   Any feedback or hints highly appreciated! :D Have a good weekend,
  8.   Hi Rob,   Why do you recommend passing vectors by value rather than reference? I've made it a habit to use const ref parameters wherever possible, and wherever ref makes sense compared to the size of the type (I wouldn't pass a char by reference)
  9. That's like asking "Will a Mechanic will be able to think of a better car, the better his skills as a Mechanic are?".   The mechanic may never have to deal with cars in his lifetime. Much like programmers don't necessarily develop games. The mechanic may be a mechanic due to a natural interest in building cars, but this is not a given. The mechanic may spend some time fixing sewage control plants before getting interested in cars. Does his skills carry over, and how much?   I'd say that the part of developing games that exist within GAMES && PROGRAMMING will improve as long as one works on GAMES while working on PROGRAMMING. Also, I think that if you get an interest for games out of the blue, after several years of programming other things, there may still be some rare topics existing within both sets that will take some learning. But obviously, if the programmer did audio synthesis for hearing aids, 3d rendering for ct scans and graphs for whatever solution, he may be well on his way.   But it is a very vague question, and I think it depends a lot on many different things.
  10. Have you checked whether your card maintains vertical synchronization with your displays refresh rate? (That could, and likely would explain your 60fps)
  11. If i understand frob correctly, you shouldn't have to determine it, only set it. You could drop points behind the car and create bezier curves through them, you'll have a nice path for your camera to follow, while looking at points closer to your car. 
  12. What do you mean by "static initialization on a global level"? Like initializing global variables outside of a function? I avoid doing that.   Yeah, sort of. Even if you do something neat like only having one, or very few of them, it can hurt; It's really more of a linking issue than it is a design issue, - but I suppose by sticking to pure functional programming and no static classes, it's doable.
  13. I agree, but I only told how to do it as an answer to Tom_Mai's question "...before stopping at the first line of code..."   - There's nothing as infuriating as stepping from main() all the way to the 20000th frame because that's around the point I'm through the menu, my world has loaded, and the buggy AI discovers an ammo crate.   Also, I strongly encourage using breakpoint conditions where possible. In the Borland/Embarcadero IDE, there was/is an option to enable and disable entire breakpoint groups. Powerful stuff. I don't think Netbeans or VS does this.... :(
  14. Having a decent page inspector/js debugger, Hodgman always wins! :D   On topic (If the topic is not about obscuring your js), game is entertaining. Typical addiction through timing - approach! I see that it works... :)
  15. Often, If you use static initialization on a global level, you can't tell which order the objects are created in. Usage of rand() here may cause code invoking rand() in a different order than expected. Of course, if the same build is causing different sequences, that's a different thing .   (Also, i must agree with Mir, stl http://www.cplusplus.com/reference/random/ is really sweet - I use it a lot.)