Jump to content

  • Log In with Google      Sign In   
  • Create Account

Pink Horror

Member Since 02 Jul 2013
Offline Last Active Aug 14 2016 02:31 PM

#5301438 Finding that balance between optimization and legibility.

Posted by on 19 July 2016 - 07:17 PM


Except when the calculations actually outweight the cost of a mispredicted branch... right? I'm not sure on the details, but shouldn't this misprediction cost be something like ~100 cycles on modern desktop CPUs? So if you can skip calculations that take significantly longer than that, a branch is the better choice.


Also on desktop, branches that are easy to predict have very little cost. Like something that checks for an memory allocation error that when thrown will terminate the program, the branch will always be false anyways so the only cost should be the branching operation itself. Thats different on consoles where there is no branch prediction (I don't think the current generation added it, did they?), but I didn't program on consoles myself so far so I can't say much about it.


They did add branch prediction.

#5300089 Finding that balance between optimization and legibility.

Posted by on 11 July 2016 - 12:20 AM

For me personally (and in my own subjectivity), I've found working within the confines of the C++ and OOP in general to be quite problematic.

You're not transcending the boundaries of C++ and OOP. You're just achieving your goal of caching these numbers with the smallest, easiest edit possible. There's no balance here. There's no actual concern for legibility that I can see.

You're modifying your code in the same way practically every modification is made to so-called OOP C++ programs out there - in whatever way lets the programmer move on to the next task and keep collecting paychecks. Please do not act like this is something special. You are not challenging conventional thinking. You are demonstrating it.

#5299915 Finding that balance between optimization and legibility.

Posted by on 09 July 2016 - 05:19 PM

After crunching some numbers, I calculated that my cache hit was approximately 70%, so I'm thinking about keeping this example in my code for now (if not for the performance gain, then at the very least as a reminder).  


I know some (most) of you are thinking "...and? is that it?", and I get it, this is a very trivial example (some may even argue that the gains are not non-existent), but I feel like it serves as one example (good or bad) of how to code with a particular mindset, expressing awareness of what is exactly is going on in your code, not always keeping a back and white approach to what you are doing, rather be creative and look for the "good enough" approach to problem solving. I also understand that veteran programmers are already doing this on a much greater scale than this, and with greater intuition than I'm exhibiting. Perhaps this example could serve well for beginners, either way I would like to hear what y'all have to say.  

First, how much faster did your program get because of this? That's how you measure performance gain, not cache hits.

Second, no, not many veteran programmers I know appreciate functions that look like they should be pure functions, and unexpectedly read and write from static variables. These "creative" solutions are very annoying when you finally figure out what's causing the rare animation bug in a multi-threaded application. I hope no beginners copy this approach. If you want to make an optimization, hacks like this should be the last resort, ideally only made on a "release" version of your game, not on code you would continue to use in future products. You should be willing to refactor your code and actually change where the function calls are made, if the performance gain is meaningful.

#5297062 Microsoft Checked C

Posted by on 17 June 2016 - 07:54 PM


It also most definitely does not include anything even close to weak_ptr.

Are you sure? When reading it through, it looked like ptr<T> was designed to NULL out when the original data was invalid. That is the functionality from std::weak_ptr<T> that would be very nice.

No. This doesn't solve anywhere near enough real problems compared to just using modern C++.

C++ can't solve this issue because it itself is based upon potentially dangerous C libraries. As a library consumer, C++ (even Java and C#) seem better than C but remembering that underneath all their hoods, the same dangers can (and almost certainly do) still lurk, it removes all the fun ;). Plus these languages end up running more C than a C program due to their additional layers written in C so they are still not ideal.

Checked C aims to remove these issues at a much lower level than possible by just bolting on another random language.


The paper says it is about bounds-checking. a weak_ptr has nothing to do with bounds checking. The introduction is entirely about bounds-checking. It mentions problems such as using already-deleted memory are beyond the scope of Checked C.

C++ can at least partially solve the issue, because you can use templates to create the checked pointer classes. That's what the team who made this did as a prototype.

Just building with Checked C instead of C gets you nothing. You have to use the new types. Converting one of those potentially dangerous libraries to Checked C means putting in the correct changes to use bounds-checking everywhere they would belong, and making no mistakes or oversights while doing so. As long as you're rewriting chunks of the library, why not rewrite them in C++? What's the difference? How does the library go from potentially dangerous to knowing it's safe? How do you know you did the conversion correctly? How do you know the library isn't dangerous because of something that wasn't covered, like memory allocation?

If, for some reason, you have a code base that's in C, and you're willing to rewrite every part of it that uses pointers, and compiling it in C++ scares you and/or you're not willing to create the helper templates yourself, but compiling it in a new version of C from Microsoft is something you're willing to do, and you're having trouble with buffer overflows, and compile-time checks will help or run-time crashing is ok, than sure, Checked C might solve a problem for you.

#5296040 Need some advice or direction on a Mod friendly data structure.

Posted by on 10 June 2016 - 08:29 PM

Large databases with around 40TB of data presently.


You mention a millisecond.


Kept in local memory lookup, that is on the order of tens of nanoseconds.


Use the nanosecond-speed one when possible.

So, you're saying that Tangletail's game's DB performance will be similar to a 40TB database, and that one frame of a typical  video game happens in tens of nanoseconds?

#5295894 Need some advice or direction on a Mod friendly data structure.

Posted by on 09 June 2016 - 07:54 PM

Big relational databases work well for persistence, but realize that queries are time consuming. Even fast queries to an RDBMS take longer than most video game frames. If you're storing a lot of data and reading it as part of loading a character or map or level it can work, but they are a poor choice for this type of data.

I don't know what database you're using, but on the servers I typically work with, the complete round-trip time of sending a simple, plain-text SQL query over the network to another server, processing it, and getting the result back often takes less than one millisecond. I'm sure a game could do it even faster with a local, in-memory database. And actually, I know that's true, because I've also worked on a game that did that.

#5295566 use ID or Pointers

Posted by on 07 June 2016 - 08:37 PM


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

You can add integer ID's (and void* ID's!) to the C++ type system like this, in order to maintain type safety:
struct PrimitiveBase {};
template<class T, class Name> struct PrimitiveType : PrimitiveBase
	typedef T Type;
	PrimitiveType() : value() {}
	explicit PrimitiveType(T v) : value(v) {}
	operator const T&() const { return value; }
	operator       T&()       { return value; }
	T value;

