Jump to content

  • Log In with Google      Sign In   
  • Create Account

Oberon_Command

Member Since 07 May 2003
Online Last Active Today, 03:59 PM

#5298125 Have I been aged out of the industry? And where else can I go?

Posted by Oberon_Command on Today, 12:03 PM

conq: My feelings are not as extreme as what you imply at the end of your post. Once people get over their initial fear, they tend to find I'm a nice, witty guy. At least, that's what my friends say - their opinion might be biased ;) Nobody "knew something about [me] that even didn't know" (but to be fair, I've heard some surveillance horror stories...) or is trying to get me fired, but people have beaten me up, and people have betrayed me - I don't see why this necessarily means I'm mentally ill.


Far and away from mental illness, to me it sounds like there's something in your mannerisms that creeps people out and you've internalized the reactions you're getting to that. Body language matters, and even little things that are "off" can make people dislike you. Certainly I've had that "fear reaction" to people with body language that was "off" before. I'm self-aware enough to repress it as soon as it happens, but I get the sense that most other people aren't. The good news is that if your body language is your problem, once you're aware of what mannerisms those are, you can change them. It may even be something really simple that you can fix just by paying a little more attention to body language in general. Have you ever actually asked one of your friends why they were afraid of you at first? Or are you just going off guesswork here? I suggest that it's worth finding someone in your personal life who initially had that fear reaction to you and asking them some questions. Your friends are supposed to help you grow, and a real friend will be honest with you if you ask them and make it clear that you're asking because you want to better yourself and not because you want to have your ego stroked.
 
A coworker once told me of interviewing someone who was qualified according to his resume, but had a creepy stare. The candidate would look at you without ever seeming to blink, without ever seeming to look away, which coupled with generally terse answers to questions made him come across as off-puttingly intense. My coworker called it a "serial killer stare." I don't remember whether or not they hired him, off the top of my head. I've encountered people who stare like that, myself, and it really is off-putting. Some more examples of people I've found off-putting:

- someone who had a creepy way of moving his hands

- someone WHOSE VOICE HAD NO VOLUME CONTROL MEANING YOU COULDN'T HOLD ANYTHING RESEMBLING A PRIVATE CONVERSATION WITH HIM

- a number of people who chewed noisily and with their mouth open (yuck!)

- people who smelled bad

- people who stood too close to me

 

These were all things that weren't quite egregious enough to say anything about, but were still sufficiently off-putting to make me (and others) avoid them, at least until I recognized what was happening.
 
I myself used to be someone who could get weird responses from people, and so I have a pretty good idea of how it feels to be on the receiving end of that fear response. Encountering others who triggered that response in me helped me become more aware of my own body language (and in fact that body language was the problem!) and tailor it to match what people were more comfortable with. Eventually the changes became habit and I don't have to think about body language that much anymore.
 
 
To clarify, the second request I made earlier in the thread was for you to provide specific anecdotes of the ways that people have responded to you. Again - understand if you aren't comfortable with telling those sorts of stories on a forum, but telling us (eg) exactly what happened when a person "betrayed" you, or the chain of events that led someone to beat you up, might go a long way to helping us understand you.




#5297993 Have I been aged out of the industry? And where else can I go?

Posted by Oberon_Command on Yesterday, 08:53 AM

I have become jaded thanks to a lifetime of predators attacking me since toddlerhood, and what few people I thought were my allies turn traitor at the most damning opportunity.

I program because it is the strongest skill I know, and the only skill in demand enough where someone might overlook their hatred of the other enough to hire me. But even that is coming to a close - people have grown to hate the other so much I have become unemployable.


You keep bringing this up without elaborating. You seem very insecure about something and I understand how that feels, but we might be able to give you advice more tailored to your situation if you went into more detail about why you think people hate you and don't want to work with you. If you don't feel comfortable doing that, maybe you could give us some examples of the shit that's happened to you so we understand your jadedness?


#5297726 Is there any reason to prefer procedural programming over OOP

Posted by Oberon_Command on 23 June 2016 - 12:14 PM

Just for kicks, take a look how much inheritance or polymorhism is used in the C++ standard library.


Not that I disagree with your general point, but I don't know that I would necessarily call the standard library especially object-oriented - in fact, its original designer believes that the C++ standard library (or at least its predecessor) isn't even object-oriented at all, so I would say that the standard library is not really a useful example of "modern OO". Relevant quotation from that link:
 

Yes. STL is not object oriented... I find OOP technically unsound. It attempts to decompose the world in terms of interfaces that vary on a single type. To deal with the real problems you need multisorted algebras - families of interfaces that span multiple types. I find OOP philosophically unsound. It claims that everything is an object. Even if it is true it is not very interesting - saying that everything is an object is saying nothing at all. I find OOP methodologically wrong. It starts with classes. It is as if mathematicians would start with axioms. You do not start with axioms - you start with proofs. Only when you have found a bunch of related proofs, can you come up with axioms. You end with axioms. The same thing is true in programming: you have to start with interesting algorithms. Only when you understand them well, can you come up with an interface that will let them work.


Note that he's specifically against runtime polymorphism switched on single interface. Most of what he's talking about specifically refers to OOP as pushed in statically-typed Java-like languages as opposed to languages like SmallTalk.

Of course, this topic has been discussed for a while and nobody agrees on what OO is, so I suggest that OP ought to have specifically referenced "which" OOP we're to compare with procedural programming.


#5297101 Why didn't somebody tell me?

Posted by Oberon_Command on 17 June 2016 - 11:52 PM

C++ doesn't allow function-local classes with static members or template member functions.

I'm a little worried that anyone ever tried to do that...


It doesn't come up all that often, but I saw a case recently where it would have been useful. Briefly: classes that inherited from a particular base class were most concisely implemented with a templated method that was called from within the base class - which was itself a template, and the derived classes were also intended to be passed to another templated method on a different class. The class didn't HAVE to be function local, and the method didn't HAVE to be a template - it just made the code substantially easier to follow, for the same reason that a lambda can make code easier to follow. In fact, in a dynamic-typed language the whole thing possibly could have been replaced with a lambda.


#5296960 Why didn't somebody tell me?

Posted by Oberon_Command on 17 June 2016 - 08:54 AM

C++ doesn't allow function-local classes with static members or template member functions.


#5296761 CrossPlatform Code

Posted by Oberon_Command on 15 June 2016 - 09:03 PM

I would go for roughly the second option - define a common interface in a header file, but instead of having #ifdefs sprinkled throughout the implementation, consider having separate .cpp files for each platform. So you might have memory.h, memory_win32.cpp, memory_linux.cpp, memory_x360.cpp, etc. Your compiler toolchain(s) should allow you to make some files compile in some configurations but not in others.


#5295996 Trivially trivial?

Posted by Oberon_Command on 10 June 2016 - 11:22 AM

I am currently looking at a custom somewhat vector-list-hybrid like container in C++ that I'm using. It's basically like an unrolled linked list with page-sized chunks, a large initial size, and a non-geometric (again, page granularity) growth strategy, and some other subtleties.

 
That sounds a lot like std::deque.
 

For these reasons, it is generally certainly a good plan to call the copy constructor because if the object has one, then it's a fair assumption that it takes care of such problems.

But: And here's the catch, we are not copying the object, are we?


Right. It's the move constructors you'd want to invoke, unless you're working in a version of C++ that doesn't have move semantics. You'd probably still want to call the move constructors on the objects since while most of the time it's just moving bytes around (which is really why move semantics is in the language!), there might be something specific that some class or other does in their move constructor.
 

Think a callback function (scripting???), but those functions are likely static, not member functions anyway.


Not necessarily, now that std::function is a part of the standard library. A more modern scripting system might even allow callbacks to be defined as capturing lambdas, which case moving anything that gets captured by reference (or that captures "this") would require re-constructing the lambda.
 

In short, can you trivially imagine something non-trivial being a problem when being treated as trivial in this context?


- the case you already mentioned: "a class which registers pointers to inside itself with some external API", eg. via something non-obvious like a capturing lambda
- more specifically, objects within the container could store pointers to one another - the main case I could see this happening was if the objects were meant to be placed in a dynamic memory pool with an intrusive free list, and the move constructors were used to fix up the list pointers. This seems like a terrible idea, but I could see someone doing it.
- the class logs how often it is moved, probably for debugging reasons
- the class somehow logs where it is being moved
- the class uses its own pointer to deduce which container it's a part of right now and cache a pointer to that container when moved; I could see this being used in a system where the objects could talk to their owner (eg. so they could remove themselves) or that made heavy use of "existence based processing". This wouldn't be an issue if moved within the same container, though.
- there exists some sort of implicit mapping between an object stored in the container and an object stored in the other container that would require the other container to be updated, and for whatever reason the code changing the first container doesn't know that

I'm sure I can think of others, but I admit that they're mostly odd corner cases.


#5295833 are vidgames disrespectful of player's time vs tabletop RPG's?

Posted by Oberon_Command on 09 June 2016 - 12:13 PM

I think it's just a different experience. Some people genuinely enjoy wandering around and taking in the world. The "gameplay" may be reducible to "greyscale and cubes", but the gameplay doesn't need to be the whole experience. Nor is it the only way to have fun with a game. Immersion and flavour can be "fun" in and of itself.

 

I am going to guess that you aren't a big fan of "walking simulators," either...




#5295543 use ID or Pointers

Posted by Oberon_Command on 07 June 2016 - 04:46 PM

Add "no type-safety" to the "cons" list for integer handles/IDs, please.


For pure integer IDs, yes, but you can always write a handle class that enforces type safety. Or you can get some type safety at runtime if you use a handle type that stores the underlying type of the object. In some cases, a lack of type safety can be a feature, not a bug - to add to what Hodgman said, consider an architecture where an entity is broken up into smaller pieces that conceptually represent the same object, but are stored in different places in memory. You could even write a custom "component container" structure that tracks the "object type" that the component is associated with at compile-time and make the object type a template parameter on your handle.




#5295314 College? Life? Urggg!?

Posted by Oberon_Command on 06 June 2016 - 11:52 AM

Whatever degree you get, do not assume that school will give you all the knowledge you need to be successful. Colleges and universities are not (usually) trade schools. Studying computer science really means studying the "science of computation," not programming, though programming is definitely a part of computer science. Make sure you do lots of programming outside of your classwork, because you won't get nearly enough programming experience to compete even with other junior devs through school alone. As someone who went through a computer science degree myself, it's depressing how many people think just going to school prepares you for your career.

 

There are huge swathes of students coming out of CS degrees that got good grades, but didn't really learn to program and can't even identify (for instance) the difference between an array and a linked list. Don't be one of them. 




#5294973 pointer safety in entity component system

Posted by Oberon_Command on 04 June 2016 - 09:44 AM

This isn't how an entity-component system usually works; what you're describing is just plain composition. A typical entity component system will keep each component type in its own array making the "entity" only an identifier used to look up components in the arrays, side-stepping the problem you're having entirely. In that way, each entity doesn't have to store a lookup and you don't have to cast anything - all you have to do is take the identifier representing the entity and look it up in the array of components you want.

Extremely contrived and simplified example (still using std::map which I don't really recommend and am only using for clarity):
struct Position
{
   float x;
   float y;
};

struct Health
{
   float hp;
   float maxHp;
   float regenRate;
};

std::map<int, Position> positionComponents;
std::map<int, Health> healthComponents;

int CreateEntity()
{
    int retval = NextEntityID();
    positionComponents[retval] = Position();
    healthComponents[retval] = Health();
    return retval;
}

void DoDamage(int entityID, float damageAmount)
{
    healthComponents[entityID].hp -= damageAmount;
}
Doing things this way can actually be a lot simpler than treating each entity as a bucket of named components. If you have your heart set on doing composition in the way you're doing things now, you're going to want to read up on templates, since your getComponent<T>() method will need to use them. You could implement getComponent as a template that looks for a static string field with the component name on the type given to it, then use that string to look up the component and cast it down if it exists.

If you're interested in the sort of thinking that leads to an entity-component system in the first place, I recommend reading this online book on "data-oriented design", especially the chapters on component-based objects and existence based processing, and most especially the section entitled "There is no Entity" as it pretty well exactly describes an entity component system.


#5294827 How does Runge-Kutta 4 work in games

Posted by Oberon_Command on 03 June 2016 - 12:28 PM

This seems relevant. The example code given is even integrating a spring.


#5294331 Selecting the actual GPU

Posted by Oberon_Command on 31 May 2016 - 10:31 AM

I recently had a similar problem and the problem turned out to be that my back buffer size didn't match my client rectangle size, resulting in my game drawing on my Intel card but not my Nvidia card.

...I looked at the initialization code and noticed that I'm deriving the back buffer width and height from a configuration file, whereas the tutorial is computing it directly from the window's client rectangle. Changing my code to use the client rectangle bounds for the back buffer got things rendering again! I also noticed that in windowed mode, the window's client rect appeared slightly smaller than it did when I ran the program on 8.1 - as though the window borders take up more room and infringe on some of the client rectangle where they didn't before. So maybe the OS has changed the way window sizes are calculated? Strange that this would only manifest when using my dedicated card, though.
 
So: moral of the story, ensure that your back buffer size matches that of your client rect!
 
...My best guess (without being much of a graphics programmer) for what must have been happening was that the back buffer was created successfully, but with a 0 size, causing all my initialization and draw calls to succeed without actually doing anything meaningful.




#5293958 Do you usually prefix your classes with the letter 'C' or something e...

Posted by Oberon_Command on 28 May 2016 - 01:28 PM

Actually, m_ for members and g_ for globals helps quite a bit while reading a lot of unknown code.


The problem is that this kind of convention is brittle. It encodes information about scope into the variable name, but if you refactor to change scope the encoding is wrong and the variable must be renamed.  Forget or neglect to rename the variable and now you've got misleading information.


Any kind of extra encoded information in a variable name can be omitted or out of date by mistake; that holds regardless of convention. I don't feel that's a strong enough argument against the practice. I would argue that if the scope of a variable has changed, then its semantics have changed enough to warrant a rename.
 

A far more robust convention is to require the use of this-> for members and to require full namespace naming for globals. The compiler can then help you by catching incorrect usage.


I didn't know you could ask the compiler to flag members accessed without an explicit this-> and full namespace qualification of symbols within the current namespace. How does one do so? Without that compiler enforcement, using this-> and full namespace qualification are just more conventions...


#5293881 Do you usually prefix your classes with the letter 'C' or something e...

Posted by Oberon_Command on 27 May 2016 - 05:05 PM

At this point, the only reason I'd entertain prefixing a class name with "C" is if I'm mixing structs and classes in my code and I wanted to be able to forward declare the identifier correctly without going back to look at its declaration. In a codebase sufficiently large that hitting "Go to Definition" can take longer than a minute, this can actually be quite useful, if perhaps of dubious value in the general scheme of things. For small codebases, it's basically not a problem.






PARTNERS