Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 02 Sep 2006
Offline Last Active Jan 19 2013 04:19 PM

#5015358 Miscellaneous OpenGL questions (mostly dealing with shaders)

Posted by on 29 December 2012 - 01:14 AM

2 more cents throws in:


If you use deferred shading (as described by LordJulian above)

DON'T! don't use deferred shading as described by me above, research it and use it as described by someone who actually used it; I only wanted to paint the available pictures.


Also, my advice is: use the forward shading technique, it's more forgiving. When that fails to provide the results you're looking for, add a post processing step and milk that into more and more complex filters. In no time you'll do the steps to prepare yourself for deferred shading and you won't even know it. Don't go full deferred until you are ready, deferred shading, while offering an elegant model that promises to solve lots of issues,  presents lots of problems in itself. You'd have to be more controlled in the way you render your scene, with the different render targets and the way you pack/unpack information, etc. In one word, you'd have to be an obsessed management whore with your rendering pipeline(are we allowed to say whore in here? we should, it's the internets).


And, before you reach the "relevant shading data for that pixel" stage, you still have to first RENDER that data into the render targets; this is done, of course, with a custom shader that outputs all the needed values, which, later, will be interpreted by the super-shader. So, shader complexity is not really lower, it's just separated into multiple shaders, which, in itself, is a complex thing to do.


So, go gradually, and know that whatever you learn/experiment with "the classical way of applying shaders to models and basic lighting " will stay with you and will be relevant. Deferred shading is, after all, forward shading a full screen quad with some real-time generated textures :).

#5015327 What kind of optimization makes C++ faster than C#?

Posted by on 28 December 2012 - 11:14 PM

Well, since the original topic went straight to hell and since everyone is throwing their hat in the ring, here I come as well.

For me (a 6.5 years developer at a huge game company, working at a few AAA titles you might just have heard of - assassin's creed, anyone?, on all the major consoles out there), the deal is like this:


GAME DEVELOPERS (because this was the original context of the question) are choosing to build their engines in C/C++ because (choose any/some/all "of the below") :


- tradition: since forever engines were made in C/C++, whatever was before that couldn't really be called an engine


- 1st/3rd party libraries: there are literally millions of libraries and APIs written in C/C++ out there. Sure, most of them are junk, but you simply cannot build a complete engine without some of them. Also, you can access them in mostly any other language, but why should you? Plus, any translation is likely to cost you.


- platform support: even though it is basically the previous reason, it deserves a repetition: any platform owner (game consoles, mainly, for our purpose) will deliver their SDK that WILL target C/C++. That's it. If you want to use it in a different language, a wrapper is a must.


- The promise of gold at the end of the rainbow: raw memory access, the way you like it. Even though, at the beginning, you don't need it, when push comes to shove and the framerate just isn't high enough, you WILL want to fiddle with memory layout and all the other tricks in the book that will yield better performance. Don't mistake this point, it is for ninja-tier programmers, but if you want it, it is there. I've witnessed some very nice and some very low level trickery that was done by a colleague of mine for a PS3 project on a particle implementation that was very optimized on the main platform to begin with. The result was mind blowing, we almost got the particles "for free" on PS3, while them being a major strain on the main platform.  To summarize: given a good C# programmer and an average C++ programmer, the C# programmer will probably produce faster code on most of the tasks; but given excellent programmers on both languages, my money is on the C++ one, every time, anytime. He just has more wiggle room and the promise of total memory layout freedom.


- Rock solid compilers. The c++ compilers usually carry 20+ years of effort spent into delivering very very fast code. The things the C++ compiler does with your code are just amazing. The other compilers are catching on quite fast, so this is becoming a non-reason fast, but still, the C++ compilers (and linkers, specifically) are geared towards maximum speed output, given the proper switches. Granted, with a certain compiler, I was able to write a VERY simple program that gave WRONG results in a certain configuration, but that was a solitary issue, they fixed it and we never spoke of it since.


Well, there are a few more reasons, but basically this is it. And now an advice for you: if you want to do a game and you're sure you can do it in C#, GO AHEAD. It is a lovely language with quite a few tricks up the compiler's sleeve. If you want to do an engine... do it, for fun, in C++. You will never finish it on your own in reasonable time with production-ready features , but it's a very nice exercise and you will gain lots of benefits.


Have fun!

#5015314 Miscellaneous OpenGL questions (mostly dealing with shaders)

Posted by on 28 December 2012 - 10:20 PM

Brother Bob wanted to stay away from exotic lighting techniques, but I'm feeling adventurous.


Basically, ignoring extremely exotic lighting techniques (and if anyone else feels more adventurous, go ahead), there are two main ways in which you do lighting:


1) forward shading: you render your scene model by model and do the lighting either in the vertex shader or fragment shader, depending on the effect you want to obtain and the trade between visual quality and speed.


2)  deferred shading: you first render your scene in special textures that will retain different attributes per pixel, like diffuse color (before lighting), screen position (depth), normal and any other kind of attribute that you would need in your lighting calculations. After the first pass is complete (all opaque objects were rendered in these special textures), you draw a fullscreen quad with a special shader that uses all these textures to perform lighting on each pixel on the screen.   This technique is a bit more tricky, but I'm assuming you're not afraid and you want to learn new and exciting stuff. Lots of new games use this, but it can be quite heavy on texture memory. Also, handing transparent objects can be quite tricky, but there are tons of books explaining all that (ShaderX 4- 7, GPU Gems, etc).


