Jump to content

  • Log In with Google      Sign In   
  • Create Account

We need your help!

We need 1 more developer from Canada and 12 more from Australia to help us complete a research survey.

Support our site by taking a quick sponsored survey and win a chance at a $50 Amazon gift card. Click here to get started!


Member Since 22 Feb 2006
Online Last Active Today, 10:03 AM

Posts I've Made

In Topic: default install folder for windows game

29 July 2015 - 12:05 PM

I'm using NSIS, not InnoSetup, but I install to:


Which works out to "C:\Users\gdunbar\AppData\Local\TotAW" on Windows 7. I believe when I researched that this was "the right place" to put an application such that it could be installed and run by a non-admin user, but I don't have that research handy. Seems to work well enough.


Good luck!



In Topic: Messing with the depth buffer for skybox effect

09 April 2015 - 04:09 PM

EDIT: Hey you're right, if I draw the planets and skybox first and then clear the z buffer, I should get exactly the output I want. I guess the only complaint would be that often the skybox takes up very little of the screen, and is therefore usually drawn last.


You're worried about the performance of drawing the full skybox, when usually it would be mostly blocked by objects in front? I'm hardly an expert on graphics performance but I wouldn't think it would be a big deal.


If you're really worried, you could experiment by drawing the skybox a bunch of times per frame and see how many you can do before it affects frame rate. If the answer is in the single digits, maybe worry about it... if in the hundreds, safe to ignore. That would be easy enough to do, and should quickly assuage your fears without doing serious profiling or anything.



In Topic: Messing with the depth buffer for skybox effect

09 April 2015 - 03:24 PM

What if you just clear the z-buffer after drawing your planets, but before drawing everything else? You could even futz with the projection matrix at the same time, and, as you say, "make it real" by drawing the planets at their proper distance.



In Topic: Writing code more general

02 December 2014 - 09:46 AM

The void pointer thing is troublesome. I may be missing some of the fine points, but to me, the point of having an interface like IMeshLoaderPlugin, and a method like IMeshLoaderPlugin::loadFile, is that, given an IMeshLoaderPlugin, you can call loadFile() without knowing what kind of plugin you have. In this case, that is lost; if you have an assimp plugin, you have to give it an AssimpDesc or it will fail. Worse, it will fail at run-time, not at compile-time.


So, my question to you: Is there some good reason to have a generic IMeshLoaderPlugin::loadFile method, and the related IMeshLoader::load function? Why not just have separate AssimpLoader::loadAssimpFile and HeightmapLoader::loadHeightmapFile functions? You may well be getting some other benefit from the generic IMeshLoaderPlugin::loadFile method that I'm just not seeing. However, if I were you, I'd be looking at my class abstraction carefully. If you really have plugins that are not interchangeable, then you probably don't need any of this enum stuff in the first place.


Anyways, I hope that's a little helpful. I've probably asked more questions than supplied answers. Good luck!


In Topic: Problem with Guest comments on Dev Journal

13 November 2014 - 07:28 AM

How much spam are we talking here? If I'm going to get more than a couple of spams a day, I'm not sure I want to moderate comments anyways. In that case, I suppose just making it more obvious that registration is free is probably the best I can hope for.