Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 15 Dec 2001
Offline Last Active Oct 29 2014 06:14 AM

#4909991 What is shining?

Posted by phantom on 05 February 2012 - 06:53 PM

The explanations I read said it was due to particles in the vitreous humour of the eye.

Particles in the vitreous humour, imperfections in the lens of the eye or the camera, basically anything which can distort the flow of light; the pattern depends on the imperfection.

#4908750 Fixed function and Shaders

Posted by phantom on 02 February 2012 - 10:20 AM

The last hardware to have the Fixed Function Pipeline (FFP), as replaced by shaders, was the GeForce FX (aka GeForce Fail) which had a hybrid FFP/Shader setup internal. The ATI card of the same time, the R300 aka 9700, was totally shader driven and wiped the floor with the GFFX.

The R300 was released in 2002.
The FFP has been dead in hardware for nearly 10 years now.

Forget it.
Move on, you are already 10 years behind.

#4908354 State changes

Posted by phantom on 01 February 2012 - 06:30 AM

The GPU won't start doing work until you do a drawcall or a compute shader dispatch; everything else push data into a command queue on the CPU side.

By batching up all the state change information together and doing it in one go you can gain both data and instruction cache performance increases which can help performance; also it simply makes your code easier to understand and follow.

Basically you want to be setting up all your rendering information in advance and then blasting through the buffer in one go to set states and issue draw calls.

#4907987 If developers hate Boost, what do they use?

Posted by phantom on 31 January 2012 - 08:09 AM

It's not just about writing 'delete' somewhere; firstly there is a code mantaince issue of changing something and mistakes croping up.

Secondly if you are using shared_ptr as a replacement for delete then you are Doing It Wrong™ anyway; shared_ptr is for shared ownership and life time control of an object and only needs to be used when an object can be logically owned by multiple other objects and needs to go out of scope when all references to it are dropped. At which point you get into the area of thread safe reference counting of objects with shared ownership semantics which has just made life much harder and code more complex.
(They also allow you to route destruction via a specified function which can be very useful rather than having to make sure it happens by hand).

Circlar references are only a problem if you can't design software; if you are getting problems with passing shared_ptrs to everything then I think you need to go back and look at your design again because you are more than likely Doing It Wrong™ as it is illogical to have the lifetime of an object depend on another object which has its lifetime depend on the first object. Even using shared_ptr et al it is fine to pass around naked pointers to objects if you know your object lifetime semantics makes it safe.

In short; shared_ptr are good at what they do but they are not a catch all for all design problems (unique_ptr and others give difference usage semantics) nor do they remove the need for you, the programmer, to think about your design and object life times.

As for the 'fugly' arguement; C++ is hardly the most attractive of langauages however extended usage of things like this (more so when hidden behind typedefs) leads you to get use to it and removes that frankly dumb 'arguement'; I mean, hell, if you think shared_ptr<type> is ugly then you are going to hate the lambda syntax and avoiding that very powerful construct just because you think it looks 'fugly' makes you a fidiot :)

#4907400 Naming question: Geometry, Mesh or Model?

Posted by phantom on 29 January 2012 - 01:24 PM

Mesh and Model would be usable but for different meanings.

A Mesh is a collection of vertex information and indices which represents the object.
A Model is the union of (at least) Mesh and Material information.

An entity would then have-a model and it would provide it with any per-instance data such as position.

In short; your class is doing to much. Split it up, it should be focused on maintaining one responsibility, another class (such as 'model') can then act as a union of these responsibilities and represent then sanely in the system.

#4903260 Component Entity Model Message Passing in C++

Posted by phantom on 16 January 2012 - 09:46 AM

Thanks to the forums new post history ability I have restored the original post.

Please don't delete your post when people have replied to it.

#4894630 Do interviewers allow you to use a compiler to answer questions

Posted by phantom on 16 December 2011 - 04:10 PM

The first interview I had for a game company involved being sat down in front of a compute and implimenting five (simple) game play features using an existing framework and then went on to a 'chat' interview.

