Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 07 May 2003
Offline Last Active Yesterday, 02:36 AM

#5315259 An alternative to "namespaces"

Posted by on 14 October 2016 - 04:32 PM

(expecially when you try mising using <namespace> in the cpp with not using namespace in the header.

What problem are you having with this?

How do you solve it?

I don't spam my codebase with classes that all have the same name. A namespace should represent a logical grouping of functionality. Just because you can use a namespace to distinguish between things that have the same name, doesn't mean that's its primary utility.

If you're using namespaces to group functionality that belongs together, and you find yourself doing "messy" cross-namespace references, then the messiness is a good thing - it's a code smell that you might not otherwise get. "Messiness" can sometimes be a sign that the way you have organized your code base may need some rethinking.

#5312850 Coding-Style Poll

Posted by on 27 September 2016 - 09:00 AM

I can work with most styles - my gripes with code tend to be related to how a feature is implemented not what the code looks like.

That being said, the basics:
- tabs instead of spaces if I'm working primarily in the IDE, spaces if I have to look at my code in other editors often; this should be consistent throughout the codebase.
- tabs equivalent to 4 spaces
- no snake_case - PascalCase, camelCase, and scope_camelCase are permissible.
- no class prefixes. IFoo is permissible, but discouraged.
- either put opening braces on their own line or don't, as long as it's consistent
- closing braces always go on their own line
- braces should be aligned with the scope that holds them, not the scope they define
- all control flow statements must include braces (except switch cases, which are obviously delimited by other control flow statements) to prevent mistakes

These ones are optional, but I like to enforce them on myself anyway:
- try to stick to a maximum line length of 100 characters
- if a line goes past 100 characters, it should be split up
- if a function signature or invocation would be split up to maintain the line length, all arguments to the function should go on their own line.
- do not declare multiple variables in the same declaration
- if a template type is long enough to take up significant space or is difficult to remember (eg. std::vector<std::vector<std::pair<std::string, int>>>), create a type alias with a more readable and meaningful name and use that instead

// don't do this
auto thing = foo();
if (thing) {

// do this instead to enforce that the variable 'thing' can only be used if it's valid
// C++'17 will add syntax to make this work for more than just pointer types
if (auto thing = foo()) {

// I saw some id Software code that did this and I'm quite pleased with it
// Yes, it's a pain in the ass, but it makes the code SO much more readable for me.
// I would only do this if I had to "pretty up" my code and didn't think it needed to change much.
float    x    = 0.0f;
ThingFoo foo  = ThingFoo::Null; 

#5311308 Visual Studio's Lower- and Upper-Case Ignorance

Posted by on 18 September 2016 - 11:37 AM

I would try opening up the project in a text editor and changing the case there.

#5311091 Game works when built in the IDE, but crashes when I run it from the .exe file.

Posted by on 16 September 2016 - 11:26 AM

Oberon_Command, you were right. There really is something wrong with my model class structure, I access some memory I shouldn't access. And is something that CodeBlocks automatically fixes for me.
Can I somehow say to the compiler to not allocate additional memory and to perform the same way as when I run the .exe file?

I don't know about Code::Blocks, but when you start an app through the Visual Studio debugger, it uses a special debug allocator that initializes all memory it allocates to 0s. This feature can sometimes hide problems with uninitialized variables. I would go through your Model class and look for uninitialized stuff. I also recommend turning your warning level up to maximum and seeing if it calls out anything like that.

Another line of thought: I don't know how to do it with GDB, but I presume there's a way to attach the debugger after you launch. Here's something to try:
- stick an infinite loop before you load the models
- launch the game from the OS
- attach the debugger and break in the loop
- force GDB to step out of the loop
- let the game run and let the debugger catch the crash

#5309817 Hostility in the field

Posted by on 07 September 2016 - 09:18 AM

At my present place of employment, we are not permitted to give any kind of employment references, positive nor negative.

I3ANAL, but couldn't that be construed as a policy that could hurt former employees' careers, and thereby open the company up to lawsuits of a different sort?

I'm not sure I'd want to work for a company that I knew would be unwilling to act as a reference during my next job search. It seems like a career-limiting move to work at a place where the employer will be unwilling to even confirm that you worked there. :P

#5309672 Terrible performance on my first game

Posted by on 06 September 2016 - 08:11 AM

How many bounding boxes are in your level? You're iterating through all of them to check for collisions every time. That's not fast, but if there's only one entity the performance hit shouldn't be too bad.

Have you tried profiling your code, or failing that commenting out sections of your code to see if disabling particular parts of your code makes your program fast again?

#5309397 Hostility in the field

Posted by on 04 September 2016 - 10:10 AM

Do you actually expect an applicant to tolerate any roadblock, spend any amount of resources to get a game programming job?

What do you mean by "roadblocks" and "resources?"

I've known coworkers who relocated oversees when the job market for game developers in their home countries started to dry up, rather than go into a different sector of the software industry.
I've known at least one coworker who was vacationing in my country, saw a job posting they found interesting, and moved here from Europe to pursue the opportunity rather than lose it.
I've known multiple coworkers who dropped out of university because they had the opportunity to be a professional game developer, and decided to take it. For people like that, meeting the CS degree requirement that's common in the game industry is the only reason they bothered with university in the first place.

And from experience, just about every one of us dedicates time and sometimes even money to learning in our own time and to side projects. Personally, I'd expect someone who wants to be a game programmer to do lots of programming related to games on their own time. Someone who just went through the motions for school, no matter what their grades, is not going to cut it. It's likely that they won't have the kinds of skillset we look for because many or even most schools don't teach the right skills, or teach the skills but don't spend much teaching time on them. Being self-taught is considered a point in your favour.

The line I would draw as of right now is relocation, especially if I'm not paid for the relocation. My family and friends are all here in the city I've lived in for most of my life, and I'm reluctant to leave it. But if I had a sufficiently interesting opportunity, or the job market here dried up, it's entirely conceivable that I would move.

I also won't work for any company that doesn't allow their employees to have side projects in some form or another. Gamedev was my hobby before it was my career. It's still my hobby. I still learn a lot from things I do on the side. Good employers know this and allow side projects as a way for employees to grow.

You not only demand an infinite patience - you demand virtual perfection. With all due respect, who are you - or anyone in this industry - to demand so much?

Now that you mention it, most game developers I've met are very patient. Working with big complicated systems like video games does take patience. Working with designers, some of whom are reputed to have a tendency to request big changes on a whim, takes patience. I've worked on some big AAA titles that had very poor iteration times. Think an hour to compile the game executable, and many more hours to get the game's data cooked. Impatient people tend to leave circumstances like that.

But none of what frob was saying is at all rare, besides "all the other superpowers." I'm not totally sure what that means. Anyway, I'd say it's rare that a game programmer is not passionate, smart, and quick-thinking. You have to be just to be able to keep up with the pace while dealing with the complexity of some of the systems we maintain. I would say that asking for those traits is not demanding "perfection" by any stretch of the imagination.

#5308943 Does anyone have any advice for my unique situation?

Posted by on 31 August 2016 - 07:45 PM

I know those values are the right ones because they've been the right ones for the last 30 years or so...These values have more than 30 years of actualy use backing them up. They are far more certain than any computer game values.

Humor us non-designers. We're curious. Tell us why those are the right values. Tell us what would happen if we didn't use those values. Please. That's all mikeman is asking. Is that really so difficult? What was the question you thought mikeman asked, that you thought you were answering?

You could even write a multi-paragraph blog post explaining those numbers alone. People here would read it.

If you can't explain why you believe something, how can you be sure that you're right?

#5308421 Why can't I print out my std::string vector?

Posted by on 28 August 2016 - 09:00 PM

Are you by any chance using XCode?
Btw one more thing: It's a security risk to do printf( myCStringVariable ); Perform instead printf( "%s", myCStringVariable );

Could you elaborate on why that's a security risk?

Suppose myCStringVariable contains "%s".
Then we have a statement here that can be rewritten as printf("%s").
This will try to print out whatever is on the stack where printf would look for its second argument - only there isn't one.

This could be anything - a valid pointer, a null pointer, arbitrary data - even executable machine code. An attacker could use this to crash the program, or look at the stack frame and work out where the current function's return address is, or do all manner of nasty things one can do with printf specifiers that point at garbage.

The %n specifier in the wrong hands could be particularly nasty because it allows printf to modify an argument passed to it...

#5308109 Style preferences in for loop structure

Posted by on 26 August 2016 - 03:57 PM

Speedwise, get rid of the conditionals in any way possible (even - or especially - if this means restructuring your data).

Branches in for loops are bad juju. They typically play very very poorly with branch predictors. Branch prediction is a _massively_ important part of how CPUs work; they're up there with cache access pattern in terms of "hardware crap you really need to understand and think about" when writing games (or any application, imo - even if raw speed isn't important to you, saving on energy costs is hugely important in mobile and server workloads)....

I completely understand and respect your argument against branches in loops. I mean I've designed and built computer systems on the circuit level and understand machine cycles, energy consumption, registers and such, but don't you think that "branches in for loops are bad juju" is a bit excessive for the general case? If you're iterating over 300,000 objects, then I can see where you can shave off a substantial amount of time eliminating branches. However, with today's PC hardware standard, would looping through 10 or 15 items with branches make a difference you should care about?

It isn't just the performance considerations. Pre-sorting objects to iterate through them without conditions simplifies the code, as well. You can look at a piece of code and know exactly where it's going to go just by looking at it. That (usually) makes it easier to see what a given piece of code is supposed to do in addition to what it does.
// this is annoying to read and debug - I have to step through the loop to see what kind of entity I'm on at any given type
for (auto& e : entities)
   if (e.type == boop) { // ... 
   if (e.type == snoot){ // ... 

// this is better
for (auto& e : boops)
  // ...
for (auto& e : snoots)
  // ...

#5307958 Does anyone have any advice for my unique situation?

Posted by on 25 August 2016 - 10:42 PM

I'm simply pointing out how I see your manners here and reiterated how others have said that they see you (in other threads). You may not intend to come across as strongly averse to criticism, but intent doesn't matter much. How your words are interpreted is what matters. With careful consideration, you can choose words that best match your intent. If you feel misunderstood, you CAN try again using different words. There is always the edit button if you find you didn't word something to best effect. Go back and read my posts and you may notice that I've been using it, myself. :)

You have said that you feel like a game industry outsider, so I also told you some of the things that I know about the industry as someone who works in it, in hopes that you may find it useful. Especially if you DO end up pitching your ideas. Is that not ultimately the point of this thread? To hear advice and learn from game devs? ;)

#5307953 Does anyone have any advice for my unique situation?

Posted by on 25 August 2016 - 10:18 PM

I have not at all acted like you are personally attacking me. Not one bit.

Then why spend paragraph after paragraph trying to save face, asserting your authority, and generally acting insulted? :)
I don't have to carry on this line of conversation, either, but believe it or not, I actually WANT to help you fit into the community. As I see it, this is best done by addressing what I see as problems head on, and right now the biggest problem is that you don't accept criticism and are easily sidetracked into reiterating your claims of experience, presumably to save face.

You are speaking too me as though I know nothing of the subject, and you are an expert I should be listening too.

I don't feel I'm doing that - again, all I'm doing is asking questions in a bid to point out what I feel you've missed - but anyone who is reading this thread can tell that you're really bothered by my posts. You behave exactly the same way as other people I've known who were personally insulted by any kind of criticism, so it's a straightforward assumption to make here. I suggest that your generally dismissive attitude towards everyone else's opinions might be the cause of this. ;)

