Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 12 Oct 2004
Offline Last Active Yesterday, 07:00 PM

#5316078 Preventing unintentional pvp (AOE , missiles etc.)

Posted by on 21 October 2016 - 08:45 AM

Instead of holding down the key maybe just make it toggle between modes? Could also not do anything about it. In World of Warcraft you either decide to use AoE and not care, the other player could retaliate or move away from your target, or you decide to not use (very harmful) AoE spells. I think it works out reasonably well, but that might be different for your game.

#5303885 Best Way To Comment Code Without Cluttering

Posted by on 03 August 2016 - 06:46 PM

I almost never comment on the "how" of things, but I occasionally comment on the "why" of things. Most of the times this means a single line of code where needed, about 2% of my lines consist of comments. If you ever get back to your code after a while and you don't remember a thing, the code will still tell you how it works eventually, but it might not always make clear why you chose to do some thing in some particular way.

#5303777 Gui Libraries?

Posted by on 03 August 2016 - 06:23 AM

Why is that so? What is the limiting factor for using it in a game?

It's mostly designed to easily create tools/debug utilities where appearance doesn't matter. It's possible to change colors, fonts, sizes and the likes, but there's only so much you can do with that. Most in game UIs have a lot more flare and animation to them, so you'll want to handle these differently instead of forcing them to work within the confines of some library.

#5303771 Gui Libraries?

Posted by on 03 August 2016 - 05:44 AM

For building tools and debug utilities I'd most definitely recommend Dear ImGui. For in-game menus and stuff you might want to do some custom rendering/handling, but that's usually not all that complex.

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

Posted by 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 on 11 May 2016 - 05:05 AM

Lovely read, thanks for sharing! :)

#5288784 Returning by value is inevitable?

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