Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 07 Mar 2002
Online Last Active Today, 03:01 PM

#5132361 Need algorith to rotate isometric image sprite !

Posted by Álvaro on 18 February 2014 - 10:36 AM

You think you can take a 2D rendering of a 3D figure and compute a rendering from a different camera angle? How do you think that would work? Do you at least have depth information in the original image?

#5132329 Just another thought (designing a fast but powerful language)

Posted by Álvaro on 18 February 2014 - 08:04 AM

Well, if we define a stupid metric, we'll get stupid code:

bool any(vector<bool> const&v){return find(v.begin(),v.end(),1)!=v.end();}

#5132210 Struct Inheritance in C

Posted by Álvaro on 17 February 2014 - 09:00 PM

What you have done is called "composition", not "inheritance". The good news is that composition is the right tool to use more often than inheritance.

The pointer cast is what makes inheritance look like inheritance: Some other part of the code can take a pointer to an Employee and do something with it, and if instead of giving it a pointer to an Employee you give it a pointer to a Manager (after casting), it would work just fine.

However, the main reason to use inheritance is not to build neat little hierarchies the way most OOP texts seem to suggest: The main reason is polymorphism, which means you can call a function that takes a pointer to Employee as an argument, and it might do something different depending on the specific type of employee that was passed. In C you would achieve this by making `Employee' have a function pointer as part of its data, so each derived type can provide an appropriate function to call there. (The mechanism that C++ uses is not exactly this; C++ compilers typically use a vtable instead (look it up).)

#5132204 Just another thought (designing a fast but powerful language)

Posted by Álvaro on 17 February 2014 - 08:20 PM

Yes. I am sure proponents of go and D would claim their language fits the bill.

#5131974 A* Bad heuristic (zigzag)

Posted by Álvaro on 17 February 2014 - 05:15 AM

As a very general rule, the heuristic is not to blame for bad quality of the results (as long as it's admissible). If your algorithm is picking a result you don't like among many possible results with the same cost, it means your cost function doesn't accurately reflect your preferences.

#5131971 per thread statics

Posted by Álvaro on 17 February 2014 - 04:45 AM

Option number 2 is indeed better, as long as you know how many max threads there are, and you can give them all an index from 0 to max-1.

The first method is handy if you don't know how many threads will be running, or if you can't index them... But the magic behind he scenes to make it work is quite complicated (extremely slow & complicated on some non-x86 CPUs)

Careful! Option number 2 can be a performance disaster if those variables are updated often. Since the elements of the array are tightly packed, they are likely to live on the same cache line, which means that the synchronization between threads can get very expensive quickly. I have seen this problem slow down a multi-threaded chess program to a crawl, because someone put the counters of nodes visited (updated millions of times per second by each thread) in an array indexed by thread, similarly to option 2.

You should have per-thread data living in separate cache lines. Whoever provides your thread library also provides a mechanism to create thread-local storage, and that mechanism should take care of this low-level issue for you.

#5131901 Where do I go next?

Posted by Álvaro on 16 February 2014 - 08:54 PM

Make something! A beginners' book is a good way to get you off the ground, but now you'll learn much more by doing. If you need ideas for projects, tell us what you have already made and what kinds of things you are interested in.

#5131867 Different fibonacci function

Posted by Álvaro on 16 February 2014 - 06:37 PM

That code is kind of awful, sorry to be so blunt. Can you please describe what the function is supposed to do? It's not completely obvious from the prototype that there should be any global state (`static unsigned i') at all.

#5131212 Different fibonacci function

Posted by Álvaro on 14 February 2014 - 01:36 AM

What is the "usual" way to do recursion in fibonacci? With or without memoization?

I am not sure. I hope they do talk about memoization. But then again, wouldn't it be more natural to introduce recursion with a problem that is naturally recursive, and leave memoization for a later lecture?

I knew how to compute Fibonacci numbers way before I knew what recursion was. If you are going to introduce a technique, it is good to motivate the need for it with an example where it helps you solve new problems.

#5131179 Different fibonacci function

Posted by Álvaro on 13 February 2014 - 09:30 PM

Has anyone ever actually used the Fibonacci sequence for anything game related? The only times I've ever had to use it is for programming tests/interviews.

The worst part is that, the way it's usually introduced, Fibonacci is a horrible example of recursive function. The natural place to use recursion is in depth-first search, which is tremendously useful in a variety of situations. IDA* and alpha-beta search are good examples of depth-first algorithms that can be used in games.

#5131024 FPS Camera calculations problem

Posted by Álvaro on 13 February 2014 - 06:52 AM