This isn't all in my head, I've had this same conversation for the last 20 years.

You know what they say, if you keep having the same problems with different people, chances are good the problem isn't with them, but with you. Other people with similar levels of experience in the game industry don't have this problem. I know this because I know and have worked with some of them.

I'm still trying to figure out where you feel that if what I say, with 30 years of experience at a very high level of this specific subject, does not "square with what you know" that you feel justified in assuming that I am the one that must be wrong, and you must be right.

If I can come up with trivial counter-examples (which of course you reject) to the things you say (to be specific, that space combat games don't have AIs shooting back and don't have dogfighting and that Artemis wasn't a game and hadn't been released), your experience level has nothing to do with it. If you make a statement that I think I can prove is wrong, I will attempt to do so. Why shouldn't I? Truth does not care about experience and experience is (in my experience!) not a valid measure of competence though it does suggest it. Even the most experienced people can be wrong, and sometimes too much experience with something can actually weigh you down. It can cause you to miss things because your assumptions are so ingrained, or you've become so insular that your knowledge goes out of date. A great many "experienced" people should not be given anything resembling a leadership role.

I occasionally encounter programmers with an attitude like yours - the attitude that because they are older and more experienced than everyone else, that their word is gospel and not to be questioned. A minority of them do prove their worth - but nobody likes them for it, and sometimes these "prima donnas" don't last very long as the morale drop associated with their presence outweighs the extra productivity they bring - or don't bring, if their blustering proves to be all a sham to cover up their own incompetence! Many of us with even a little experience in the industry will have met one or more of the latter. Consequently, I actually respect a person less if they harp on about how much experience they have. It suggests that they're compensating for something.

