Jump to content

  • Log In with Google      Sign In   
  • Create Account

tivolo

Member Since 19 Jun 2004
Offline Last Active Sep 21 2016 07:09 AM

Posts I've Made

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

19 July 2016 - 02:05 PM

 

In a development build, each script is compiled into a single shared library for hot-reloading, fast iteration times, etc.
In a retail build, all scripts are compiled into the game executable, so the builds that go through QA are also what ends up in the user's hands - 100% identical.

Well no, that was my point. While it's the correct thing to do (from a security point of view), it does not lead to 100% identical code being executed.

Not only is (this is rather pedantic since it should hopefully make no difference, but who knows) the function binding and calling different between "same executable" and "in a shared library", but also, more importantly, you can expect a modern compiler to perform whole program optimizations on "same executable" code that are simply impossible across shared modules where the respective part isn't present at link time.

Hopefully, you never see a difference (and I guess most of the time you won't), but you can never be 100.0% sure (only 99%). The things that are most nasty to debug are the ones where it works fine on one machine, but doesn't on another, and then it turns out that's because they were running kind-of-the-same code, but not exactly.

 

 

Ok, if I understand you correctly, you're talking about the difference between a development build and a retail build?

If so, then well, yes, that is true for every game I've ever worked on. Development builds usually have lots of features which are stripped out in retail builds.

Console games always had the "happens only when being started from the DVD"-kind of bugs, so debugging retail builds without symbols was the way to go.

 

Or did you mean something different? But then I didn't get your point, I guess :-/.


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

19 July 2016 - 07:38 AM

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.

 

In Molecule, the scripts are always compiled to native code.

In a development build, each script is compiled into a single shared library for hot-reloading, fast iteration times, etc.

In a retail build, all scripts are compiled into the game executable, so the builds that go through QA are also what ends up in the user's hands - 100% identical.

 

There recently was a similar question on the Handmade Hero forums where my engine was also mentioned, and I provided a bit more info over there for anybody who's interested.


In Topic: Can someome please tell me why this crashes?

11 August 2015 - 07:26 AM

On Windows, use the following on a command-line:

dir *.mp4 /s /b > myFile.txt

Execute in any directory you want to gather all the .mp4s in that directory and all sub-directories, recursively.


In Topic: Bizarre 60x slowdown with DSP filter

30 December 2014 - 08:20 PM

These two might be of help:

https://software.intel.com/en-us/articles/x87-and-sse-floating-point-assists-in-ia-32-flush-to-zero-ftz-and-denormals-are-zero-daz

http://msdn.microsoft.com/en-us/library/e9b52ceh.aspx

 

You likely want to enable Denormals-are-Zero (DAZ). I had to do that in my real-time radiosity simulation, because denormals also caused huge performance drops whenever values became too small.


In Topic: Storing position of member variable

14 July 2014 - 08:17 AM

 

 

EDIT: Unfortunately, pointer-to-member seems to also have a problem with the child-POD-struct:

class Sprite : 
	public ecs::Component<Sprite>
{
public:
	math::Vector2f vPos;
	float z;
	
	void Test(void)
	{
		float Sprite::* pZ = &Sprite::z; // works
		float Sprite::* pX = &Sprite::vPos::z; // doesn't even compile... I don't even know how that should work
	}
};

I don't know... is there even a solution to this? offsetof would work, though I like pointer-to-member better... I don't want to replace the vector with pure floats eighter... any ideas?

 

 

The problem is that &Sprite::vPos::z is not a pointer-to-member of class Sprite, but rather a pointer-to-member of math::Vector2f, which is entirely unrelated to Sprite.
One solution to your problem would be to implement a generic (but typesafe!) pointer-to-member, something using inheritance and type erasure should do the trick.


PARTNERS