Jump to content

  • Log In with Google      Sign In   
  • Create Account

samoth

Member Since 18 Jan 2008
Offline Last Active Yesterday, 06:56 PM

Posts I've Made

In Topic: what good are cores?

24 May 2016 - 11:31 AM

In addition to what Hodgman said... any game that renders anything or plays sounds, any such game, uses several cores. Plus, any game that uses asynchronous file I/O.

If you just open a device context, a thread is created. You don't see it, but it's there. It will work off the render commands that you submit or it will mix the sounds that you play.

Especially in processing sound, running stuff asynchronously (preferrably on another core) is very much real life, and very mission critical. Let the sound card's buffer get empty once, and the user will immediately and inevitably hear it. This must never happen.

Process draw calls on the same core, the same thread even? Sure, it's possible. Welcome to 1995. But you're not getting anywhere close to 201x performance.

In Topic: How come most HD photos I see online look worse than their downsized versions?

23 May 2016 - 05:46 PM

First of all, HD (read as: many pixels) is not equivalent to quality. HD is first and foremost marketing.

Good lenses = good quality (... if the photographer doesn't fuck it up, it does take a little skill to take a good picture, too). You can somewhat estimate this fact from the trend not to increase pixel counts indefinitely any more in cameras (speaking of camera-cameras, not cellphones). Surely, your favorite Nikon/Canon/whatever could easily have 50 megapixels nowadays, why not. Well, it doesn't.

Storage going up drastically is another reason, but RAM/Flash is so ridiculously cheap and abundant, it's hardly a matter any more. The point is rather that increasing resolution not only has diminuishing returns, but it actually makes quality worse. Some manufacturers have even reduced the pixel count (Panasonic did, for example, in its traveller series, in favour of slightly better optics).

The reason why more pixels tend to decrease image quality under some conditions is that the surface (and aperture) is the same, so the same amount of energy falls onto more sensors, which necessarily means that each one must be smaller and gets fewer photons. Sensors thus need to be more sensible, which however means more noise.

That, and of course hardly anyone uses a real camera any more nowadays... virtually everything is done with the cell phone's builtin camera. You can't expect a thumbnail-sized fully-automatic thingie to produce anything high quality, really. Not only is fully-automatic usually equivalent to fully-shit, but also it's just physically impossible to make something out of such a small thingie.

Your idea about upscaling may be a factor as well. You don't even know what the camera is doing. It applies some color profile, does some anti-shake trickery, then some filters, maybe it combines 3-4 images into one, too. And then it does perspective corrections and scales everything without you even knowing. What you have on disk has little to do with what the sensors saw, and you have hardly a way of telling or even influencing it.

In Topic: My C++ gotcha of the day

20 May 2016 - 05:17 AM

Your code is invalid, but irrespective of the use of union (and your compiler is apparently broken because it does not notice). Your inline initialization of the color values in Color is equivalent to a default contructor, and members with constructors are not allowed in anonymous aggregates. That is, you are not allowed to write anything like struct { HasConstructor foo; };
 
Your "type punning" use of the union is actually legitimate because the standard (as of C++09 if I am not mistaken, but could as well be C++11) explicitly makes it well-defined as long as there is a common sequence. It is reasonable to assume that an array of identical objects which require no padding has a common sequence with several subsequent objects of the same type. Not sure if it's guaranteed (probably isn't), but the assumption is by all means reasonable.
 

This reminds me of a different topic "Are accessors evil?" from not long ago. You can rewrite your code without the troubles of unions like so:
 

struct QuadCorners2
{
    Vertex vertices[4];

    Vertex& topLeft() { return vertices[0]; }
    Vertex& topRight()  { return vertices[1]; }
    Vertex& bottomRight(){ return vertices[2]; }
    Vertex& bottomLeft() { return vertices[3]; }
};

 
The only downside is that now you have to write somevertex.topLeft() = blah; instead of somevertex.topLeft = blah;

However, on the positive side, you now have a plain normal struct which will default-initialize each element of its member array per §8.5. For arrays of PODs or arrays of types without default constructor, that will still do nothing, but Color has a default constructor, so everything is good.
 
(I left out const accessors in order not to bloat the code snippet up too much, you may want to add those)
 
So, in reply to "Are accessors evil?" one could say: "Accessors just saved my ass".


In Topic: can c++ be used as a scripting language

20 May 2016 - 04:40 AM

It is certainly possible, and being done (I do it myself). There is a nice in-depth description of yet someone else using C++ for scripting on the molecular web site.

 

The obvious problem about using C++ as a scripting language is that it is not a scripting language.

 

Scripting languages suck because they are so slow, blah blah. But they also have some very noticeable advantages (some of these are more obvious, some are less obvious but nonetheless important). For example, a scripting language exposes to the script writer exactly what you want it to expose, and nothing else. It enforces that you do exactly as allowed, nothing else. An invalid script should never result in an application crash or undefined state, either.

 

C++ does not do things like bounds checking, and it allows you to dereference any valid or invalid pointer, reading from or writing to any address. You can in principle call any OS function, including one that modifies files on the harddisk, opens a process handle, or... a network socket.

 

Which means that user-modifiable scripts are always in some way troublesome. A badly written user script may cause a crash (which you can catch in a handler, see the molecular article), but it might also mess up some random state in a non-obvious way without causing a crash. It might deliberately change state, allowing a player to cheat. It might allow someone to publish a "mod" that has a somewhat nicer window layout and uses your game to host a botnet. It might let someone write a ransomware mod on top of your game. Imagine the PR nightmare linked to "your game encrypted my harddisk and demands money". You will never recover from that one.

 

If scripts reside on a user-controlled computer, it is a valid consideration to remove the feature before shipping, and instead compile all scripts to native code right into the application (or into signed binary modules). Of course that approach isn't without problems either. Among other things, it means that what user and developer have in their hands is no longer 100% identical... It is thus unlikely but possible that the user experiences a bug that the developer cannot reproduce.

 

I'm only using C++ as server-side scripting language. User-side, no thank you, I do not like to open Pandora's box. Never know what comes out of it. On a server, however, it gives me fast iteration, the ability to modify behaviour at runtime, and native speed.


In Topic: ABS and handbrake

17 May 2016 - 12:43 PM

Impossible to tell. There used to be a mantra "brake must be strong enough to tame engine at all times" but that's for the main brake.

The hand brake, or parking brake as it is sometimes called, is not really designed for that purpose. It's for preventing the car to roll down a hill, to do a hill start, and to serve as emergency brake if everything else fails. It's not really meant to be able to subdue the engine (although it might). Whether or not the engine stalls depends on your particular car's design.

5,000 RPM in gear 1 is usually pretty close to the maximum possible torque, so it might very well be that the hand brake is unable to stall the engine in this condition.
Also note that the hand brake often (usually, almost always) address the rear wheels while the majority of non-pony cars has front transmission. So, while the brake might be able to stop (or effectively stop) the car, it might still not stall the motor. Front wheels might do a burn-out while rear wheels stand still (or slide very slowly). Burn-out with front wheels would be a funny thing to see though, don't think I've seen that in my life.

PARTNERS