viewMatrix = {
xAxis.x, yAxis.y, zAxis.x, 0,
xAxis.y, yAxis.y, zAxis.y, 0,
xAxis.z, yAxis.y, zAxis.z, 0,
-dot(xAxis, eye), -dot(yAxis, eye), -dot(zAxis, eye), 1

#5130861 Calling a virtual function, illegal call of non-static member function?

Posted by Álvaro on 12 February 2014 - 12:44 PM

You can't call a member function from a static function, because the member function needs an instance on which to be called. I don't understand the rest of your post.

#5130823 how alive is oop?

Posted by Álvaro on 12 February 2014 - 09:37 AM

I don't think these trends change much in the timescale of a couple of years.
I use objects all the time, but my programming is in no way "oriented" towards objects. Objects are just a tool, and a pretty useful one because it emphasizes interfaces between parts of the code, which allows large systems to be built without getting overwhelmed by complexity. But to me "Object Oriented Programming" is a bit like "Nail Oriented Roofing".
Even if you think of your programming as "procedural" and "modular", chances are you'll end up using objects naturally. For instance, if you have a type `Image', it is very likely you'll end up having a module that implements functions that operate on Image variables.
In C, the header file would look something like this:
/* ... */
typedef struct {
  unsigned char R, G, B, A;
} Color;
typedef struct {
  unsigned width, height;
  Color *pixel_data;
} Image;
/* Create a new image, allocating memory for its pixel data. */
void create_image(Image *image, unsigned width, unsigned height);
/* Clear an image by setting every pixel to the given color */
void clear_image(Image *image, Color color);
void set_pixel(Image *image, int x, int y, Color color);
Color get_pixel(Image const *image, int x, int y);
void bit_blit(Image *destination, Image const *source, int left_x, int top_y);
/* ... */
I made the switch from C to C++ in 2001. Before then, my C code often looked a lot like this example. If you find yourself writing code in this style, you too are using objects. What are called "member functions" in C++ are essentially the functions that take a first argument of type `Image *'. When it has type `Image const *', it is called a "constant member function". In C++ instead of `set_pixel(&my_image, x, y, my_color);' you would call the member function as `my_image->set_pixel(x, y, my_color);'.
Once you get used to using objects, a lot of your code will naturally be organized this way. However, there are things that in my mind don't fit this model at all. For instance, mathematical functions like `log' don't naturally take a first argument that is a pointer to anything, so it's better to use a free function (i.e., a non-member function) in this case.
A project can be anywhere in the spectrum between not using objects at all and the extreme of organizing all the code as objects. All the projects I have worked on are somewhere in the middle, with lower-level parts of the code using objects only sporadically and higher-level parts being closer to the OOP extreme.
There are good reasons why you may not want to use OOP when dealing with low-level code. For instance, modern hardware is very good at operating on batches of data, either through SIMD instructions or using GPUs. An programmer using OOP in a straight-forward manner can easily write code that does things on a large collection of objects one object at a time, perhaps calling a virtual function on each object (similar to calling a function pointer that is part of the type, in non-OOP terms). That eliminates any possibility of using an SIMD implementation, and therefore results in code that doesn't make optimal use of the computational resources available. An alternative design would have separate arrays for each specific type of object, so instead of calling a virtual function on each object, you can call a function that performs a fixed operation on a collection of objects, and then a SIMD implementation becomes possible. Check out this thread: http://www.gamedev.net/topic/575076-what-is-data-oriented-programming/

#5130578 is this linear?

Posted by Álvaro on 11 February 2014 - 12:18 PM

I do not understand this thing with tangent



Here's how you can rasterize a sphere:

 * Among the lines that pass through the camera and are contained in a plane that contains the center of the sphere and the vertical direction, select the two that are tangent to the sphere. Use them to compute the top row and the bottom row of the rasterization.

 * For each row between those two:

   * Among the horizontal lines that pass through the camera and are contained in a plane that contains the row we are rasterizing, select the two that are tangent to the sphere. Use them to compute the left end and the right end of the scanline.


The steps of computing the tangent lines can be reduced to solving a quadratic equation, so you'll have to use a square root. Unless you can come up with a Bressenham-style algorithm, which is perhaps possible.


I haven't thought about how to compute the depth of each pixel. Computing a square root might be unavoidable, but you can always come up with some approximation that is good enough for this purpose.

#5130555 is this linear?

Posted by Álvaro on 11 February 2014 - 10:09 AM

Well, you could compute the leftmost and rightmost tangent to the sphere contained in the plane determined by the camera and the scanline. You might be able to reduce that to a Bressenham-style algorithm, but even if you have to take one square root per scanline it should be fast enough.