Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 28 Feb 2011
Offline Last Active Yesterday, 11:41 PM

#5144856 Linked List vs std::vector

Posted by on 06 April 2014 - 06:18 PM

Linked lists have applications, for instance in kernels, where it may be physically impossible to get all the list items in a nice preallocated array in memory (for instance, in interrupt handlers, where the relevant pieces of data may be strewn across arbitrarily many address spaces throughout various processes and threads). In that case a linked list or other indirect data structure may be the only option available. But if you have the ability to modify your data layout so that it is laid out contiguously and coherently in memory, you will see really big gains using an array data structure because of cache coherency, the memory access pattern is predictable and that is what CPU's are good at, rather than fetching random bits of memory scattered all over the place. In most cases you can do that, so that is why linked lists are not too popular, they have a rather large constant factor that typically makes them worse than simple arrays despite any theoretical advantages they may have, and that constant factor is growing over time as memory becomes slower and slower compared to CPU speed.

#5144822 I have some new habits.

Posted by on 06 April 2014 - 03:19 PM

Why use True/False?


That really just looks like a boolean property "on" of the "light" object. Usually "True" is implicit as in first order logic, simply stating "P" means the predicate P is true, so "if light.on then" translates to "if the predicate `light.on` is true then". Types and variables are not the same thing.




Sometimes I don't like the names of standard functions:


I wouldn't recommend doing this. It might look cute in the short term but once you work with other people they will have no idea what you mean by "Display". Does it display things on a window? Does it print them out in the console? Does it do anything else in addition to that? Unless your function actually does something more than just being a pass-through to an existing standard function, you should just use the standard function, it's clearer and idiomatic. Otherwise everyone rolls their own version of function and type names and it's harder to understand other people's code. If you must, make it an alias instead of writing useless wrapper code, but I don't find it a good habit.




I really like to use Synonyms for functions that do similar but different tasks. 


It really depends on your code. In most cases it's not advisable since it's harder to immediately know what a function does ("is it Begin() that does X? no, wait, that would be Start().. or Play()... lemme check the code...") but in a few select cases it might make sense depending on what you are writing. I would honestly think hard about whether it is meaningful to do this, because you could waste a lot of time confusing yourself - and others - down the road with all these identical-sounding functions.




Being descriptive with my argument names:


Being descriptiive with argument names is a good thing. Though in your given example the code might look cute with the grammatically correct "walk slowly" function call, but why is speed a boolean variable? Shouldn't it be a floating-point variable giving the speed in units per second, or at least an enum like "slow", "normal", "fast" or similar? "Slowly" is also not very precise - if you just want an argument that says whether to move "slowly" or "quickly", then you should probably just call the argument itself "slowly", or make it accept an enum with two values "slowly" and "quickly". That's much more expressive if you don't intend to actually pass in a speed but only one of two options.

#5144685 DRM protection

Posted by on 06 April 2014 - 03:23 AM

Locally enforced DRM is a fundamentally flawed concept as information located on digital storage media under the user's control can unconditionally be copied or altered at near zero cost, especially since it is enough that one person do it and then freely release a crack to the world. There is nothing you can do to prevent that - if the information is stored on the user's computer, you've already lost whatever battle you were trying to fight. Indeed, the DRM problem ("the user cannot access the game without being authorized to") can be reduced to the problem of information copy ("the user cannot copy this information without being authorized to"), i.e. they are equivalent, and information copy cannot be prevented without limiting the user's ability to read that information in the first place.


