Promit

IF used correctly, std::vector should show equivalent performance to raw arrays IF optimizations are enabled and IF you have a sane implementation. There are caveats here to be wary of, especially if you're cross platform. But knocking std::vector out of your code is not an optimization strategy.

By comparison, I see people on these forums throwing together prototypes on a matter of days (I don't even understand how you can prototype a game, with all of the underlying framework that is required). People participate in the Ludum Dare competition, creating full games in under 48 hours. And full released games on Steam, like Terraria, which were developed in only 6 months.

There's your mistake. No framework is required. Some developers use existing frameworks (Unity, Allegro, whatever) and some just plain freeform it. The key to coding fast is to throw architecture to the winds. This is a healthy skill to have, though whether you should make a habit of of it is another matter entirely.

Rapid prototyping is a valuable way to build out the basics of a game, make sure it's worth building at all, and catch early design mistakes. I would suggest that it's vastly more useful than the idiotic design documents everyone thinks they need. Sit down and write a full, playable game in a week. It will force you to think very hard about what is actually machinery for the game, and what is your own toying around with code. Eventually you'll learn to do this in a way that doesn't defy expansion into well engineered code later.

I forgot to mention, also, that both APIs are essentially a minor part of your code these days. Once you've got the concepts down, it's more just a question of wiring up the API to do things the way you need. It seems like a really big deal as a beginner to be coding all this D3D or OGL stuff, but I can honestly say it's probably the most boring part of my graphics coding work. The API is just a machine I have to configure so that my CPU code and my GPU code talk to each other properly.

Both work fine, D3D's much nicer, usually your platform dictates the choice. That's pretty much it. At the end of the day, learning modern GL (ie 4.0 and ES 2.0) prepares you for most of the non-Windows platforms you're likely to see, and that makes it a compelling choice even though the API itself is fairly shoddy.

C++ isn't that hard. You just have to remember if you wrote new you have to write delete somewhere. There also also some tricks which make code looks complicated, but you don't have to use them.

That's exactly the kind of dangerous advice that leads people into thinking that they should just learn C++ without worrying about the details. Oh, it's only complicated if you write it complicated.

No.

The whole danger of C++, the reason the experts are always telling people to start elsewhere, is not that you can write complicated code in C++. It's not even the memory management thing. It's that the whole language is afflicted by "here be dragons" quirks and corners that you can't see. I ran into a bizarre bug about two weeks ago and I'm still not sure whether I broke C++ rules or whether it was a compiler bug generating bad code. They key to understanding C++ is that, if it seems like a simple and easy to use environment, then you've probably made several major missteps. That you can't find. And THAT is why people need to go to C++ only after they've got a solid handle on the fundamentals.

You're a bit vague about exactly what order the stuff in your drawing is drawn in, but I think you've got essentially the right idea. Just keep in mind that stencil ref doesn't do anything by itself, it just feeds the other operations. Your first block of states will set the stencil to 1 only where stencil and depth test pass. In the second block, you tell it to set the stencil to 1 again when both tests pass, which implies that stencil was already 1. So the second draw call will never change the stencil value. You also don't seem to be setting the stencil fail value, I don't know if that's intentional or not.

Check this article and see if it helps clarify the masks. It basically does a bitwise operation on the stencil values to determine which bits are significant and which are ignored for the rest of the stencil operation.

So the provided example may not issue branch instructions at all. This is a candidate for uniform branching, in which case the runtime or driver may choose to produce multiple compilations of the shader where all of the branches have been resolved and the loops unrolled. This was really common before we had hardware branching, in the 2.x days. I'm not sure to what extent it's still used now, but you can hint the compiler to unroll loops and avoid branches.

Uber shaders give you much more precise control over compilation though.

Meh, both are fine -- though I'm dyed in the wool Direct3D myself. The trouble is that although current OpenGL is passable, finding documentation and tutorials on current OpenGL is next to impossible. So instead you end up following shoddy old OpenGL tutorials that were a bad idea in 2002, and have to spend months undoing the damage piecewise. It doesn't help that the bad versions are waaay easier for beginners to code. D3D 11 is a bit trying as a newbie, but at least the correct path is drawn clearly.

How much fidelity do you need? You could simply go with the old school technique of a sample from a 1D texture lookup table.

So all in all, I believe this "synth vs organics" pretext at the end of the game was BS. The part of the game that revolves around it is way too small for it to justify the atrocities committed by the reapers. And it's not even the least bit explained.

This is really what I was getting at regarding the ending. The ending suggests that it should have been a central theme throughout, but it wasn't. The places where it would've been possible to make it a central theme, it wasn't really even present. It simply shows up at the end and is supposed to be a big deal because projected hologram kid said so. "Synthetics will destroy all organics." Why? There is no reason. But they said it so it must be true. I am projecting my own desires for how I wanted the game to go onto that ending, I will admit. I love what that ending could have been.

The most emotional part of the synthesis ending is actually Joker and EDI, and has nothing to do with the Reapers or Earth or Shepard.

I did not find the ending disappointing. I did find it awkward and half baked, like a first draft that was never revisited. I see what they were trying to do and I think the idea was good, but the execution was botched.

First: Of the three endings, only synthesis makes any sense. The other two are token choices that aren't actually worth existing. The destroy option is struggling to be interesting, and the control option is just plain idiotic. That doesn't even begin to touch on the insulting point that you couldn't tell the endings from each other anyway. So I'm only going to talk about the synthesis ending.

Across the three games, a couple themes are set up: control vs destruction, organics vs synthetics. To end the game by exposing these choices as false is an interesting, somewhat subversive, very Deus Ex approach to ending the game. I like this basic concept, and the fact that it was considered is what makes the other two choices token. The Quarian-Geth conflict does the most to set up the idea of unavoidable stand-offs between organics and synthetics, although the way it's written makes the Quarians seem like insane irrational douchebags.

For Shepard to close the story by transcending the conflict entirely lends a sense of meaning that is intended, I think, to make both the Illusive Man and Anderson seem petty and short sighted. They do a reasonable (but not subtle) job on the Illusive man, but not so much with Anderson. At the time the ending hits, you are very much sympathetic to Anderson, for good reason, and to place "his" choice on equal footing with the Illusive Man doesn't quite work. He's too eminently reasonable and good natured throughout the whole thing. For this to work, Anderson needed to be set up as a much more ruthless, battle hardened Renegade style leader -- but that was never his character. BW tries to haphazardly and quickly give you that impression in the final conversation with the Illusive Man and it simply doesn't work.

Then there is the idea of synthetics versus organics, and the final conversation with the Citadel/Catalyst itself. This could have been extremely interesting, if the approach wasn't completely botched. The idea that the Reapers themselves are subservient to a greater conflict, one that cannot be avoided by simply destroying them because it is inherent in the system of life itself? That is awesome. But the game doesn't bother to set it up. There is, by my count, ONE line in the entire game (delivered by the Prothean VI) that hints at what is going to happen. The one Reaper you kill personally also sorta hints at it. Yeah it's an RPG and every prophecy comes true, but this was sloppy. Again, the Quarian-Geth conflict could have gone a long way to setting this up, as could have the conversation with the Reaper, conversations with the Illusive man, conversations with the Prothan VI, etc. The game and story needed to be suggesting from the beginning that something else was leading the whole conflict, and that didn't happen. Instead it simply crashes on you at the end of the game like a cartoon piano. Something needed to happen, so here it is. And it happens too fast to provide any actual context or closure.

Which actually brings me to the real problem with Mass Effect 3's writing: a lot of things happen because Bioware says so, without the proper setup. Why are organics and synthetics doomed to fight? Because the dude said so. Why are you sad and emotional about that kid at the beginning? Because the game says so. Why is James a good marine? Because Shepard says so. Show, don't Tell is just forgotten entirely.

ME3 works best when it's bringing closure to things that you are already emotionally invested in from the previous games (which suggests that if you didn't play them, this is a shitty experience). You are emotionally invested in what happens to Wrex, to Mordin, to Tali, to Legion, etc. The second game in particular spent a lot of time getting you invested. But the characters in this game? They show up out of the blue and the game tells you to care -- but you don't. James is supposed to be a complex character with an interesting back story, in some sense a reflection of Shepard before the events of Mass Effect. But he's not. He's just a generic space marine shoved into the game who has a minimal number of not very interesting lines. Ditto Cortez, though maybe that's better if you follow the romance plot. The game never bothered to invest you, they just tell you to be invested because arrr Reapers.

