617 reputation
53
bio website
location
age
visits member for 4 years, 5 months
seen Oct 13 at 23:20

Oct
9
awarded  Yearling
Oct
6
awarded  Commentator
Oct
6
comment Library to load images into textures, Linux, C and OpenGl
For those seeing this now - SOIL doesn't seem to work on iOS, so if portability is your aim, using stb_image directly may be a better option.
Aug
23
awarded  Yearling
Jan
18
awarded  Good Answer
Aug
11
awarded  Yearling
Aug
11
awarded  Nice Answer
Jul
30
comment Game State 'Stack'?
Ah, true. I feel dumb not remembering the difference between representation and topological ordering--that's actually why (as I mentioned below in my response) we developed the concept of multiple stacks for our state machine for the Sharplike project. I don't think it's that valuable (and the workarounds aren't that ugly), but I can see cases where it would be.
Jul
30
comment Game State 'Stack'?
The point that UIs are actually DAGs is well-taken, but I do disagree in that it certainly can be represented in a stack. Any connected directed acyclic graph (and I can't think of a case where it wouldn't be a connected DAG) can be displayed as a tree, and a stack is essentially a tree.
Jul
30
answered Game State 'Stack'?
Jul
30
comment STL for games, yea or nay?
I don't think it's provocative at all--it's phrased in a way to make it stick in someone's memory, but it's an extremely conservative and straightforward stance. In short: the people who develop the STL are more knowledgeable and better-equipped than somebody who finds that they have to ask this question. If you have to ask somebody else whether the STL is appropriate or not, you almost certainly lack the domain-specific knowledge to adequately prepare a home-rolled solution.
Jul
22
awarded  Beta
Jul
17
answered Automated testing of games
Jul
17
comment STL for games, yea or nay?
I would say that gamedev is about making games, but OK. If your assumptions are so poor that you are getting drilled on that kind of resource allocation, then, yes, you need to step back and reevaluate them. But you can make blindingly fast applications that use the STL just as well--and, certainly, any other implementation--when you actually know what you're doing. Learning what you're doing > cargo-culting a refusal of the STL. Nobody said the STL is always the best answer. What I'm saying is that if you can't elaborate why it's not the best course, you should be using the STL.
Jul
17
comment STL for games, yea or nay?
But if you don't want dynamic memory allocation, then you shouldn't be using the STL. That is sort of the point. Your own code is going to be no better, and could certainly be quite worse. The design decision to misuse the STL is the issue here, not the STL, its capabilities, or its perf characteristics. You're attacking the wrong part of the problem.
Jul
17
comment STL for games, yea or nay?
Mr. Acton's comment seems sketchy. Generally speaking, the STL is a good fit for those problems. If you're trying to do something in such a way that the STL approach seems "wrong," it is probably a really good idea to re-evaluate your approach and see if you're actually doing it a smart way. In my experience, more often than not, you probably aren't. (It is vastly smarter, IMO, to solve a problem by strongly understanding it in the context of your tools than to throw away your tools just to redo it from scratch.)
Jul
17
comment STL for games, yea or nay?
I agree 100% with the last part of your comment, but I'd go even further: if you can demonstrate conclusively why the STL is not a good option, don't use the STL. Otherwise, do. The cargo cult (everything from "oh, game developers use C++!" to "oh, game developers don't use the STL!") is unhealthy. I would, however, take a bit of an issue with your second paragraph: it's pretty unlikely that people who are still naive enough to think reimplementing the STL is a good idea will build a better vector than the STL folks. By the time you can do it, you no longer think you need to! :-)
Jul
17
comment STL for games, yea or nay?
This is pretty solid advice. The "STL is slow" meme hasn't been true for at least five years and probably well longer. It will continue to live on, much like the "Java is slow" and ".NET is slow" nonsense, until it becomes apparent to everyone that it's no longer the case. The STL helps you write better programs; I'd go so far as to say that not using it, in most cases (aside from that 0.1% somewhere), is irresponsible. (The claims that it doesn't fit a given problem domain are often more of an indictment of the way the problem was tackled, not the STL itself. Fix your code, folks.)
Jul
17
awarded  Teacher
Jul
17
comment STL for games, yea or nay?
So you'd rather home-rolled code than generally tested, strongly robust code? The problem domain is not all that different from project to project (aside from maybe embedded projects-- even consoles have decent STL implementations these days!). Regardless of game, your problem just isn't that different, and if you're making something you intend to ship, you have an implicit responsibility to write robust code. Is reimplementing the wheel going to lead to better robustness and flexibility? I lean toward "no". That it's not the "only way" doesn't imply it's not generally superior.