Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 21 Feb 2008
Offline Last Active Today, 06:06 PM

#5089816 A proper way for help screen?

Posted by NightCreature83 on 28 August 2013 - 07:42 AM

Generally speaking professional UI systems don't really have position values coded out in the source code it is data for the system to act upon. This can be XML, a full scene graph or even a 3ds max or maya scene that gets loaded up.

#5089769 a map<T,T> as a default parameter...

Posted by NightCreature83 on 28 August 2013 - 03:32 AM

Just as a side note but in general strings should be passed as const reference arguments and that is very much true for the map<T,T> as well. All big objects that don't need changing in the function you are calling should be passed by const reference

#5089516 C++ Optimization week!

Posted by NightCreature83 on 27 August 2013 - 08:59 AM

A few things I keep in mind:

- use const where possible, both in member functions as parameters

- pass objects as const reference when their size is 'relatively' big

- don't let 'outsiders' get to crucial class members (make things private, make const 'Get...' functions public) 

- use VLD Always in debug mode, detect memory leaks a.s.a.p.

- use &auto when possible to make code more readable

- where possible always use std::vector instead of dynamic arrays (new/delete)

(helps in following 'the rule of 3')

You should reserve the space of vectors as well this will at least in the avarage case help the vector not resize as much.


Check your template usage if you have loads of this it will upset compile times and may even make a compiler cry once in a while.


Batch compiling will also help, look for unity builds for that subject but keep in mind that you should always have a single file compile path in the solution as well.

#5089254 Managers, which pattern should I use

Posted by NightCreature83 on 26 August 2013 - 01:33 PM


As for input, Radikalizm points out that you can have all sorts of different input devices, but in this case I think a 'manager' is okay for exactly that reason: your game can only support the device types that you code support for, and it needs a system in place to 'manage' which devices are active/connected, etc. That system can function as a means of allowing easy access to your input device interfaces, but it shouldn't implement those interfaces. I have no problem with something like


I mostly follow the mindset that there will probably be some devices which I'll want to implement later on in my game's development lifecycle without having to bloat existing systems. Some devices also require you to use an existing SDK with some of their own manager objects which need to be alive during the time you want to use the device (like the Oculus Rift for example), so that's more of a reason to maintain the code driving a certain input device separated from other devices. 


Hiding all of your device info behind an input manager also hides which input devices a certain other input requiring class need, which can become a real mess when you want to change something in your input manager class.


But you should hide all of you input devices behind an interface anyway otherwise you are going to add special code paths for certain device which lead to even worse design. Implement against and interface not an implementation, and behind that interface all kinds of nasty can go on but your game code doesn't need to know about this and that is exactly what an input system is supposed to do.


I agree with the idea that as soon as you try to create a manager object you need to rethink that part of your code to see whether this is a system or cache type situation but the example you use just doesn't work. In that case implementing against an interface will save you from a lot of trouble in the rest of the code base.

#5084895 Mathbook for dummies, any recomendation?

Posted by NightCreature83 on 11 August 2013 - 05:46 AM

I used these ones: http://www.amazon.co.uk/Primer-Graphics-Development-Wordware-Library/dp/1556229119 and http://www.amazon.co.uk/Mathematics-Programming-Computer-Graphics-Development/dp/1584502770/ref=sr_1_9?s=books&ie=UTF8&qid=1376221532&sr=1-9&keywords=math+for+game+development

#5084402 What is a tight loop?

Posted by NightCreature83 on 09 August 2013 - 08:22 AM

Tight loops are to do with performance, they don't necessarily have few instructions inside of it, they are however time critical to the application so you want to eliminate operations from them that can be dealt with elsewhere.

#5080549 Data clipped before Output Merger

Posted by NightCreature83 on 25 July 2013 - 02:01 PM

Well seeing he has the graphics debugger up in VS2012 we don't have to worry about the OP having an express version. It is worth getting a pro version for VS if you don't have one btw, but try and get it through someone who works for MS as that saves hundreds of <your currency here>.

#5080530 Data clipped before Output Merger

Posted by NightCreature83 on 25 July 2013 - 01:16 PM

I have run into a few issues with the new graphics debugger that PIX didn't have and it is really annoying I had something fail a depth test but the depth test wasn't on for that particular drawcall it turned out that it actually failed a stencil test. I had to go through all the states for that particular draw call to figure out what was happening to it.


The other problem is that PIX no longer understands the DX11.1 runtime so even if the application is shared if it is build against the DX11.1 runtime PIX will fail to open the application, and seeing he is building his application with VS2012 it is very likely it's built against the DX11.1 runtime sadly.


Currently I am having to deal with GPUPerfStudio 2 and it is not perfect either and only works for AMD cards, there is another plugin for VS that might help you and it is called NSight but that only works for NVidia cards and you have to register as a developer with NVidia to get it.

#5080424 Data clipped before Output Merger

Posted by NightCreature83 on 25 July 2013 - 06:08 AM


