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

#5268927 Practicality of a C++ Garbage collector

Posted by Satharis on 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.

#5268921 Criticism of C++

Posted by Satharis on 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.

#5268901 C++ without pointers

Posted by Satharis on 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.

#5268104 Issues with enemy class

Posted by Satharis on 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.

#5267959 How Does One Program A Voxel Editor?

Posted by Satharis on 25 December 2015 - 10:11 PM

I'm interested in creating something like MagicaVoxel, for the sole purpose of learning more about voxels.
I'm not sure what spatial partitioning structures are.
I also have not created a voxel renderer, or any renderer at all.
This is overwhelming o_O

Looking up octrees would give you a good idea of what spatial partitioning is, all the examples listed basically all go down to the same thing, they're a data format for dividing up logical objects in a 3d space in order to work with them more efficiently and avoid comparisons, sort of like putting information about them into big grouped bins.

A renderer is just something that takes vertices(and other data) and draws things, a voxel renderer is just a renderer that is working with voxels on the back end. If I want to draw a line of five voxels that are supposed to be a model for a game(ignoring optimization) you're basically just going to have some representation of those five cubes in memory, and use that to render 5 boxes. When you export the data you'd just be exporting the data structure that represents the boxes. You know the voxels are uniform size and shape so you don't need to keep information about each one and their position relative to each other in vertices or anything, you could just represent one spot being filled at a voxel, then a spot adjacent to it, or whatever. Basically you don't need all that fancy information like what triangles form each cube and all that stuff, since you can figure it out mathematically.

Using minecraft as an example, they implemented a model format now I believe, so you'd write code that can import and export that data, and have some kind of representation in memory, then set up your UI and rendering to let you view the placed voxels and to work with them. It isn't fundamentally different from a model editor, just less detail required.

#5267955 Advice on coding style

Posted by Satharis on 25 December 2015 - 09:21 PM

In regards to comments the most important rule to remember is that a programmer is going to be reading your comment, you should assume that they are competent with the language and not point out things that would be learned by studying the language.

If anything comments should reflect what is actually happening, if you make a couple function calls in the middle of your code because you're verifying some data before you do something with it, write a comment saying that. At the very least you're going to be writing comments to yourself, even if you work solo on a project, because at some point you're going to look at some old code of yours and have no idea what it does, or only a faint idea. Also try to make your code self documenting, you don't need to point out that m_position is the position of an object but you might need to clarify that you're pulling some data from a database connection to do something with it that may not be obvious. Some things are easier to self-document than others.

#5267471 Understanding better the 3D texture coordinate?

Posted by Satharis on 22 December 2015 - 03:54 AM

Conceptually you can think of your normal 2d texture as a sheet of paper, you have a 'corner' like the top left where we designate cartesian coordinates from, u and v to designate a position on the texture. You might know that part already.

Taking the paper analogy further a 3d texture is like a stack of papers(you can think of them floating slightly apart if that helps you visualize it easier,) each sheet of paper is a 'plane' of the 3d texture, specified by a W coordinate, so its like specifying between slices of paper vs just horizontal and vertical.

This can be used for certain rendering techniques like vstrakh mentioned, but 3d textures are arguably pretty rare, most techniques just use 2d textures and even then a 3d texture is technically just an array of 2d textures.

#5267466 Game loop sucking up CPU

Posted by Satharis on 22 December 2015 - 03:15 AM

I guess that depends in how much input you throw at it.

You would want to process a sensible amount per frame but yes you are artificially introducing lag to stop someone spamming your game loop with windows input events.

The last time I did this I processed 30 input events per game loop iteration from my queue and couldn't find any device which would fill the buffer with more events than that in one 60th of a second. Even if it did the player generally doesn't constantly spam inputs so the game would catch up in fractions of a second...

I would find it perplexing at best if a computer being faster made any sort of difference in input handling, even a really dated computer should be able to chew through all your input events in no time at all. Adding artificial delay sounds like overkill.. you could argue that in something like a multiplayer environment that would be like trying to control latency too, except latency can be up to a second or more while input handling is likely to take a millisecond or less to process.

As for sleep we(i.e. game coders) usually avoid sleep because it basically puts you at the mercy of the thread scheduler, even on separate processing threads its usually better to design them to block than to use sleep, the OS scheduler is better at handling cases like this anyway.

#5266998 Are macros like 'FORCEINLINE' worth it?

Posted by Satharis on 19 December 2015 - 12:48 AM

Macros are just another tool, used properly in situations that they make better, sure, why not?

Problem with tools like macros in coding is they usually have a lot of side effects so you should really be sure you -need- or will greatly benefit from said tool before using it.

Also the old addage comes to mind that the compiler usually knows the code much better than the programmer, so unless lots of profiling and testing has told you otherwise, it is usually rarely a good idea to override something the compiler wants to do for you.

#5266997 What is the best way to go about making a top side up tile and turn based rpg?

Posted by Satharis on 19 December 2015 - 12:40 AM

Depends if you just want a game or if you want to learn to code.

If you just want a game you should look into something like rpg maker or game maker, they're simple to use and much more biased in their design towards games of the type you're speaking of.

If you want to learn to code then it really depends on what language you want to learn..

#5245801 C Language and SDL - Getting Ready for Vulkan API

Posted by Satharis on 11 August 2015 - 01:09 PM

Anyone that wants you to know Vulkan(or any other API really) is going to want you to know C++, not C.

I don't think you're gaining as much benefit from trying to learn it as you think you are.

#5245794 Safety vs Efficiency

Posted by Satharis on 11 August 2015 - 12:43 PM

I recommend to rethink this. I do quite some interviewing these days and saying something like this in an phone screen or interview would be a dark red flag. I don't know what experience you have in professional development, but maybe don't think so much shipping, but daily development in large teams of maybe 100 people. If you crash loud and hard on every little bug because of not programming defensively I don't see such a team working effectively.

