Jump to content

  • Log In with Google      Sign In   
  • Create Account

We're offering banner ads on our site from just $5!

1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


Don't forget to read Tuesday's email newsletter for your chance to win a free copy of Construct 2!


Tasche

Member Since 06 Aug 2011
Offline Last Active Apr 20 2013 07:57 PM

#5042136 Existing 3D Game Engine for Gameplay Programming

Posted by Tasche on 11 March 2013 - 07:10 PM

Just on the subject of Triple A asking for C++:

Not 100% sure about this, but that does not necessarily mean you will be coding in C++, its just the fact that if you can handle C++ really well, you will be able to adapt to other languages rather easily, because most modern languages abstract the nitty gritty that C++ does (at the cost of performance).

Also, you will most certainly NOT start your career at those big companies, they ask for 5 years of work experience for their junior staff. And you can be sure that in those 5 years, you need to churn out kick ass stuff, because they really get to choose, and they have a reputation to fulfill (and the budget to back up being picky).

What i'm saying is, along the way you will most certainly have to do several different languages, having a big portfolio and being able to work with whatever you are given, and get the maximum out of that.

 

So this what MrDaaark said in his last sentence is a good working/learning paradigm in my opinion.




#5042084 DirectX 11 Rigging in Shader

Posted by Tasche on 11 March 2013 - 04:37 PM

i'm not sure this will help you, but i think this may be what you are looking for:

http://msdn.microsoft.com/en-us/library/windows/desktop/ff476523%28v=vs.85%29.aspx

 

i personally have a fixed maximum number of bones and use the constant buffer, and send the updated matrices by mapping that buffer. calculation of those matrices from quaternions is done on cpu, only the skinning itself (vertex transformations) is done on gpu, and stored in a dx buffer using stream output.




#5041763 Quick question on DEVICE_OMSETRENDERTARGETS_HAZARD

Posted by Tasche on 11 March 2013 - 03:04 AM

it is always best to have no warnings so just set the shader resources to zero (and bind then agian if needed) before switching render targets.

yes, though i've never ever seen it happen, some drivers supposedly treat these warnings as errors, so set to NULL. it's almost no performance cost if no actual memory is moved/mapped to cache during SetRenderTargets. also, PIX may act up if you have warnings in the code (provided you are using PIX).

 

EDIT: i usually only unbind the slots in question, not all of them, but it can be done in a single call, so unbinding more may be useful (e.g. you need them unbound later maybe). don't unbind them if not necessary, cause you might need them, binding is rather expensive. as always, do it correct first, then worry about doing it fast. smile.png




#5041471 Animation blending matrix math

Posted by Tasche on 10 March 2013 - 05:37 AM

if the angles are really really small, you might get away with it (actually pretty sure you will). nlerp is already approximating, so you want to minimize the error. if the angles for your source rotations are almost the same, you also won't notice any additional error. if they are too different, the blend will differ significantly from the expected animation. from personal experience i would say if the renormalization constants differ around 2-3% it already gets noticeable (like a slight awkward twist in a joint). just try it out, if your keyframes are tight enough, it should work out.

however i would suggest you go for normalizing in between, since the nlerp approximation only changes speeds, not angles or axis, unlike interpolating unnormalized quaternions. and a few square roots less are not worth getting crappy animations.

by the way, the problem multiplies the more animations you blend.

also, as a general rule of programming (imho), is get stuff working perfectly and as expected first, then optimize and judge the quality/speed tradeoff. especially for something so easily implemented.




#5040581 Attempting to create a pool allocator

Posted by Tasche on 07 March 2013 - 04:13 PM

I showed some c++ source code and they said that naming c++ class members with m_ is a bad habit from the C language. Just curious : )

read the posts on this stackoverflow page for a discussion:

http://stackoverflow.com/questions/1228161/why-use-prefixes-on-member-variables-in-c-classes

i personally go for Jason Williams approach, have yet to see the bad side of prefixing.




#5036041 Check My Normal Calculations functions? Please?

Posted by Tasche on 24 February 2013 - 03:55 AM

im a lazy guy, so i haven't read the entire code section, but if stuff turns up black when it shouldn't, go slow at first.