Thanks for your hint. In currently not at my computer but I think the problem ain't related to the vertex data. The post vertex shader view in the debugger shows the output of the vertex shader in projection space with the usual clipping already applied, e.g. clipping near and far plane.

So I think the problem is that the pixel shader never gets called. I'm not 100% sure but I thin that there are only two possible situations.
1) The rasterizer does not generate any fragments but as all checks are disabled in the rasterizerstate that should not be the case.

2) My pixel shader is not attached correctly even though it shows up in the debugger.

I will have a look at everything when I'm back home.

Thanks and a nice afternoon

Your problem is most likely related to your view transform, if the object is drawn outside of the view frustum or view port, the transformed vertices will not be going through the pixel shader. And this is also the reason that you can't find another pixel with a different pixel history then the clear call, objects that are not in the view port will not have a pixel shader run for them.

#5080363 Data clipped before Output Merger

Posted by NightCreature83 on 25 July 2013 - 02:29 AM

Do you know where on the screen it should show up? If so look at the pixel history it might tell you why it failed to draw that pixel.

#5080135 Why companies still use C++ and what should I learn then

Posted by NightCreature83 on 24 July 2013 - 08:55 AM


But I've looked for topics where members ask what to study first and you usually let is start with C#.

I'd say Python comes up even more often than C#, and for good reason.


Anyway, the consensus from academic circles (read: people who are tasked with teaching hundreds of students to program, year after year) is veering towards this: starting with a language that is overly complex, incoherent, low on expressive power or otherwise user-hostile means you are wasting your time. My gut feeling is that it's even more true if you are trying to learn on your own. Everywhere people are opting for Python, Scala, etc. when choosing languages for introductory programming courses.


I recall one particular experiment where a school carried out their two initial programming courses in two groups. The first group used Scheme for the first course. It is an excellent learning language that looks nothing like languages common in production use. The second group used Java. Both groups took the second course, whose subject was object-oriented programming, in Java. Even on such a limited timescale, the end result was that the students of the first group were better at programming in Java at the end of the second course. One can only imagine how much better they grasped programming in general. Also note that Java, while clunky and lacking expressivity, is much more forgiving than C++ is.


If you wish to learn C++ in the end stay away from Python, Java and C# are your better options to start with as a lot of the syntax will be the same. Not having to learn a new syntax in your second langauge is really useful as you are focusing more on learning the particulars of the language instead of feeling like starting over. Having to pick up a new syntax becomes easier when you are more comfortable in constructing non trivial coding solutions and algorithms.


I started out with Pascal -> Delphi and then transitioned through C# and Jave to C++, moving away from Pascal/Delphi at the time wasn't really easy as I wasn't that good at coding yet and meant I had to learn a whole new language effectively.

#5080059 Cleanest way(s) to negate a predicate in C++11?

Posted by NightCreature83 on 24 July 2013 - 02:16 AM

The problem: I have a predicate bool pred(const T&) which I can feed to an algorithm like partition, but what I want is its negation (!pred). I'd prefer a solution that works regardless of what pred is exactly, but at least the solution has to work if pred is a named lambda.


I can come up with three ways of getting the negation:

1) [](const T& t){return !pred(t);} or

2)  bind(logical_not<bool>(), bind(pred, _1)) or

3)  not1(function<bool(const T&)>(pred))


but all of them are clumsy. I feel the lambda version (1) may be the easiest to write and read, but on the other hand I like the bind version (2) because it avoids the need to specify T's type explicitly. (3) has nothing going for it. Am I overlooking something? I thought about writing a template function function<...> neg(pred), but could not think of a way to deduce the parameter type of the callable, which would be necessary to specify a correct return type for neg, and apparently function is also less efficient than raw lambdas and function pointers.


The first one is the only clean solution and the preferred way of doing this in C++11 (http://herbsutter.com/2013/05/16/gotw-3-solution-using-the-standard-library-or-temporaries-revisited/). Why don't you write your predicate in such a way that it takes and "auto" as then your lambda doesn't need to take a type at all.

#5079873 Data Driven Design: Questions (and Answers?)

Posted by NightCreature83 on 23 July 2013 - 09:46 AM

A decent tool for XML serialisation is tinyXML2. There is no benefit in chosing JSON over XML in C++ as neither of them will deserialise directly to C++ data structures like JSON does in Javascript.


Data Driven Design can be used together with an OO hierarchy, by using a praser and a factory you can construct the instances the data is specifying and initialise them with data from the data.

#5079577 Decals in XNA or DirectX9

Posted by NightCreature83 on 22 July 2013 - 08:23 AM

Well use normal projective texturing in that case but that won't always look as pretty as that one will. But it should teach you enough tricks to overcome it's short comings.

#5079522 rusty c++ coder

Posted by NightCreature83 on 22 July 2013 - 02:00 AM

Maybe try some Euler project problems to get you into the flow of thinking like a programmer again. After that who knows your ideas might start to flow again for games. Or try to make clone with a twist of a simple game you love.