We need your help!
We need 7 developers from Canada and 17 more from Australia to help us complete a research survey.
phantomMember Since 15 Dec 2001
Offline Last Active Today, 06:05 AM
- Group Members
- Active Posts 12,699
- Profile Views 19,781
- Submitted Links 0
- Member Title Member
- Age Age Unknown
- Birthday Birthday Unknown
Has had an item featured
Blog post contributor
Posted by phantom on 17 September 2012 - 06:54 PM
The past couple of days at work I've been working on optimisating/vectorising some C++ code - something I'm in fact normally very very good at (low level stuff is a kind of speciality of mine). Last week was a long one (~52h, or close to 7 days worth of hours in 5 days) due to us being in the closing weeks of the project so I was a little tired and thus didn't check the code in as I wanted to test it when I was fresh.
I tested the code, worked on two platforms but the rewritten SPU code didn't do as expected.
The code compiled - the code ran - but the code clearly wasn't correct.
Many hours of debugging later I discovered the two problems;
1. a difference in the API for SPU/PS3 vs PC/XBox
2. I'd made a mistake with some pointers.
Basically when I started writing the code on the friday I started with float*, so all my sizes, offsets and pointers were in terms of floats.
Later, however, I swapped to a vector format, 4 floats wide, but in my tiredness failed to update all my pointer offsets correctly.
The compiler accepted the code.
The SPU ran the code.
The code even produced some output without crashing for a good while.
But the code was wrong.
This is the kind of thing you get to work with when it comes to C++ : you might not be working with SPUs but it is oh so easy to make mistakes which function correctly 999 out of 1000 and then on the 1000s try blow up in your face.
An older tail, from a good 8 or 9 years back - I was working with a friend on some rendering concepts for a game. Code ran fine on my PC, didn't work properly on his. About a day later I finally found out why; an uninitialised variable. On my machine it would always spin up as 'true', on my friends it seemed to be 'false' 99% of the time.
When learning to program you don't want something which trips you up like this causing random and hard to explain bugs. I'm an experianced programmer and, despite the tale above, very good at it but even I trip up from time to time (I also write code which functions flawlessly as well, but that doesn't make for a good cautionary tale *chuckles*).
Reasons such as this are why C# and Python are recommended - they let you learn to reason as a programmer BEFORE you have to deal with the subtle and hard to find issues that C++ brings to the table.
And it's not like starting with a language which shields you from the crazy makes you any worse off in the long run; I started with BASIC and was happy there for many years before taking the leap into 68000 Assembly but at that point I had a strong understanding of programming which meant the assembly was easier to follow and understand.
Posted by phantom on 16 September 2012 - 04:34 AM
I wouldn't bet against managed languages taking the place currently occupied by C++ in the industry in the near future.
I wouldn't be surprised if C#/.Net based languages took the place of C++ for many things, although I suspect you'll end up with a mixed mode of things. Some stuff, like the rendering backend, might well stay in C++ but higher level logic might well shift to C# and the like for ease of development with the option of pulling in C++/C/Unsafe code as an optimisation.
(I say this because as good as compilers are there are still times when you need to get in there and hand massage some intrinsic based vector code into the mix because it simply can't do it due to lack of context about the operations being performed.)
Maybe this will finally get game play programmers to think in terms of 'threads' and 'tasks'... *sigh*
Posted by phantom on 13 September 2012 - 03:15 PM
Did you see my post with the diagram, and does that seem to make sense and convey the right idea?
It's close but the key thing I would say is that a 'material' is a combination of shader and it's resources.
Nor should it have to worry about 'external FX variables'; anything which isn't set by the material or the draw call directly (per-instance/batch stuff) should be handled by some external system. So things like camera position and the like, which are setup once per scene, would be set via something else and just read.
In the context of DX11 this would be a per-scene constant block, the material would be a per-material constant block and the instance data would be one or more per-instance blocks.
Keep your frequency of updates down as much as you can for each block, try to instance things too as CPU time is still a killer if you want to handle lots of draw calls.
Posted by phantom on 12 September 2012 - 02:49 AM
IIRC, D3D9 does all it's blending without taking sRGB into account (which means it's incorrectly blending in gamma-space), but D3D10 does it correctly (i.e. decodes the texture to linear, blends, re-encodes to sRGB).
Having spent a lot of time this year looking into sRGB issuesI can confirm this
Posted by phantom on 11 September 2012 - 05:22 PM
So I guess, I rest my case in the knowledge that the C# language is flawed but "who cares"... C++ just ain't cool.
And you are saying C++ doesn't have flaws in it too? That some how it is the 'perfect' language?
C++ has more flaws in it than C#, more flaws which will trip up someone who isn't using it AND has less productivity associated with it in situations where that matters more.
And before you bash me as some C# fanboy I should point out that my primary coding enviroment is C++ and will likely continue to be C++ for some time however to dismiss C# over some trivial issue (and it really is) and thus avoiding the benefits of the language and the massive class library which comes with it is frankly idiotic.
It's not a matter of 'what is cool' its a matter of 'what is the right tool for the job'.
Sometimes that tool is C++.
Sometimes that tool is C#.
Sometimes that tool is Python.
Or some other language or method.
If you want to wander around with a set of 'C++ is bestest!' blinkers on then feel free; be prepared to be taken to task over it however because most of us who work for a living with the language know better... apprently much better.. and apprently have a much better appreciation for other languages and tool sets.
Posted by phantom on 09 September 2012 - 05:38 PM
Finally, just to counter your argument from ignorance that C# has nothing to offer that Java had for years - one word: LINQ, oh - and DllImport, hm, maybe the unchecked and unsafe blocks, lambda expressions, etc. etc.
Oh man, LINQ is probably one of the best programming improvements to happen in... well, years.
I'm mainly a C++ programmer, day job and problem domain generally demand it, but I also use a fair chunk of C#/.Net and getting a handle on LINQ just made programming that much more enjoyable and let me solve problems faster.
The async/await system which is coming is also pretty cool and the Reactive Extensions just make life that much nicer too.
Anyone who doubts C# has brought anything good to the table needs to extract their head from whatever dark area they have placed it and learn about it - some truely great tools in there.
Posted by phantom on 09 September 2012 - 10:17 AM
What I do is follow the trend; I do what PRO game developers do because, if you do, at the end you will achieve the same goals and results. It's just a matter of logic deduction.
Unfortunately your logic is wrong.
Beginners are not pros - pros are often people with years of experiance in the field thus what a pro does or does not use is of no importance to someone just starting out.
For example where I work we play many tricks with how memory is allocated, pointers are fixed up and how things are passed around the system; we are professionals and yet I would never advise someone to follow our line of thought without experiance.
The end result of the journey might well be using the tools that pros use however this will be relevent once the person in question gets to their level.
Another thing, if virtually all the modern tools/games/engines are made in C++, it's because it has to be very versatil and rewarding (Valve or Epic can't be wrong), thus, needs some time to understand and learn; but when you do it, the results are limitless.
And they are designed this way due to legacy and existing requirements - those are not the same requirements that a beginner is going to have.
Also there has been a shift to the vast majority of in-hosue tools being written in a .Net language.
Most games in existance are probably Flash or otherwise based as such C++ has no relivance there either.
AAA game production, staffed by experianced people with specific requirements, is not a guide for where someone should start regardless of their ultimate goal - it might guide their process as they progress however first of all you have to learn to program and as such what pros do is not important.
Posted by phantom on 09 September 2012 - 09:21 AM
"You're still a beginner, so don't give advice to a beginner." Now wait a minute. If this is in fact one of the things you're trying to tell me, that's nonsense.
Pull a quote where I said precisely that.
You can't complain about being talked down to and attacked when you go around blowing things out or proportion and misrepsenting what others have said.
You've been doing this for ten years you say? What was C++ like ten years ago? What was it like to be a beginner ten years ago? I dunno. Do you? Do you even remember most of the problems you had, let alone all? I know a lot more about being a beginner than you do. I remember all the things that got in my way, all of the self-started projects I completed or never even got halfway done on. In this department, your ten years work against you.
My own personal experiance in general beginner problems isn't relivent, nor in the area of being a beginnner did I claim that my experiance was. By the time I got to C++ I'd been programming for 10 years, including one assembly language variant and a brief stint in early Java.
However my experiance with C++ gives my view of C++ more weight and my observations over the 10 years of my being on this site give me a pretty good idea of the problems that beginners suffer from in C++ and the problems that come up when they try to deal with it.
You think about all the problems you've had with C++, and most of them might truly be far too advanced for a beginner, but as has been said: That means a beginner probably won't run into them. And if he makes those mistakes, so what? Is it mission critical code?
If the code is mission critical or not is utterly unimportant.
But ok, lets take something which is simple C++; a Standard Container.
Those things can blow up with some of the most god aweful error message you'll ever see.
Yet they are key and central part of the language; somethinig a beginner should be starting with from practically Day 1 (if you are doing strings via char * or dynamic arrays of memory via <type> * then you are Doing It Wrong). Yet these areas can produce some of the most hard to understand and track back error messages out there.
And even if you fall back to doing char * strings or <type>* memory allocation you now run into the world of no bounds checking where you can do as you like and nothing will tell you otherwise until something blows up in your face.
I've seen beginners confused by things relating to 'access violation at address 0x000000c' which I can look at and say 'oh, it's this...' right away but they have no idea about. And yet allocating instances of types and calling functions on them is central to C++ but not for learning to program and can be taughted better in language which tell you via better error messages what has gone wrong. Try missing of a ';' somewhere in a header and watch the explosion of error messages which happen due to one tiny syntax error which has no impact on the ability of someone to learn the basics of programming.
Hell, there was an example recently of someone being confused because they could apprently call a function via a null pointer to a class without things going wrong.
The C++ standard itself is known for using the word 'undefined' or 'implementation defined' through out its language.
None of the things I've mentioned above are 'advanced' and yet I've seen over the years people repeatedly trip up over them and then the resulting cryptic error messages/reactions from the runtime which can come about from it.
Edit: you can also add to that list compile times, header files, pathing issues and libraries.
Again none of those are advanced but being forced to deal with them just to learn is, to use your phrase, 'insane'.
He'll learn the best way to do the things he's been doing later. Just like when you start off writing code like int box1, int box2, etc, and then later you learn "Oh, that's what arrays are for. Bad habit erased."
But it's not just Bad habits like that - C++ carries with it a massive legacy and with it comes 'advice' which might have been important 10 or even 5 years ago but these days is worthless.
New C++ programmers, the ones who seem to defend the language with such tenacity (or ones who only know C++ like it is the only thing worth knowing), are also the biggest source of 'not made here syndrome' - many shunning the standard library as if it is some slow and horrible thing, instead favouring that own bug ridden versions, because they once read somewhere that it was slow. This persists going forwards and instead of taking advantage of tools which exist they go on to try and reinvent everything because they feel somehow they will 'learn more' (also the classic excuse of someone who wants to make a game but believes making an engine first is a good idea).
This is a mind set which is VERY hard to break and one which continues to be recycled from programmer to programmer as someone new starts all the other newbies around them just tell them what they have done themselves.
(I figure it must be some kind of self reinforcement cycle - "if someone else does it then I can't be wrong" but that's far far off topic).
All of the above is why, when compared to other languages, C++ is lacking.
Yes, C++ has it's strengths, one of which is being on all platforms and other of which being if you know what you are doing you can get more out of it than maybe you can in another language HOWEVER those two arguements are utterly moot because they are advanced topics (often requiring knowledge of the target platform and how the code generation can work) and you have already stated that advanced things don't matter to beginners.
When you are starting out getting told what you are doing wrong is more important than speed or frankly other considerations beyond learning the art of programming.
C++ makes this harder than it needs to be.
Posted by phantom on 09 September 2012 - 08:24 AM
And one more thing: To those of you who might, for some unfathomable reason, think that the comparison of C++ to any form of advanced mathematics is a realistic one, you need a wakeup call:
It is called a 'smilie' where the progress of learning in one situation was compared to the progress of learning in another situation.
I did not comapre C++ to QM as you seemed to think, I compared a situation where a beginner in one field questions the experise of someone in the same field when they don't have the expertise to do so.
At no point did I say 'OMG! C++ IS LIKE QM! LULZ!' or whatever insanity you seemed to read - I liked two situations to give you an idea of the 'insanity' (a word you seem very fond of) of your position where you seemed to think that your whole year of C++ gives you some real insight into the subject.
Posted by phantom on 09 September 2012 - 03:44 AM
The D3D11 API replaces and improves upon the D3D10 one and renders the later useless
Also, when it comes to semantics, unlike D3D9 D3D11 allows you to define your own; they are basically free form strings now (aside from the system ones).
Posted by phantom on 09 September 2012 - 03:40 AM
In the end, I would say if somebody wants to learn C++ straight away, let him.
And no here is stopping anyone so...?
It's not about 'letting' people do anything, it's about laying out that C++ is NOT easy as was claimed.
If someone still wants to go off and work with it then it's not like we could stop them and when they rock up there with the questions people will still help them.
It's about making an informed choice about how you are going to spend your time; if you don't need the complexity of C++ because you are just starting out or your project simply doesn't need it (and most projects don't; our build system at work was written in python, the new version is C#, most of our tools are either python or .Net based, only the main game is C++ because it is aimed at consoles where we have no choice and we need C++) then picking C++, without being informed, it's the wrong choice.
It is simply an extension of The Right Tool For The Job and it is also a good starting place because it gets people, very early on, use to the idea that if you are serious about this then you won't stop at once language you'll keep picking up new ones so the fact you didn't start with C++ doesn't matter.
(C++ was in fact the 5th language I learnt, and then a couple of languages later I learnt it again properly - and yes, I started with an 'easy' language too in BASIC as that was all I had access to.)
Posted by phantom on 09 September 2012 - 03:33 AM
That is quite likely true. But the counter-argument is that having a language hold your hand is not very beneficial for your overall growth either. If you aren’t allowed to make mistakes, you aren’t able to learn from them.
Just because you haven't seen the outcome of your mistakes does NOT mean you have not made them.
The problem is that until you see those mistakes you can't learn from them.
You can write C++ code which during an array traversal wanders out of bounds and gets away with it because you've been lucky. You never encounter the error, you never learn from it.
Something like C# is going to very quickly yell at you about doing so giving you a chance to catch the mistake and the algorithmic error which comes from it allowing you to learn.
It's about setting up solid foundations, the ability to reason about a problem and write the code without being tripped up by the little things along the way.
Once someone decides to learn to work with C++ this will give them a sound basis to work from when it comes to programming knowledge and make the transistion to the unprotected world of C++ easier.
Posted by phantom on 08 September 2012 - 03:30 PM
I've been programming in C++ for a little over a year, and according to you it's likely that I have yet to encounter any of the world-ending, flood-causing, tsunami stirring disastrous mistakes that you can make when writing C++. Which means, then, that none of these vague, non-specified horrors actually apply to a beginner. Right?
Just because you haven't seen the outcome of your mistakes does NOT mean you have not made them.
Welcome to C++ - when you do something wrong you don't always get tripped up on it.
Doesn't make what you did RIGHT it just means you've been lucky.
Does it sound vague as a reason? Yes.
Welcome to C++.
I haven't come across them yet, my life isn't a waking nightmare, and I enjoy C++ and coding games with it. So then how is it a bad language for beginners, exactly? I'll never understand this use of vague scare tactics to keep people from just trying the damn language out. Don't do it! There's stuff hidden! You're too stupid to make the mistakes, that's why you haven't made them yet!!!! Oh, well then I guess I'm all good then. And when I do make the mistakes, I'll probably do what you did: Learn from them.
No, it is not a matter of 'being too stupid to learn from your mistakes' it is that C++ makes those mistakes hard to spot, hard to understand, vague due to the massive amount of 'undefined behaviour' which is allowed and more importantly makes the whole process of learning HARDER for BEGINNERS which implies, very heavily, that this is their FIRST language.
Which is why we advice against it and point out that C++ is a BAD language to start with - not that it is impossible but because you are making your life harder for yourself by trying to both learn to program AND learn to program around C++'s own vagueness and issues which is NOT helpful. C++ as a starting language WILL teach bad habits and WILL teach bad design - how do we know this? because we have seen it both in ourselves and many many times over the years.
Typical forum behavior. You see someone who's honest about their possible ignorance and try to inflate it to a size reasonable enough for you to discredit his opinions. Instead of arguing against what I say reasonably, you try to take away my voice by reminding me and everyone else that "You haven't been doing it enough yet to ruin everything." But as I've already shown, if I've been doing it a year and I still haven't encountered the horrors, that means beginners won't encounter the horrors until they're not beginners anymore. And even if I do find out something and want to switch languages, is that the death of my programming career? Is Java an entirely different world? Or Python? Or any other object-oriented language? Was my time spent with C++ wasted? Will I start from scratch? This is ridiculous.
Yes, it is typical behavior of people who have more experiance than you in a subject.
You wouldn't take 1 year of a maths class and then declare that the maths behind QM is easy - nor to should someone who is, regardless of if your ego likes it or not, a beginner in the subject be saying 'oh, I've had no problems, it must be easy'.
Many people with many more years of experiance KNOW you are wrong by saying 'C++ is easy' so YES your lack of experiance IS important when giving advice to other people who are just starting out.
And no, it isn't rediculous it is advice given after years of experiance in both learning the language ourselves and watching others trying to learn it too. Your claim that it is easy and that everyone has to touch it at some point is the thing which is rediculous here.
(Also throwing around sentences like 'world-ending, flood-causing, tsunami stirring disastrous mistakes' in an attempt to make the person you are replying to look like they are over stating the problem is also rediculous and a tactic so transparent you'd have to be blind to not see through it.)
You want to learn C++? Fine. Great. Knock yourself out.
HOWEVER the moment you come here and claim it is 'easy' expect this reply because those of us who know better WILL take you to task on it because not doing so is a disservice to those who follow you and think 'oh hey, this random guy who has only been doing it for a year says it is easy so it must be!' and end up taking longer to learn to code than they might well have done with something like Python (and in many cases Python would have got them where they want to go faster and with less mess than trying to deal with C++).
Posted by phantom on 08 September 2012 - 10:07 AM
But when we're talking about making games, I reiterate, you're going to have to read some C at some point).
No you aren't.
There is no ultimate 'you must use a C language for making games' requirement anywhere.
If Python fits the need of the OP then there is NOTHING to be gained by going to a more complex language which is considerably more dangerous to use. And lets not fools ourselves here; C++ IS a complex language. Yes, you can use it for a year and go 'hey, there is nothing hard here..' but that's because you've been using it for a year and you've no idea what lurks in the darker areas of the language or how many mistakes you have already made which haven't come back to bite you yet.
At one year of using C++, more so if its your first language, I do not believe you are qualified to say how hard the language is. You are still very firmly a beginner and more than likely are making mistakes which you are lucky haven't blown up in your face yet. I work with professionals on a daily basis who have been using C++ (as well as many other languages; C++ is not an end point either, most professionals if any degree of skill will know a few languages and can switch between them at will) for years and still make mistakes which can lead to hours in a debugger tracking them down.
So no, C++ is not easy.
It might look easy but that's just because you don't know what you are doing wrong.
(and that's coming from someone with 10+ years of using the language behind them.)
Posted by phantom on 07 September 2012 - 05:38 PM
Not all work loads are going to parallalise well onto a GPU and use them effectively, at that point you need alternative solutions.
GPUs are good at highly parallel workloads where you can get good occupancy and don't need to worry about the latency involved. However there is a point of deminishing returns when it comes to the occupancy issue and if you start issuing too little work then the GPU starts to stall out waiting around for memory and your thousands of cores goto waste. Dispatching less than 64 threads worth of work on a modern GPU is going to bite you in the effiency stakes. GPUs also don't deal well with branching as with 64 threads all moving in lock step you need to ensure thread branch cohearancy is good or you'll start wasting time and resources. If you had an 'if...else' block on a GPU where both paths are approimately equal in cost then all it would take for your GPU code to run slow would be one thread going down the 'else' path and doubling your run time.
CPUs, on the other hand, are very good at low latency branchy code where you have a few diverging paths you can take. While OpenCL can deal with this it isn't going to always be the best way of dealing with the problem which is where libraries such as TBB and MS's TPL come to play. Expressing a parallel 'for' loop is trivial in TBB/TPL; not so in OpenCL.
As for The Future, right now AMD have the right plan; a mixed approach where a CPU has both conventional and ALU-arrays (GPU in other words) which can do work loads they both do well at. The conventional core race has hit a wall, notice how we haven't increased core count recently? (I bought a 4C/8T i7 back in 2008, just recently I brought a 4C/8T Ivy Bridge i7). The future is mixed cores and even with OpenCL around you need to place your workload and pick your API accordingly.
So once again; they do not do the same thing. The GPU isn't best. Don't depend on increasing core counts to fix performance issues. There is no 'one API to rule them' when it comes to this kind of work.