Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 12 Oct 2004
Offline Last Active Today, 12:39 PM

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

Posted by Mussi on 19 June 2016 - 01:21 PM

Your examples aren't really procedural vs OOP. Also your first example does dynamic memory allocation while your second doesn't and honestly looks weird to me. It's hard to say something sensible about the pros and cons with short snippets of code. Here's Brian Will's channel where he rewrites reasonably sized programs from OOP to a procedural style. I'm not aware of anyone who does the opposite so it's one sided, but you can find some takeaways in there.


I'm actually running an experiment myself where I take on a more C style approach to programming and I have to say I'm very much liking it so far. I made a journal entry about it a while ago. One of the biggest advantages that I've personally noticed is that procedural code is much easier to read, but I'll get back on that once I'm further ahead in my journey.

#5291097 A Brain Dump of What I Worked on for Uncharted 4

Posted by Mussi on 11 May 2016 - 05:05 AM

Lovely read, thanks for sharing! :)

#5288784 Returning by value is inevitable?

Posted by Mussi on 26 April 2016 - 12:08 PM

Anyone care to explain what is wrong with the static variable solution? I've used this for years and always thought it was a convenient and fast solution.


It's not faster nor more convenient than RVO. Also, it breaks on multi-threading.

#5288484 Noob pointer question

Posted by Mussi on 24 April 2016 - 01:07 PM

There are some things you will have to lookup and take your time to get a good understanding of. I'll try to give a short version of that in this post, but it's by no means complete, but I hope it's enough to send you off in the right direction.


Using new and delete in C++ are ways of allocating and deallocating memory. It's true that new returns a pointer and that delete takes a pointer as input, but there is no such thing as deleting a pointer.


What new does is basically request some memory (the size of the given type) and returns something that allows you to access that part of memory, a pointer. A pointer is nothing more than some value indicating a location in memory. If you view your memory as a giant array of bytes, a pointer would just be an index. When this memory is allocated, it'll stay that way until you instruct the computer to deallocate it. Unlike JavaScript, you have to manually manage this memory. You can deallocate memory by calling delete and passing it the pointer you got from new.


So why doesn't it work in your second case? Well there are two types of memory allocation, one is for static allocations and the other for dynamic allocations. The stack is used for static allocation and the heap is for used for dynamic allocations. The stack is basically some memory allocated beforehand, which requires no work from your side, that's used for things like local variables and function arguments. It's called the stack because it's literally how it works. Things are put on top in some order and in then they're taken off in the reverse order. In code that means that at the beginning of a scope (e.g. a function) the necessary space is reserved, and at the end of the scope (e.g. exiting a function) that reservation is lifted. Everything about this is automatic, but the stack has limited size and one other limitation; what if you want to retain the memory outside of the scope? This can't be managed automatically by the stack, it only knows how to put stuff on and then take it off again, it wouldn't be able to know when that part of memory will be free for use again. This is where heap memory comes in, it's memory that you can manually manage and is practically unlimited in size. This manual management is done with new and delete.


In your second example, you are trying to delete memory from the stack, but delete is meant for heap allocations.

#5285433 If statements are all you need

Posted by Mussi on 06 April 2016 - 09:27 AM

Before you open the link, the file is over a 100K lines!



I'm actually amazed at how he turned this into functional software, that's dedication right there.

#5282223 (split thread) c-style casts

Posted by Mussi on 20 March 2016 - 05:51 PM

Const allows optimization in some handful of cases, too.


I've only recently found out that this is not really the case, e.g. const methods apparently have no utility to the optimizer. See this talk from Chandler Carruth who's the technical lead of Google's internal C++ team and also leads Google's LLVM team:




For those of you who can't watch the video:

  • There isn't a compiler that does aggressive optimization based on const, as there isn't a whole lot that can be done
  • There are two cases that can be optimized effectively, but it's very hard to optimize on and the benefits are not what you would expect
  • Const methods have no utility to the optimizer
  • Const parameters have no utility to the optimizer as they can be const cast away

#5278435 How do I make a good open world? (not engine specific)

Posted by Mussi on 27 February 2016 - 07:18 AM

Picking the brains of landscape architects seems to very helpful, this was done for The Witness. Luis Antonio, one of the artists for The Witness has done a GDC talk and has an art dump where he talks about their approaches to creating the world which you might be interested in.

#5275968 Pointers: "type* var" versus "type *var"

Posted by Mussi on 16 February 2016 - 10:28 AM

Personally I use type* var, because I feel like it's part of the type and I find it aesthetically more pleasing, but one could argue it's more clear and more consistent to write it next to the variable name because:

int* a, b;

Here a is a pointer, but b is not.


Put next to the variable name makes more sense here:

