Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 07 Feb 2001
Offline Last Active Jul 13 2015 02:58 AM

#5158387 Metal API .... whait what

Posted by on 05 June 2014 - 07:53 AM

They mention a 4xMRT limit, so 4 x 4x32bit follows on from that anyway, seeing as 4x32bit is the fattest texture format biggrin.png

But yes, a "feature level" API would be nice, so you can ask the device what kind of limits it actually has.


BTW, I wouldn't dare use 4 x 4x32bit on the nextgen consoles! That's way too much bandwidth -- At 1080p, that's over 120MiB of framebuffer!

(or if you assume a perfectly optimal only 1 write followed by 1 read per pixel, then at 60Hz that's 14.8GiB/s of bandwidth)

3 x 4x8bit is a pretty standard setup for deferred rendering, and even that's uncomfortable from a bandwidth point of view...


Keep in mind that on Xbone, you want to keep your frame-buffers under ~30MiB! 3 x 4x8bit plus a depth buffer just barely fits in 32MiB of ESRAM.


3 x 4x8bit isn't uncomfortable on next-gen consoles. I guess Xbone has more restrictions here, but Infamous Second Son used 6 1080p gbuffer targets + depth + stencil - 3 of the gbuffer targets are 4x8bit, the other 3 are 4x16bit. See slide 41 here: http://suckerpunch.playstation.com/images/stories/GDC14_infamous_second_son_engine_postmortem.pdf

#5086851 Generic Datatypes --Are Templates the Way to Go?

Posted by on 17 August 2013 - 02:38 PM

Yes, these are "intrusive lists" and I would use caution when deriving from a type to add 'next' and 'prev' pointers to your object. What do you do when you want the object to be in more than one list? Also, how do you keep code from looking confusing - going this route, if you add an object to a list, you have to remember you're implicitly removing it from any list it was in previously.

#5024602 Basic Level Editor Question

Posted by on 22 January 2013 - 11:07 PM

The way i have done it is that the editor uses the engine directly. So the level loading function all comes straigh from the engine. That way when i have a standalone executable that i release i can reuse the exact same loading function. Everything the editor does it uses the engine. That way you get what is WYSIWYG (What you see is what you get) type of editor. I have attached an screenshot of my 3d editor which i am currently working on just to give you an idea.UpdateEditor3.png

Looks like someone likes Unity smile.png

#5016965 Number of vertices and number of triangles in modern game

Posted by on 02 January 2013 - 10:23 PM

No, vertices can be shared between adjacent triangles, as long as all attributes match (position, normal, uv, whatever). For example, vertices along a 'hard edge' (not shared normals) are not shared between adjacent triangles. At maximum, numVertices = numTriangles*3, but there is as much sharing as possible.

#5016219 ID3D11ShaderReflection

Posted by on 31 December 2012 - 06:28 PM

I don't know how fast it is, but I'm sure it wasn't designed with speed in mind. It's more the kind of thing you want to run once over your shader to get the information you need, then store that in your own data for use at runtime as necessary. I wouldn't use it in your render loop, it's more of a tooling library for inspecting the shader code.

#5014659 What kind of optimization makes C++ faster than C#?

Posted by on 27 December 2012 - 04:03 AM

The lesson for me was: Yes, C++ is faster when you know how


This is a very important point. Many game engine developers have the "know how", but the problem you run into with managed environments is that even if you know how, you simply don't have low level enough access to implement the optimizations, so you're stuck. That's a deal breaker for a major engine to adopting a language.

#5014623 Writing for 32-bit Windows XP on 64-bit Windows 7

Posted by on 27 December 2012 - 01:19 AM

What version of Visual Studio? It's called Win32 in VS, not x86, in the configuration manager.

#5014622 What kind of optimization makes C++ faster than C#?

Posted by on 27 December 2012 - 01:17 AM

GC is another topic that always pops up in these kind of discussions... IMO is pure non-sense. GC won't trigger if you don't "new" stuff, and will be VERY fast if you don't have objects with medium life expectancy.. it's just a matter to take some time to understand how the system works and how you can make it work for you... it's much easier to learn to deal with .NET's GC than learning proper memory management in C++, simple or through the 6-7 "smart" pointers available.
Just as you try to avoid new and delete in your game loop in C++, avoid newing class objects in C# and GC won't cause any troubles.


But really what you're suggesting here is that to "solve" the problem of the GC needing to halt all threads and needing an unknown amount of time to complete, that you do "manual memory management" and try to avoid invoking the GC, which also means designing around ctors/dtors and doing init/cleanup of your objects yourself so you can reuse instances. IMO that's a lot easier to do when there is no GC to worry about, and you reintroduce the problems GC was meant to solve (ie dangling pointers).

#5014613 Questions about encapsulation, resource management, global variables* and the...

Posted by on 27 December 2012 - 12:30 AM

Global variables can be fine, and it certainly helps when debugging to just be able to type gResourceMgr into a Watch window and get at the resource lists.


I think the resource loader is fine to be global - it's the sort of thing you would only want one of in a process. Every engine I've ever worked with has had the resource loader be global. I certainly wouldn't want to pass a pointer to it through every function that could possibly call a function that might call a function that needs to get a resource.

#5014611 What kind of optimization makes C++ faster than C#?

Posted by on 27 December 2012 - 12:23 AM

Performance on modern hardware is less about optimizing instructions and more about memory access patterns and data layout. C++ lets you exactly control how your data is laid out in memory, so you can more explicitly control your memory behavior. C# tries to abstract this sort of thing away to favor programmer productivity at the cost of some performance.


I think most game engines being written in C++ is simply because C and C++ are extremely portable languages. If there were another language that was equally as portable you might see more engines written in that. It doesn't hurt that one of C++'s goals is also to be performance king.

#5008841 Pulling my hair out over D3D11 lighting bug

Posted by on 09 December 2012 - 12:35 PM

In your fragment shader, the input.pos (surface position) that you're using is in projection space. However your light position is in world space. So when you compute the 'surface to light' vector (tmp_light - tmp_pos), you're doing it with coordinates in different spaces, and certainly not getting the world space direction you're looking for. Send the world position into your fragment shader and use that instead.

#5000121 Game Design Crysis!

Posted by on 12 November 2012 - 12:06 AM

It doesn't cost money, nor is art required to prototype gameplay. Just start coding.

#4997490 Thread safe array

Posted by on 05 November 2012 - 02:16 AM

To write scalable parallel code, the answer isn't to take serial code and replace the data structures with 'thread-safe' versions that do the same operations. If you're resorting to using locks, then you're already down the wrong path. The right path is to create algorithms that don't need read+write access to shared data, or to constrain those stages of your algorithm to as small a piece as possible, but still extract parallelism where you can. The data transform you're performing dictates the data structures and algorithms, and a std::vector with locks in every member function is likely a terrible structure.

#4993004 Am I making good progression?

Posted by on 23 October 2012 - 12:47 AM

Everyone's pace is different, just keep going.

#4956869 [solved] PointLight renders as HalfSphere

Posted by on 08 July 2012 - 03:00 AM

You're missing that you're calling normalize() on these encoded [0-1] vectors, and that's not doing what you want.

Keep everything in its natural [-1,1] form until just before you write it to the render target, then deencode it on the other end when you read it from the texture