Last year when I had a few interviews however all the programming tests I had were either simple written ones (series of questions generally) or, in one case, a series of questions which were emailed to me and I had to complete at home and email the completed code back again.

(I had the string reversal twice in two days, which was useful as when asked to do ti the 2nd time I did it in a matter of moments ;) although I did mention after I'd done it that I'd had the same question the day before which caused amusement, heh)

#4894152 32 vs 64 bit

Posted by phantom on 15 December 2011 - 06:18 AM

* I hear that 64 bit can be slower for some reason, is this true?

Yes. For example, as pointers double in size you can get more cache misses with some data structures. Also the compiler may not be as well optimized for 64-bit instructions as 32-bit ones.

However they can also be quicker, as in 64-bit mode you get more registers too. The only way to be sure is to test it.

Compilers are also free to make more assumptions about the hardware; MSVC, for example, will use SSE2 instructions where it can beause all x64 processors support the instructions.

#4894151 32 vs 64 bit

Posted by phantom on 15 December 2011 - 06:15 AM

Indeed, unless you have made any assumptions about variable sizes then in many cases simply switching to x64 mode will Just Work.

About the only thing which will definitately change, going to x64 mode, is pointer sizes. Everything else depends on the platform you are using, which includes the compiler. For example, iirc, with MSVC 'int' stays 32bit and 'long' becomes 64bit. edit: apprently I did not recal correctly, see the post futher down :) (However I still wouldn't assume this to be the case and if I needed a precise/forced size then I'd either typedef my own types or use boost's sized types.)

#4893984 Writing a game engine

Posted by phantom on 14 December 2011 - 03:39 PM

That is not how things work around here; topics are only closed if they are judged to have violated rules or generally got out of control.

If you have no more questions simply stop posting however you do not own the thread nor do you decide when it 'closes'.

#4893967 Writing a game engine

Posted by phantom on 14 December 2011 - 03:00 PM

You can not, by definition, perfectly plan something you don't know how to do.

#4891665 Writing a game engine

Posted by phantom on 07 December 2011 - 06:54 PM

Here is my personal implimentation to stop this.


Trying to protect against user malice is wasted effort. Document clearly and when it blows up in their face point out the document which says clearly "do not do that shit you've just done!" and then get on with your life.
I swear more harm has been done to projects by trying to protect against people trying to do stupid things then happens when the same users ignore and do it anyway...

OP; you are in school. Finish the assignment to get your grade, worry about other stuff once that is done.

#4891241 [DX11] Fastest way to update a constant buffer per draw call

Posted by phantom on 06 December 2011 - 04:29 PM

Right, I see... well, what I said above still stands for most of your data, if you look at slides 30/31 you'll see they have a very small cbuffer for the per-draw call data so you might want to consider how much you place in it.

I suspect if you are moving around small enough buffers either option would be fine; we had a pure CPU limited rendering test at work which was drawing 50,000 cubes and, for each draw call, was doing a map/unmap for a cbuffer on mulitple contexts (6 iirc, there might have been one per context but don't quote me on that, its been a while since I played with that bit of the code). With that test we were good up until around 15,000 draw calls before the driver started to get into trouble internally with memory issues.

Do whatever makes organisation sense I guess...

#4890838 Casual vs Dress interview

Posted by phantom on 05 December 2011 - 03:34 PM


#4887036 Productive Hours

Posted by phantom on 23 November 2011 - 04:38 PM

Unless you have something which can disturb you then 'productive hours' are nothing more than a learned habit and purely psycological.

I'm most productive when I decided to be and do something to adjust my brain so that it is happy to do so; this basically involves putting on some music + headphones and sitting down to do something.

This too is nothing more than an associative trick; I code listening to music, thus when I list to music I'm transported into the correct mindset to code.

The music thing also works well at work as it cuts out distractions, invokes the same mental status change and makes it less likely people will bother you with idle talk when you've got things to do.