Jump to content

  • Log In with Google      Sign In   
  • Create Account

Hodgman

Member Since 14 Feb 2007
Online Last Active Yesterday, 11:57 PM

#5153482 What DirectX version?

Posted by Hodgman on 13 May 2014 - 11:51 PM

Yeah it's mostly only a big deal for China, where they have modern hardware but pirated XP is very popular -- in which case D3D9 is ok, but GL4 is also a possibility if you want modern features!




#5153427 Instance data in Vertex Buffer vs CBuffer+SV_InstanceID

Posted by Hodgman on 13 May 2014 - 05:54 PM

Thanks MJP, Can you give me a paper about this?

Here's the latest public AMD in-depth hardware doc that I know of:
http://developer.amd.com/wordpress/media/2012/12/AMD_Southern_Islands_Instruction_Set_Architecture.pdf
 
I don't know if nVidia have equivalent public docs - but the CUDA manuals are likely to be very close to to their hardware.




#5152954 Graphics baseline for a good-looking PC game?

Posted by Hodgman on 11 May 2014 - 05:44 PM

The quality of your art matters more :P
Bad art in a state-of-the-art engine will still look bad, but great art can make a very dated engine shine beyond its years.


Back on topic though - the genre that you're targeting will have a big impact on graphical expectations.


#5152950 Visual Studio 2013 Solution Exporer h/cpp pairing

Posted by Hodgman on 11 May 2014 - 05:40 PM

AFAIK, those groupings are saved into the vcproj file. If you're using something like CMake to create your projects, you could configure it to do it ;)

Otherwise, a key to switch between cpp/h might be useful as mentioned above. I don't know if newer versions of VS support it natively - years ago I just searched google and c&p'ed a macro that someone else had made to add that feature ;)


#5152947 Making games on the Nintendo?

Posted by Hodgman on 11 May 2014 - 05:36 PM

To make games legitimately, your legitimate games company need to sign a bunch of contracts with Nintendo ;-P

Making homebrew games is hard - probably much harde than actual legitimate development, because instead of having the official hardware, SDKs, documentation and tools, you've got community-made reverse engineered stuff (and retail hardware)...

If you're not already quite an experienced programmer, it will definitely be worthwhile to continue practicing on PC.

Also, FWIW, every console game I've worked on has actually been developed on PC as well.
E.g. When making a Wii-exclusive game, we'd internally develop it to work on both Wii and Windows/D3D (which isn't sold to customers). Most of the staff developed the game using the PC version because it's easier. You'd only need to use the Wii version if you're developing new engine features, doing performance testing, or doing final art checks on a TV -- otherwise it was the same as making a PC game most of the time!


#5152944 Vertex Shader unexpected results, bizarre

Posted by Hodgman on 11 May 2014 - 05:25 PM

Gobal values are given the 'uniform' qualifier by default, which means their values are supplied by the CPU (the Effect system in your case).
On the other hand, if you hard-code a literal value as a local variable, the compiler knows it will never change and will perform algebraic optimization of your code, and branch removal.

Also, there's (almost) no such thing as int in SM3 (they're emulated using floats in most cases), so it's better to use floor/round/etc if you're trying to do that in the shader...

So... Your code, below, returns different results based on whether you pass a or b into 'Something'... But what is inside 'Something'?
uniform float a = 12.0;float4 main() : COLOR{  float b = 12.0;  return Something(...a or b...);}



#5152621 Four pillars of object oriented programming

Posted by Hodgman on 09 May 2014 - 06:43 PM

Whoa, whoa whoa, OP.

Inheritance, abstract classes and polymorphism are not the core or most important parts of OO. They're rarely used compared to the rest of OO!!

As mentioned earlier, composition is the killer feature, and SOLID is the 5 pillars.
http://en.m.wikipedia.org/wiki/SOLID_(object-oriented_design)


#5152477 Force feedback the same as vibration.

Posted by Hodgman on 09 May 2014 - 12:40 AM

Racing and flight games definitely still use it on wheels and joysticks that support it. My racing wheel at home is pretty violent if you turn it up to full strength (out of the box, Logitech only have it configured to 50% strength).

 

The Xbone has added some advanced rumble/vibration features, where the triggers can be vibrated individually, as well as being able to vibrate the whole controller.

 

The Steambox controller has some fancy haptic hardware underneath it's touchpads. From what I can gather, they can not just "rumble", but can make it feel like there are ridges of any kind of shape on the surface, among other things.




