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!


Member Since 15 Dec 2001
Online Last Active Today, 04:30 PM

#4913756 How to access the vertex and indices buffer data in graphic memory card?

Posted by phantom on 16 February 2012 - 03:41 PM

My first question would be; why do you want to?

If you have filled the buffer already you should have the data laying around after all...

#4913656 Annoying Visual C++ Linker Errors (not from missing libs)!

Posted by phantom on 16 February 2012 - 07:53 AM

Yes, it is because of the template; you can not declare a templated class or function in a header and then define it in a .cpp file.

The whole templated class, declarations and definitions, must be avalible when being used in a translation unit.

Typically this means that you'll either write the whole thing in the header file, or declare in a header file, define in another file (typically with a .inl extension) and then include that file at the end of the header file.

In your project itself you'll include the header file and that is all. You do not have a .cpp file for the definition of the functions.

#4911391 Compressed sound, what format to use?

Posted by phantom on 09 February 2012 - 12:20 PM

I don't think block and chunk are the same thing, if you follow the link to the WAVEFORMATEX structure details and then onto the MSDN page you'll find the following;

Block alignment, in bytes. The block alignment is the minimum atomic unit of data for the wFormatTag format type. If wFormatTag is WAVE_FORMAT_PCM, nBlockAlign must equal (nChannels × wBitsPerSample) / 8. For non-PCM formats, this member must be computed according to the manufacturer's specification of the format tag.

So for a 16bit stereo sample you get (2 x 16) / 8 or 4 bytes per sample.

A 'chunk' on the other hand looks to be header + audio data, which will of course be larger than 4 bytes ;)

#4911114 Custom Model Plug-Ins

Posted by phantom on 08 February 2012 - 05:16 PM

Currently using the following setup:

Source format: FBX
Converted to 3 file types;
.vb => binary dump of vertex data
.ib => binary dump of index data
.mat => material information file

Later is effectively a shader type/id + surface details and includes start and end indices to draw for that material from the model data. A material file can hold more than one piece of material information.

.vb and .ib files are loaded directly into vertex and index buffers; mat file will have minimal processing to hook things together.

#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.