this means:

  • first, directly output all your inputs as color (in this case, esp. the normals) and check if they have sane values (represented as colors in the framebuffer) you might want to pack them before outputting them (something like (normal+1)/*0,5), so you get the full range.
  • after that, output every step of your lighting, and do a check if it is as expected
  • also, don't forget to check constants, that can mess up things too
  • have a very simple model handy for this, where results are easily predictable (i use cubes and spheres)

you can also always use something like nsight or so for error checking, but i got kinda used not to use those, because they don't like me and have more issues with my code than me (especially with stream output/transform feedback, they love failing on those).

 

hope this helps,

    tasche




#5035928 D3D11 Constant Buffer not being sent correctly!

Posted by Tasche on 23 February 2013 - 06:33 PM

didn't go through all the code... so this may not be applicable

  • this is HLSL code as far as i can tell... use fxc.exe  to test your shader code explicitly without having to feed it any info.at the top of the output it gives you info of what sizes the shader expects for all your constant buffers. fxc.exe is part of the directx sdk for windows 7 and below, and (afaik) part of the windows sdk as of windows 8.
  • make sure the sizes of your constant buffers in C++ match the sizes of the shaders'. easily done by making your struct mirror the cbuffer, and using sizeof() when mapping the memory.
  • make sure all your buffers are multiples of 16 (in bytes that is). i always found this restriction to be stupid, but probably has some performance reason.
  • make sure all buffers are actually created and mapped, send in dummy values if you have to.
  • make sure slot numbers are passed in correctly when calling the XXSetConstantBuffer() method, where XX is the appropriate shader stage.
  • make sure you set the buffers for the correct shader stage. (see your fxc output to find out what is expected where)

well this is a very general troubleshooting list, but running through these i usually solve all my constant buffer issues.

good luck,

   Tasche =)




#5029526 Data pair searchable structure

Posted by Tasche on 06 February 2013 - 03:02 PM

You could store all pairs ordered by min(A,B) and with every pair store a boolean that tells whether the values of that pair are reversed. That way you would not have to search twice for a read or write operation. Some variant of balanced binary search tree, like a red-black tree would be fine for this. In C++ std::map is implemented like that.

min() only works with an ordering relation. i basically used swiftcoder's solution, which uses a map Pair->Value (the hash function), then collapse the buckets into a list. seems to perform well, and i learned something (which, btw, is a key goal of this exercise). this solution is also nicely scalable with respect to the expected data (and its amount), since i get to choose the hash function. most of the time i have lots of elements in M, but only few pairs get generated. +1 for swiftcoder (not that he needs any rep :P)




#5019481 how to do a brightpass properly

Posted by Tasche on 09 January 2013 - 09:37 AM

okeys... got stuff working now, still looks kinda crappy :D

parameters used:
-gauss blur sigma: 0.84
-gauss blur domain: -3*sigma to 3*sigma; codomain normalized to sum = 1
-gauss kernel samples: 15 (on all targets)
-highpass filter funtion: inputColor-(0.5,0.5,0.5)
-target sizes: B0:512x256, B1: 256x128, B2: 128:64
-scene texture size: 1280x720
-combine blur targets function: blurAccum = B0+B1+B2
-combine bloomtexture with scene: finalColor = blurAccum*0.5+scene*0.5

i played with the values, but not too much (only thing that can be changed in runtime is sigma and domain range, rest is hardcoded atm)
esp. the combining of the blurs and the final add to the scene are probably really lame, but its just preliminary testing
if anyone knows any good values, or how to come up with those other than trial and error, or has anything else to add, feel free to post

EDIT: removed screenshots


#4866697 Terrain rendering using DirectX

Posted by Tasche on 28 September 2011 - 12:09 AM

16 bit indices should also have been a problem - he is using 6 indices for each quad. This means that it would be 200*200*6 = 240,000. Although I am sure that the stack overflow is caused by the problem you described...


but the maximum index value would still be 40k-something, since hes only got 40k vertices, and therefore fit into an unsigned short. if he wanted to use WORD for indexing into the index array he would have a problem, but that is only done by the GPU itself...
anyway, if your vertexarray has less than 2^16 entries (65k), WORD is a suitable index size, no matter how many indices are in the index buffer.
sorry for being a smartass :)

cheers,
tasche


#4861267 Terrain Stitching

Posted by Tasche on 13 September 2011 - 03:34 PM

using the 16 index buffer approach works pretty well, however i have still to figure out on how to do vertex morphing to hide the quite visible pops in my engine. if you go with this approach, and get vertex morphing done, write a tutorial fo me^^

cheers,
tasche


PARTNERS