int *a, b;

This makes it clearer that a is a pointer and b is not and it's also more consistent in case b were to be a pointer.

#5273569 Unity vs. a more "lean" game engine

Posted by Mussi on 31 January 2016 - 08:11 PM

I do most of my hobby game dev in C++, ranging from writing low level engine stuff to using existing engines. The first time I started up Unity I was like dude...? Where the hell is my main? Where do I start typing!? After a short while I got the hang of it and now it's my go to game engine when I need to whip out a game in a few days for a competition or something similar. It's nice for things I don't what to think about much, but I'm also a stickler for control so I only use it for small time stuff.


I wouldn't worry too much about your first impression. There's an easy way for you too find out: just make a simple game in Unity, finish it and then look back and reflect. It doesn't have to take long, you could probably do it in a weekend.

#5273510 Advice Wanted - Bad luck or just me?

Posted by Mussi on 31 January 2016 - 01:05 PM

Employers aren't stupid - they can easily see this transparent ploy, and aren't impressed by it.

According to your statement you should neglect them?

No that's not what Tom Said. What's an employer supposed to think? *We put up this list of requirements and this person has repeated those requirements in his application letter...Gary, I have a strong feeling about this one!*. Frankly, I'd feel insulted. Respect the employer's intellect and write things that will allow him/her to conclude that you do or may meet their requirements.

#5270573 Criticism of C++

Posted by Mussi on 11 January 2016 - 01:50 PM


but this is criticized as being ugly, having hard to read compiler errors and increasing compile times

Which may have been true at the time he made that criticism, but certainly isn't at this point.


Largely since Clang hit the mainstream, all of the major compilers have made massive strides in compilation speed and template error reporting. I don't think I've ever seen an error stemming from misusing std::unique_ptr that didn't immediately identify the root cause.


I use std::unique_ptr all the time, but I honestly have no idea how much it impacts compile times (but very interested in knowing), do you have some numbers at hand that could serve as some sort of indication?




... except you don't.


 Most of the times you don't, that's correct. That's not what he was arguing though.




From what I gather he's saying that it's a generalized solution and that there should be more specific solutions for handling memory as it's the most commonly used resource.


I couldn't disagree more with that line of argument. A very common weakness of GC'd languages is a lack of robust facilities for managing resources other than memory. In my opinion, RAII is the gold standard for resources management. 



I wouldn't call a GC a more specific solution than RAII and that's most likely not what Jonathan Blow meant in his video as he explicitly mentions that GC based languages aren't viable alternatives for big/complex (can't recall what terminology he used) games.


This talk by Bjarne Stroustrup has some great insights into solutions specific for managing memory:

It's all based on having a static code analyser so that it can be used right away, but it would be nice to see some compiler support for this soon.

#5270409 Criticism of C++

Posted by Mussi on 10 January 2016 - 10:26 AM

The biggest point in this video seems to be about how RAII is bad, but the only real point he's made against it is how it's "boring". The rubber has to hit the road somewhere as far as resource cleanup is concerned, and I'd rather it be done in a special cleanup method than anywhere else. Having that method called automatically is really nice, which is why you should make that method the destructor (hence, RAII). He also claims that RAII exists because of exceptions, but that's kind of a moot point seeing as many C++ programmers heavily make use of RAII while avoiding exceptions completely.


From what I gather he's saying that it's a generalized solution and that there should be more specific solutions for handling memory as it's the most commonly used resource. The example he gives is that whenever you have a pointer in your class you have to write a constructor, copy constructor and destructor, and maybe add in some move structors. One of the C++ solutions to avoid this is unique_ptr, but this is criticized as being ugly, having hard to read compiler errors and increasing compile times. He argues it should be built into the language.


He has a lot more videos and an actual compiler now, but I'm not sure if he mentions how he solves all other issues that arise in any of those. His criticism does resonate with me though. Personally I think "boring" is a pretty big issue, because it's a major player in productivity. It's one of those things that prevents you from getting into the flow and becoming insanely productive wondering where time has gone.

#5268702 Random Circles in a Circle

Posted by Mussi on 01 January 2016 - 06:56 AM

It's not clear to me what you're trying to do, could you elaborate on what problem you're trying to solve?

#5267034 Creating own 2D game engine from scratch - howto

Posted by Mussi on 19 December 2015 - 09:53 AM

If you really want to make a 2d game engine from scratch you should check out handmadehero.org. Sorry can't link on mobile.

#5267018 What about 3d development can be simplified to make it more practical?

Posted by Mussi on 19 December 2015 - 05:19 AM

Other things you can do is making your game less content heavy through smart reuse (simple colors and the likes) or by designing you game around it, e.g. by making it a multiplayer game.