The most blunt version is probably in the meeting with the Lawson family at Sanctuary, because it places a character you care about smack in the middle of a conflict that you don't give a shit about, involving people you've never met. Why is Henry Lawson evil? Because he just is! Why does Oriana Lawson need saving? She just does! What kind of danger was she in? The game doesn't even bother to explain. You're running around doing stuff because that's what you're supposed to do.

So when you get to the final conversation and decision point, it's a tough decision. Because the game said so with a mangled hologram that is apparently some AI? And the Crucible modified it somehow because shut up and don't ask questions. They've just dropped a crucial new character on you, out of nowhere, and they give you absolutely nowhere to take that. The context of your ultimate choice? Some kid told me to do it. They don't even give you the option I wanted -- walk away from the choice entirely. Tell the AI to solve its own problems and let the battle go on its own. DXHR does give you this exact fourth option. But the epic final decision is only interesting if the game has been properly written to set it up, to foreshadow and hint and tease, and finally give you what you've been expecting. ME3 just pops up with it out of nowhere.


Incidentally, I found this article to be quite interesting.

glFlush is fundamentally a legacy toy and best ignored. It's at the driver's discretion what to do with it, and in most cases that is probably not much.

I do not think you should skip anything in favor of C++. It's a terrible starting point. I'm not fond of Java and would push for Python or C# instead, but definitely not C++.

Steam.

A lot of problems with OOP stem from the way it is badly mis-taught to programmers. The recent push for data oriented design is related, but it isn't quite the same. The trouble is that object oriented programming as presented in most educational material is badly flawed. It does not reflect real world usage of objects, it does not reflect real world problem solving, and it certainly isn't a good way to think about code.

We learn in school and in books that object oriented programming is invariably applied to logical, human based objects. I've heard this referred to as "noun-based" design, and frequently imposes constraints that have everything to do with a human abstraction and nothing to do with the technical problem we're dealing with. The problem is further exacerbated by is-a and has-a relationships, UML diagrams, design patterns (GoF), and all that other crap that passes for "object oriented software engineering". Then you wind up with projects like Java, blindly applying the OO principles in the most pointlessly abstract terms imaginable.

And to top it off, most of this code never turns out to be "reusable". The biggest promise of OOP simply does not deliver. And the tight coupling headache leads us down a whole new rabbit hole of design patterns, IOC, and stuff that lands us so far in abstracted land that we've lost sight of what it was we were trying to do. I understand why the guys who think we should have stuck to C feel that way, though they are misguided.

The object as a unit of control and a point of polymorphism is, in itself, a useful tool. Functions are useful tools. Combining the two gives us an enormous amount of flexibility, and largely defines what an OO language is all about. (Hi Java, you piece of moronically designed trash.) But it is absolutely critical to dispense with the notion that either of these tools must or even should correlate to any kind of normal human concept. And I for one am finding that particular habit to be enormously difficult to get away from.