Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Member Since 29 Jun 2004
Offline Last Active Today, 04:37 AM

#5000940 Naughty Dog Company Profile

Posted by Rattenhirn on 14 November 2012 - 09:56 AM

I think your best (and pretty much only) bet is to get in contact with Naughty Dog Inc.:

#5000937 Virtual still the bad way ?

Posted by Rattenhirn on 14 November 2012 - 09:53 AM

My question is quite simple : Is virtual still bad on both console ?

The answer is really quite simple, independent of the platform:
If you do not need the decision at runtime, you do not need virtual or other decision structures and their performance cost and vice versa.

#4999857 Switch vs if else

Posted by Rattenhirn on 11 November 2012 - 03:49 AM

All other things being equal, switch expresses your intent more clearly. While it may not matter to the compiler, it will matter to readers of your code including your future self. Having a bunch of else ifs will force them to examine the whole construct in detail to hunt down the reason, why it is not a simple switch/case.

So, in short, prefer switch/case over else/ifs.

#4989494 Thread safe array

Posted by Rattenhirn on 12 October 2012 - 09:17 AM

It's very tough to build data structures that are thread safe in every conceivable use case and allow a wide variety of functionality.

If you really need to iterate over the array data, while other threads might be modifying it, then you have two options:
First, like you already said, make a copy and iterate over that. This won't work in all cases though, just imagine an array that stores pointers or references to objects. Those might not be valid anymore. Actually this is also an issue with all the methods that return elements of the array.

Secondly, acquire the array lock from the outside, iterate, release the lock. This works in any case, but requires the users of that array to know what they are doing...

#4989488 What Are a Game Designer Job Requirements?

Posted by Rattenhirn on 12 October 2012 - 09:02 AM


#4989394 Rock Band 3 piano support

Posted by Rattenhirn on 12 October 2012 - 02:48 AM

You can use all XBox peripherals on Windows, when you get one of these:

Then DirectInput / XInput, or whatever it's called now should give you access like to any other controller.

In addition, if I remember correctly, some game instruments have Midi output (the latest GH drum kit, the RB Fender guitar and very likely the keyboard), so you can go that route, which would automatically add support for _all_ midi based instruments.

Lastly, why wouldn it be legal to make a game that uses a rock band peripheral? In fact, on XBox you can play pretty much every game with those instruments, it's just not very pleasant. ;)

#4976726 Why even use virtual functions in a Parent class?

Posted by Rattenhirn on 05 September 2012 - 01:12 AM

What difference does the virtual function declaration in the Automobile class make? Couldn't I skip the declaration in automobile function since it is really not even a function (it does nothing) and just declare the function as normal in the Ferrari class? and if i made more child classes of the parent class Automobile, i could do the same?

Well, you could've just tried it out!

Anyway, here's the solution:
If you do not have a "drivespeed" function in "Automobile", your main would not compile.
If you'd make it not virtual, then your main would call the "drivespeed" function of the "Automobile" class and not of "Ferrari".
And that's exactly what polymorphism is. You can use a pointer to the base class to call a virtual function and it will automatically call the function implementation that matches the actual class.

Additionally, you state that the "drivespeed" function doesn't really make sense, because the speed of an "Automobile" is unknown. This can also be expressed in C++ by making the function "pure virtual".

That would look like this:
class Automobile
       virtual void drivespeed() = 0; // no implementation needed here

And lastly, the purpose of inheritance is not to avoid code duplication, but to semantically link classes with similar functionality.

I hope that helps!

#4975396 Anti-aliasing like Clear Type

Posted by Rattenhirn on 01 September 2012 - 05:18 AM

Two things:

1) Since this technique is a trade off, it only looks acceptable in certain situation. The most prominent is high contrast with sharp details (like black text on white background). In many other situations it would make matters worse, so the shader would have to be very very smart.

2) The technique is extensively covered by patents, which Microsoft owns.

So, in conclusion, you'd have to write a very sophisticated and expensive shader to gain minimal improvements on certain image areas, while trying to move around the parts covered by patents. Doesn't sound very nice to me! ;)

#4963072 FXAA, why not use Depth

Posted by Rattenhirn on 25 July 2012 - 03:37 PM

