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

lunkhound

Members
  • Content count

    35
  • Joined

  • Last visited

Community Reputation

1332 Excellent

About lunkhound

  • Rank
    Member
  1. There is a Unity tutorial on making a 2D roguelike.
  2. The vertex shader is outputting a VS_BASIC_OUTPUT while the pixel shader is expecting a VS_LIGHTING_OUTPUT as input.  The VS_BASIC_OUTPUT structure is not shown, but if it differs from VS_LIGHTING_OUTPUT that could be the problem.
  3.   Well PNG is for compressed raster/bitmapped images (i.e. a fixed resolution).  I don't know much about SVG but from a cursory look, it seems to be a vector graphics format, where shapes are described with curves and such.  PNG and SVG are really very different.  You wouldn't want to save your raster images as SVG, as much would be lost in the translation (I'm not even sure if SVG can do raster images).  Likewise you wouldn't want to save vector based art in PNG format as that would lose all the scalability.   There is software that can convert from a raster format like PNG to SVG, but I wouldn't expect the results to be very good for detailed images like what you are trying to scale.
  4. This is really just an extension of what you are doing already. Take all of the details that don't scale nicely (anything with sharp edges like the little cracks and nicks, the gem inlays, etc) and make each one into a separate texture (with a transparency channel).  Remove all the details from the image so that what is left can be scaled using your existing method. Then after scaling, apply all of the detail textures (with alpha blending).  Taking some care to place the details appropriately on the scaled image.
  5. For audio, I'm using OpenAL-soft.  It isn't as full-featured as FMOD, but it is open source, and I like having the code to everything I'm using. I'm also using http://nothings.org/stb_vorbis/, a public domain Ogg vorbis decoder.   Other libraries I've found useful include: nvidia-texture-tools -- for creating compressed textures Intel Threading Building Blocks -- task scheduler for multicore processors However, I suggest taking a look at UE4 -- for $19 (or $19/mo for continuous updates to the code) you get a complete high-end game engine with tools -- with source code to everything (except PhysX, the physics engine).  It's going to be miles better than anything you'll be able to cobble together with libraries like Ogre.
  6.   If sorting particles was the bottleneck, you could use a fast order-independent transparency method such as WBOIT to skip sorting altogether.
  7. One reason against using UE4 that I haven't seen mentioned is:  because you don't get access to ALL of the source.   Specifically, the physX source remains unavailable, as I recall.  So if having all of the source code is important, that could be a dealbreaker for some.
  8. Try this:   alSourcei( mSource, AL_SOURCE_RELATIVE, AL_TRUE ); alSourcef( mSource, AL_ROLLOFF_FACTOR, 0.0 );
  9. For your largest-area covering shadow map cascade (the one farthest from the main camera), how many objects are being drawn?  How many vertices are you drawing for that shadow map?
  10. I've played with the Weighted Blended OIT method.  There is a lot to like about it:   Simple to implement Performance is very good Combines nicely with offscreen particles (where particles are rendered into a downsampled offscreen buffer) Although it is an approximation, it actually fixes the visual "popping" that occurs with particle sorting However, one big drawback with it is that it doesn't support emissive transparency.  Meaning effects like flames and such, done with additive blending.   At first glance it looks like it should work because the method works with RGB in premultiplied form, so you would think that you could just pass in an alpha of zero for emissive and it might just work.  Unfortunately not.  The weight function is scaled by alpha, so when alpha is zero, the weight also goes to zero and the effect disappears.
  11. This is a half truth. Sorting can take: Best Case: O(N) Avg. Case: O( N log( N ) ) Worst Case: O( N^2 ) 1. In best case, N/2 + N/2 = N; so in theory it doesn't matter whether it's split or not. But there is the advantage that two containers can be sort in separate threads. So it's a win. 2. In the average case, 2 * (N/2 log(N/2)) > N log(N); having one large container should be faster than sorting two smaller ones (though there remains to be seen whether threading can negate the effect up to certain N) 3. In the worst case, 2 * (N/2)^2 < N^2; which means it's much better to sort two smaller containers than a large one.   In the end you'll have to profile as it is not a golden rule. Spiro's suggestion of using temporal coherence assumes that most of the time you can get O(N) sorting using insertion sort; thus most likely having two smaller containers should be better (if you perform threading).   While I love your posts in general, this "correction" doesn't seem right to me.  Specifically #2.  With O( N log N ) run time -- worse than linear -- divide and conquer is beneficial when possible.   Plugging actual numbers into your inequality in 2 (N=1024, using base 2 log):   left side expansion:  2*(1024/2) log (1024/2) = 1024 * 9   right side expansion:  1024 log 1024 = 1024 * 10 The left side is LESS, contrary to your inequality.   Sorting 2 half-sized arrays is sometimes faster but never slower than a single full-size sort. Perhaps you were thinking of searching with O( log N ) run time -- better than linear.  In that case, doing divide and conquer IS harmful.
  12. Yes the hardware is spending a lot of time processing vertices for small triangles that don't cover any pixels.  If triangle throughput is the bottleneck, then you should try to reduce the number of triangles/vertices you are sending.
  13. For your smallest objects, only draw them for the cascades closest to the camera.  Your farthest cascade will have the largest frustum, and so by excluding small objects you can save a lot of triangles from being submitted.  It's basically LOD for shadow cascades.
  14. Additive blending, that is:   destColor = srcColor + destColor   can only lighten the color of what is underneath (because srcColor can't be negative).  Its fine for making white smoke, but not black smoke. For black smoke, you could try subtractive blending (not sure if D3D9 supports this mode or not):   destColor = destColor - srcColor   Alternatively you could use normal alpha blending:   destColor = srcColor * srcAlpha + destColor * (1 - srcAlpha)   with a mostly dark colored texture with an alpha channel that is opaque in the middle and fades to a transparent circular border.  You'll probably want some noise added to the texture to make it look smoky. Note that with alpha blending, the order the quads get drawn in matters (unlike with additive or subtractive blending) so you'll want to draw them in back-to-front order, otherwise it won't look right.
  15.   Actually, a ZFS-based NAS *could* protect against such a virus.  ZFS snapshots are a filesystem feature, not files--you can delete every file and folder on the filesystem but the snapshots are still there.  The snapshots are basically read-only from Windows.