Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 28 Feb 2011
Offline Last Active Yesterday, 09:13 PM

#5243139 undefined symbol: curl_easy_setopt

Posted by Bacterius on 28 July 2015 - 04:58 AM

When linking, object files must come before their dependencies (because the linker resolves symbols from left to right on the command-line). Hence the correct order is your object files followed by libcurl followed by gnutls (probably) because your code needs symbols from libcurl which itself needs symbols from gnutls.

#5242533 The amount and structure of exception handling in production game code

Posted by Bacterius on 24 July 2015 - 07:20 PM

Basically, yes, I could ask the hard drive "does this file exist", but it's not going to prevent you from failing to open a file because they happened to disconnect the storage unit between your query and the open command.

Asking the filesystem if a file exists and then opening it afterwards is a logic error (time of check to time of use) although it's usually acceptable to treat your own files as a private resource. And, sure, you could disconnect the hard drive while the program is reading from the now open file, but then it wouldn't be a "file not found" error but rather an "device not found" error or similar on any half-assed system, that more accurately describes the underlying fault.


It's certainly important to handle all common cases of failures, and ideally take appropriate action in each case. On the other hand, I wouldn't worry too much about trying to handle everything; being truly robust (against every failure mode) typically involves copying large amounts of data because any destructive operation may need to be rolled back at any time in the eventuality of an error to preserve your program's state if you want to have any chance of recovering from the error. Furthermore this copying needs to be done speculatively regardless of whether an error actually occurred. Most software doesn't need or want to (or even can) pay that price; high-performance software like games certainly do not.


In any case, most everyday software crashes are due to programmer error (which will generally not result in an exception but instead in an inconsistent program state) and not environmental problems like an I/O error. And when it is, it's often pretty obvious to the user (hard drive failure, network down, ...) . So don't obsess over exception handling, you're better off spending your time testing your code exhaustively and making sure it works properly!

#5242373 Thoughts about me action system theory.

Posted by Bacterius on 24 July 2015 - 06:07 AM

Have a look at https://en.wikipedia.org/wiki/Priority_queue

#5240212 How can L-system detect intersections between two lines

Posted by Bacterius on 14 July 2015 - 04:06 AM

I like that neither of you noticed kitman20022002 is the OP tongue.png

#5240114 Compiling libnoise on Linux x64?

Posted by Bacterius on 13 July 2015 - 01:33 PM

The command is missing the --shared flag to have it create a shared library instead of an executable.

#5240015 Problems with vsync on Linux

Posted by Bacterius on 12 July 2015 - 11:43 PM

3D acceleration is the one thing that VM's actually don't do very well, so you'd do well do run your OpenGL experiments on actual hardware rather than a virtual machine. It will save you time and frustration in the long run.

#5239137 C++ most vexing parse

Posted by Bacterius on 09 July 2015 - 12:12 AM

C++ has lots of silly things in it. But there's not a whole lot of incentive to change that specific parsing peculiarity because it can be easily worked around by using extra pairs of parentheses to force the compiler into getting the parsing right, or using the new C++11 initialization features (which use curly brackets instead, sidestepping the issue). It looks odd but it's not that big of an issue in the real world; yes, people go WTF for the first time, but then read up on it and just move on.


By the way, declaring functions inside other functions is also uncommon in C. There's really not a whole lot of uses for it, except maybe for ultra-pedantic coders who insist on functions being declared only when used. There are uses for declaring (and defining) temporary, localized data types, like enums or structs, at function scope, which can come in handy sometimes, but functions... no, not really.

#5238548 Instancing question

Posted by Bacterius on 06 July 2015 - 12:53 AM

In your shader you should be able to access a per-instance unique index that you can use to select the appropriate transformation matrix to apply. For DX11 for instance (pun intended) it's SV_InstanceID. Dunno about DX9.

#5236507 Load Compiled Shaders

Posted by Bacterius on 24 June 2015 - 12:24 AM

When using reflection isn't it also dependent upon having the debug layer installed?