There are AA alorithms out there that use depth. But the big seller for FXAA is, that it only needs the backbuffer as input and does everything in one fairly simple pass. It's simple to integrate and fast to boot.

It can also smoothe edges with no depth information, for example reflections or refractions, as well as edges created by post processing.

In my experience, purely image based algorithms don't get signigicantly better than that.

#4953987 std::vector vs std::unique_ptr

Posted by Rattenhirn on 29 June 2012 - 09:50 AM

Please explain in what way it is misleading? std::vector is used to manage vectors. std::unique_ptr is used to manage pointers to objects or vectors. So it is rather obvious what I was asking for, isn't it?

The title of this thread is "std::vector vs std::unique_ptr". I'm pretty sure most people started to read it, because they were wondering how one could possibly meaningfully compare those two and not because they want to discuss vector vs. array, which has been discussed to death already.

I don't understand this. A vector is a one dimensional array. So for the one dimensional case, there are no differences by definition.

In your original post you asked "What are the general guidelines here?" for "std::vector vs std::unique_ptr" (to a T[]).
I gave you a general guideline, that is very simple and very effective.

If you look at vector vs. array from the perspective, that both of them store a sequence of values in a continuous chunk of memory, then yes, there is no difference. However, there are differences between "std::vector vs std::unique_ptr" (to a T[]), which is, if I understood you at all, what you asked for. And the answer is that vector is preferable in pretty much every case, because it offers more functionality and safer interface, at the cost of approximately 2 extra pointers.

If you're so starved on memory, that you can't afford those 2 extra pointers, you'll need to stay away from allocations on the free-store anyways, so unique_ptr to a T[] is no help either.

I hope that clarifies things!

#4953646 std::vector vs std::unique_ptr

Posted by Rattenhirn on 28 June 2012 - 06:51 AM

First of all, the title of this message is very misleading.

What you actually want to know is the difference between an array which life time is managed with unique_ptr vs. std::vector.

Fortunately there is a good general guideline:
Use std::vector!

If you need to know why, please search for some of the discussion about arrays vs. vector and remove all arguments against arrays that concern lifetime management of the array's memory.

#4953569 HTML5 Game Development?

Posted by Rattenhirn on 28 June 2012 - 12:53 AM

If you want client side interactivity with HTML, you're gonna need JavaScript. If you can do everything on the server side, you can use pretty much any programming language out there.

#4941892 Get Pitch, Yall and Roll from matRotation

Posted by Rattenhirn on 21 May 2012 - 05:59 AM

I see some issues stated about converting matrix to Euler, I want to guarantee that I will receive VALID values and EXACTLY the same rotation values from a D3DXMATRIX every time I convert D3DXMATRIX to Euler without any problem, is that possible?

Barring rounding errors, you'll get the exact same rotation in euler angles. However, euler angles do not represent orientations uniquely, meaning there's more than one set of euler angles for any given orientation.

Of course, as long you'll use the same algorithm for conversion, matrix M will always give the same angles X, Y and Z. But, for instance, if your rotate M by 45 degrees around the Y axis, you won't necessarily get X, Y+45 and Z. Just another set of angles that represent that orientation.

So, if you want to keep the exact euler values, e.g. as entered, you have to save them...

#4939334 Class Function Overloading Method Question

Posted by Rattenhirn on 11 May 2012 - 10:08 AM

Check out the LSP, which is generally regarded a very good practice in OOP:

Relying on the "smarts" of users is a very error prone approach.

Why make add an extra parameter to Draw, if all that does is modifying the state of the object anyways? It's more intuitive, if "Draw" would always draw the object, and if you want it at another place, call "SetModelPosition".

#4937760 pointer behaviour

Posted by Rattenhirn on 06 May 2012 - 07:19 AM

If you delete an object, not all pointers to it are automatically set to 0. This would be very convenient, but that's not how it works.

The simplest, but also pretty dangerous solution would be to manually set every reference to the deleted object to 0 manually.

Alternatively, you can add another layer of abstraction, i.e. a "shared_ptr". This would ensure, that as long as something is pointing to the object, it does not get deleted. This is probably not what you want, but there's also a standard solution for that. For references that should not keep the object alive, use "weak_ptr".

Here's a quick tutorial that google spat out after a quick search:

I hope that helps!