• 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

576 Good

About mightypigeon

  • Rank
  1. The rounded edges are due to your shadow filtering, perhaps try D3D11_FILTER_MIN_MAG_MIP_POINT for your filter.
  2. If you're using bilinear filtering (or any kind of filtering), turn it off and just use nearest/point filtering instead and see if that looks crisper.
  3.   Smoothies?  More of a soft shadow technique though.  http://people.csail.mit.edu/ericchan/papers/smoothie/
  4. DX11

    SSAO and god rays can be very pixel heavy effects and I'm guessing you're doing them at full resolution (1920x1080).  Even full screen blurs can put a fair amount of pressure on fill rate at high resolutions.  When you take into account that more than likely every one of your branches is being evaluated even if the conditions are false, this could be adding up to make a very expensive shader.   A lot of these effects are rendered to smaller render targets, such as something like 1/4 size of the backbuffer (experiment with the size to get a good image quality vs. performance trade off).  And as mentioned above, even though it's 2013 we still really need to be using the preprocessor for our branches rather than if statements.  My recommendation would be render SSAO to a small target by itself, then god rays to another small target by themselves, then have your big post process shader at the end composite those effects along with blurs and distortion etc. using #defines to turn effects on and off as needed.
  5. Speaking of profiling and performance tracking, riting your own lightweight profiler is a great way to keep on top of how different bits of your game are performing.  You set it to run per-frame and record timings for various bits of code.  This is valuable for knowing where to look when you get performance drops during development - you might think the hit may be coming from what you're working on, but another part of the code has been affected.   A good example/tutorial is here: http://www.rorydriscoll.com/2009/04/21/direct3d-11-multithreading/   I wrap certain functions up (culling, physics update, particles update, game code update, rendering, etc etc) in a profiling event and output a colour coded graph so I can quickly see what's going on.  No where near as fine grained as a proper profiler but I feel it's much more useful!
  6. Your "object" struct has doubles whilst it seems like ODE is using single precision floats for dReal.  You can instruct ODE to compile using doubles instead of floats (the default), perhaps you previously had this in your compiler options.   This page has some information on how to configure ODE to use doubles (though unless you really need the precision I'd recommend just using floats...) http://ode-wiki.org/wiki/index.php?title=Manual:_Install_and_Use   --enable-double-precision enables double precision math   Further down:   Add one of the preprocessor symbols dSINGLE (single precision) or dDOUBLE (double precision), depending on how ODE was configured. If none is defined, single precision is assumed; if the wrong precision is enabled all floating-point data going in and out of ODE will be corrupt, producing all kinds of errors.
  7. Back in the day I used C# for the interface with a small helper DLL written in C++ which was used to communicate with the engine using .NET interop.  It was a pain.   Lately I've been doing it the other way around, I was playing around with WPF and enjoyed it so now I have written a couple of dialogs for the editor using it and C#.  They export to a COM library.  After a lot of mucking around, the end result I can load up those WPF windows in native C++ using COM - no managed C++ or C++/CLI stuff at all, wanted to keep that away from the engine.  I ended up pulling an all-nighter to get it going, and I'm having nightmares just thinking about it again, but it's one of those things that once you do it the first time, it's there forever.  Definitely a learning experience!         Rendering ad-hoc lines and labels and things like that is definitely worth implementing, even if you aren't writing an editor.  It can be a life saver down the track as you can quickly implement debug drawing in your game code (draw an AI's navigation path for example)   And speaking of gizmos, here is something I found that I found a while back: https://github.com/CedricGuillemet/LibGizmo Works great.
  8. My editor uses the game engine.  That way it's more or less WYSIWYG, so what you're working on in the editor will pretty much be what to expect in-game.  It's actually part of the main engine project but abstracted enough it could probably be a separate application and just reference the engine DLL.  I use wxWidgets for the interface.   The actual 'game code' is not really referenced at all by the editor (it is in its own DLL), just the renderer is used.  Everything is data driven so game entity definitions are loaded in from the script system which is actually separate from the game code.  (part of the engine).   It does make things a bit more difficult, as normally you would have certain objects in different data structures (static objects vs. dynamic objects for example), and since any model can be moved around you need to be able quickly update these in the background.  We also have a fairly complex shadow system so when lights are moved around part of their shadow maps need to be quickly recalculated as well (VSM shadows).     This is easy enough for small scenes but as levels get bigger and more complex you need to be able to do this super quickly so the editing experience is impacted by poor performance or things popping everywhere.   There are lots of other things like being able to hot-reload assets in the engine, which means a little bit of extra work on the resource managers, but this gives the added advantage that you can update a texture or model even when in the game without having to open up the editor.   The editor code isn't the prettiest (I don't think it ever is...) and is bit of work to get going but definitely worth it in the end.  It's good being able to open the game up to test things out and having it look exactly as expected.   Bonus screenshot...  
  9. [quote name='krippy2k8' timestamp='1344916895' post='4969307'] Personally I like to just use the file modification time stamp for local files on the platforms that support it for better performance. Then it is also feasible to do the checks continuously in the background at runtime for live updating. Just compare the time stamp of the binary file vs the readable files. Some platforms like Windows provide support for watchers that will let you know when files in a directory are modified as well. I just use hashes for syncing over the network. [/quote] I did this, and it was very fast and easy to implement, but artists got annoyed when trying to roll back older versions of assets and the cache wouldn't update itself (because the timestamp of the old file was older than the timestamp of the cached file). Hashing is definitely the way to go. (You can always do both and give the ability to turn off hashing to speed up loading)
  10. Sleep() may do the trick... it won't allow for a fine range of tuning but will give you a general idea of how things are going... If you have a high performance timer (ie something using QueryPerformanceCounter) then you can sit in a loop checking the time each iteration until you hit your desired limit - I use this in my engine to implement a frame rate cap, so at the end of the game loop it will sit in a while loop until the total frame time has hit the frame cap: ~16.66ms for 60 FPS, 20ms for 50 FPS, etc etc (1000/fps will give you the miliseconds). In most cases, however, your game loop should be designed to be framerate and speed independent... this may give you some ideas: http://gafferongames.com/game-physics/fix-your-timestep/ Finally, just a little note... although I recommended Sleep above for testing, you should avoid using Sleep in production code completely... it's not very reliable and the OS may start doing things in the background (context switching to another thread/process which may eat up a lot of time). Hope this makes some sense!
  11. Here's a photo from a while back (I still have the exact same setup but my desk has a lot of junk on it right now...). This is my work setup. I put the netbook and extra tablet in as a joke, but you get the idea. Can't bear to code on landscape monitors anymore... [img]http://i43.tinypic.com/oad7wn.jpg[/img] At home I have one landscape as the main monitor and one portrait for coding. (Can't fit any more monitors on my desk at home... and don't use the PC enough to justify having more, haha)
  12. This topic is over three years old and the OP hasn't been around for over half a year, you'd have better luck posting your own topic. On a more constructive note, I played around with dual paraboloid shadow mapping in my deferred renderer (though found the results unacceptable in most cases, unfortunately). I went about things slightly differently than the different formula, so maybe you may want to try something like this (in your pixel shader): [source] float4 Pos = mul( WorldPos, LightViewMatrix ); float Length = length( Pos ); Pos /= Length; if( Pos.z >= 0.0 ) { // pick from front map Color = 1.0f; } else { // sample from back map Color = 0.0f; } [/source] where LightViewMatrix is, as it's name suggests, the view matrix for your light. This is typically facing forward from the lights position, however you may want to point it up or to the side to move the location of the (annoying) seam. EDIT: I think I misread the question! But I'll leave this here anyway in case it helps someone...
  13. Why are you so against Win32? It seems strange to dismiss an entire language because of that. Win32 will make up a tiny fraction of the boilerplate stuff for a game project, the majority of the game code is not dependent on anything. Java still uses win32 under the hood. There are application toolkits and libraries for C++ like wxWidgets and Qt which allow you to do the things you want to do without having to touch Win32, but you will never see such a thing in the STL/standard library
  14. I do something similar to this: [url="http://www.rorydriscoll.com/2009/04/21/direct3d-11-multithreading/"]http://www.rorydriscoll.com/2009/04/21/direct3d-11-multithreading/[/url]