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

ddlox

Members
  • Content count

    89
  • Joined

  • Last visited

Community Reputation

168 Neutral

About ddlox

  • Rank
    Member
  1. When you play some AAA games you will notice that some characters do sink into the floor (or gound) or do also float on some platforms. So I personally wouldn't worry too much about it. What you don't want to see happen is that your character collision gets the player stuck into a wall or bush, with the only resolve being to restart a game checkpoint. (This has happened in Uncharted 2 in a swimming pool level and in Uncharted 3 when I sent the boy jumping from the roof into a bush on the adjacent balcony) Fixing those will get your collision detection into the right direction.
  2. Sorry, my previous post didn't go well, here it is corrected: [code] bool myfunction (int i,int j) { return (i<j); } int main () { int myints[] = {32,71,12,45,26,80,53,33}; vector<int> myvector (myints, myints+8); // 32 71 12 45 26 80 53 33 vector<int>::iterator it; sort (myvector.begin(), myvector.end(), myfunction); // 12 26 32 33 45 53 71 80 for (it=myvector.rbegin(); it!=myvector.rend(); ++it) // notice I used "r" for reverse traversal cout << " " << *it; }[/code] the output will be: 80 71 53 45 33 .....
  3. Are you traversing your sorted list from last to front? [source lang="cpp"]// here is a bit of code to do a back-to-front traversal in a vector (or list) of ints. bool myfunction (int i,int j) { return (i<j); } int myints[] = {32,71,12,45,26,80,53,33}; vector<int> myvector (myints, myints+8); // 32 71 12 45 26 80 53 33 vector<int>::iterator it; std::sort (myvector.begin()+4, myvector.end(), myfunction); for (it=myvector.rbegin(); it!=myvector.rend(); ++it) // notice the reverse search by using "r" cout << (*it); [/source] so the output will be something like: 33 53 80 26 ... - replace myvector with yours (whatever list or structure set that you're using) - replace myfunction with your distance_to_camera function - replace cout << (*it) with your render call I'm doing this from the top of my head, but that's the main gist done in clever engines :-)) Good luck.
  4. The problem that you do not realise is that 'you are mixing 2 things into 1 Framerate (FPS) and Rendertime (RT)'. Looking at your gameloop, I can tell that it is framerate dependent loop. No doubt about that. Why? - because your update call feeds with the last RT and this RT is produced by an uncapped Framerate. That's why your bullet still travels fast/slow because you are rendering what the last rendertime dictates (rather than what the last update should dictate). Your framerate should ALWAYS be capped (or fixed) and your rendertime is ALWAYS variable. This last rendertime variance is then broken into steps into your future update calls for the next frame. This is how your loop becomes framerate independent. Currently, your render call comes immediately after the update call, which is fed with the last render time. This is a typical scenario for framerate dependency. This is why your bullet will still seem to be fast or slow (depending on CPU). To achieve independence you need to do what Firestryke31 or the suggested link said. What he/she posted there is typical scenario for framerate independence. This method will allow you to cap or fix your framerate (FPS) and allow your render time (RT) to feed into your next update call in steps . As an example: you can cap your game loop to always run at 60FPS on slow and fast machines, but your RT will be the one changing. Your updates (logic) will therefore take place in steps as highlighted by Firestryke31 then after those updates you call render. You cannot achieve framerate independent updates with immediate render call after it, it will never work well across CPUs. You need to break down your updates in steps. Good luck.
  5. Marek, Explicit constructors have been in placed for years. It's standard c++. You should always use explicit (whereever possible, whenever possible). What to bear in mind is that this form, you wrote, does call a constructor and not the assignment operator. It doesn't fool the compiler, unless your compiler is a very old one (which probably would fail). Without explicit specified, your compiler will call your constructor with a matching parameter. It's programmer-fool, rather than compiler-fool. In other words, "Marek-didn't-know.com" :-)
  6. Aha! I see... I wasn't doing the left multiply at all. OK cool thanks and sorry for posting in the wrong forum, I didn't realise I was in Lounge.
  7. Hi guys, I have this transformation matrix M = Scale * Rot * Trans At some point later in my code, I'm trying to remove scaling from M. I'm currently failing big time... I guess I'm tired or something.. can't think straight. Could anybody tell me how ? Thanks.
  8. My view on the OP: Let ObjectA denote a solid or non-solid object - If the whole world can erase ALL information available about ObjectA (even from human thought) then ObjectA will cease to exist - If you had access to ALL space and ALL time, and if in this environment you cannot find the smallest particle of information about ObjectA then ObjectA does not exist So ObjectA exists as long as ANY information about it is. Example: If I could erase all information about my friend Joe (DNA, bones, flesh, blood, etc...) he will cease to exist, but if there is any form of information about Joe (whether found at the morgue, or in burn ashes particles, etc...) then Joe whether dead or alive does exist. So I believe it is with God as well... the fact that there is a lot of information about him, whether this is man-made-or-twisted, divinely inspired or not, altered or original, means to me that he exists. He will cease to exist if ALL information to the smallest particle about him is erased.
  9. Hi Sorry to post it here, but I don't know who the appropriate moderator for WIKI is. It's not been online for 3 - 4 days now since the new year: http://www.gamedev.net/community/forums/topic.asp?topic_id=592153 Who can fix it? Many thanks, ddlox
  10. Thanks phresnel Maybe the unit just needs a reboot or so... 2k11 bug just caught up with it ;-) I hope the GDNET wizzeds can fix it for us soon. Cheers
  11. Hi I use a customised bucket algo sorting by material ID: -First, you need dynamic vertex buffers (D3DUSAGE_DYNAMIC if using D3D - dunno about OGL or other). - Then you need X amount of vertex caches. Each of these caches contains a similar amount of maxverts of the same type e.g. 10000 verts of type D3DUSAGE_POSITION|D3DUSAGE_NORMAL. Each cache can also store a material ID. (so you can create caches with differents types of verts) - Then when you're about to render a vert buffer, pick an empty cache, set its material id to the one of the incoming vert buffer and fill it up with these verts, but do not render the cache yet (if vbuffer exceeds cache size, then pick next empty cache and repeat this step) - Proceed with the next vertex buffer and repeat the previous step. If this vertex buffer has a different material ID then find an empty cache or one (not-yet-full) with matching ID. DO NOT MIX in CACHES of different IDs! - If all caches are used, but you still have "unbucketed" verts, then find any full cache and render all caches with the same material id, and continue with the filling process. This is a short description of my vertex cache manager, so you're not rendering the object as such but its caches ;-) You can do all sort of other things...: - Reduce draw calls - Pass in a 64b or more key that contains all sorts of command to sort your render effects etc... For more read here: http://realtimecollisiondetection.net/blog/?p=86 All the best.
  12. Hi Sorry if this is the wrong forum...but since the new year I've not been able to access the d3dbook on wiki: http://wiki.gamedev.net/index.php/D3DBook:Lighting Could somebody please check?.... Many thanks ddlox
  13. Allingm, It looks very understanding and worth the try. I certainly go in this route. Thank you SO much ;-)
  14. Oh OK, I see. No I haven't done any deferred rendering mode before. Sounds like your suggestions sit well. Where would I find tutorials on those deferred modes? (I know I can google this, but maybe you know one or two that works from your experience?...) Thanks for your advice as well.
  15. MJP, Thank you so much for your reply. Very good tutorial! Looks like that's what I needed to know ;-) I will now endeavour to give it a go! Thank you Mr MJP. Good gift! IT'S CHRISTMUSSS! ddlox