TriencoMember Since 22 Aug 2001
Offline Last Active Dec 20 2013 11:18 PM
- Group Crossbones+
- Active Posts 2,339
- Profile Views 4,825
- Submitted Links 0
- Member Title Member
- Age 36 years old
- Birthday November 13, 1977
Posted by Trienco on 19 September 2012 - 10:24 PM
Considering that your binary will most likely be in POOA when you're done, you may want to change the debugger settings to use that as your working directory (something like $(ProjectDir)/..) and stick with "data/tiles.png" as your path.
Posted by Trienco on 12 September 2012 - 10:37 PM
This means the first three columns are basically the cameras x,y,z (typically "right", "up" and "forward") axes expressed in world coordinates with the last column being it's position. It's convenient and easy to read.
To use it as view matrix, you obviously need to move everything "the opposite way", so you need the inverse of your matrix. Since you didn't scale, your matrix can be inverted in a simple way. The rotation part is transposed (which explains why it's rows, not columns) and the translation is negated along the original axes (which is better explained by showing the result.
So if your camera matrix (using r,u,f,p as right, up, forward, position instead of uvn) is:
r.x u.x f.x p.x
r.y u.y f.y p.y
r.z u.z f.z p.z
0 0 0 1
Your view matrix will be (created from the camera matrix once per frame):
r.x r.y r.z -(p dot r)
u.x u.y u.z -(p dot u)
f.x f.y f.z -(p dot f)
0 0 0 1
So: keep your camera matrix around, don't recalculate from scratch every frame and for heavens sake, stay as far away from Euler angles as possible (ego shooter style camera is about the only thing they can handle without a lot of head ache).
I'm not sure why Kaptein makes rotating an object around itself so complicated. If you want the camera to rotate around itself, you use camera_matrix * rotation_matrix. If you want it to rotate around the origin you use rotation_matrix * camera_matrix (or the other way around). If you are in fact feeling lazy, you can abuse OpenGL to do the matrix math. Translation and rotation are always applied in object coordinates, so objects already rotate around themselves (using their current right/up/forward axes), no matter where they are and always translate along their local axes as well.
Point is: OpenGL is not doing anything "backwards" unless you insist on thinking in world coordinates instead of object coordinates.
-Strafe right is always glTranslate(1,0,0)
What people often do: calculating some "right" vector (instead of 1:1 extracting it from the objects transformation matrix) and then going to the trouble of translating along that vector in global coordinates by forcing things to be done "backwards".
-"Pitch around self" is always glRotate(angle, 1,0,0)
What people often do: calculate some "right" vector (again), then do stuff backwards (including translating stuff to the origin and back)
If you want to mix things, like rotate around "global up" but around your current position, you still don't need to start translating. You just need to adjust your axis by multiplying the "global" axis with the transposed rotation part of the object (basically you cancel out the existing rotations, so your objects "up" is the same as the worlds "up"):
To rotate around global (0,1,0):
axis.x = 0*r.x + 1*r.y + 0*r.z
axis.y = 0*u.x + 1*u.y + 0*u.z
axis.z = 0*f.x + 1*f.y + 0*f.z
ie: glRotate(angle, r.y, u.y, f.y)
Bottom line: think forward and think local, it will make things much easier and more intuitive
Posted by Trienco on 03 September 2012 - 10:27 PM
'and' is not a C++ keyword. If you have a macro named 'and' that is defined as '&&', get rid of it!
Actually it is and it is the same as &&. However, absolutely nobody uses it to the point where I didn't even know about it after almost 10 years of C++. Maybe it's because && is easier to type or simply because it sticks out a lot better than 'and'. Basically, use && and || instead of 'and' and 'or', unless you are extremely paranoid of accidentally using & and | instead.
Posted by Trienco on 30 August 2012 - 09:56 PM
The design doesn't really seem to try and separate game logic from display.
I'd also question if it makes any sense to have specific classes for stuff like a Warehouse or a HandTrolley. That would seem like the kind of stuff that is defined by data, not by class.
Posted by Trienco on 18 August 2012 - 07:04 AM
Daytime doesn't matter (sunlight doesn't change direction and is always straight down). Darkness (at night) isn't applied by updating and recalculating all sunlight values, but by simply deducting a darkness value from the existing sunlight value.
There is no easy way to recreate that system with basic 3D API functions and it only makes sense for a grid/block based world like Minecraft.
Posted by Trienco on 12 May 2012 - 12:34 AM
If that is the case, it might be time to google for the Rule of Three.
Did you place a breakpoint in the destructor and make sure it only gets called once? Debug output might actually work better, as some debuggers are notoriously bad with breakpoints in destructors.
If in doubt, place a breakpoint in the destructor of your Wall class and check the call stack when you hit it to see where it's getting called.
Things don't get magically deleted on their own. A more far fetched explanation would be writing out of bounds and screwing up the internal pointer of the vector.
Posted by Trienco on 03 May 2012 - 10:27 PM
Posted by Trienco on 01 May 2012 - 10:28 PM
Isnt it the job of #pragma once to stop multiple inclusions anyway (using VC2008)?
I strongly suggest to read Antheus post, because I really wish more people would actually care about how compiling and linking works.
#include doesn't mean "use this as a source to look up stuff". It means "recursively copy/paste the whole frigging thing and everything it includes". If in this whole mess of headers including headers including headers the same header appears twice, then and ONLY then pragma once or inclusion guards come into play.
Header files on their own are never compiled, so you can't have a project that is "header only". Nothing will really happen when compiling this.
Every .cpp file is compiled completely in isolation. It doesn't matter what might be in other files. Some compilers might make special exceptions for inline and template code, but you might notice that those are exactly the two things that should be entirely defined in header files, if you expect them to work.
After every .cpp file in your project has been compiled to an .obj file, the linker will try to piece them together and make the final binary (.dll, .exe). In THIS stage, you got your error about multiple definitions, long after anybody cares about headers or inclusions guards. All that matters is having the same definition in two different .obj files.
Posted by Trienco on 26 April 2012 - 01:14 PM
Ideally, you can replace your view of the game world without major rewrites (ie. replace 2d sprites with 3d models, a top-down view with a freely moveable camera, etc.). That means NOT saying "left moves the image" but saying "left changes the player position" and "when displaying the game state, place the image according to the players position".
Posted by Trienco on 21 April 2012 - 10:53 PM
And finally, one more thing that bothers me most. In the very first scenario I described in this thread, with the plane mesh filling the whole screen and taking 190ns to render, I noticed that depending on how close the camera was to the plane, the render time varied, despite the fact that the plane was the only geometry entity filling the whole screen. I noticed that the closer the camera was to the plane, the less time it took to render it. My times varied from 180ns (as close to the plane as possible without frustum near plane clipping) to 220 ns (as far as possible to still fit the entire plane on the screen).
Why is that a surprise? You sound like you somehow moved from thinking that only the number of polygons matters to thinking that only the number of pixels matters. You get closer to the plane, more geometry gets clipped, fewer triangles get rasterized -> less overhead. You are measuring ns. There are about a gazillion factors that come into play, many of them hidden from you by things the driver might be doing or just the way stuff happens in the hardware.
How are you even measuring the exact timing for vertex and pixel processing when these things should be processed in a pipeline on the hardware? If you have more than one triangle, it's not first going to process all vertices and then do all the pixels. One triangle is done and gets rasterized/shaded while at the same time the next triangle gets prepared. There are caches, the second time around a vertex might not even be processed anymore. Hardware today has unified shaders that can be dynamically used for either vertex or pixel processing, completely changing how long vertex and pixel processing will take.
There is little to no point to make ns measurements and expect any obvious and linear relationship between numbers. Not on modern hardware.
Posted by Trienco on 17 April 2012 - 10:26 PM
Over here, we pay a small fee on every blank medium (from printer paper to DVDs) than can be used to copy stuff. At a time they even tried introducing it for RAM, arguing that there are "temporary copies" created in RAM. In return we have the right to create "private copies" and distribute small numbers to friends (rule of thumb says around 7 and you must be familiar with the people you give them to).
Then the lobbying began to change copyright laws and just as Hodgman said, it was now illegal to copy anything with a copy protection (there was a wording about "effective copy protection" which I bet has been removed by now, because obviously if you can copy it anyway, it wasn't that "effective"). As a result, everything is copy protected, we still pay that fee for everything, but the "private copy" thing has become purely hypothetical.
In short: don't underestimate the amount of legal stuff companies and lawyers can throw at things. Even if they don't have a clue about the technology they will still try to drown in licenses, just to legally be on the safe side. Particularly if you use licensed art, expect them to enforce some way make it non-trivial to just extract and distribute it.
Posted by Trienco on 16 April 2012 - 09:47 PM
A concept you might want to look up is called Hysteresis (IF you really want to keep that approach).
Even if you add an area where the paddle doesn't move it won't look very natural to constantly stop-move-stop, because a real player estimates where the ball WILL be when it reaches him. AI can easily calculate that, add a random error and simply move to that position. To look more like a human player, the calculated position can be adjusted every once in a while as the ball gets closer and the random error gets smaller.
Posted by Trienco on 15 April 2012 - 10:23 PM
If your class is only showing up as a pointer or reference in some other header, do NOT include the entire class header and just forward declare. After a while it will be as natural as not putting 'using namespace' in header files and just type out the entire names.
Posted by Trienco on 14 April 2012 - 10:57 PM
The location of declaring choice is plain weird, declare them right before they are used for the first time and in their own line (and initialize... always). What if you fail to read because the user entered "slkjsfg"? Choice will still have some random value.
Don't use if/else chains when a switch is perfectly fine.
Put success _inside_ the loop, inizialize to true and avoid setting it in every single if block (removing the need to do something in a million places removes the possibility to forget it half the time).
Posted by Trienco on 14 April 2012 - 01:58 AM