•      Sign In
• Create Account

# Bacterius

Member Since 28 Feb 2011
Offline Last Active Today, 12:56 PM

### #5248197Distance between two trajectories

Posted by on 22 August 2015 - 05:11 AM

Your integrals are just leaving out the initial integration constant at t = 0 which balances out the initial acceleration (when alpha is not zero) so that x(0) = x0. Remember that in general:

$v_x(t) = v_{x_0} + \int_{0}^t a_x(t') ~ \mathrm{d}t'$

And similarly:

$x(t) = x_0 + \int_{0}^t v_x(t') ~ \mathrm{d}t'$

You need to take into account the initial acceleration (and hence velocity) at t = 0 to get the correct results, else you'll be off.

EDIT: to be clear, that means that the correct equations are:

$v_x(t) = v_{x0} - \frac{|F|}{m\omega}\cos(\alpha + \omega t) \color{blue}{ + \frac{|F| \cos(\alpha)}{m \omega} }$

$x(t) = x_0 + v_{x0} t \color{blue}{ + \frac{|F| \cos(\alpha)}{m \omega} t } - \frac{|F|}{m\omega^2}\sin(\alpha + \omega t) \color{blue}{ + \frac{|F| \sin(\alpha)}{m \omega^2} }$

Which as you will observe cancels out to x0 when $$t = 0$$.

(please double check those integrals for sign errors, but rest assured the math works)

### #5247566Databases: Why should I use prepared statements?

Posted by on 18 August 2015 - 11:52 PM

Need I remind you that SQL injections stem from the fact that you're treating user input as SQL. "Validating" the user input the way you suggest amounts to treating it as SQL and then checking that it's not SQL. Uh, okay? Why not just, you know, not treat it as SQL but as a parameter to a query (i.e. prepared statements)? The user input still needs to be validated against the parameter's type (string, boolean, etc) and also according to your usual business rules, of course, since user input always starts off untyped as a raw string, but that's no excuse for doing not only useless but illogical and dangerous "SQL validation" on user input that should never be treated as SQL in the first place.

There is no reason to validate, it does not even make sense from a typing perspective. The user input is not just another random chunk of the query, it is a parameter that is referenced by the query. Sure, you can validate all you want, and it might eventually work (actually the typing rules are quite complex owing to SQL's odd grammar) but it's pointless because you don't need to. All you need to do is treat the user's input like a parameter and not like a part of the raw query, and that's what prepared statements do. Same result, but vastly simpler (and more logical) solution: you simply say "THIS is the query, THOSE are the parameters, and you plug them HERE, HERE and THERE" and suddenly the problem is gone. You didn't even need a validation function! (and neither does the database, by the way; databases don't magically consume SQL statements, they parse it and then do computation based on the action, parameters, conditions, etc.. involved).

This is an obvious typing problem, and the reason it's so widespread is because of the untyped, string-based nature of raw SQL, which is rather unfortunate (if convenient). Types exist for a reason, if people actually took advantage of the type system they have available to them they wouldn't need half the validation methods they are using.

So, to pertinently answer your question: why not use prepared statements?

### #5247461Changing a C++ vector list via Lua

Posted by on 18 August 2015 - 01:42 PM

If you really wanted to you could add #define capabilities to Lua by simply running the C preprocessor on your scripts before executing them (it's not hard) but I think it would be a questionable approach for what you're trying to do.

My suggestion: stop trying to come up with a DSL and just use normal Lua constructs. There's quite a bit of syntactic sugar available so you can be creative and still manage to write something nice without resorting to horrible hacks just to e.g. remove parentheses.

### #5246287Is Javascript easy if you know basic C++

Posted by on 13 August 2015 - 01:30 PM

Is Javascript easy if you know basic C++

Yes.

If the average Web programmer can use it then any quasi-sentient life form should be able to pick it up pretty quickly.

Even cats can!

### #5245053GCC auto vectorizer alignment issues

Posted by on 07 August 2015 - 11:20 PM

If you're relying on this code to be performant, and you have the resources and skills, then you really want to look at vector intrinsics (or, linking a vector routine written with... I forget the name, but its a vector-aware C-like compiler, or perhaps an assembler, depending on which of those dependencies is more comfortable).

You might be thinking of ISPC

### #5243139undefined symbol: curl_easy_setopt

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

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

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

### #5242373Thoughts about me action system theory.

Posted by on 24 July 2015 - 06:07 AM

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

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

Posted by on 14 July 2015 - 04:06 AM

I like that neither of you noticed kitman20022002 is the OP

### #5240114Compiling libnoise on Linux x64?

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

### #5240015Problems with vsync on Linux

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

### #5239137C++ most vexing parse

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

### #5238548Instancing question

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

### #5236507Load Compiled Shaders

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

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

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

PARTNERS