#5152475 Vertex Shader unexpected results, bizarre

Posted by Hodgman on 09 May 2014 - 12:29 AM

Maybe post some shader code? How is ImagesPerView used in the shader?




#5152463 Optimisation of core code

Posted by Hodgman on 08 May 2014 - 10:46 PM

I haven't used VS's profiler, but the more advanced ones out there will definitely let you configure what statistics/measurements you see -- such as cache misses incurred by each function.

 

 

You can get a long way just using theory - look up Cache-oblivious algorithms.

 

Step through your code and see what the memory access patterns are like. Have you taken cache behaviour into account when designing the code so far? Can it be redesigned so that the memory access patterns are either more linear or have much more locality? Do you run a single algorithm at a time, progressing in stages, or do you jump around a lot with things like calling virtual void OnHit() in the middle of collision resolution?




#5152285 Modern C++ looking for information

Posted by Hodgman on 08 May 2014 - 05:36 AM

For 1) the equivalent of POJO is POD - where you make a struct where all the members are public, and all the members are either primitive types, raw pointers, or other POD types.

If every member has a getter/setter, then they may as well just be public.

Also, getters/setters at all are a strong sign that you're not actually using OO, no matter which language you're using... An object should provide some *useful abstraction*; if all the members are exposed through getters/setters, then there's zero abstraction going on, so theres no reason for it to be an "object" (usually this is where POD types come in).


#5152010 Managing instancing

Posted by Hodgman on 07 May 2014 - 04:50 AM

I was going to do what LS is suggesting -- sort my draws (and filter redundant states) then merge consecutive draws and dynamically build the instance buffer.

But I ended up doing what you're describing in the OP - after culling, sort model instances by model asset (and material), then submit the submeshes of each asset to the render queue once (for each material).
Each high level drawing system (such as this ModelRenderer) has to come up with its own logic to make use of it.

I may still try out the other version eventually, but I went with this way to begin with so I could make no assumptions at the lowest level about what kinds of per-instance data the user might want - such as from vertex buffer streams, cbuffers with VertexId, both at once, etc... The lowest level of my renderer is supposed to be a general purpose GPU API, like D3D/GL, without much magic.


#5151958 Direct3D 12 Staging Resources

Posted by Hodgman on 06 May 2014 - 08:09 PM

AFAIK, D3D12 is going to support hardware all the way back to 9.3 level, so this would have to work across old and new architectures.

 

Newer devices can just put the resource into a memory location that's mapped in the address space of your CPU project and in the GPU's address space. No staging/copies required (just manual fencing by the application to avoid race conditions).

Older devices will still require you the creation of a CPU staging resource, which the GPU can transfer the data into.

 

So - I guess you'd want this staging resource to be a driver-internal detail, rather than an application detail? Instead, at creation time we tell the driver that we want both CPU & GPU access (which lets the driver create a GPU-local and CPU-staging allocaiton if required), and then at runtime we issue these barriers to tell the driver when to transition from CPU-ownership to GPU-ownership and back. On newer devices, this could be a NOP, but on other devices it would perform the copying between staging resources as required?

 

[edit] The alternative is what mantle is doing, described by the Dice guys here: http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2012/10/Rendering-Battlefield-4-with-Mantle-Johan-Andersson.ppsx

Where the application can choose where resources will be placed -- and would have to implement 'staging' resources themselves (and the required copies) if there was no GPU+CPU mapped heap reported as available by the driver, or if they decide there's no heap that has high enough GPU-write and CPU-read performance.




#5151928 Multithreading vs variable time per frame

Posted by Hodgman on 06 May 2014 - 05:05 PM

There two types -- 1) the compiler can choose to reorder your code, and 2) the CPU can choose to dynamically reorder your code.

The function call out to the SDL library ensures that the compiler won't reorder your code (either because because it has no idea what's inside that function at the time, or because it does know what's inside that function, and sees a barrier hint).

Inside the function, there's an expensive lock/fence instruction, which ensures that the CPU won't do any reordering across that boundary at runtime.

Also, in your example, the "other thread" would usually be using SDL_LockMutex(sameMutex) to ensure it doesn't start using those variables until the first thread has unlocked the mutex...


#5151728 Multithreading vs variable time per frame

Posted by Hodgman on 05 May 2014 - 05:29 PM

If you use any properly written mutex (SDL included), it will be performing the required barriers for you. Nothing for you to worry about (except ensuring you're always using the mutexes correctly!)




PARTNERS