Don't be that "prima donna." It doesn't matter how right you are if nobody will work with you. If you ever want to work with video game developers - especially programmers - it is a very good idea to completely drop the attitude that being the most experienced person in the room means nobody will question you. Because they will. "Pointy-haired bosses" may prove easily dazzled by self-advertising of the type you continuously do on the forums, but programmers do not respect it (we prefer quiet demonstrations of competence), and your fellow designers will have the vocabulary and experience themselves to point out things that you miss. Don't reject that feedback out of hand!

#5307944 Does anyone have any advice for my unique situation?

Posted by on 25 August 2016 - 07:02 PM

So you are certainly in the majority in your opinion. So I would really like to ask you, since you say you've even read my blog, what it is that has you completely convinced that you are the expert here, and I don't know what I am talking about.

Sigh. Do note that I never claimed either of those two things. Please re-read my posts with that in mind. :)

All I've done is question and contradict specific claims that you've made, because they didn't square away with what I know. I suggest that, in the interests of your future interactions remaining productive, you re-consider how to respond to a little mild critique that is intended to be of use to you. So far, your response to people pointing out small things that appear to be inaccurate to us is to act as though your reputation is at stake - as though you were personally attacked. You act as though disagreement is a personal insult. I suggest you stop, as that kind of response is one of the things that caused the community to react poorly to you in the first place. There is no cause to feel personally attacked here.