#define MAKE_PRIMITIVE_U64(name)					struct tag_##name; typedef PrimitiveType<u64,tag_##name> name;
#define MAKE_PRIMITIVE_U32(name)					struct tag_##name; typedef PrimitiveType<u32,tag_##name> name;
#define MAKE_PRIMITIVE_U16(name)					struct tag_##name; typedef PrimitiveType<u16,tag_##name> name;
#define MAKE_PRIMITIVE_S16(name)					struct tag_##name; typedef PrimitiveType<s16,tag_##name> name;
#define MAKE_PRIMITIVE_U8(name)						struct tag_##name; typedef PrimitiveType<u8,tag_##name> name;
#define MAKE_PRIMITIVE_S8(name)						struct tag_##name; typedef PrimitiveType<s8,tag_##name> name;
#define MAKE_PRIMITIVE_PTR(name)					struct tag_##name; typedef tag_##name* name;
class Foo
  MyObjectId Create();
  void Release( MyObjectId );

What does PrimitiveBase do for you in this case?

#5294384 responsiveness of main game loop designs

Posted by on 31 May 2016 - 06:46 PM

>> I'm pretty sure he was joking.... 


see, things are so whacked in game development i couldn't even tell!   i've seen some really crazy and stupid sh*t come down the pike over the years.  i used to think its was only regular software development that was full of idiots.  time has proven otherwise.

So I'm an idiot, eh? Oh well, I don't really suppose I could prove otherwise.


i later realized what hodgeman meant. they poll at 5 hz and update for 200ms, so the player still gets a fair share timeslice. physics runs at faster speeds, similar to stepped movement for projectiles, for greater accuracy, but the overall timeslice length is the same (i assume).


He's saying HUMANS act at 5 Hz. He's not suggesting that means a game should poll input devices at 5 Hz.

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

Posted by on 30 May 2016 - 01:04 PM


Sure sure... it's just worthless information encoded in to a name which a human is reading... and just wait until you need a 'ThingClassClass'... or when you decide it is no longer a class.. or something becomes a class...

Or a type for a classification of a group of students; a ClassClassClass? :lol:


That does sound like it might be a little ambiguous. Maybe the naming should be more like:







I make variable names like this for real when I have to make something as a workaround:

std::string copyBecauseFuncIsntConstCorrect = str;

#5294205 How to set a namespace properly in this case?

Posted by on 30 May 2016 - 12:52 PM


I don't want to create a library yet since my code is still changing, but I do plan on doing that once it settles. I just wanted to know how to reference the base code. It's ok I'm looking it up right now though. Thank you for pointing me in the right direction.


A static library doesn't require having anything close to a settled interface to it. It's just a collection of compiled code bundled up into a file. If you're working in Visual Studio, you barely even notice it is separate.

