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

Tasche

Members
  • Content count

    65
  • Joined

  • Last visited

Community Reputation

222 Neutral

About Tasche

  • Rank
    Member
  1. Just on the subject of Triple A asking for C++: Not 100% sure about this, but that does not necessarily mean you will be coding in C++, its just the fact that if you can handle C++ really well, you will be able to adapt to other languages rather easily, because most modern languages abstract the nitty gritty that C++ does (at the cost of performance). Also, you will most certainly NOT start your career at those big companies, they ask for 5 years of work experience for their junior staff. And you can be sure that in those 5 years, you need to churn out kick ass stuff, because they really get to choose, and they have a reputation to fulfill (and the budget to back up being picky). What i'm saying is, along the way you will most certainly have to do several different languages, having a big portfolio and being able to work with whatever you are given, and get the maximum out of that.   So this what MrDaaark said in his last sentence is a good working/learning paradigm in my opinion.
  2. running the risk of d/ling a virus i wanted to be a nice guy and test your game. however, you compiled it with the .NET debug dll, the standard .NET runtimes don't include these. recompile with release settings and try again.
  3. Good thinking. Could you show how you got there? Which equations you used? the same ones you did, just different constants (acceleration A = g, S=d distance traveled in time t):   s(t)=v*t+(g*t^2)/2 (with s(t0)=d, at some arbitrary time t0, initial velocity v=0) => d=(g*t0^2)/2 => sqrt(2d/g) = t0 (I) for any time t: v(t)=g*t (II) is true, by calculating total derivative of s: ds/dt = v (change of distance s per time t is velocity v by definition) this is especially true for time t0: (I) substituted into (II): v0 = v(t0) = g*sqrt(2d/g) = sqrt(2dg) q.e.d.   so whats actually calculated here is the speed the object has after falling d units (starting at s=0, going to s=d, with initial velocity 0, trying to find end velocity v0). since ideal newton physics are symmetric in time its the same the other way around.
  4. a bool would work. but that's an int in c++ however... you also may want to consider using bounding spheres instead of boxes, if your application allows that. (point-plane-distance test is easy and quick, no fiddling with signs :) )
  5. i'm not sure this will help you, but i think this may be what you are looking for: http://msdn.microsoft.com/en-us/library/windows/desktop/ff476523%28v=vs.85%29.aspx   i personally have a fixed maximum number of bones and use the constant buffer, and send the updated matrices by mapping that buffer. calculation of those matrices from quaternions is done on cpu, only the skinning itself (vertex transformations) is done on gpu, and stored in a dx buffer using stream output.
  6. if the angles are really really small, you might get away with it (actually pretty sure you will). nlerp is already approximating, so you want to minimize the error. if the angles for your source rotations are almost the same, you also won't notice any additional error. if they are too different, the blend will differ significantly from the expected animation. from personal experience i would say if the renormalization constants differ around 2-3% it already gets noticeable (like a slight awkward twist in a joint). just try it out, if your keyframes are tight enough, it should work out. however i would suggest you go for normalizing in between, since the nlerp approximation only changes speeds, not angles or axis, unlike interpolating unnormalized quaternions. and a few square roots less are not worth getting crappy animations. by the way, the problem multiplies the more animations you blend. also, as a general rule of programming (imho), is get stuff working perfectly and as expected first, then optimize and judge the quality/speed tradeoff. especially for something so easily implemented.
  7. yes... there's a reason these titles consume huge budgets
  8. short answer: no. post back here if you need the long answer.
  9. read the posts on this stackoverflow page for a discussion: http://stackoverflow.com/questions/1228161/why-use-prefixes-on-member-variables-in-c-classes i personally go for Jason Williams approach, have yet to see the bad side of prefixing.
  10. ah sry to dig out this old one, but just for completeness, i tried the alpha = 0 version and just setting first pass target to 0 is marginally quicker. so if anyone ever wondered, go for a nulltarget =)
  11. How do you do bloom with only one render target? Eg, do you only use one for your blur pass? nope, of course i got a bunch of smaller targets... but they are, well, smaller^^. didn't think quarter size was worth mentioning
  12. DX11

    i also switched from dx9 to dx11 like a year ago, and it seemed a annoying and not straightforward at first, but actually, it is. you will also love the new DXGI system, no more stupid resets when going fullscreen, or doing other stuff which involves display. all handled natively by the API. that's all i can vaguely remember, and its something positive =). so switching will be rather easy and rewarding for you, i'm sure.
  13. very interesting thread...   gbuffer: 1 FP32 rgba bit (will probably be dropped once i reconstruct position from depth) 2 FP8 rgba   bloom: 1 halfsize FP8 rgb   distortion: 1FP8 rg   shadowmap: 1 2048x2048 FP8 r   light accumulation: 1 FP8 rgb   i guess im being very wasteful with memory, but optimizimg should be the last step of the process right? =)
  14. thats the way i do it. the animation data is already loaded as quarternions, then gets interpolated that way, and only before final composition with bonematrix do i convert. (also cuts load time a wee tiny bit i guess)
  15.   Thats some pretty sound advice dude, ta muchly. However you lost me a bit with "first, directly output all your inputs as color (in this case, esp. the normals) and check if they have sane values (represented as colors in the framebuffer) you might want to pack them before outputting them (something like (normal+1)/*0,5), so you get the full range."   So you mean use my normals as colours? frag_colour = normal.xyz?   Also, what's this doing ( x) / * 0  ?   Thanks again dude yep, exactly. something along the lines of: cbuffer { float4 something; } struct vsIn { float4 position; float4 normal; float2 tex; } struct psIn { float4 position; float4 normal; float2 tex; } psIn vsmain(vsIn input) { psIn output; ...some vertex manipulations... output.position = finalPos; output.normal = rotatedNormal; output.tex = input.tex; } float4 psmain : SV_TARGET { float4 ret; ...some cool lighting done here... return ret; } now just before you 'return ret;' you insert: ret = input.normal; for example. if that is already messed up, pass the normal from the vertex shader untouched (may have to add an extra var using the texcoord semantic in psIn), and output that first. psIn vsmain(vsIn input) { psIn output; ...some vertex manipulations... output.position = finalPos; output.normal = input.normal; //<----change to this output.tex = input.tex; } use this for quick and dirty 'judged-by-eye' tests   that was just another way to show you how typos work. was meant to be (normal+1)*0.5. this moves normal component values from -1,1 range to 0,1 which can be viewed as rgb.   good luck finding your errors!