Okay, so right now, I have a piece of code in a no-name programming language that can project the 3D coordinates on to 2D screen.

It uses these following values:
ScreenSizeX - Integer
ScreenSizeY - Integer
Zoom - Float, Usually 0.
Perspective - Float, which is currently 256

The calculations go something like this:
ScreenX=ScreenSizeX+(VectorX*Perspective /(VectorZ+Zoom))
ScreenY=ScreenSizeY+(VectorY*Perspective /(VectorZ+Zoom))

Now I'm trying to figure out how to convert this to gluPerspective() which contain these values:
fovy, aspect, zNear, zFar

In which the input values look like this:
gluPerspective 45.0, 640/480, 0.1, 100.0

Please note that Perspective, and fovy are not the same values when it comes to getting the viewing perspective right.

So if "Perspective" = 256, what value would "fovy" be on the gluPerspective side?
And would it apply to the three other variables too?

I hope this question is understandable.

(Ive changed your quote to what ive read it as).
Im not sure myself, but this doesn't look right?

cxzuk

Yeah, it does look right.

So anyways, what I meant to say was, that I have a custom code(a simple) that will do with projecting 3D coordinates on to 2D screen.

Now when I use OpenGL, what related command like the "gluPerspective", will make the 3D scene projection look like with the values I use for my own custom projection code(Screen Width, Screen Height, Zoom, Perspective)?

If I can find something like this, I could save a lot of time from trying to write my own pseudo 3D engine without GL.

I apologize if I went a little bit off topic.

You can use glLoadMatrix() to load custom data

_________________
Long pork is people!

wzl's burrow

MrThat, can I ask why you want to do 3D without using GL?

I ask because I spent (i.e. wasted) a lot of time writing a 3D engine before moving to DirectX/OpenGL. If I had the time again, I'd go straight to a mature API and skip the year or so that I spent re-inventing the wheel while pulling my hair out trying to get perspective, texture mapping and z-buffers to work properly in my own engine.

Just trying to save you some pain.

_________________
10 PRINT "Bad Monkey ";
20 GOTO 10

I have to say that Codehead is right, because I spent some time writting a 3D engine a long time ago. I think that the problem is not the math, but the fact that you will write a abstract code, in other words, a code using a high level language, without hardware specifications, leaving the processing for the software instead for the graphic hardware. The result will be a slow 3D engine. The fact that DirectX and OpenGL can do it in a fast way is because the industry follows a standard of hardware architectures and these libraries(OpenGL and DirectX) are huge and adjusted for each specification.

_________________
"Life finds a way." - Ian Malcolm
My WebBlog: PixelDeveloper
English is not my native language, so excuse me for any writing mistakes.

I love to reinvent the wheel...

_________________
"Life finds a way." - Ian Malcolm
My WebBlog: PixelDeveloper
English is not my native language, so excuse me for any writing mistakes.

From a learning perspective, reinventing wheels is very useful, as you get good quality information what the solutions actually do, and where their weak spots are.

Just be sure to throw your code away when you want to do something "real" :D

_________________
My project: Messing about in FreeRCT, dev blog, and IRC #freerct at oftc.net

Unfortunately, I would have to re-invent the wheel when it comes to using a non-C related programming language that I know how to use a lot.

So anyways, as I already know how to project the 3D vector using the camera eye view.

All I need to know is, what do I do with the projected vector? Do I translate it or multiply it with the projection matrix that comes with OpenGL?

I'm pretty sure that there's one more calculated formula for it's final touch after this.
Will be looking into this. I can understand math code better than traditional math, so I apologize for that.