Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 18 Oct 2007
Offline Last Active Jan 05 2016 03:34 AM

Posts I've Made

In Topic: Practicality of a C++ Garbage collector

02 January 2016 - 09:00 PM

Garbage collectors are usually pretty well designed to do what they do, but the problem is that they really are just overkill as a core subject. You're talking about having an entire extra layer of code between you and the machine that does nothing except try to guess how you want to use memory and when you want it released. Or even try to second guess you because you may not actually have a clue of when things should be released. I'm not saying garbage collectors are bad or not useful, it certainly is a constant that programmers make mistakes, but in a way that's the big flaw, its a construct that tries to make up for you making mistakes.


It is kind of a cost benefit thing though, coding can feel much more smooth and intuitive(and less work) in languages with more automatic features than C++. But if that's what is important to you then you should probably be coding in that language, C++ is usually used specifically because it is so bare metal and offers freedom of choice.

In Topic: Keyboard/Mouse input missing because of low FPS

02 January 2016 - 08:42 PM

Keep in mind input generally comes in two forms: events and polling.

Events are like what you get from windows messaging(the OS, or more specifically the things you drag around that the OS of the same name creates for you), you get messages posted to a queue that happily sit there until doomsday until you process them, so you can package them up and ship them off wherever to process when you need them, you don't 'lose' messages that way.

Polling is usually just checking the state of some array that is being updated for you, or calling an OS function that will actually return the state it has on the device as soon as the function call is made. Problem with polling is that it happens essentially in realtime, if someone clicks a mouse button and releases it and you poll the state at a certain speed, you might flat out miss the message(because it is a state existing between two time periods, not an actual event.)

Theoretically you could make your own events by polling constantly and packaging up the data so you don't 'miss' it but that's hacky at best and would probably need a dedicated thread, usually you'll want to set your input up to deal with the message side of things to generate your own events.

In Topic: Criticism of C++

02 January 2016 - 08:35 PM

C++ is an extremely flawed language. There are endless things to criticize about it, which is why people keep making new languages to compete with it.
But... Despite it's flaws, it's still IMHO one of the best systems programming languages available, which when combined with its legacy/momentum/inertia, it's not being seriously displaced any time soon.

In order to be the best programmer you can be, its important to really understand all the criticisms and are able to fairly take on the viewpoints of the critics, even if you don't agree with them. This includes using as many different languages and paradigms as possible and taking the time to grok their idioms.

P.S. Yes I'm a die hard C++ fanboi.

I'm not even sure a language will ever really 'replace' C++, maybe someday long off in the future when new design patterns or something are so vastly different and majorly used that it warrants changing to another language. Problem is C++ does some things right, some things 'eh' and some things just confusing. People make languages that try and fix or make more obvious some of those problems. That in itself is the issue, they fix a few things and suddenly their language takes off in an entirely different direction from C++ and then it can't do what C++ can as well as C++, thus the target crowd has no interest in switching.

Every language I've tried has a bunch of different flaws anyway, perfect is an imaginary thing. As programmers we should all know that things are usually just tradeoffs, trade memory for cpu cycles, make something run slow the first time and fast later, more code and development time to save later, etc.

As a side note a big thing people seem to brush over complaining about languages like C++ is that it isn't that simple to come up with a -better- solution, usually the proposed changes are just a different shade of the same problem or don't even help the problem really.

In Topic: C++ without pointers

02 January 2016 - 05:06 PM

I also use C# a lot, which has GC, which is a very different beast.

If anything they're rather similar, in languages like C# and Java everything is basically a pointer(or acts just like one) maybe I should say pointer with training wheels because the GC handles de-allocation of memory so you can essentially let things go out of scope on a whim. You can get similar behavior in C++ by using smart pointers, but obviously you have to take care of what you're doing.

So I'll read up on smart pointers, but honestly at this point I might as well just stick with new/delete as it is closer to malloc/free that I'm used to.

You're never going to take advantage of the features of a language by just trying to treat it like another language. That'd be like being used to drifting so when you switch to driving a bus you try to drift everywhere. Not super productive.

Smart pointers are a relatively new feature(at least in the standard library) or at least the good ones we have now are. But they're pretty simple to use, unique_ptr can be just thought of as changing the lifetime of a pointer to be just like a stack variable, as soon as it goes out of scope the memory gets freed with it. They're mainly important in C++(besides being nice to use) because C++ has a lot of corner cases with exceptions where things can be left dangling without careful planning. Placing all that load on the destructor means(in every case I can think of anyway) the memory gets freed even if everything comes crashing down.

In Topic: Issues with enemy class

27 December 2015 - 02:22 AM

I don't really python but from my layman's perspective you are making an Enemy and making baddie refer to it, then adding it to your list of baddies.

That means baddie will be set to the last enemy you made. You then check if baddie is alive before drawing all of the baddies in your list. You should actually be checking if each baddie is alive before drawing it instead of just checking the last one. For instance if you have 3 baddies if you shoot the first two, they'll always be drawn even if they die, and if you shoot the third one the entire group will appear to die.

Least that's what it looks like to me.

SIDENOTE: Usually objects in games(and enemies for that matter) should be separated logically from their visual representation. You'd be better off say, making an enemy class that has a position and dimensions, and then in your drawing code if they are all made of the same red square or whatever, you can just have one red square and draw it at the position of each baddie that is alive still. You don't need each enemy to have its own copy of a sprite.