Jump to content

  • Log In with Google      Sign In   
  • Create Account

Brother Bob

Member Since 26 Nov 2001
Offline Last Active Yesterday, 08:40 PM

Posts I've Made

In Topic: random generators

Yesterday, 02:13 PM

You need an engine for every independent and deterministic stream of random numbers.


Say, for example, that you want enemies to appear randomly during the game but in a predictable way so that you can save the game and replay or continue to play with the same stream or enemies (not only for replay, but also to stop the player from reloading because the stream of enemies was not in favor of the player; reloading with a predictable state ensures the same stream of enemies in the future as well, so no use reloading to get an easier game).


You also want your power-ups to appear randomly, but for the same replay and reload purposes as with enemies, you want to ensure a predictable stream of random numbers. Let's say a new power-up is generated every time a power-up is picked up (the game contains, say, three of them at any time).


With a common engine in this case, enemies are generated based on if and when a power-up is picked up, and that breaks replayability and predictability. You need to decide if things such as replayability and predictability are important.

In Topic: Need help: a vector of different extended classes

Yesterday, 10:08 AM

Look up slicing; your vector stores Entity objects by value, so only the Entity part of your EntityArrow ends up in the vector. Your vectors has to store pointers and you need to allocate your Entity objects dynamically instead.

In Topic: glOrtho - a beginner question

Yesterday, 06:22 AM

gluLookAt does nothing more than apply an equivalent rotation and translation. If you can describe the orientation and location of the plane by some parameters to gluLookAt, then you're set.


For example, if the center of the plane is located at (px, py, pz) with a normal pointing towards the direction (nx, ny, nz), then you should be able to locate the view point with something like gluLookAt(px, py, pz, px+nx, py+ny, pz+nz, ux, uy, uz) where the vector (ux,uy,uz) orients the plane (you may want to orient the up vector along, for example, the point X3-X1).


The orthographic projection is then set up with width and height corresponding to the distance between X1 and X2, and X1 and X3, respectively. Make the projection symmetric if the point (px, py, pz) is at the center of the plane.


You can also replace the call to gluLookAt with the equivalent rotation and translation yourself if you know your linear algebra. The vector X=(X2-X1), Y=(X3-X1) and Z=X cross Y, or some variant thereof, defines the coordinate system as seen from the projection plane. A translation to shift by (px, py, pz) the coordinate system is also necessary.

In Topic: Function Pointers in Structs

11 March 2014 - 10:49 AM

Some obvious drawback are:

  1. The object has to physically contain a pointer for every "member function" you want to use.
  2. The syntax is worse in the sense that you have to provide the object twice: once to obtain the function pointer and once to pass it to the function. In C++, for example, the hidden this-parameter is implied from the syntax you use to call the member function on and you only mention the object once.
  3. No way to force the two objects to be the same. Nothing stops you from doing test1.get_a(&test2).

Don't fool yourself that it's more OO because you have an object on the left hand side of a period and a function on the right hand side; OO is just as fine with the object as a parameter instead. It's about how you design your objects and functions to operate on them, not about what syntax you use to call a function.


One benefit of storing a function pointer is to get runtime-dynamic behavior. For example, as Olof said, it is a similar approach to how virtual functions are typically implemented. For compile-time behavior, there's no reason to store the function pointers.

In Topic: Matrix Stack & New OpenGL Standards

06 March 2014 - 02:58 AM

If you are worried about losing the matrix functions in the new versions, then you are also losing display lists and immediate mode rendering at the same time. Vertex arrays and shaders are the only way forward in the new versions. Also, this is not really new. The new API which dropped all the old stuff was released nearly six years ago.


Moving the thread from coding horrors as well, this is clearly and OpenGL topic.