Do remember that critique of or even attacks on on something you say do not constitute attacks on your self or your reputation. I'm not sure how one can rationally infer "you know nothing and I know everything" from "I think you are wrong about [specific thing], prove it." None of us here know everything - calling out each other's mistakes, or explaining to others how what looks like a mistake is not, is how we help one another grow. Experience is not a shield. If you're looking for people who will only genuflect at, as opposed to actually discussing your ideas, then I suggest you look elsewhere, because I doubt you'll find anyone here interested in that.

#5307934 Style preferences in for loop structure

Posted by on 25 August 2016 - 05:08 PM

That's make sense. Never thought about from a debugging standpoint.

No matter how correct your code is, if it goes out into the world, someone will always want to step through it with a debugger. Even if they aren't chasing a bug, some people use the debugger to understand how unfamiliar code works. Don't make it hard on those people - those people might even be you, six months from now. :)

#5307930 Style preferences in for loop structure

Posted by on 25 August 2016 - 05:00 PM

It depends on how many such conditions there are, and what the "most common" case is. If there are several conditions, then I would prefer the second form, because it's easier to follow and to debug. Compare:
// first way
for (int i = 0 ; i < MAX ; i ++)
    if (someCondition && someOtherCondition && unrelatedCrap && 
        whyIsThisHere && isThereAnyCoffeeLeft)
        foo () ;
        bar () ;

// second way
for (int i = 0 ; i < MAX ; i ++)
    if (!someCondition)
    if (!someOtherCondition )
    if (!unrelatedCrap )
    if (!whyIsThisHere )
    if (!isThereAnyCoffeeLeft)

    foo () ;
    bar () ;    
The second form is much longer, true, but note that now I can put debug breakpoints on each individual "continue" statements, so when one of the conditions fails I can explicitly see which one it was. Similarly, if I put an uncommon condition in its own if/continue block, then I can put a breakpoint on it and add logging to catch that case. In the "real world", each of those single variables in the condition might be giant expressions in and of themselves, so separating them helps make them more understandable, too.

If there's only one condition and you expect to be the most common one, I would say go with the first one, as it's more straightforward and only one condition that could fail.