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

Drilian

Members
  • Content count

    891
  • Joined

  • Last visited

Community Reputation

1067 Excellent

About Drilian

  • Rank
    GDNet+
  1.   That's an apples to horseshoes comparison, though, unless I'm misreading - they're comparing the timings of two different techniques (both of which are running in compute from the sound of it) and comparing the timings of each. Yeah, the constant-time shader is slower, but it's solving a different problem. You wouldn't use that for a small kernel because of all the extra overhead involved.   There are other ways to make compute blur faster (like using groupshared memory which doesn't seem to be mentioned in that article, which can drastically reduce your memory accesses), but it doesn't say anything about comparing a 1:1 pixel shader:compute shader version of the same operations.   Also, how you decide to break your compute shader up can make a difference with performance (including cache coherency) - if your compute shader's thread groups load/store things in BLOCKS as opposed to in scanlines, you're likely to get better coherency group to group because you'll be writing into places that are related in memory, as I understand it.   I don't think that compute postprocessing is NECESSARILY slower than a pixel shader, but it does likely depend at least partly on how you've got it set up.
  2. Thanks for the info. Yeah, that kinda sucks (it's a sad regression from D3D11), but I've at least worked around it in the short term by having a simple copy postprocess (via a pixel shader) that gets things onto the backbuffer and still allows all of my postproc to run as compute (as you suggested).   Thanks again!   EDIT: I suppose I could use CopyTextureRegion instead and use that fancy DMA hardware that may or may exist, if I'm already using a backbuffer-format-compatible texture by the time I'm at the end of the postproc chain. But a pixel shader works well enough for now.
  3. Hey! I was hoping to do all of my postprocessing (tonemapping, bloom, etc) in my D3D12 renderer using compute shaders, Thus, I think, in an ideal world I'd just write to it as a RWTexture2D<float4> in the compute shader and blast the processed colors out directly.   However, IDXGIFactory4::CreateSwapChain fails if I try to specify a BufferUsage that contains DXGI_USAGE_UNORDERED_ACCESS ("DXGI ERROR: IDXGIFactory::CreateSwapChain: The BufferUsage field of the swapchain description contains some DXGI_USAGE flags that are not supported.")   Without that, I can't create an unordered access view to it, or transition it into the proper state using a resource barrier, so I can't seem to write to it using a compute shader at all!   Is there a way around this (another way to write to a texture from compute, or another way to create a swap chain that plays nice), or should I just go back to postprocessing using pixel shaders like a caveman?
  4. For what it's worth, Infamous: Second Son used the particle system to render up to 25,000 raindrops near your field of view, and uses a rain "shadow map" to determine where the particles should spawn (and end). That includes, I believe, the particles for the splashes on objects (which are randomly scattered throughout the view and spawned wherever the rain shadow map's depth says they should be for that point). The splashes, I should note, are not tied to where the actual raindrops intersect the ground - it turns out that totally doesn't matter.   Using a nice GPU-driven particle system on relatively modern hardware, you should be able to handle particle rain like that fairly efficiently.
  5. You need to sign up for a creator's club account to be able to submit to Xbox Live Indie Games. It's $99/year, but it's what allows you to develop and release on the Xbox.   People are still releasing XBLIGs, so it's definitely not disabled :)
  6. To expand on Jutaris' comments, XNA is not DEAD. It's just not being developed anymore.   However, everything that XNA has done in the past (PC/Xbox/Windows Phone 7 games), you can STILL DO. You can still get XNA, you can still write games with it, you can still release those games on any of the ever-supported platforms.   All "XNA is dead" really means, as it's stated is that Microsoft is no longer planning new revisions of it, so we're stuck with XNA 4.0 unless they change their minds.
  7. I can sort of see both sides of this one: 1. It's stonemetal's personal blog (hosted by gdnet), and thus, he should be able to moderate comments if he wants, just like he could if he'd posted it to Wordpress or some other standard blogging site. 2. It's on gamedev.net and part of all of the content here has traditionally been the ability to freely comment on, without restriction. Personally, I would like to see gamedev not allow this sort of comment moderation on dev journals hosted here, as it would keep the content posted to the site at a higher standard of accountability, but considering other choices made in the site redesign, I don't think that's particularly high on their list. If he wants to moderate comments on his posts, he could post them to a 3rd party blog, but I'd personally prefer it if journals on gdnet didn't have that capability. tl;dr: I agree with Aardvajk on this one
  8. Great so far! The music in the title screen is really chipper considering the hellish, fiery landscape in the background I have trouble still keeping track of my arms...it'd be nice if they were labelled with L and R instead of just the colors (or, better, keep the colors but only show them to the left or right half of the "hand" depending on which button it's assigned to) so that I could better track which was which... I had the same problem with the orange/blue portals in Portal, so you're at least in good company Your transitions between scenes are lovely! Very smooth, very nice Keep rockin' it, it's looking/playing pretty solid!
  9. No, it doesn't take that much time! It's not like I've been working on this project for three years or anything like that! Wait...it IS? I HAVE? Fffffffffuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuu<connection terminated>
  10. [quote name='way2lazy2care' timestamp='1294774225' post='4757356'] It said quite plainly in the "rate this user" dialogue what it meant. I am sorry that so many people don't read the dialogue before clicking it or assume that it means something that it isn't meant to. [/quote] You're right. It very clearly said something along the lines of "helpful or friendly" which is not, at all, just the "technical competence" that you have mentioned. Overall, I basically agree with MikeP. While I do like the concept of rating posts rather than users, I feel like not being able to rate posts DOWN is, overall, a detriment to the community in my opinion.
  11. Quote:Original post by Aardvajk Glad great minds thinking alike [smile]. You're updating your journal even less than me at the moment. What are you up to? And where the hell is Milkshake? Bought an island off the iPhone sales of Melon Golf and given up gamedev I reckon. Hah...I guess I should probably update my journal ever again, eh?
  12. That's the exact same mechanism I ended up using for Procyon's enemy flight paths, to get constant speed :) Glad I'm not the only one that backed off of the ideal of pure curves and went with subdivided line segments instead :)
  13. OH GOD! UNCLICK! UNCLICK!
  14. niiiiiice! Nobody would ever accuse that of being programmer art :D
  15. Congrats! While it's decidedly simpler than your last two games, I will say that I played it for much longer while peer reviewing it than I'd intended to, so you obviously did SOMETHING right :D