Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 29 Jul 2001
Online Last Active Today, 12:19 AM

#5224487 Remaking Mario 64 from scratch, how long?

Posted by Promit on 20 April 2015 - 08:05 AM

The core technical work is actually not that bad - some guy did it in Unity for kicks.
The amount of assets comprising the game is pretty gigantic, though. Simple assets with simple textures, but still many of them. And various levels have enough special pieces to complicate the work considerably.

#5222755 How does boost::shared_ptr/make_shared equality work?

Posted by Promit on 12 April 2015 - 09:37 AM

make_shared is conceptually the same as:

boost::shared_ptr<Object> selObj;
selObj.reset(new Object());

If that helps.

#5222670 Is this fair use?

Posted by Promit on 11 April 2015 - 05:37 PM

Without a lawyer on retainer, the extent to which you're protected is zero - regardless of the legality. You're correct that parody is protected as fair use, but in the unlikely event that someone wants to take you to task, what do you plan to do? 

#5221976 Looking for a good sound card

Posted by Promit on 07 April 2015 - 08:18 PM

For audio recording work, I would tend to go to an external pro audio interface rather than any type of old style internal sound card. Needs vary, but something like a Focusrite Scarlett 6i6 would be an example. It has XLR, 1/4", and MIDI connections. Another possibility would be the Presonus Audiobox.

#5221974 SPIR-V Macro Compiling

Posted by Promit on 07 April 2015 - 08:09 PM

There's no runtime conditional compilation stuff in SPIR-V. You would create all variants, or use static/uniform/coherent branching to select. 

#5221423 Vertices and indices in the same buffer?

Posted by Promit on 04 April 2015 - 07:50 PM

@Promit: I may very well be reading incorrectly between the lines, but I get the impression that mixing different kinds of data in single buffer (in old or current GL or D3D anyway) is not something you've done or seen done, at least enough to be a somewhat common pattern?

Correct, but that's not to suggest there's any issue with it. I've just never seen any of the documentation from the IHVs suggest that you should do it, so it never really crossed my mind to try it. I think it's a good idea if GPU memory fragmentation is a concern. 


This was a few years ago: https://developer.nvidia.com/sites/default/files/akamai/gamedev/files/gdc12/Efficient_Buffer_Management_McDonald.pdf

#5221409 unethical

Posted by Promit on 04 April 2015 - 06:17 PM

If other members of both projects are aware and okay with it, obviously not. If other members are not aware and it doesn't interfere, probably not. If you're not being paid anyway, probably not.


If they're aware of it and express a problem with it, maybe.

#5221367 Vertices and indices in the same buffer?

Posted by Promit on 04 April 2015 - 12:26 PM

Back in the day, GPUs weren't actually able to read indices from GPU memory. They were always streamed from main memory. But that is ancient history. Nowadays, on at least some hardware, I've heard that uniform buffers, texture buffers, and possibly shader storage buffers get special handling. The glBufferStorage API (which you should be using, not BufferData) requires you to pick a specific buffer type, not a mask. However on closer reading this appears to be simply a question of the buffer's binding point, not anything to do with the actual usage (which doesn't kick in until BindBuffer). I don't see anything offhand that says you can't bind the same buffer to more than one binding point, and from there it's just a question of offsets.


So yeah, go for it. I would be inclined to keep constant/uniform buffers and texture buffers separate from everything else, though.

#5221244 Safe endian macro

Posted by Promit on 04 April 2015 - 12:48 AM

An M68k? Sparc? The freaking HPPA?? What on earth are you coding that requires this level of flexibility? (If it's a generic header for 'everything', stop and do something else that is grounded in reality.)

#5221146 SetTexture question

Posted by Promit on 03 April 2015 - 11:18 AM

in performance costs, apparently the state changes from most to least expensive are:
1. textures
2. meshes
3. materials
4. projection matrix
5. world matrix
6. other state changes like cull on/off, etc.
which means you want sort your render queue on texture, then mesh, then material, then near to far.

Maybe in 2005 - not so much today.


A modern day GPU is a very different creature from the devices for which D3D 9 and even 10 were developed. The older advice on performance is almost totally irrelevant. Ultimately there are just a few categories of state changes that make any difference:
- Total GPU flush changes. In most cases this is an RT switch.

- Shader changes.

- Pipeline reconfiguration. This can include some of your rasterizer states, depth stencil settings, and blend settings. On some GPUs, changing these states to unexpected values will trigger shader recompiles.


Note what's NOT on the list: buffer changes, shader constant changes (which are buffers now), texture changes. (Texture format changes may have an impact; it depends on the situation.) The GPU doesn't care at all about binding different resources to the pipeline, because all of these things are now flowing through virtualized memory.


Oh and when you change one pipeline state, you may as well change all of the pipeline states. It's the same thing. Changing anything will trigger validation of the pipeline against the current shader and potentially the current RT. Clever sorting serves no purpose. Avoiding duplicate changes is only useful if it allows you to avoid setting an entire state block, or ideally changing state at all. (May be hw dependent.)


Lastly, all state is validated at draw call time. If you change state, basically the driver sets some dirty bits (so it knows how much validation is needed later) and records the new state in a table. It doesn't care whether you issue one change or a hundred. Desktop drivers usually detect duplicate changes, but mobile drivers may not. Be aware of what impact patterns like: SetTexture(A); SetTexture(B); SetTexture(A); may have in setting dirty bits even if the change is ultimately redundant.

#5220542 What will happen with OpenGL after Vulkan?

Posted by Promit on 31 March 2015 - 12:56 PM

Public statements by Khronos so far indicate that OpenGL development will continue. There is a lot of momentum in GL, which is what screwed previous attempts to revise it. This time, they are offering both.

Personally I despise GL. It's horrible to work in. So I am chomping at the bit to change over.

#5220013 No matching overloaded function found: mix

Posted by Promit on 29 March 2015 - 01:23 PM

Looking at the docs, I don't think mix is defined for matrix interpolation at all. You might want to write up a custom function for it.

#5219457 Direct3D 12 documentation is now public

Posted by Promit on 26 March 2015 - 03:57 PM

I would not be surprised if MS decided to roundhouse kick the reference driver...

Don't know - the reference driver may be more useful on the driver side. Remember it's a reference, not a generic soft rast. It exists to be a stable basis of comparison.

#5219384 SLI with an advanced OpenGL game?

Posted by Promit on 26 March 2015 - 12:13 PM

Heh, yeah. Doing SLI or Crossfire on your own is a nightmare. The GL API doesn't help at all.

Here's the situation: you cannot debug it. Some of NVIDIA's performance tools (NSight) might help but sometimes these things blow up or fail to give productive results in GL. Basically, something in your code is shutting off SLI or breaking it. It might be a bad Map or BufferData. It might be an extension that isn't supported.

The way to find it is to throw an FPS counter in, and then shut off the entire pipeline. Then start bringing phases of the render back in, until you find which piece breaks the speed up. It's going to be boring and time consuming, and the offending call may not make any sense when looking from outside the driver. Good luck.

#5219237 Direct3D 12 documentation is now public

Posted by Promit on 26 March 2015 - 12:11 AM

Have fun!



P.S. Yes, SlimDX will be supporting D3D 12. We're going to build a modern version of the library that is streamlined to 12 + utilities/math only, and supporting all Win10/D3D 12 hardware platforms. It will be slick.