Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 28 Feb 2011
Offline Last Active Today, 05:44 AM

#5253774 Lua C API tutorial / book

Posted by on 24 September 2015 - 01:41 AM

Programming In Lua, 3rd edition. Like a quarter of the book is dedicated to the C API and the rest is not bad either.

#5253106 JavaScript Platformer Level Format

Posted by on 19 September 2015 - 05:37 PM

I don't see a problem with using this to grab the next level, one thing you could do if you don't want your game running in the background is display some kind of loading screen while the file is being retrieved, something like:


1. show a loading screen in the middle of the page or something (as a DOM element like a div or whatever)

2. send off XMLHttpRequest with an onready callback that goes parses the json and loads the level, and then hides the loading screen when it's done

3. resume running the game...


I don't think hardcoding the level in your game is a good idea. It's okay to prototype but having it on the server allows for plenty of interesting mechanics like letting users upload and share their levels, etc...

#5252293 Linux c++ debugging

Posted by on 14 September 2015 - 11:55 PM

I use Valgrind primarily. I very rarely need to break out an actual debugger, the times I did I just used gdb and it worked fine, though I could see it worthwhile to invest in both better front-ends and actually learning how to use it efficiently.

#5251881 Is there a language like Python but without the tab requirement?

Posted by on 12 September 2015 - 08:07 AM

If your most important goal is sensible syntax, you need an Algol-family language. Weird that none of them ever caught on.


I guess Pascal is not really "in" any longer these days, especially on a game development forum, but Ada and Lua are pretty popular (though not for the same reasons). Plus Lua has first-class functions and proper closures which I guess comes more from functional languages like Lisp, although the syntax is very sensible and easy to grasp.

#5251850 Is there a language like Python but without the tab requirement?

Posted by on 12 September 2015 - 04:17 AM

It runs faster too, because the CPU doesn't have to keep scrolling down.


Wouldn't it have to scroll right way more though? This is why I limit my line lengths to 80 characters, 120 is acceptable but I can definitely feel the slowdown on longer lines. They just run slower.

#5249823 Strange pinching effect with raytraced reflections

Posted by on 30 August 2015 - 11:43 PM

Your code calculates (dir - dir * dot(dir, norm)) * 2, whereas you should be calculating dir - dir * dot(dir, norm) * 2, that is:

Vector3 ReflectionDirection = newRay.direction.nor().cpy().sub(surfNorm.scl(newRay.direction.cpy().dot(surfNorm)).scl(2.0f));

Or just:

Vector3 ReflectionDirection = newRay.direction.nor().cpy().sub(surfNorm.scl(2 * newRay.direction.cpy().dot(surfNorm)));

This is incidentally the main reason why I strongly dislike the lack of (reasonable) operator overloading in languages, it makes it impossible to write such things in a sane way (and, no, separating this simple equation into three or four temporary variables is not sane either). But anyway this is where the pinching comes from.


(actually it's pinching not so much because the reflection is wrong but really because of your error the resulting reflected vector is not unit length, which wreaks havoc on the rest of the ray tracing code something fierce; so a good thing to do whenever stuff looks really weird is to look at your directions vectors and check if they are actually unit length; if they aren't, you've screwed up somewhere)

#5249675 Background color ruins Antialiasing

Posted by on 30 August 2015 - 02:56 AM

It could be that it was running your old code before you added anti-aliasing or something, dunno. If it works now then cool, looks nice by the way smile.png

#5249618 C++ | Fixed Byte Size

Posted by on 29 August 2015 - 05:23 PM

That code is illegal JohnnyCode. You cannot reinterpret m_Memo (which has no alignment constraint, being a pointer to char) to a pointer to WORD or DWORD, which have alignment constraints (2-byte and 4-byte boundary respectively). Your code will work "correctly" on x86 systems like  your desktop/laptop because the processor takes care of the unaligned access and fixes it up itself; you will obtain some kind of bus error on less generous processors like many ARM ones.


You can see the access cannot be aligned since you reinterpret both m_Memo and m_Memo + 14 as pointers to DWORDs, and clearly these addresses can't both be aligned to a 4-byte boundary. If you want this code to be portable (which, hey, you might not; if you are only interested in supporting x86 hardware then this will work fine, you'll just incur a small performance penalty each time you access these fields due to the CPU having to do extra work for unaligned access) then you can use memcpy to safely unpack the bits of m_Memo into words and dwords.


Oh, and you also don't handle endianness. Not a problem on x86 as all x86 chips are little-endian AFAIK, but could cause strange behaviour depending on where the header is coming from!

#5249539 How would I be able to do this in C++?

Posted by on 29 August 2015 - 04:43 AM

Did you remeber to #include ?


He is probably not using C++11.

#5249530 How would I be able to do this in C++?

Posted by on 29 August 2015 - 04:15 AM

A Lua "table" is just a generic associative mapping, which maps a set of keys to a set of values. In this special case it also happens to be what is known as a list or array in most programming languages. Read up on datastructures and you should find that C++ also has a notion of arrays, lists, mappings, ...

#5249122 Firing many rays at one pixel?

Posted by on 27 August 2015 - 02:21 AM

The pickRay method takes floats so I figured I could fire rays at x+0.99f and y+0.99f but it doesn't work that way.

Actually it works exactly like that (well, not 0.99f, but you want to average up rays in a neighbourhood of (x, y)). If your camera object doesn't allow you to fire rays over a continuous plane, as opposed to a discrete grid of pixels, then it's broken.

#5248487 C++ | Fixed Byte Size

Posted by on 24 August 2015 - 05:23 AM

So, the width in bits in the uint16_t type is exactly defined (16 bits, none more and none less, and no pad bits), and it is not optional at all (unless your machine doesn't have 16-bit capable registers at all). But go figure that out, the standard doesn't precisely make that easy...

I think the point that Sean was making is that a byte (as defined by the C/C++ standard) need not be 8 bits, so that while a uint16_t (if the type exists) will be exactly 16 bits long with no padding bits, it is not guaranteed that the sizeof operator applied to it will return 16/8 = 2, a fact which is liable to break large amounts of code out there (not that much existing C/C++ code would survive an architecture where a byte is not 8 bits). However, the intersection of the set of people who work on systems with CHAR_BIT not equal to 8 and the set of people who are not aware of CHAR_BIT is, I hope, very small.

Of course, note that since C/C++ mandates that CHAR_BIT is at least 8, the existence of a standards-compliant [u]int8_t implies that CHAR_BIT equals 8. So if you are going to be using that type then you are already tacitly assuming an architecture where a byte is exactly eight bits. So to cut the pedantry short it's safe to say that one may assume stdint.h exists and behaves "as expected" on the typical modern system, and one should not rely on stdint.h but instead define one's own types when working on exotic hardware like DSPs. Or just use it on "real" systems and roll your own on systems which aren't developer-friendly enough to include a few standard typedefs (like it would kill them to spend half an hour writing the thing).

#5248197 Distance 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)

#5247566 Databases: 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?

#5247461 Changing 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.