Jump to content

  • Log In with Google      Sign In   
  • Create Account

Matias Goldberg

Member Since 02 Jul 2006
Offline Last Active Yesterday, 08:28 PM

Posts I've Made

In Topic: Hi, Im Dave and I'm an Generic-aholic.

Yesterday, 01:42 PM

Aside from having a clear scope, well defined rules of what you want to do / how to behave, and a working prototype, something that helps fight the "genericness" urge is to use assert.

 

What if somebody wants to use foo( ptrEnemy ) with a null pointer because it isn't initialized or an enemy couldn't be found?

assert( !ptrEnemy && "Enemy can't be null" );

What if the user wants to load the materials first then textures (and not viceversa)?

void loadMaterials()
{
    assert( texturesLoaded && "Textures must be loaded at this stage when loading materials" );
}

Artificially restricting the number of ways users can interact with your API prevents you from getting stuck in coding "all possible case scenarios". Make your users adapt to a few ways of interactions rather than allowing them to do whatever they want in the order they want.

 

If you think you're doing your users a favour by giving this kind of flexibility, you're not. Users want to be told when they're doing something wrong (hence the asserts) and users want to go online and find an answer in stack overflow on how to use your library and move on.

Having a few combination of valid usage scenarios googles far better when all search hits agree on what to do ("ok this is definitely the right way of using the library then") than having a lots of Google results where everyone tells completely different story on how to initialize and use your library (and obviously some ways will be buggier than others).

 

Of course that some flexibility is good, but too much is counterproductive for everyone involved. Artificially limit them and place asserts when non intended ways are detected.

Later on if that limitation needs to be lifted, you can do so.

 

Edit: In the context of GUI tools where the user isn't a programmer, replace "assert" with some form of UI feedback (like flashing red in a bottom status bar, with an explanation of what they're doing wrong. Word it expressively so it can be easily searchable online. Having numbered error codes can also help)


In Topic: C++ CLI or native for game engine

28 April 2016 - 09:50 AM

Clarifying so what Josh Petrie said makes sense:

You're confusing the CRT (C Run-Time) with CLI (Common Language Infrastructure).

 

CLI is some weird hybrid between C++ & C# for interoperating between those two languages.

CRT is native and provides common basic C functionality such as malloc, free, strcpy, etc. When you see projects linked to the VC Runtime, they're linking to the CRT.


In Topic: D3D12 / Vulkan Synchronization Primitives

27 April 2016 - 08:20 PM

I fail to see how:

waitOnFence( fence[i] );

is any different from:

waitOnFence( fence, i );

Yes, the first one might require more "malloc" (I'm not speaking in the C malloc sense, but rather in "we'll need more memory somewhere") assuming the second version doesn't have hidden overhead.

 

However since you shouldn't have much more than ~10 fences (3 for triple buffer + 6 for overall synchronization across those 3 frames + 1 for streaming) memory usage becomes irrelevant. If you are calling "waitOnFence(...)" (which has a high overhead) more than 1-3 times per frame you're probably doing something wrong and it will likely begin to show up in GPUView (unless you have carefully calculated why you are fencing more than the norm and makes sense on what you're doing).

 

Btw you can emulate DX12's style in vulkan with (assuming you have a max limit of what the waiting value will be):

class MyFence
{
#if VULKAN
       vkFence m_fence[N];
#else
       D3D12Fence m_fence;
#endif
       MyFence( uint maxN );

       void wait( uint value );
}
due to creating 1 fence per ExecuteCommandLists

 

Ewww. Why would you do that?

Fence once per frame like Hodgman said. Only exceptions are sync'ing with compute & copy queues (but keep the waits() to a minimum).


In Topic: GPL wtf?

25 April 2016 - 01:10 PM

A quick read of the SFC post shows quite a different view.

 

From their perspective, it's not the GPL, but rather that the CDDL license forbids distributing their software linked with software that can't be covered by the CDDL (such as the GPL).

 

I guess "GPL Violations Related to Combining ZFS and Linux" or "Canonical accused of violating the GPL"" calls more the attention than "CDDL Violations Related to Combining ZFS and Linux" or "Canonical accused of violating the CDDL".

 

So to your question "So, since it is against the GPL to combine non-GPL stuff with the Linux kernel, is Valve in violation with the GPL?". No, because Valve isn't saying the Linux kernel shouldn't be GPL when distributing their SteamOS with their own software, while the ZFS' license says the Linux kernel can't be GPL if ZFS is included in binary form.

At least, from SFC's rationale being discussed here.


In Topic: Compiling HLSL to Vulkan

19 April 2016 - 07:37 PM

There is an hlsl-frontend to compile HLSL to SPIR-V, but I don't know in which state it is.


PARTNERS