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

MaulingMonkey

Members
  • Content count

    5060
  • Joined

  • Last visited

Community Reputation

1725 Excellent

About MaulingMonkey

  • Rank
    Troll

Personal Information

Social

  • Twitter
    MaulingMonkey
  • Github
    MaulingMonkey
  1. 2D

    Fire up an image editor and use the dropper tool. Most of the banding I'm seeing is single color level changes (e.g. #373737 -> #383838) without enough texturing to obscure the effect - one band per drop. I think I found *one* drop out of 10+ where it was 2 instead. You *are* hitting the precision limits of what 8-bit buffers and monitors can give you. Much of the scene obscures the banding effect from textured backgrounds which have a much greater range and effectively drown out the banding with texture. The places where this doesn't happen are where you have your single, solid, untextured light as the dominant or only contribution to the color channel. Aside from having the background contribute more (that concrete wall has easily +/-32 levels of color difference just pixels apart, easily drowning out the effects of banding), you could also try texturing your volumetric lighting - think dust particles catching the light etc. And as Unbird mentions, dithering would help as well (at least if you've got e.g. HDR render buffers that you can get more than 8 bits of precision out of in the first place to dither *from*.
  2. I treated matrices as a black box until I had to debug a d3d9 -> opengl es 2 porting bug involving them, at which point I built myself a solid geometric understanding of 3x3 and 4x3 matrices, and at least enough of an understanding of 4x4 matrices to debug them.  (The bug was not realizing glUniformMatrix4fv ignored the transpose parameter in ES2.) As a single reject reason, it seems rather picky for a junior position.  If you've got a flood of well qualified candidates, it might be reasonable to be this picky (especially if they're expected to start working on graphics code right away).  If you've got a trickle and several slots urgently in need of filling, it may be *very* worthwhile to give them a shot - you can always try and mitigate some of your risk by trying them out as a contractor first.  If they work out, you can always offer them an upgrade to full time employment.
  3. To recap some points from discord: Low poly meshes are still a thing (you don't use your high poly render mesh for bullet hitboxes or nav meshes either, you use a lower poly equivalent) Tracking your current triangle means you don't need a line-mesh intersection vs the whole mesh every frame (just scan neighboring triangles instead) Cheat and limit what your animators can do, thereby simplifying your options by assuming more - such as having them not flip the model, and thus let you cull the entire stomach mesh, etc.
  4. > Thats just ridiculous (discount the example about generated assembly).   It gets worse:  https://fgiesen.wordpress.com/2013/01/29/write-combining-is-not-your-friend/   There's a couple of additional strong recommendations:  Always write sequentially, and don't leave any holes.  IIRC violating the latter rule can even result in a cacheline read by the CPU on at least one arch - although I can't find a proper source/docs for that.   My golden rule now is:  Always use memcpy.  Always.  For the entire buffer.  *Always*.
  5. The basic tradeoff here is merge early/often vs merge late/rarely.   If features A-D are small, I'd argue "who cares" - cherry picking or temporarily disabling changes is easy enough that I wouldn't bother optimizing my workflow around it.  So let's assume they're large.   "Feature D" doesn't get merged with the changes introduced by "Feature A" and "Feature B" until the last minute in your workflow.  Refactoring conflicts will be a real mess to resolve, near impossible to properly review, and impossible to bisect for problems.  I have repeatedly, in the past when faced with such problems, rebased "Feature D" atop "QA" or incrementally merged "QA" into "Feature D".  This makes it much easier to highlight refactoring conflict resolutions that need proper vetting in code reviews, makes the merge much more reviewable, and makes the history bisectable in a useful manner.  Unfortunately, this is basically turning your workflow back into the original one - with all it's problems.  If we suddenly decide Feature B is out, I'm still SOL.  Still, I'd generally rather have those problems than megamerge problems.   Maybe your situation is different enough that you'd rather make a different tradeoff somehow?  An alternative option possibly worth mentioning here:  Feature toggles.   > If someone in QA notices a bug on the live site, do you create a Hotfix branch from your current master/development branch or the old dead-end release branch?   You don't actually solve this conundrum with your workflow any better ;).   Hotfixes should generally always be branched from whatever commit is live ("master" here?) to minimize the scope of the hotfix - or the previous unshipped hotfix - and thus reduce the risk that you'll introduce additional bugs that won't be caught by the typical vetting process of soaking in the Dev/QA branch for awhile that you're mostly skipping - and then merged back into "Development" and/or "QA" at your earliest convenience.   Speaking of broken CSS: It's impossible to see what text I've selected for copy/paste on Chrome on that site.   > Release day! We get news Feature C is being removed.   I don't think I've had this happen once in my years of game development.  Occasionally we'll roll back a recent change for stability, but that's about it.  Having *this* late notice sounds weird to me.  Having it happen regularly enough to base your branching strategy around it - well, hey, maybe you do have a use case, but I don't think this is a "closed source" issue per se ;)
  6. Does seem to be broken.  A working download can be found here:   https://code.google.com/archive/p/slimdx/downloads?page=1   (Broken links are @ https://slimdx.org/download_june10.php )
  7. Most of the low level I/O, if it fails, returns uninitialize data at best (which makes debugging nice and nondeterministic.) There's no sane bounds checking - it appears trivial to create a tiny file which will eat all your memory when using read_string. If you're lucky, it will throw std::bad_alloc or dereference null (depending on if exceptions are available or not).  If you're unlucky you'll exhaust all available memory and have OOM crashes later elsewhere.   I wouldn't consider this usable even in a non-hostile environment currently - savegame corruption happens, I don't want it crashing my titles on startup.   In a hostile environment, your attacker will use l=0xFFFFFFFF, the call to new char[0xFFFFFFFF+1] will succeed - it's the same as new char[0] which returns a unique non-null pointer.  The resulting read() call *without* the +1 will then be the start of the buffer overflow, likely probed for possible use in code injection attacks...   Throw SDL MiniFuzz or other fuzzing tools at this if you want to harden it up...
  8. [quote name='Aardvajk' timestamp='1343894354' post='4965436'] Well then it seems highly unlikely you need to worry about loss of precision when converting from float to double, unless your simple arithmetic involves numbers like 23423.4234234098029384233409583405 [img]http://public.gamedev.net//public/style_emoticons/default/smile.png[/img][/quote] Of course, do note that simple decimal expressions like "0.3" have an infinite number of digits in binary fraction form and will suffer additional rounding if coerced to float.
  9. Nothing out there quite like I want. Rolling my own pile of hacks: [url="http://i.imgur.com/ET1Me.png"]http://i.imgur.com/ET1Me.png[/url] Needs more icons, better sorting metric, more accurate metrics in general, better handling of branches.
  10. Zol on #gamedev suggests some sort of lightweight sourceforgelet stack that you run locally to quickly share local projects (or their information) with others.
  11. I've been digging into my projects\dead\ folder recently, a dumping ground of projects I've stopped working on. There's some stuff well worth salvaging for use in new projects in here. This process is daunting, despite 'only' containing 31,705 files out of the 64,473 files in my projects\ folder. I want a way to better document my hundreds of throwaway projects. I'm going through, renaming project folders based on language, branch count, adding short descriptions, taking screenshots, etc. -- but this is inefficient, slow, and isn't all that ideal for browsing. I'm after a better at-a-glance view of all my projects. VCS websites like github and sourceforge tend to at least have a project list that lists project names and descriptions -- I'm looking for something similar and more advanced that works locally. Before I roll my own, is there anything already existing out there? If so, my google-fu is failing me. Failing that, what are some of the features that could be useful? Screenshots, Short Descriptions, Tagging, Statistics (language, loc/commit/branch count), Pending changes, VCS and Website tracking all come to mind.
  12. [quote name='Eelco' timestamp='1332837904' post='4925588'] [quote name='Promit' timestamp='1332788172' post='4925422'] I'd like to remind all of you that we are talking about XML, Xerces, and libraries. [i]Not[/i] languages. If this becomes a language thread, I will end it. [/quote] Not to question your ultimate authority, but if it happens with the consent of the OP, and with good manners, whats the problem exactly? [/quote] A long, sordid history of language flamefests degenerating into complete and utter shite on this forum, as they attract out every lurker who doesn't know what they're talking about but has strong (and wrong) "opinions" and "facts" about programming languages. This derails and prematurely ends thread after thread in the process, either because the concentrated stupid drives away the rest of the participants, or baits them into participating, or gets bad enough that a moderator has to close it. Premature thread death is seen as bad for some reason, so effort is taken to avoid it. [quote name='Eelco' timestamp='1332837904' post='4925588'] My point is merely that the typical usability of a library is strongly intertwined with the characteristics of the language it is written in; and that C++ scores low on this metric, in my opinion. Not that crazy a tangent, is it?[/quote] Wack's bringing up lists of C#, Java, and C++ "pros/cons". Without reading too closely (as like many members, I've taken to skimming past this stuff when it comes up as it comes up so often) that certainly smells like it's getting/heading toward the rather tangential. And -- lets assume I'm full of shit and it's completely on topic (since I [b]am[/b] skimming after all) -- it's still [b]exactly[/b] the kind of thing that [b]will[/b] attract the wrong sort of people and conversation. So what can be done? Well, if you're Promit, you can tell the wrong sort to fuck off before they even start, and remind the right sort not to fall into the trap again. And now you know (tm)
  13. [quote name='Nyxenon' timestamp='1332805553' post='4925488'] Let's say that "_randomString" is the variable that you want to return, but perhaps you have no way of modifiying the "Brute" class to allow you access to this variable.[/quote] Even modifying 3rd party headers is preferable to the complete evil that is random address offsets. I don't care if Jesus smacked you with a bible-by-4 and said "thou shalt use this address instead of modifying mine headers" -- I'd still prefer it over this nonsense. No code is perfect, and practicality takes precedence over trying to be perfect -- but even if you're going to do the wrong thing, don't use that as an excuse to not even try. Asserts, sanity checking, a few comments warning about how you're expecting it to break and why... try to make it so that, when it inevitably breaks, that's okay because the how and why are clear. Random address offsets aren't going to break cleanly nor clearly. Down that path lies memory corruption, heisenbugs, and crashes 2 hours down the line in a completely unrelated part of your program.
  14. Even ignoring SIMD, interleaving like that makes no sense. In your typical game, you might update the position once per frame per object from velocity, whereas there's a ton of use cases that can end up at higher use counts where you simply don't care about velocity and it's merely wasting cachelines and memory bandwidth at best: Rendering (both for culling and for setting up transforms) AI (pathfinding, LOS / sight distance checks, target prioritization) Gameplay (distance based damage calculations like AoE falloff, fog of war calculations) With seperate arrays, you're potentially halving your required cache/bandwidth from getting positions if you only care about the position. Interleaving can speed things up by reducing bandwidth during random access when you're using all the fields, but even then you're going to gain less than nothing by interleaving on a per-component basis.
  15. [quote name='MarlboroKing' timestamp='1331711094' post='4921898'] I could of sworn MSDN said it was apart of TR1[/quote] TR1, or "Technical Review 1", is part of the work leading up to (and predating) C++11. What Washu is getting at is that the technical reviews are not part of the C++ standard itself, although what they contained was effectively rolled into the core C++ standard in C++11 (with various errata to e.g. take advantage of new language-level features, and little things like putting them in the root std namespace, etc).