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

RobMaddison

Members
  • Content count

    852
  • Joined

  • Last visited

Community Reputation

1151 Excellent

About RobMaddison

  • Rank
    Advanced Member

Personal Information

  • Location
    UK
  1. Managed to get a really nice and natural effect using a bit of dot and normal trickery.  The good thing is that when you get further away from the rocks and the LOD changes, the material also changes to one without normals and at a distance it you can't distinguish it from it's close-up counterpart - just the effect I was looking for!   http://i475.photobucket.com/albums/rr118/Purpl3Ha2e/SnowyRock.jpg
  2. Thanks.  I'm willing to put in as much as it takes to make it look convincing.  I hadn't thought of virtualized textures so that's an idea but I'm not sure that it would be worth its quality seeing as most of the mountain will be white.  It's a third person game.  Also, rocks at far away distances would use the low-resolution parts of the virtualized texture so unless I get it just right, I think it would perhaps suffer from the same granularity issue as using my lo-res surface textures.   On a side note, if you draw a rock mesh at a distance and it overlaps another mesh, does that cause an actual degradation in performance for another reason other than it just meaning you're drawing pixels two/three/multiple times?
  3. My game requires rendering of a relatively large snow-covered mountainous terrain. Most of the terrain, probably 80% of it, is pure snow with some detail texturing but there are areas of it, mostly near-vertical areas that have exposed rock under the snow. My terrain system is fairly standard I think and allows me to render chunks with a lo-res texture combined with detailed textures. At a specified distance, the detail texture fades out leaving the lo-res texture at distance. Unfortunately, whilst the lo-res texture is great for things like giving some features to repeating textures (like grass or rock), it's too low to use for rock exposure at distance (and in fact up close as the highest resolution it gets is generally one pixel per metre). My current idea is to use LODed geometry for the rocks. My material system allows me to add a second texture 'layer' to the material exposed by an alpha channel, so the base texture would be mountain rock with the relevant normal and specular maps, etc and the snow texture would be the second layer. To add some variety, I'd need to create several materials, each with the same textures but different alpha maps. I think I can probably achieve a fairly organic look with a handful of rotated and scaled rock meshes and a few of these double layered materials. Before I embark on this, is it a good way of doing it? I don't use texture splatting for my terrain, I use multi-pass layers drawn using index buffer lookups. Because the layers use the same geometry as the terrain tiles (32x32 @ 1m resolution), this is not fine enough to use the sort of granular splatting you'd need (ie with a hi-res blend map). Thanks
  4.   Hi, thanks for the response   I did try that and whilst it does align the rotation with the screen when the object is in the centre of the screen, you still end up with perspective skewing when you move the camera:   http://s475.photobucket.com/user/Purpl3Ha2e/media/Gizmo/Image1.jpg.html   http://s475.photobucket.com/user/Purpl3Ha2e/media/Gizmo/Image2.jpg.html   The first image shows the object selected whilst in the centre, and the second shows the camera moved to the side.  Although the rotation of the gizmo is correct, the perspective of the camera is skewing the gizmo.  Should I be rendering the widgets using an ortho projection?
  5. I have a 'gizmo' in my level editor which I use to rotate, translate and scale objects.  The gizmo is just a mesh which has 3 arrows pointing along each axis, you can hover over and click on the arrows to move, translate etc - standard stuff.  The gizmo is drawn at the same position as the object it is targeting but is a set distance away from the camera so however near or far the object is, the gizmo stays the same size.  This all works fine. What I'm trying to do now is offer local, world and screen coordinate systems for rotating, translating, etc.  local was simple.  I basically borrow the world matrix from the targeted object (the thing we're rotating) - removing the scale.  For world, even simpler as there's no rotation at all so it's just an identity matrix set to the position of the targeted object (again set at a certain distance away from the camera).   Screen space is causing me lots of headaches.  My train of thought was that I would use the inverse view projection matrix of the camera which will effectively remove what will be added at the rendering stage leaving the object oriented in alignment with the screen.  This does work to a certain extent, the orientation of the gizmo stays in the right position inside the object and in an orientation aligned with the screen no matter where my camera is situated.  The problem is, the view projection matrix intrinsically contains scale (for perspective) which causes my gizmo to get smaller the further away from the object I am - even though the position of the gizmo is still that set distance away from the camera.   I've tried lots of different methods of removing scale but it always messes up the rendering of the gizmo.  Is there a better way or a step I'm missing?
  6. Thanks everyone, after some testing I went with rendering a smaller quad against the large texture, works great.   Also, I didn't intentionally double-post, I initially posted it and gamedev reported an error twice.  After I checked to see if it had gone through despite the error [both times] and it hadn't, I tried again.  I'm a regular on this site with a lot of posts so I can't really understand why anyone would assume I had double-posted intentionally.   I also received a warning about it from a mod - not appreciated at all after contributing to the site financially and it being gamedev's fault.  *shakes head faster than finger*
  7.   Thanks, I did some googling but couldn't find anything obvious - I was wrongly looking for locking
  8. Is it possible to do this in direct X 9? I'm rendering to a very large texture but I only want to update a relatively small region of it. Seems wasteful to render the whole thing?
  9. Is it possible to do this in direct X 9? I'm rendering to a very large texture but I only want to update a relatively small region of it. Seems wasteful to render the whole thing?
  10. One last advice - profile obscure problems on multiple machines, or use safe mode to test application deployment unlocal requirements, or to identify spoils, as veteran development machines are generaly spoiled as it can get. I don't have another machine I can use at the moment, but yes, that would have been a good early indicator of the potential issue
  11. I finally got one of the profilers working and to my utter astonishment, it didn't leak any memory.  But in order to get my application working with the profiler, I had to fix the error it was giving me about the Microsoft Application Verifier.  I tried virtually everything to remove/uninstall the Application Verifier, even manually removing references to it from the registry (backing up first of course) and deleting the exe from the Windows\System32 and SysWOW64 folders.  That still didn't work.   I then, by pure chance, stumbled across a thread on a forum that mentioned there was an area in the registry which lists image file execution options for applications with which to start the Application Verifier, my editor was in there but my game was not.  When I removed the entry for my editor from that list, the profiler started working and I'm back to running my app standalone with 8192x8192 terrain in under 800MB as expected.  Quite an obscure one!!   As usual, thanks a lot to everyone for all your great help and advice
  12. Well I've had no luck with any memory profilers, there's always something stopping me from getting a good set of results, one app I tried wouldn't run because it said Microsoft Application Verifier needed to be disabled and after spending hours trying to disable what wasn't even running, I gave up. I also tried one called MTuner which showed lots of promise and looked quite polished only to fail with a completely unhelpful error. I tried the Net profiler mentioned above which did allow my app to be profiled, but it showed the significant chunk of memory was in unmanaged as <unifentified> not overly useful but at least it showed there's nothing on the c# side that is using lots of memory. I tried changing my test entity object (the one I used to create 87k instances on the heap) so it didn't use boost shared_ptr in the map and vector and the memory usage was a lot less
  13. The huge chunk of memory does not release afterwards, but at that point, nothing that is created should be released. The only data that is new'd is data that should exist in engine until the next level is loaded. There aren't any strings used in this operation. It'll be difficult to remove the vector and the map as they're integral to the entity class and would require a large refactoring job. I added the same vector and map to my test object that I created 87k times and it caused the memory to soar again so I'm guessing it's something to do with these members. When I get back to it this morning, I'll try adding those members but with straight pointers rather than boost shared pointers.
  14. Interestingly, I reduced my Construct method down to a very simple loop from 0-87000 doing:   for (int i = 0; i < 87000; i++) {     new Entity(); }   and immediately return.  So the method is no longer iterative, this is all it does and it still eats up GB of memory.   sizeof(Entity) returns 744 bytes.  I created a simple test class with 12 matrices in it which returned a sizeof of 768 bytes.  Creating 87000 of these does not drastically increase memory at all, in fact it went up around 66MB which is roughly how big that would be.   In my Entity class, I don't really have anything overly special, a std::map, a std::vector, a few pointers, a couple of matrices and several value types.  It must be something to do with the std::map and std::vector classes.  Both collections have boost::shared_ptr objects in them, I'm now wondering if this has something to do with boost.
  15. The only object I create on the c# side (that is possibly related to the memory issue) is the scene object wrapper which exists throughout the whole session. The scene object is essentially the interface between the c# front end and the scene. Because I'm not passing memory (of any significance) between unmanaged and managed (and vice versa), I'm not sure it would make a big difference. The only thing I do pass back are simple value types or strings and those get free'd correctly. I'll do some profiling and see if I can see what is using up all this memory.