• 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

133 Neutral

About nietakt

  • Rank

Personal Information

  • Location
  1. Any chances of getting an answer or a hint?
  2. I am having problems when trying to PIX-run apps that use D3D11 API but at D3D 9.* feature levels. The very same app built using feature levels >= 10.0 does not generate such problems. It's hard for me to list all the things that are unavailable, but the issues I've come across so far are: (i) the inability to view geometry (Mesh tab) and (ii) depth buffer. All the information I get from PIX is the following vague message "There was a problem". I am attaching screenshots illustrating the issue for a very simple app (a single non-textured quad) - one is for 10.0 and the other for 9.1 FL. Is this a known issue? Do you happen to know how to make PIX fully functional for D3D11 at 9.* feature levels? Thanks [img]http://public.gamedev.net//public/style_emoticons/default/smile.png[/img].
  3. Oh, so it seems I cannot grasp the logic behind your approach . If you do use the technique described in gamasutra, you should have several shaders (for separating glow sources, blurring and combining). I think we will sort it out, but I need you to post all the shaders and also describe what you do on the CPU before and after launching them, since I cannot really get much from just a single PS.
  4. I cannot really understand what you are trying to say here, but the glow as I know it is approached a bit differently: [list=1][*]you first draw the glow sources to an intermediate texture (let's call it glowTex);[*]you blur glowTex texture;[*]you add the original image to the blurred glow sources texture;[/list] As far as (1) is concerned - I guess you want to do a simple multiplication of the non-glow pixel color and the pixel value from your mask-texture to pick only those pixels which are supposed to glow. I suggest you read this [url="http://www.gamasutra.com/view/feature/2107/realtime_glow.php"]article[/url] from gamasutra. I am bit anxious that I may be writing obvious things while you're trying to achieve something I cannot comprehend - if so, I apologize .
  5. Okay, did it :]. The first rating was not from me, seems somebody else has found your reply helpful as well. See you some other time, nietakt
  6. Yep, that's it! unbird - thanks a lot^2 . (I tried to rate you, but couldn't find the proper switch).
  7. Hello! Just a short preamble before I actually begin - precision and repeatability of computations is *very* important to me, that is why I even noticed the issue to be described in a sec. Well, calling the Device constructor does *something* to the calling thread. I cannot say what it is (hence the question), but it changes the way this thread multiplies doubles. Resultantly, the thread seems to cast them to floats and back to doubles. Here comes the example: [code] //init. //... //double multiplication test double a = 0.86602539649920685; double b = 1.0000000000000000; double c = a * b; // c = 0.86602539649920685 //device creation _device = new Device(d3d, iAdapter, devType, this.Handle, flags, _presentParams); //double multiplication test double d = 0.86602539649920685; double e = 1.0000000000000000; double f = d * e; // f = 0.86602538824081421 [!!!] double g = (double)((float)d * (float)e); // g = 0.86602538824081421 [!!!] [/code] And as of now, the thread will do the same lousy thing whenever it stumbles upon double multiplication. However [list][*]calling the very same multiplication in a separate thread (once the main thread has gone through device creation) -> okay[*]forcing the device creation to a separate thread (just for testing) -> the main thread remains okay[/list]and that is why I guess it must be a certain thread 'setting' or whatever. The question: what is the reason for this and can I sanely undo what device creation seems to be doing? Thanks
  8. Okay, now I get it :). Thank you for the sound explanation, jpetrie. See you next time!
  9. No ideas? Or maybe my mumble was unclear?
  10. I don't really get the whole picture, but I've noticed a strange detail. tweenEffect->SetMatrix("proj",&matr);//Used to be SetVertexShaderConstantF() tweenEffect->SetMatrix("view",&matr);//Used to be SetVertexShaderConstantF() I may be missing something, but you seem to pass the same matrix (whatever it holds) as both view and projection and then multiply them in your VS. Is that what you need?
  11. Hi there! As the subject says, I'm having a problem with DepthStencilSurface in SlimDX & D3D9. The thing is that according to my general experience/observation and [url="http://scientificninja.com/blog/com-and-slimdx-part-1"]this[/url] article all the DX objects NOT created by the application explicitly don't need to be released (= no need to call Dispose() on them). And this works e.g. for the backbuffer: [code] Surface bbuf = dev.GetBackBuffer(0, 0); //doing something super-duper with bbuf... //then doing many other things (device is still using the same BackBuffer) //quitting the application //=> no leak (Total of 0 objects still alive.) [/code] However, when I get the DepthStencil surface, it keeps leaking: [code] Surface ds = dev.DepthStencilSurface; //doing something unimaginable with ds... //then doing some cool stuff again (device is still using the same DepthStencil) //quitting the app //=> Object of type SlimDX.Direct3D9.Surface was not disposed. [/code] Then again, if I do call Dispose(), like this: [code] Surface ds = dev.DepthStencilSurface; //doing something mind-blowing with ds... ds.Dispose(); //then doing some cool stuff once again (device is still using the same DepthStencil) //quitting the app //=> no leak [/code] I find it pretty counterintuitive - is there any reason for this? Thanks :). P.S. SlimDX guys - this question is in no way trying to belittle your efforts, SlimDX is very useful and handy - thank you for your work :). [Edited by - nietakt on October 23, 2010 4:29:56 AM]
  12. Emm, okay, I was wrong. This thread can be killed. Just in the very improbable case some of you had the same problem: in the linked article, when you look at the page number 10, you will see that the blurriness measure (f) is forced into the interval [0, 1] (with 0 and 1 both representing max-blurriness and 0.5 no-blurriness), which makes the aforementioned line simply making discRadius value be in the range [0.5, 5] proportionally to the blurriness measure, with a "minimum" at 0.5. It also makes me feel like a moron. Sorry you had to go through that and see you in different threads, nietakt ;] [Edited by - nietakt on January 16, 2009 8:21:52 AM]
  13. Hello I am trying to create a DOF shader roughly based on the article/presentation: http://ati.amd.com/developer/gdc/Scheuermann_DepthOfField.pdf Summarizing it, DOF is obtained by: [1] Pre-storing depth-and-focal-pont-based blurriness measure (per pixel) [2] Blurring the pixels basing on the pre-stored blurriness measure If you think I should write something more - please tell me, I will expand this hyper-short summary. What I want to ask you about, is a piece of code in the page number 18 of this paper, function PoissonDOFFilter, the line where discRadius ic calculated. discRadius = abs(cOut.a * vMaxCoC.y - vMaxCoC.x); where discRadius is the radius of the Poisson disc filter kernel, vMaxCOC.y and vMaxCOC.x are the diameter and radius of the maximal circle of confusion, respectively (paper hard-sets them to 10 and 5 pixels); cOut.a holds the pre-stored blurriness measure (range [-1, 1]). The question is - why (the heck) is the discRadius calculated in such a strange fashion? As far as my understanding of this thing goes, discRadius should be simply proportional to the absolute value of the blurriness measure, however, if you draw the function y(x) = abs(10 * x - 5), you will see that this is not the case. The values (y) for negative arguments (x) will grow faster than the positive ones (head-start of 5), and for the x-interval [0, 0.5] y (discRadius) actually decreases with the growth of x (blurriness measure)! Well, either I am totally mistaken here or, hm, or I don't know what. If you can make anything out of it - please help. Thanks! PS I guess I can only expect help from someone, who has actually gone through this article or knows the case from their own experience, since my summary cannot be really helpful with my question.