0
101 Dec 31, 2013 at 09:02

@stainless: i meant ‘2 years’ as a good thing.
I’ll be using directx (everything i listed in the original post).
Thanks

In response to reply on OpenGL matrix
1
167 Dec 31, 2013 at 06:39

OK, if you want to look up/down then you’ll need the pseudo-pitch I mentioned.

When you construct your view matrix for a normal camera, you’d usually do it by combining some rotations for yaw and pitch (and maybe roll). The shear matrix I’m talking about would replace the pitch rotation.

If your camera starts out in standard position, facing along the -Z axis, you’d normally do a X-rotation to pitch it. Instead, you’re going to do a YZ shear, meaning there will be an offset along the Y axis proportional to position along the Z axis. The matrix for it will go like:

        [1 0 0]
[x y z] [0 1 0] = [x y+az z]
[0 a 1]


The value ‘a’ there is the shear amount, which is equal to the tangent of the pitch angle. The matrix above is written for row-vector math; transpose it if you’re using column vectors in your app. Move the ‘a’ to a different component of the matrix if you need to shear along different axes.

In response to reply on OpenGL matrix
0
109 Dec 31, 2013 at 05:32

That’s exactly what I did Reed, but the problem is, I don’t want to only display my model horizontally. For example, my camera is on a street at human height over the street, looking at high buildings. I want to look up a bit but I want the verticals to stay verticals. The same with Ortho projection, you can still look up/down, rotate etc. and the verticals still stay verticals except there is no depth. So I’m trying to build a matrix that will do kind of like ortho except with depth. Do I make sense?

In response to reply on OpenGL matrix
1
167 Dec 31, 2013 at 03:49

You’re making it way more complicated than it needs to be. Just get a regular camera view and projection matrix working for your raytracer. You can look up the docs for glOrtho, glFrustum, and gluPerspective and they give you the exact formulas for the matrices. So just use those and get regular cameras working.

Then, for two-point perspective just use a regular camera with no pitch or roll, just yaw, so it stays horizontal. That’s all there is to it. Forget the idea of an extra “two-point matrix”. There’s no such thing. It’s just the regular view and projection matrix, with the camera horizontal.

(Optionally add back in a pseudo-pitch by shearing the camera up and down instead of rotating it. This is the only part that would be different from a standard camera matrix stack.)

In response to reply on GLSL and different GPUs
0
167 Dec 31, 2013 at 03:45

I’m not sure what you’re looking for then. Obviously for the things that differ between GLSL versions you’re going to have to have multiple versions of the code somewhere, somehow. Nothing can save you from that.

The best you can do is segregate all the platform-specific stuff, so its impact is limited and you can write the rest of your shaders to a platform-independent API as much as possible. Whether you do it with the C preprocessor, or some preprocessor of your own, is just an implementation detail.

In response to reply on OpenGL matrix
0
109 Dec 31, 2013 at 00:47

I finally got the Ortho to work in OpenGL without using glOrtho. thanks for the links.

For the two-point perspective, I have found lots of documentation, but I just can’t get it to work in OpenGL. I am not understanding it or I’m not using it right. What I want to do is use it with glLoadMatrixf after using glMatrixMode(GL_PROJECTION); or glMatrixMode(GL_MODELVIEW); and I don’t know which of the two to use, but I assume it’s the model view matrix. Also, do I have to build the normal view matrix first then multiply it with the two-point matrix? I’m lost!!!

In response to reply on OpenGL matrix
0
151 Dec 31, 2013 at 00:32

Then you are not zooming the camera, you are moving it.

For ortho you have, well google.

http://en.wikipedia.org/wiki/Orthographic_projection_(geometry)

For parallel you have

0
117 Dec 31, 2013 at 00:28

Yes, several. I won’t give a list - rather than that I’ll describe my newest (work-in-progress one).

Creating core functionality took around a week (part time work). Adding further stuff - 6 months of part-time work so far, and it will take more. Don’t be scared by the number, it has really a ton of features, naming few of them: - Cloth physics; Ray tracing reflections (through custom OpenCL ray tracer); Custom full-featured GUI; etc.

Implementing each feature takes time, it’s up to you whether you need it for a game (or software) or don’t.

I’ve used some libraries so far - namely Alure, Open Dynamics Engine - apart from them I also use standard and platform libraries.

0
151 Dec 31, 2013 at 00:27

True, but you asked how long till it was “useable”

A 3D engine is never finished, you can always add features until you die

In response to reply on GLSL and different GPUs
0
117 Dec 30, 2013 at 18:10

Yeah, well in the end thats similar system to what I have now (I decide upon GLSL version that hardware has, of course in case of some really complex shaders some hardware might not compile it -> lower-glsl version is supplied).

Still they have to (as do I) to write multiple versions of shaders.

In response to reply on GLSL and different GPUs
0
117 Dec 30, 2013 at 18:02

Yup, I know I could use pre-processor, thanks for mentioning it. Although we basically handle the same thing by loading different shaders (they are at different locations -> example -> data/shaders/v330/ vs. data/shaders/v420/ … this way in case some shader compilation fails, the system tries to use one with older version).

