• 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

1842 Excellent

About InvalidPointer

  • Rank
    Advanced Member

Personal Information

  • Location
  1. Direct3D11 would not yet have been a production thing while the research was taking place ;) EDIT: As has been pointed out below, this is incorrect; I had it in my head that D3D11 was launched late 2011 when in fact the API (and HW capable of running it, not just WARP) were available around ~2009.
  2. As I understood it they are just blitting from the source textures to the shading buffer in the first pass, no explicit rasterization. Otherwise known as submitting a command, i.e. 'draw call.' :)
  3.   Currently nVidia's hardware straight up cannot support async compute, at least in the sense most people think of the term. Cool guide here, and the tl;dr is that the nVidia compute queue implementation doesn't support resource barriers and as such cannot implement the current DX12/Vulkan spec.
  4. Based on my understanding of the spec, it's actually because you're mapping into an image with tiling VK_IMAGE_TILING_OPTIMAL layout, which does not necessarily have to have things exist in linear scanlines. The fix is to create a staging resource with identical format and VK_IMAGE_TILING_LINEAR layout instead, and then copy from the LINEAR image to the OPTIMAL one by way of a vkCmdCopyImage.
  5. Same as anything else, put it into the texture, sample for the 'real' draw.   EDIT: If you're having trouble visualizing what's going on, think of it like having a really fast artist who can whip up a color map (hesitate to say 'diffuse' here because there's going to be specular in it too, but I guess in the name of artistic fudgery here we'll go with it) with all the fancypants shading baked into it at 30Hz.   Vlj is actually incorrect here, each object is drawn a minimum of twice.The first time around, though, it's not *quite* going to look the way you're used to with traditional forward rendering, you use the UV coordinates for screen position instead of the actual, you know, position. The end result is that you're going to have a cool single color texture (probably HDR, too) that you can then just sample from and filter like a normal boring color map. This should be super duper familiar if you were around for Eugene d'Eon's seminal work on texture space diffusion, as has been mentioned. See here in section 16.4 if you want some helpful visualizations.
  6. Vulkan

    FYI the AMD drivers are partially broken, at least on my 290X. There's something wrong with their ICD implementation, there are posts on the internal AMD developer forum about the issue.   EDIT: Never mind. I went to go check on the status of this and it looks like AMD has issued a hotfix.
  7.   "Drastically improve performance" is probably drastically exaggerated, but I see your point.   I don't want to move the registration into the asITypeInfo interface as I want to keep it centralized in the engine interface. However, I should be able to do something about the performance anyway. I could for example cache the last used object type between calls, thus avoid the lookup most of the time. Or I could simply change it so that instead of passing the name of the object type, the asITypeInfo representing the type would be given by the application. I'll think about it.   Just how big is your application interface, since you're saying the performance is impacted by this? Can you perhaps send me the configuration file so I can take a look at it and perhaps do some performance tuning (create it with the WriteConfigToFile helper function)?     This is entirely fair. Startup time is actually very reasonable right now, but I'm a meganerd for application responsiveness. Your idea to take the asITypeInfo as a parameter seems a very acceptable compromise and I think I'd be happy with that. On the other hand, while I think understand your rationale for the caching idea, (common case for API registration is to create a type, then register all properties/methods on it-- worth noting I completely fall into this case) I would argue it's the inferior API decision considering it adds additional hidden state/inconsistent behavior. The parameter idea keeps the constant-time lookup and is less invasive of an source change.     I'm not sure what you're trying to get at here. Each engine instance keeps its own garbage collector, and you can already interact with it through the asIScriptEngine interface. What is it you feel is missing?   I'm always on the look-out for ways to improving the garbage collection. Ideally nothing would be stored in the garbage collector until it really is garbage and has to be collected, that way the garbage collector wouldn't have to do time consuming sweeps to try to identify if an object is garbage or a live object.    I have few ideas for improving the garbage collector already on my to-do list. Maybe I'll be able to try out some of those in 2016.     This was more along the conceptual lines of separating out script data (asITypeInfo/asIScriptModule), the stuff being scripted(asIScriptObjects on a micro level, and a notion of a hypothetical asIGarbageContext larger-scale), and the stuff executing scripts (asIScriptContexts/asIScriptEngine) into more distinctly scoped concepts. This one is definitely more out there in terms of direct feature usefulness, and revisiting this I'm not sure it's as attractive as I initially thought.     Yes, looking up functions by name/signature is slow. That's why it is recommended to do it only once, and then keep the asIScriptFunction pointer.   How often do you look up functions by name/signature? Can you reduce the number of lookups by caching the result? How much time is your application spending on the look-ups?   There is always room for making improvements in the library. But there has to be really good argument for adding more complexity to the code and data-structure in order to speed up a few look-ups. Name-mangling might be possible, but there are other ways to speed up look-ups too.   Very frequently. Current use case is something very similar to Theron whereupon all game events/application to script notifications are modeled as typed data structures sent to a (possibly overloaded) handler function. The caching solution you described was something I arrived at independently, but it just bothers me that maintaining a completely separate yet highly similar lookup system is necessary when some extensions to one would largely solve the problem.
  8. Hey Andreas, long time no see! Since it looks like we're in a refactoring spell, I'd humbly like to submit some suggestions for (breaking!) API changes that would improve performance, readability, or both. In no particular order:   Is there a reason why RegisterObjectProperty()/RegisterObjectMethod() live in asIScriptEngine rather than in asITypeInfo? Not only would this drastically improve performance for more complex application APIs, (as we don't need to repeatedly look up the type) but the error handling could be radically simplified as we don't need to handle cases where the name string doesn't refer to a previously registered type, etc. This seems like a no-brainer and it looks like most of the infrastructure is in place anyhow. What's the consensus about pulling asCGarbageCollector or something similar into the public interface? While I don't know if this would be practical in the general case, my engine project currently can currently run multiple game worlds concurrently and it'd be nice to have them all run garbage collection in parallel with one another. Likewise, there would be fewer individual objects in each collection which would improve GC latency over what we have now. Building off the prior idea, what if we move the CreateScriptObject() family of functions into the proposed asIGarbageCollector interface? Looking up functions by name/signature is *super* yuck from a performance perspective. Could we perhaps hash a combination of the signature and argument type ids to avoid the mega-gross linear search through all registered functions in the type? Is it even possible for the multiple matching function case to occur in practice? As a final, long-shot bit, what are the odds of moving the project over to GitHub? Things like pull requests become super-easy if you're interested in accepting more community contributions. It's pretty cool!
  9. The answer is really subtle-- it's actually implicit/handled in the projection into screen space!   It's important to first remember that the actual equations in use here are approximating overall energy distributions over the sphere/hemisphere, though a lot of learning materials just kind of present things as pretty arbitrary quantity modifications. Engineering calculus says you can chop that space up into little tiny bits, and very loosely that's what's going on when you shoot rays in a path tracer/*mumble mumble mumble* in a rasterizer. Ever seen all the cool environment map integration techniques for spherical harmonic projection, etc.? Think about applying that literal process, just from the perspective of the camera.    As a simple illustrative thought experiment, consider the case of a white triangle on a back background. If you were to hypothetically draw this triangle at increasing distances/oblique angles, then sum up all the white pixels, you should notice that the white pixel count decreases according to the inverse square law/cosine of the triangle normal with camera forward vector.
  10. Another interesting approach used by UE3 was to composite all lights CPU-side into a set of spherical harmonics coefficients, then send these to the GPU for shading. This is an awesome tradeoff for mobile where the extra detail afforded by calculating things like falloff per-pixel are harder to see and the performance benefits are huge-- lighting time is completely independent of the number of lights influencing the object!
  11. It just turns the specific value in question into something that can vary over the surface of a model instead of being uniform. Granted, ambient texture maps don't generally make sense, but it's just a question of scale and artistic intent.
  12. Generally, intensity values like that are unitless unless you specifically work out some scale for them. A fair number of archviz renderers do so in order for them to work nicely with measured IES light profiles. There isn't a *formal* standard with games/the DCC packages used to create their assets, though, as physically-based rendering is just starting to catch on these days.   Incidentally, you very much want to establish some sort of PBR framework so the values you feed into the shader(s) are used in a meaningful context, which should hopefully make sense when you think about it.   Re: quadratic attenuation-- that should again make some intuitive sense considering real-world light follows the inverse square law. You likely will see better results moving over to a simple area light model, though, as point lights are physically impossible. This would also give you a more sensible attenuation model 'for free.'   Lastly, tone mapping is pretty much entirely an artistic process, you fiddle with it until it subjectively 'looks good,' and that's that.
  13. If your platform offers the ability to configure graphics settings, sure. I think a lot of folks don't mind the *option* to burn GPU horsepower should their hardware afford them the opportunity. For lower-spec systems, post-process-based antialiasing systems could offer a reasonable, low-cost(!) alternative.
  14. Yeah, skinned animation will still work perfectly fine; after all, what is a rigid animation but a mesh skinned to only one bone with unit weight ;)
  15. I would generally not use the term 'bump map' to describe it as that's a reference to an entirely different, very specific technique that just so happens to use a similar-looking texture as an input.   In simpler terms, you're using a distortion shader that adds or subtracts a value to the texture coordinate (distinct from the value sampled from a texture at that texture coordinate, though the actual offset would be taken from a second texture) depending on the location onscreen. tonemgub's soltution is basically to paint a texture that contains offsets gradually pointing towards the middle of the screen, with decreasing magnitude as you move away from one of the corners. It would work, but is likely more computationally expensive than it could be.   Fortunately, folks have already worked out how to do most of this with math. If you're interested in a really detailed CRT monitor simulation, give this neat site/shader a gander.