After all that, you can (and should, because it's nice) do some image post processing. In the deferred shading technique, since you have more information per pixel than just color and depth, you can get quite creative with your post processing. In forward shading, for more complex post processing you will most likely need to render the scene multiple times in multiple textures. Come to think about it. deferred shading can be considered a quite heavy post processing effect :P

#5015311 Program Wide Global Vars in C++?

Posted by on 28 December 2012 - 10:06 PM

And, taking the wonderful example of Rod, if you don't feel like including a whole h(pp) file for a variable, you can extern declare said variable in any place that you want it.




void BlaBluBli()


 int a = 2;

extern int counter = a + 7;



As long as you ONLY declare it NON EXTERN once, every other external declaration will be solved by the compiler at link time.


But, DON'T! NEVER! Not even once! As an abuser of global variables, especially at work, especially when I need to do things quickly, I can tell you that usually it comes back to byte you (pun intended!).  The hassle, when you decide to expand on your work, far outweighs any gains; usually this is a sign that your overall design has a few flaws in it.


Don't do it, EVER, I mean it :P  (or if you do, don't let anyone else play with your globals :P )

#5015309 Java: Cannot find symbol error

Posted by on 28 December 2012 - 09:56 PM


#5015308 How to check if dynamic memory is there before deleting?

Posted by on 28 December 2012 - 09:53 PM

Wanting to delete memory and not being sure if you actually should delete it is the root of all evil. Try to impose as many rules as you can on your own code and make it as close to impossible as possible for others using your classes to do something stupid. One such an idea would be to enforce the creation and deletion of your object to stay in your own code (private constructors/destructors and friend class manager?). Anyhow, it's a tricky subject that cannot be taught in a few posts. Learn the basics of allocation/deletion very well, experiment a lot and grow wiser. At one point, you will feel confidant enough to answer your own question (and, from time to time, you will fail tongue.png, but keep it up ). You will know that you have the right implementation the moment you will KNOW that you MUST delete some memory and not wonder anymore.

#4990485 Try/catch absurdity and calling destructors...

Posted by on 15 October 2012 - 01:35 PM

Sorry to double post, but, for learning purposes, here's another suggestion: If you want to track "troublesome bugs" with memory allocation (i.e. using pointers after you delete them - happens more often than you think), you set them to an invalid, but easily recognizable value, kinda like 0xfefefefe. Then, when the program blows to bits, you look at the pointer in the debugger, and if it matches (or it is close) the 0xfefefefe, you know you have this problem. enjoy

#4990483 Try/catch absurdity and calling destructors...

Posted by on 15 October 2012 - 01:29 PM

If you absolute want to avoid using smart pointers, you could try using a cleanup member function.

class some_class{

	void cleanup();

	int	 *ptr1;
	int	 *ptr2;
	int	 *ptr3;
	int	 *ptr4;

some_class:some_class(int some_val)
: ptr1(nullptr), ptr2(nullptr), ptr3(nullptr), ptr4(nullptr)
		ptr1 = new int(some_val);
		ptr2 = new int(some_val);
		ptr3 = new int(some_val);
		ptr4 = new int(some_val);
	catch (...)


void some_class::cleanup()
	delete ptr4;
	delete ptr3;
	delete ptr2;
	delete ptr1;
This takes advantage of the fact that it's OK to use the delete operator on a pointer equal to nullptr.

quite good suggestion, BUT: in the cleanup function check for NULL and if not, then delete and assign to NULL. :). I know that delete checks if the pointer is NULL, but for teaching purposes it is good to suggest that. Also, setting it to NULL after deleting is not mandatory, but is, again, good practice and, perhaps, would keep the user to double delete the same pointer and/or access it after deletion.

#4980178 What are the most important things that should make me consider moving to C++?

Posted by on 14 September 2012 - 02:52 PM

- Code will compile to just about any platform

I actually missed this one the first time around. It should probably say something more like "Code can be beaten into compiling on just about any platform, given a significant porting effort".

  • Want to compile your 32-bit code with a 64-bit compiler? Sorry, your standard integer type changed size, and nothing works anymore.
  • Want to compile your standard-conforming code on Android? Sorry, we disable RTTI and exceptions, just because.
  • Want to compile your file-system tool on Windows? Sorry, we only kind-of support POSIX over here.
  • Want to compile your file-system tool on Mac? Oh, hey, we do support POSIX, but we moved all the header files.
  • Want to compile your GUI application on a Mac? Sorry, we don't have Win32 or MFC. We do have GTK+ and QT, but they have subtle differences from their linux counterparts.

Even though a number of those points are library related, when you compare to the portability of a language/ecosystem like Java, C++ just doesn't cut it.

And then you start thinking about more game-like issues , such as direct memory access and , let's not forget, execution speed, and then you see the light :D

#4980175 What are the most important things that should make me consider moving to C++?

Posted by on 14 September 2012 - 02:49 PM

Detailed, explicit control over your application

Eh? You don't even know the size of your int's...

Sure we do, it is sizeof(int) :P

#4979869 What are the most important things that should make me consider moving to C++?

Posted by on 13 September 2012 - 04:41 PM

It boils down to whatever you want to do... You want to be productive now - stick with what you've got, as long as it works for you. You want to learn a lower-level language and have the determination to feel stupid again without giving up (because switching will, at times, make you feel that way), then go ahead onto C++. What C++ has for you ... it's the de-facto standard for any "serious" (read consoles + PC/MAC) game dev company (I should know, I've been working for one for 6.5 years). If you want to code an xbox game (short of little XNA games), you will do it in C++ at least at some level, because the sdk they offer is for C++; want to code something for PS3... yep, C++ sdk as well... So, just define your goal: productivity now or study_now_reap_benefits_later. If you're determined and willing, I see NO reason not to go into some C++ programing. Have fun!