A dark red flag? That's like saying you wouldn't hire someone because they use different code style than you, you can't just ask them to follow your company's style instead? To me it just sounds more like you're taking people's style decisions personally, and refusing to hire anyone that doesn't think the same way as you. That's a big red flag to me as anyone that would want to work there. You're trying to say infinitevly that crashing is bad style, but it isn't.

There are two ends to this point, one is to avoid crashing at all costs. This introduces bugs frequently, it keeps them around longer, possibly forever, it flat out lowers the quality of the software. On the other end we have crashing all the time, it gets the most bugs fixed but scares people more because in theory it might crash at an inopportune time and embarass people or cause frustration.

To me that says a very simple thing: it depends. It depends on the environment, the type of software, and who is working on it. If I'm working on my own game by myself i'm probably more likely to just make everything explode if it fails, that helps me find bugs fast, and I lose nothing from it crashing. In a big team environment it depends on what you're making, a tool crashing is more annoying than a game crashing. A game crashing is only bad really infront of customers. There isn't a one size fits all solution here.

#5245332 Questions before I start solo on a basic 3D RTS...

Posted by Satharis on 09 August 2015 - 06:43 PM

The "game or engine" thing generally goes down to the fact that, these days in particular, you can make a game significantly faster by using an engine(like Unity) but you won't learn nearly as much about coding or the gameplay by doing that.

You're generally learning about the engine's systems and the way the engine does things rather than the low level route. If your only goal is to make a game(for fun or profit) an engine will save you months adn give you a much better product.

However if your goal is to get a job professionally and be working on the really low level stuff, it helps a lot to work at that low level, it impresses employers to show you can make a relatively complicated game using from scratch D3D or opengl or whatever.

Not to say you couldn't get a job as well by making games with engines, some employers want that(if they use that engine a lot) but you're much more likely to be stuck in game logic if you do that, it entirely depends on what your goals are.

#5234014 Engine design, global interfaces

Posted by Satharis on 10 June 2015 - 02:31 AM

What the singleton debate really comes down to is not singletons, it is global state. I would say most code theorists or people that want to figure out better practices seem to come to the conclusion that global state causes more trouble than it solves and keeping code compartmentalized has many benefits, including simpler code reuse.

If I had one big complaint about these forums that might make sense to point out in a thread like this, its that a lot of people tend to get way too passionate about the designs they have run into over the years, they get through many failures and find what are probably good design patterns, but then they stop searching. They don't keep looking for even better ones they just come here and preach thme as "this is THE WAY it must be done."

If there was a "this is the way it must be done" we'd probably all be sitting outside on rock chairs looking at a sundial to tell the time of day.

#5233995 Special question about learning (STL and STD, etc.)

Posted by Satharis on 10 June 2015 - 12:09 AM

If you are learning I would try to do a 'real' project of some kind.


Even something simple like a console program to calculate pi to a million places or something.

Er.. maybe. The entire point of making things to learn is to progressively set yourself bigger and bigger challenges. I could use a racing game as an example.

You might start racing on a simple circular track, you've never driven the car before and the controls, weight of the car and movement are foreign to you, you start in this simple track to learn these things, but after awhile you aren't going to get much better at handling your car just by driving that simple track. Moving on to more complex things a step at a time is the best way to get better at anything, coding included.

Using another racing analogy, books can help, you can learn about how the car works and read up on techniques to improve your driving, even watch other people play the game and such. But as anyone who has played a game after watching it will know, there is always a big difference between experience and study. You can watch ten different people drive one particular car on one particular track until you can recite every inch of it in your sleep, but you still won't learn the minute details of experience and feeling that come with doing it yourself.

A bit of a rant but I feel this part in particular requires a lot of emphasis, you can read an advanced graphics coding book front to back and unless you actually go and make things none of it is going to stick.

I don't think there is much point to learn STL. It's crap for game programming,

I don't know where you got that idea, I use standard library classes all the time, they're much more performant than what you or anyone you know is likely to write in any reasonable amount of time.

and if you get a job working for a company doing C++ they will probably have their own data structures.

They might, most of the time if thats the case it is because the environment(engine or whatever) came with that stuff already implemented to be a more performance intensive version for games.
The main weakness for stl classes in games is that they are very generic whereas games benefit much more from more specialized containers and algorithms.

It's also fairly complex and using it won't really teach you much as far as what's going on.

So you should avoid using helpful code because you don't understand how it works? I would postulate the opposite, that you should take advantage of useful and convenient code whenever you can and learn more about it when it strikes your fancy or when the knowledge will be useful to you. Using stl classes made me look up and learn a bit about a lot of things I had never used before.

You need to learn at a low level before you worry about high level APIs too much, basically.

You talk about jobs and such but at any job, especially as the new guy, you're not going to be making that low level stuff. They're just going to toss you into some corner of the code, lay out your clay cutting tools before you and say "make stars explode from this carrot" using more or less existing code. Yes knowing that low level stuff is helpful, in fact it makes you a much better programmer in the long run. But you shouldn't act like someone has to stop and learn how everything in the programming world works before they start writing any code. Oh and i'm not trying to downplay jobs, but in reality when you're new people don't know what they can trust you with, so they treat you like they would their potentially dumbest employee.

As a footnote, if you start writing a game and think about including that nice vector class and go "I bet I can write that better" you're already failing at game programming, quite honestly. What seperates good programmers from mediocre ones are being able to accept the fact that their skill will be required -when it is required- and you should try to avoid having to use it if possible. Don't rewrite a class just to rewrite a class, your mantra should be not to rewrite an stl class unless you have great need and benefit from doing so.