Even when just starting out, it can be useful to keep the majority of your code in a library. That allows it to be linked against the main executable and any other secondary executables, such as unit tests, easily.

Your general problem is that you want to share one file with the WinMain stuff among several other projects you're working on, right?

I don't really think there's going to be a way to do this - to have one main file that links in different other files depending on what you're in the mood to do - that feels clean. It's going to be a little hacky one way or another. So here's one really hacky idea:

In Visual Studio you can have multiple projects under one solution. There's nothing stopping multiple projects from sharing the same files. So, you give each game its own project. You should make sure each project puts its build artifacts in different places using project properties. Then, you still have to choose which code gets used by the main file. You've mentioned a "using namespace" line. That should work. Just make it "using namespace GAME_NAMESPACE". In the properties for each project, define the GAME_NAMESPACE macro to be the correct namespace for that project.

Now, I must point out, it's not really ideal to have the same files built multiple times for different projects. That's where the static libraries come in. If you have some code shared by all your games, that can go into a library project and be built once. Then it doesn't have to be rebuilt just because you switch. This can save you some time if you change some code in the library, and you want to make sure all of your games build at once. Also, if there's a compile error in a source file that is shared between projects, it'll be repeated in every project you build. That's just annoying. Libraries are easy enough to make to be worth it just to avoid that nonsense.

I should also point out that you don't want to get carried away with this. Source code included in multiple projects, compiling with different macros in each one, can quickly become a confusing mess. Visual Studio doesn't know what to do with it when you browse the file. If you're lucky, Intellisense will at least be based off just one project, not a mix. It's much more annoying than just multiple compile errors. I worked for a company that did something like this. That project was a buggy disaster.

It's probably a better idea to break down your main file into shareable functions as much as possible, and then copy-and-paste the rest. It shouldn't be a file that is revisited much. If you do find yourself making the same edit to several of these main files in different projects, use that as a opportunity to extract more shared code.

#5294201 Recent Graduate Looking For Advice

Posted by on 30 May 2016 - 12:28 PM

Have you tried searching for game programming jobs? Do you know any studios where you want to work?

I could just be old-fashioned and bad at networking, but I thought business cards are for people who have a job already. Maybe I could have done better, but I've managed to find work without ever making my own business cards, writing a blog, going to a career fair, or participating in any game nights/jams. I did make a portfolio when I first started out. It was really, really bad.

I looked at your web site. There's one obvious thing missing: programming. You want a game programming job, right? You mention a little about Unity programming, and there may be more buried in an actual article somewhere, but on the surface, you're presenting yourself as a game designer and artist. It's good to be enthusiastic about games and design as a programmer, but it's better to demonstrate that you actually want to do some programming, and that you know how to program.

#5293966 responsiveness of main game loop designs

Posted by on 28 May 2016 - 02:51 PM

just cause you can only draw the screen once every 8 games turns doesn't mean you should let the computer move every turn and only let the user move every 8 game turns.

There should also get to be one human player for every core involved, or else the computer is ganging up on the player.

#5293137 Wrapper Function for lua_register?

Posted by on 23 May 2016 - 07:04 PM

Lua is written in C and thus cannot interact interact with C++ (there is no well-defined C++ ABI and as such 'calling a member function' is an unsolvable problem because different C++ compilers have very different idea what exactly that means and how to do that).

Lua is written to be capable of building in C or C++, and it is distributed as source code, so it doesn't need a well-defined ABI to interact with other C++ code. You can build it to match however you're building the rest of your code.

#5292932 Confused About Frames Per Second

Posted by on 22 May 2016 - 03:44 PM

I am confused however because it typically ends up being > 1000 fps. If it drops below 400, I start to notice a lag. If it were to run at 60 fps it would be cripplingly slow. But 60 fps is what most games run at, isn't it? That is my understanding anyway. Why are the numbers I'm seeing not matching up with my understanding? Is this method incorrect?

It's your own code. You should be able to describe what is happening better than "lag". You should be able to see in your code what is happening.

I didn't see an answer to this question: (Please excuse me if I missed it.)


1.  I assume your objects all are moving based on the deltaTime?!  If not, you will need to make that change because if not, things will move at different speeds on different computers.

To be clear, where in your code do you determine how far something should move in one frame? Does the time factor into it? You're almost certainly doing it wrong, if frame rate breaks your game in any way other than how it looks.

#5292550 Introducing Stanza: A New Optionally-Typed General Purpose Programming Langua...

Posted by on 19 May 2016 - 06:50 PM

That tab thing gives me an idea. If I ever make a language, you'll be forced to have whitespace around any binary operators. No more "a+b" in my language. The inherent productivity will be huge.