That leaves online games (mmorpg's and other persistent worlds, where the closest thing to a DRM breach is setting up a free - or paid - private server and garnering a community of your own), or remotely served gaming (OnLive and the like, which are certainly not designed for DRM purposes anyway).


These are the hard facts. The kind of DRM you are thinking of does not work, never has, and never will. Think outside the box, the most successful forms of DRM were those that provided value for actually owning the game, instead of oppressing the player with dozens of "security checks", with half of them not even working reliably and the other half actually favoring players who do not own the game (used CD keys, anyone?). In short, if when people see "DRM" written on a game they mentally conjure up the image of a padlock, you have failed.

#5144563 Does any one use mono c# to develop game server?

Posted by on 05 April 2014 - 08:37 AM

Why do you think there should be a problem? Mono C# isn't some kind of thing that comes specifically with Unity, it's a full-fledged implementation of the C# language. It can do the same things as C++, Java, or Golang, it doesn't have any particular predisposition or weakness to writing servers or game servers for that matter. Therefore you can write a game server with it just as well as with C++, Java, or Go. Therefore, without any additional information, the answer to your question is yes. Perhaps you would like to be more specific?

#5144548 help on hdr rendering

Posted by on 05 April 2014 - 06:26 AM


Isn't it just possible to write a compute shader that goes over all pixels and sum all of log luminances and put it in a float . then simply we can multiply this float value by 1/N either by cpu or gpu ?


This can be done by using Parallel Reduction algorithm:




Which basically amounts to downsampling in the case of a 2D buffer smile.png

#5144027 [C++] Is there an easy way to mimic printf()'s behavior?

Posted by on 03 April 2014 - 12:26 AM

Is printf not ok?


I think he wants to automatically do other things when that function is called in addition to printf'ing (like wrapping the function) so, yeah, a variadic function with vsprintf - or a variadic macro - would be the usual way to do this in C99 as Hodgman suggested, and of course if you go C++ there's probably plenty of alternatives.

#5144015 Why are my ray traced reflections wrong?

Posted by on 02 April 2014 - 10:24 PM

Since your plane doesn't appear to be reflecting light in the same way as your spheres regardless of the reflection formula you use, I would check that your surface normal is pointing the right way for both objects. It's almost certain your sphere surface normals are pointing inwards of the sphere whereas your plane surface normal is pointing upwards (or vice versa).


Remember: the surface normal is typically defined as always pointing "outwards", that is, if V is the direction of the ray as it hits the geometry, then dot(V, N) < 0 (so that dot(R, N) > 0 where R is the reflected ray). You can define it the other way, with it pointing inwards if you want, but you have to be consistent and make sure this is true for all your geometry, since the reflection formula kind of "needs to know" which way to reflect your incident vector, and that depends on the orientation of the normal vector.


It's fairly easy to enforce if you're only doing reflection, since you can do the dot product check and flip your normal as needed, but it gets messy when you start doing refraction/transparency where non-watertight meshes are physically meaningless (they have no boundary) and you can't flip normals since you need to keep track of which object(s) your ray is currently inside of, therefore you have to be a lot more careful in these situations to make sure your geometry is self-consistent. For opaque reflection you can just hack the surface normal to make it point in whichever direction you need and you're good to go (again, because with reflection only your ray is always "outside" and you know it).


EDIT: if you could show your code for the GetSurfaceNormal() method, that should help track down the bug.

#5143354 AES Encryption

Posted by on 30 March 2014 - 08:08 PM

The expanded key material for encryption and decryption is the same afaik (unless there exists some strange variant that does not) so if your encryption routines work then it suggests your decryption routines are wrong. Perhaps you could post them so we can take a look.

#5142840 Cryptography - am I doing it right?

Posted by on 28 March 2014 - 07:23 AM

Thanks guys! smile.png

I've had a think, and I've decided that using TLS isn't neccessary. This is an open source project, so people can figure out the protocol either way. And there's no way they can retrieve the password from the hash.

However I won't remove the encryption currently in place, because its been a learning experience. I'll switch to using RSA key exchange just because I can. smile.png


Ignoring absolutely all of the advice in this thread is your call, but "people can figure out the protocol either way", "there's no way they can retrieve the password from the hash", "it's been a learning experience", and "just because I can" really aren't good ways to write security-related code, and don't inspire confidence. There's a reason it's recommended not to roll your own. Learning experiences in cryptography should be confined to personal experimentation, as soon as you're handling user information you are morally and ethically obligated* to secure it to the best of your ability, and if that means using existing, industry-standard, proven technology or contracting an expert to implement or audit your code, so be it. Just be aware that by making this choice, you are almost certainly not acting in your or your users' best interest.


* depending on what your program does, you may in fact be legally required to submit such code for an audit and be held legally responsible for protecting your users' privacy, whoever that may be. This probably doesn't apply in your case, though, usually this applies to banking authentication and transactions, storing employee payroll information, and so on, but it is worth keeping in mind that if a significant data breach occurs, and a company is found to have not acted responsibly by using a home-made security backend, things can occasionally become very, very unpleasant for them.

#5142466 Need help with 2D oscillation

Posted by on 26 March 2014 - 10:06 PM

What I am trying to understand is how they (amplitude and frequency) are used/implemented in code (specifically the code you posted).


When you're not sure what equation you should be using to describe some motion or are unsure what the variables represent, it's a good habit to do a summary dimensional analysis on the equation, using the simple rules below:

- dimensions multiply and divide as usual

- you cannot add or subtract different dimensions

- transcendental functions are dimensionless


Using this on the equation Alvaro posted, you can see that the frequency (as inverse time, i.e. in Hz) is multiplied with the time variable to give a dimensionless value, the sine of that is dimensionless and is then multiplied with amplitude as a (peak) displacement, giving a result as a measure of displacement, which checks out and is what you wanted. Using the same reasoning you can deduce that the frequency cannot be a vector (unless time is a vector too, which would imply that your x and y coordinates are subject to different times, which is probably not what you want), and so on. As you can see this gives a quick way to check what units a variable should be, whether a physics equation "makes sense", and is also handy to verify that you didn't make an implementation/logic error somewhere.

#5141969 auto generate mahjong level with at least 1 way to win

Posted by on 25 March 2014 - 05:35 AM

Were you aware that the linked page describes an approach for solving existing puzzles rather than for generating puzzles?  We can still help you to understand it if you wish though!


If the algorithm to solve an arbitrary puzzle is sufficiently constructive, it is often not hard to reverse it to produce an algorithm to generate a solvable puzzle smile.png (though such an algorithm can probably more readily be obtained by simply reversing the game rules, as frob suggests).

#5140810 Good specular for water surface

Posted by on 20 March 2014 - 06:40 PM

You want a much higher shininess than 20 for water. Water is extremely reflective, and is usually a near perfect mirror at most viewing angles (though you don't want to do that in a shader because of aliasing), so make that a lot higher, maybe somewhere near 128-256. As it is now your water looks like plastic.


You mention wave amplitude - that usually doesn't matter, if you've ever watched a pond or a lake in calm weather, there are almost no waves, yet the water sparkles. Why? Because those tiny waves are actually sharp (high frequency), so only a small part of them is able to face the right direction to reflect lots of light towards you. What does that mean when translated to graphics? It means your normal map (and possibly wave heightmap) isn't high resolution enough, and is being blurred so much in the process that the wave normals lose all their high frequencies, resulting in a yucky "jello", almost flat appearance.


In shallow water, caustics play a huge part in lighting, as light that refracts into the water is reflected off the bottom and back towards the surface, and is then refracted towards you, which tends to produce a kind of "ambient lighting" term for water (consider your last two pictures - all those unlit areas on the water surface, should still get some light).


And finally, water is not air, it's a liquid. So you can't just render the plane (interface) between water and air and expect it to suffice. Light loses energy in a liquid, and is scattered by it, so the bottom of your ocean shouldn't be visible at all, except near the shore where it appears slightly blurred and tinted. Sufficiently deep water takes a color depending on its composition, usually ranging from light blue/green for shallow seawater to deep blue for deep seawater. Obviously it's unrealistic to simulate all of these in a game, but a cheap way to approximate it is to have a kind of "fog" in water depending on the distance between your terrain and the water plane (by reading the depth buffer) with exponential decay and a green/blue tint. That will almost certainly make your water look much better.


Fixing that and then adding proper reflection/refraction with a little caustic map should dramatically improve the quality of your water.

#5140807 sli and the pci express bus use

Posted by on 20 March 2014 - 06:18 PM

does having 2 cards use up the bus twice as quick?


Each card has its own bus, and they can also communicate (synchronization, and I believe some types of resources are shared) without going the long way around through the PCI-E bus, to system memory, back to the PCI-E bus of the other card, as they can just use the SLI bridge.

#5140525 Random Arbitrary Precision Numbers

Posted by on 19 March 2014 - 09:16 PM

Then I run into the problem where I don't know what I'm handling. I guess requiring some sort of standard interface is required.


Yes, if you don't know what you're handling then you can't do anything with it wink.png though if you know that they are all unsigned integer types, you might be able to use a compile-time sizeof() to work out how many bits you're getting from the RNG, and using that to piece together a digit, I don't know if such a thing is idiomatic in C++ though.


To what extent should things be required? Should RNG classes also be expected to provide things like floats in the range [0, 1], and other things?


To be perfectly honest there is no convention. Some people (like me) advocate for separating the RNG from the type (distribution) of data generated, so that the RNG provides only a stream of bits (either as a literal stream of bits, or by chunks of 32/64 bits, whichever is easier) and then another class uses that to produce floating point values, another class uses that to produce a normal distribution, another class uses that to produce integers between 0 and N, and so on. Other people prefer to couple the two together, so that you have this big "Random" object that usually doesn't expose its output directly, but is able to convert it to what you need on the fly. It's a trade-off between composability and convenience, but even if you don't separate them in code I feel it is crucially important to understand the difference between a pseudorandom bit generator and a probability distribution.


Both approaches are sufficient in terms of features you need, but of course the code needed to make use of them will not be the same in both cases. At the end of the day, you (so far) only want to generate uniform "big integers" in a specific range. As I've shown in my previous post, you can build this using only a single primitive: "give me N random bits" (or "give me N random 32-bit integers", and so on). That is what your RNG needs to be able to do. There's no way to tell which particular signature is best-suited without knowing more about your code and its potential use cases, but they are all equivalent and sufficient.

#5140296 Exactly what's the point of 'int32_t', etc.

Posted by on 19 March 2014 - 05:59 AM


Another thing int32_t family of types does is guarantee twos compliment arithmetic.

Really? I highly doubt that, can anyone confirm?



It does.




The typedef name int N _t designates a signed integer type with width N, no padding bits, and a two's-complement representation. Thus, int8_t denotes a signed integer type with a width of exactly 8 bits.