We also wanted to avoid preprocessor directives in shaders, as we use somehow modified GLSL that is already pre-processed by our preprocessor (F.e. we have all shaders inside single file).

0
101 Dec 30, 2013 at 17:27

That’s less than 2 years

In response to OpenGL matrix
0
109 Dec 30, 2013 at 16:04

It’s not for a game but for my raytracer!

My zoom is done by moving the camera forward/back.

I do not use gluPerspective, glOrtho or gluLookAt. I’m trying to make my own matrices for them, which I did for the normal Projection and View matrices, but I’m having problem for Ortho and Parallel projection.

0
151 Dec 30, 2013 at 14:01

For me, I have written many 3D engines.

Probably easiest to list by machine if I can get this awful formatting system to do what I want….

C64 3 months 6502

Atari ST 4 months 68000

Amiga 2 days (ported from ST) 68000

PC (CGA) 3 weeks 8086

PC (VGA) 3 weeks 8086

OpenGL (no shaders) 3 weeks C++

OpenGL (with shaders) 2 months C++

OpenGLES (no shaders) 2 days C++

OpenGLES (with shaders) 2 weeks C++

XNA 1 month C#

I never use libraries, usually because of license or stability issues

In response to GLSL and different GPUs
1
151 Dec 30, 2013 at 11:28

A lot of commercial games use a shader bank.

They all call it different things, but in general they create a few flags to cover everything they need to know about the client platform. Things like if the device supports context less surfaces, how many instructions per shader, etc.

In response to reply on OpenGL matrix
0
151 Dec 30, 2013 at 11:22

So you don’t want to pitch the camera up and down? You want the camera to rise and fall instead?

Zoom is easy, just increase or decrease the field of view Rotating around the vertical is easy, take a forward vector and rotate it by the current heading

Then just create a look at matrix from the camera position towards the rotated forward vector. Create a perspective matrix with the desired field of view and you are away.

When you have it working, a neat trick is to zoom in and move the camera at the same time to get the famous horror movie camera trick.

In response to OpenGL matrix
0
109 Dec 30, 2013 at 04:28

Yes, but I do want to rotate, pan and zoom, just like in ortho view!

In response to reply on OpenGL matrix
0
167 Dec 30, 2013 at 04:12

It’s not something you do with a matrix. That’s down to the controls. You just don’t let the user tilt it up or down.

In response to OpenGL matrix
0
109 Dec 30, 2013 at 03:35

So how do you set such matrix to keep the camera horizontal?

In response to OpenGL matrix
1
167 Dec 30, 2013 at 03:03

I think I remember a StackOverflow question about this once. IIRC, two-point perspective is just regular pinhole perspective where you’re looking at a scene that has lots of vertical lines (like buildings, fence posts, etc), and you keep the camera horizontal, not tilting it up and down. That way vertical lines in the scene are guaranteed to be mapped to vertical lines on screen.

(You can actually still get a form of vertical camera motion by shearing the frustum up and down rather than tilting - since it keeps vertical lines vertical that way.)

The matrix for it would be the same as the regular perspective projection, since it’s just a restriction that the camera be horizontal.

In response to GLSL and different GPUs
2
167 Dec 29, 2013 at 19:54

A common trick is to hide away the version-specific stuff using macros or wrapper functions, like

#if __VERSION__ < 400
vec4 Foo(vec4 bar) { /* GL 3.x implementation */ }
#else
vec4 Foo(vec4 bar) { /* GL 4.x implementation */ }
#endif


When you compile the shader, since multiple source strings can be put in, you can put the #version directive in the first string and the rest of the source in another string. Select the correct #version for the platform you’re running on, and the preprocessor does the rest.

At my last job we used this to hide differences between HLSL and PSSL (the PS4 shading language), so we could write shaders to work in either one. It worked reasonably well.

0
102 Dec 29, 2013 at 18:03

This is how I made the integrated help system in GamePascal.

In response to reply on a new programming style
0
151 Dec 28, 2013 at 08:43

A MOB is just a Moveable Object Block, what most people now would call sprites I guess.

It was used in MOS Technology’s graphics chip literature (data sheets, etc.) However, Commodore, the main user of MOS chips and the owner of MOS for most of the chip maker’s lifetime, applied the common term “sprite”, except for the Amiga line of home computers, where MOB was the preferred term.

In response to reply on a new programming style
0
104 Dec 27, 2013 at 15:06

hmmm, well, a mob might be better, but what are they exactly?

1
102 Dec 27, 2013 at 02:05

I may use something called Jmonkey. It seems to have what I want, plus it’s commands are easier to follow.

@Override public void requestClose(boolean esc) { if (!esc){ System.out.println(“The game was quit.”); }else{ System.out.println(“Player has Collided. Final Score is “ + Score); } context.destroy(false); }”

Welcome to DevMaster, a community-driven game development website of posts and resources!

indie × 5
ios × 3
android × 3
algorithm × 1
effects × 1
physics × 1
iphone × 1
c# × 1
mobile × 1
native × 1
macos × 1
sound × 1
music × 1
networking × 1
testing × 1
multiplayer × 1
3d-engine × 1