Jump to content

  • Log In with Google      Sign In   
  • Create Account

Promit

Member Since 29 Jul 2001
Offline Last Active Today, 10:12 AM

#5235508 Tiny Serialization Library

Posted by Promit on 18 June 2015 - 09:51 AM

I dunno, I'm skimming through your code and it seems like serializing objects in yours is a crapload of work and code to write, plus you have to maintain matching read/write functions. Is that an accurate assessment?




#5235167 Uses of curves in graphics?

Posted by Promit on 16 June 2015 - 12:36 PM

Lighting response curves - http://graphicrants.blogspot.com/2013/08/specular-brdf-reference.html

http://blog.selfshadow.com/publications/s2013-shading-course/karis/s2013_pbs_epic_slides.pdf




#5235019 My .OBJ Model Loader doesn't seem to output the right scanned data of cub...

Posted by Promit on 16 June 2015 - 12:08 AM

Oh - you still need the v part in the string. Try: "v %f %f %f". 

Also, your array declaration is incorrect, it should be value[3] as you have three values. 




#5235015 My .OBJ Model Loader doesn't seem to output the right scanned data of cub...

Posted by Promit on 15 June 2015 - 11:00 PM

%d is integers, %f is floats. You probably just need "%f %f %f". Your values are also ints, which is obviously wrong.




#5234649 how much i can trust the shader compiler?

Posted by Promit on 13 June 2015 - 02:35 PM

Depends on the API and platform, which already means that in the general case: no, you cannot trust "the compiler". The worst of the compilers are the mobile GLSL compilers, which may fail to make even trivial optimizations properly. HLSL is tricky because it's an intermediate compiler to a problematic format that is then finally compiled by the NV, AMD, Intel drivers. Overall I'd say HLSL on NV is probably the most reliable of all the platforms, with HLSL/AMD close behind. It also appears that Apple/Metal is very strong, as it's essentially running the clang/llvm stack.

 

And yeah, sometimes it's bad.




#5234488 Making a tool for the engine

Posted by Promit on 12 June 2015 - 11:49 AM

That's a big topic, but I'm actually going to start by encouraging you to read the Bitsquid blog stuff. Of note is Our Tool Architecture.




#5233569 Game in pure C99

Posted by Promit on 08 June 2015 - 11:45 AM

Without static linking, you have to manually decode a bunch of COM interface details and build function pointer tables. Honestly if you want to do a pure dynamic loader, it will be much easier to use OpenGL, as it is a pure C API.


#5233346 MIT: Is it even remotely possible?

Posted by Promit on 07 June 2015 - 08:54 AM

There's minimal harm in applying, and nothing in particular that tells you yes or no until you try it. I certainly wouldn't plan around getting in, but meh? There are easily dozens of other great, world class computer science programs out there. MIT is a big name but that doesn't even mean they are a good fit for you.


#5232763 Water texturing of caustics effects

Posted by Promit on 04 June 2015 - 08:53 AM


I created actually a 3D texture that was used to achieve this effect (so with animation it was actually 4D texture), the performance was okay and I didn't care about the memory that much (I still had budget in memory).

An alternative way to pull it off would be to use mip maps with additional blur applied, and then apply a bias to the texture lod.




#5232225 What kind of infrastructure is found in game or software studio's

Posted by Promit on 01 June 2015 - 02:28 PM

Offhand... This is just the dev team, not operations.

Lots of back end servers. Source control requires big drive arrays and network bandwidth to handle all the requests. Build servers, the exact use of which depends on the studios. Code build, asset builds of all sorts, etc. Misc servers to run email (usually Exchange), do internal file sharing, provide other internally hosted services, etc. Often times there are internal tools that are built to use the internal server network. Tons of network infrastructure to keep these things humming along.

Lots of desktop computers, usually clones of two or three hardware specs. If you're working on a different platform, lots of dev kits. Typically some spare parts bins for misc needs.




#5231766 virtual pet game

Posted by Promit on 29 May 2015 - 05:34 PM

I would also decide whether you want to start with the visual piece (rendering a pet, having it do things, etc) or the gameplay piece (keeping it fed, watered, happy, etc). They're very different aspects to work on.




#5231381 What are your opinions on DX12/Vulkan/Mantle?

Posted by Promit on 27 May 2015 - 07:13 PM

Just for laughs...

 

uGgcRYG.jpg




#5231271 What are your opinions on DX12/Vulkan/Mantle?

Posted by Promit on 27 May 2015 - 10:51 AM

That's going to depend on the on-the-ground realities of driver and operating system support, when the dust finally settles. Remember, GL sounds like a great cross platform Direct3D killer on paper but doesn't live up to that in reality. We still don't know how Vulkan in real life will be. I expect that major engines, including DICE/Frostbite, will simply support both.




#5231269 Graphics engines: what's more common; standard vertex structure or dynami...

Posted by Promit on 27 May 2015 - 10:50 AM

I have a couple base types that are byte-for-byte matched to their shaders (now mandatory in Metal), and a couple specialized types that are for specific things but also matched to shaders. So there's essentially a utility vertex, a skinned model vertex, a scene model vertex, and a few specialty things like water surface vertices. Technically the underlying mesh format is data driven and allows you to declare any vertex type you like, but the tooling will only give you a few types to export.

 

I don't like to custom build and interleave vertex formats based on the shaders, though I've seen this done. I'd rather pay some extra transfer cost than deal with the static memory use explosion when shader formats differ in trivial ways. I also don't like to deinterleave the streams and bind them separately as KaiserJohan suggested, because this is actually not optimal on the GPU side. In a few specialized cases we do use vertices that assemble from multiple streams, but I try to avoid it.




#5230744 Movie IP rights

Posted by Promit on 24 May 2015 - 05:48 PM

It varies depending on the exact deal that was struct bringing the movie to the market. The publisher is most likely to hold the IP, but sometimes the actual production studio does. In any case, if it's not some random indie thing your likelihood of getting rights - or even a response - is in the "lottery odds" territory.






PARTNERS