Shader reflection is available in all DirectX runtimes (it's not a debugging tool).

#5236270 How to get people to test your game engine?

Posted by Bacterius on 22 June 2015 - 11:56 PM

You're supposed to show that your engine stands out among the many alternatives by eating your own dog food and making one or more complete games using your engine and using them to highlight your engine's strengths and also weaknesses (or lack thereof). Just saying it's "simplified" or it "has a small learning curve" doesn't really cut it when someone is trying to pick an engine to work with, he'll see all those awesome games made in Unity or Unreal and that's what's going to drive his decision. Your engine may be awesome but unless you get people hooked on to it by marketing it you won't get many users.

#5235031 My .OBJ Model Loader doesn't seem to output the right scanned data of cub...

Posted by Bacterius on 16 June 2015 - 01:12 AM

You’ve done this 2 times now.  You keep declaring your array 1 shorter than it has to be.
float value[3];
In both sets of code you posted you overflowed the buffer when you used it in ::sscanf().

L. Spiro





For the record, clang by default emits a warning, among others, that highlights the out of bounds access (gcc, obviously, does not):

test.cpp:24:73: warning: array index 2 is past the end of the array (which contains 2 elements) [-Warray-bounds]
  ...sscanf(objfiletext.c_str(), "%f %f %f", value[0], value[1], value[2]);
                                                                 ^     ~

#5234595 Reading a binary file

Posted by Bacterius on 13 June 2015 - 07:16 AM

char* whdBuffer = new char(sizeof(USHORT)*3);

What's this? I think it allocates a single char and puts the initial value 2 * 3 = 6 inside it, which is likely not what you want. Did you mean:

char* whdBuffer = new char[sizeof(USHORT)*3];

At this point you are probably corrupting the stack by asking ifstream to write 6 bytes into an array that contains only space for one byte, so fix that and try again.


Secondly, reinterpreting a char pointer as a USHORT (unsigned short) pointer is in general illegal and undefined behaviour because USHORT has stricter alignment requirements than char (doing the opposite is valid, though). If you need an array of USHORT, ask for an array of USHORT. It will work fine in this case because the "new" operator is guaranteed to return "sufficiently aligned" memory for all primitive types, but this may not hold in general (especially if you reinterpret a pointer into the middle of an array) and is a bad habit to get into, so just avoid reinterpreting pointers like that. Many C++ programmers are actually not aware of alignment constraints because the x86 processor in your desktop fixes up the unaligned accesses in hardware at (some) performance cost, however code that just freely reinterprets pointers like there's no tomorrow is liable to fail hard on less friendly processors like some ARM (mobile) processors wink.png

#5233687 should i release my code?

Posted by Bacterius on 08 June 2015 - 07:30 PM

Well, realistically if you just drop it in a Github repository and forget about it you won't really get any visitors to it. You'll need to at least tell people that it exists, via e.g. social media or a GDNet journal entry or whatever. Beyond that, you don't have to maintain it if you don't want to, but if you are not interested in maintaining it, it's unlikely someone will just step up from the shadows to contribute and provide feedback, especially if it hasn't been "cleaned up" and if there's nobody else interested in said contributions.

#5233140 Why don't game engines run in kernel mode?

Posted by Bacterius on 06 June 2015 - 08:48 AM

No. Ignoring for a moment that the virtual to physical address space mapping is done in hardware through the MMU, which has a built-in cache, so the address space translation is pretty much free, the main bottleneck in games these days is either CPU/memory/IO (which kernel mode can't really help much with) or graphics API overhead (which kernel mode would make worse, since there is no usable graphics API in kernel mode, so you'd have to basically reimplement a D3D or OpenGL runtime in kernel mode for every version of every display driver you intend to support, which is not realistic). Add to that the fact that switching from user to kernel mode is not free, and that kernel mode development is harder (and more difficult for cross-platform development), that all code has bugs and that in kernel mode any bug has the potential to, say, silently corrupt your physical memory, and that since Vista any Windows drivers you use must be signed or just won't be loaded, and that the driver would be sitting there idling for no reason even when the game is not running, that you'd be unable to run the game on a system you don't have administrative privileges on... just, no. User mode exists for a reason, and there really isn't much performance to be gained in kernel mode anyway compared to the work you'd need to put in to make it work to begin with.

#5233099 Sacrificing time: Elegance vs crude coding

Posted by Bacterius on 06 June 2015 - 03:00 AM

Just so you know, Glass Knife is exaggerating (using a hyperbole is common when trying to make a point, especially among us technical bunch). Yes, trying to be elegant or robust *can* lead to inefficient or over-engineered code. Many novice or even advanced programmers will often go overboard, making their code unnecessarily hard to use and maintain because they fell in love with some design pattern or algorithm. That does not mean, of course, that code written in the plainest way possible, using only three keywords and avoid anything remotely nontrivial, is going to be any better. In fact, I find that people who write this kind of code often fail to make crucial connections between different parts of their code and end up with unnecessarily complex architectures, because they have forgotten how to think abstractly in their quest to "keep it simple".


You should strive for elegant, modular and reliable code, balancing that with the time and money available for it to be written. Do not tolerate mediocrity, but do know that there may not be time to study a problem or piece of code in detail to better understand it and make it simpler, so you have to compromise sometimes. Never stop learning new ideas, approaches to a problem you may not have considered, keep challenging yourself when coding, and you'll be on your way to becoming a good programmer. Finally, I would take anything a programmer says with a kilogram of salt.


Often the *real* breakthroughs in elegant code come after thinking hard about how to rework a complicated, ugly piece of code into something much shorter, more expressive, and easier to understand and maintain to boot. That is an example of clever code. Creating three different classes that ultimately do very much the same thing on different types of objects, just perhaps not immediately visible to the untrained eye ("because there's obviously no better way"), on the other hand, is not an example of clever code, it's just an example of a programmer's inability to reflect on the code he writes and finding/exploiting patterns that arise naturally in the problem he is trying to solve. Nevertheless, the time taken to arrive to the better solution may in the long run outweigh the time saved by just sticking to the basic, uninsightful approach, so it's as always a tradeoff.


TL;DR: programming is an art, but if you do programming for a living your primary job is to produce value, not write masterpieces