Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 05 Jul 2012
Offline Last Active Aug 23 2013 10:38 AM

Posts I've Made

In Topic: Why companies still use C++ and what should I learn then

26 July 2013 - 09:48 AM

There seems to be this assumption on the internet that you have to stick with one language as you learn the various concepts of programming. I'm of the opinion that the idea of Languages being interchangeable tools is one of the most important.


 I'd like to propose a different appraoch to learning: 


Start in a memory-managed language. I'd recommend C# or java just due to syntax ( { and } and stuff makes it easy to understand how code is laid out). Learn how this language works, and learn the basics here. Types, variables, Functions, Arrays, strings, loops, arithmetic, conditionals, and finally recursion. Some good practice would be learning how to sort arrays of numbers, and how to find out if two words are anagrams of each other. The language you settle on doesn't really matter, so find one you like. I would avoid most object-oriented concepts at this point (If you don't know what a class is that's perfectly fine.)


Next, go to C (Not C++!), and re-learn the same things there. This will MOSTLY be familiar, but you will have the added challenge of basic memory management. Learn about how memory is allocated and freed, how pointers work, how they relate to arrays and strings. Now might also be a good time to learn about Binary numbers, Hexadecimal numbers, and bitwise operations (not language-related, but C supports them and they're handy to know.) - This is probably the one that will be most argued over, and I understand why. I just feel like C as applied to the basics of procedural programming and without any clutter from trying to design OO programs is a good environment to begin understanding memory management in. 


Third, go back to your original language, and begin learning Object Oriented concepts. Learn how to make a class, learn the differences between static and non-static, public vs private,  pass-by-value and pass-by-reference. Learn about how classes can inherit from one another, and what virtual inheritance / interfaces / abstract classes are. The advantage is that you can focus on how to accomplish this without worrying about memory again. 


Now, start learning about how to apply those classes. Look up some common data structures (linked lists, stacks, trees), and some algorithms (tree or graph traversals or self-balancing trees would be a good place to start), and implement them. Bonus points if you test and see why and when different algorithms are faster or slower. By the end of this you should be able to make a text-based maze game if you put your mind to it. 


Finally, start learning how to implement this stuff in C++. This will still involve loads of foot-shooting, but you will understand the basics and have freedom to focus on the quirks of the language rather than the basics of computer science. Even now, I wouldn't touch templates until you've re-implemented everything from the previous step in C++.


Around this point (Could very well be many months of work) you'll have a solid foundation which you can apply to most any language you want. Now's the time to play with LISP, or learn you some Erlang for great good, and open up your mind to a completely different set of concepts. 

In Topic: problem writing complex vertex shader

25 July 2013 - 04:54 PM

Glad to see you caught my mistake. I was calling "indices" weights, also. Clearly I didn't test that code :/


Those results look good! I am surprised that the ancients have so many bones. If I had to guess, maybe WC3 probably did software skinning so it didn't matter?


As an option, maybe you could look through the model and split the mesh based on the bone indices accessed? (half for indices < 110 or something, half for >110) and do two draw calls for the big guys.. This would work best if pieces don't rely on the root bone bones too much.


Alternatively you could split the model and duplicate the most shared bones into each of the two smaller models' bone arrays, changing the indices on your vertex data appropriately. It still might let you cut down the number enough to fit into your uniform space. 

In Topic: Questions about OpenGL

25 July 2013 - 04:42 PM

1) Are things better? That depends on where you look. On the one hand, we just got 4.4 drivers from NVidia, and some of the ARB extensions in those include features that won't hit DirectX until 11.2... On the other hand, many parts of the OpenGL API move VERY slowly, meaning old concepts stay in use longer than they would in DirectX. (For example, it is just now kinda-sorta-almost getting away from the concept of working in terms of bind points for textures and buffers.) 


2) I've been using NVidia's parallel NSight to debug on windows, and it's worked pretty well for me so far (Visual Studio + Nvidia cards only, unfortunately). I have used GDEBugger in the past, but the original version died out, was picked up by AMD, and now exists as CodeXL. I can't comment on its newer incarnations, but historically it served well enough. It appears to run without VS, but probably requires an AMD card and Catalyst driver. Most of the open source projects on this front seem to have died out, unfortunately. 


3) I personally am a huge fan of Sublime Text for coding. It's a bit more of an editor than an IDE, and It's not free ($50 and worth every penny imo), but it's got an unlimited-length trial period, so you could learn it while saving money and not have a period where you're stuck without an editor. For Windows in particular, the express editions of Visual Studio have served me well over the years and are completely free.


4) I originally learned on DX9, and have since mostly used OpenGL due to jobs. If anything I'd say it feels like they are converging more and more, and the underlying concepts are often the same even though the APIs are laid out differently. You'd only stand to benefit from making the transition, even if you went right back to DirectX afterwards. 


5) I can't give any real recommendations for books, but I have thumbed through the OpenGL SuperBible, and it seemed reasonably thorough. The newest (6th) edition claims to cover up to 4.3, and will be out in a few days. Hopefully someone else here can speak to how useful it is for learning. 

In Topic: Rendering a texture

25 July 2013 - 04:15 PM

I think the main case where you'd be unable to use a context is due to multithreading. An OpenGL context cannot be active on multiple threads, so in the case where you wanted to call OpenGL functions from different threads, you'd need to either create more than one context and have them share data (with wglShareLists), or have each thread sync and make the context current / not current as needed. 

In Topic: OpenGL 4.4 spec is published

25 July 2013 - 11:41 AM

GPU hardware hasn't supported 3-component texture formats for a long time (aside from packed formats like DXT1).

If you ask GL to give you an RGB texture, on the GPU it will allocate an RGBA texture and pretend that the alpha channel doesn't exit...


Learn something new every day! Good to know this..