Submit
In response to I love asm...
545a4a0985e6053873a2500bd757fd1b
0
robirt 101 Jul 22, 2003 at 00:14

What is a good book or Online resource for learning ASM??

In response to Looking for help
065f0635a4c94d685583c20132a4559d
0
Ed_Mack 101 Jul 21, 2003 at 23:20

Here’s something I have lying around. I made it on Linux, hence the funny end of lines and the makefile. But, it’s SDL + OpenGL so you should be able to compile it ok.

It opens up hut.3DS and displays it in iso (although I’m not using orthgonic projection, as I hate not having some perseptive), it’s iso angle anyway :)

Download my zip here:

http://www.koyote.dk/other_files/iso_max.zip

This isn’t the best code, it’s just my first attempt, but it works and is quite well contained to separate files. I have one recursive function that does all the parsing, but I only grab the face and vertex data, nothing else! But the following links show you how to grab the rest.

I’ll be changing hosts soon, so download it :)

Here’s sources of info so you can learn these things:

http://www.xbdev.net/3dformats/3ds/3ds.php - very good

http://www.the-labs.com/Blender/3DS-details.html - basic format

http://gametutorials.com/Tutorials/OpenGL/…/OpenGL_Pg4.htm - Many brilliant loaders source code

http://www.cevis.uni-bremen.de/\~uwe/opengl…gl/glOrtho.html - ISO ala orthogranic projection

So, enjoy and learn :)

In response to I love asm...
0684f9d33f52fa189aad7ac9e8c87510
0
baldurk 101 Jul 21, 2003 at 21:55

I’m going to be bringing my 500+ out of retirement soon, as an old friend is coming over and we have fond memories of playing on it as a child.

In response to very simple question
4851117d61425bafb6c034e0f595d517
0
DrunkenCoder 101 Jul 21, 2003 at 15:28

or have a look at select() …

In response to Lines
27340afba8e6bbd010c1e520a843e50f
0
moomin 101 Jul 21, 2003 at 11:20

Hmmmmm having to write a piece of code that solves simulataneous equations is apparent. I may have a go at that soon.

In response to Lines
F7a4a748ecf664f189bb704a660b3573
0
anubis 101 Jul 21, 2003 at 10:06

nice page, it just helped me out with a problem… bookmarked !

In response to Lines
Fdbdc4176840d77fe6a8deca457595ab
0
dk 158 Jul 21, 2003 at 09:20

I found the following page useful:

http://mathworld.wolfram.com/Line-LineInte…tersection.html

Let me know if that helps :)

In response to Normals
F7a4a748ecf664f189bb704a660b3573
0
anubis 101 Jul 21, 2003 at 08:23

imagine it like this :

you find per-polygon normals for each polygon in your model. obviously this will result in surfaces that will look very flat when lit as apex said. the easiest way around this is to average the normals of faces that share a vertex. you then assign this new averaged normal to the shared vertex and thus get a different normal for each vertex instead of one for each face.

result == smoother shading.

In response to Normals
27340afba8e6bbd010c1e520a843e50f
0
moomin 101 Jul 21, 2003 at 08:23

per vertex normals are teh w1n!!!!

Render a sphere with per face normals, then

Render a sphere with per vertex normals

the difference is amazing.

That reminds me how many of the neighbour face value normals should I use to calculate the per vertex value?

In response to Ray/Cube Intersection
065f0635a4c94d685583c20132a4559d
0
Ed_Mack 101 Jul 20, 2003 at 22:29

Hi, thanks :) I’m currently trying to learn a good bit of colision detection math, so I thought I may as well reguritate it in a way I would have liked it. Once I get some demos done using this stuff, I’ll make a short (or maybe not so by then) article on collision, and post it on this nice central resource.

Anyway, I’m off to think how reaction forces will fit into my scheme of things.

In response to Ray/Cube Intersection
Fdbdc4176840d77fe6a8deca457595ab
0
dk 158 Jul 20, 2003 at 19:52

Hey Ed Mack!

Very nice detailed post. I’m sure that was very helpful for cdgray. That could be made into a small article, btw.

In response to Ray/Cube Intersection
065f0635a4c94d685583c20132a4559d
0
Ed_Mack 101 Jul 20, 2003 at 18:45

Oh, and as smokey said if your cubes are aligned to all 3 axiises then you can just use simple < statements. I hope I spelt that right as a big green corrupted looking box has appreaded in my screen after starting a second X with weird config file :)

In response to Ray/Cube Intersection
065f0635a4c94d685583c20132a4559d
0
Ed_Mack 101 Jul 20, 2003 at 18:41

Basically, it goes like this (I’m bound to make a mistake):

Take the 8 vertexes that make up the cube’s corners. We will work in quads for the working of it out.

The first task is to work out all 6 face normals, and store them in an array somewhere. To work out the normal you must use the cross product of two of the vectors parralel to the face. From that normal you can use the plane equation to make sure that the end point of the ray is outside (result > 0) all of the planes.

Ok, some math:

The four vertexes (x, y, z) that make up a face ABCD are used to make two vectors.
To get these two vectors, it’s a simple matter of B-A and C-A (that means B.x - A.x, B.y - A.y ect..)

We have our two parallel vectors, A and B I’ll call them for clarity

Now, take these two vectors and work out the normal (the order of this whole thing is important, which means I probably got it the wrong way around :) If so, the normal points inside instead, not life threatening) using the cross product as follows:

c.x = a.y*b.z - a.z*b.y;
c.y = a.z*b.x - a.x*b.z;
c.z = a.x*b.y - a.y*b.x;

C is our normal. This can be used for lighting and so on. All these values can be stored if you’re keeping the plane the same.

The next thing is to find out the plane’s distance from the origin, which we will put back into the plane equation later on.

The plane equation is

result = Ax + By + Cz + D

Now I’ll explain the bits of it. result is the distance the point x, y, z, is from the plane. It is 0 if the point is on it, a negitive number if it is behind the plane and positive if infront.

A, B and C are the x, y and z of the plane’s normal, as it would be far too confusing to use x, y and z :) As I said x,y and z is a point. D is the distance our plane is from the origin (as the normal vector doesn’t show this). Note, a plane is infinite in size and has no bounderies. Just a flat plane surface.

Anyway, we need to know D so we can test points. So, rearrange the formula like so:

-D = Ax + By + Cz - result
D = -(Ax + By + Cz) + result

We know the normal, so that’s sorted. D is what we will try to find. But, how do we know the result? We know a point on the plane gives a result of 0, so once of the vertexes we used to get the normal will do fine for a point on the plane, and then result no longer matters as it is 0.

So, do this:

vertex is some one that we used earlier. Normal, well I hope you have that :)

D = -(Normal.x * vertex.x + Normal.y * vertex.y + Normal.z * vertex.z)

Keep D too now.

This is a the useful bit now, finding out if our ray has went into the plane. Now, this is a simplier version of testing a whole line. This is only testing a point, so you may want to test both points or something dependinh upon your engine. Note that your ray, if moving very fast could “skip” the cube.

Anyway, here’s our test for our arbitary point:

result = (Normal.x * Ray.x + Normal.y * Ray.y + Normal.z * Ray.z + D)

Do this for all 6 faces of the cube, and if ALL of the planes return that the point is beneth them (a negitive result), then the point is definately inside the cube, thus at least part of the ray is inside. You could try the start point of the ray aswell, and make sure it is outside of the cube (at least one plane returns > 0) and if so the ray definately intersects the cube).

If the cube doesn’t move around, you should pre-calculate the Normal and D. If it moves but doesn’t rotate, then you could precalculate the normal and work out D at run time.

I hope this is useful, near correct and not a stupid approach :)

In response to Ray/Cube Intersection
Fe2c292911f2fadfba66571370810280
0
Smokey97 101 Jul 20, 2003 at 06:24

Be more specific, do you want to know if a ray intersects a cube or a box? is the cube/box axis aligned or not? all these things matter if you want the fastest intersection algorithm.

In response to Normals
Fdbdc4176840d77fe6a8deca457595ab
0
dk 158 Jul 19, 2003 at 19:08

Yes, it’s possible to have a normal for each vertex. This is done for lighting calculations. If you find the normal to a triangle, you are finding a “Face Normal”. If you give OpenGL a face normal for lighting, it will make your object look really flat and not very round. If we find the normal for each vertex, it makes the smooth lighting look. This also covers up blocky looking objects and they appear to have more polygons than they do.

In response to Shell writing
065f0635a4c94d685583c20132a4559d
0
Ed_Mack 101 Jul 19, 2003 at 16:27

You probably already know this, but that isn’t a simple task, put it this way: explorer is the largest component of Win98, it’s almost the whole system ;)

Anyway, I think that you may run into a heck of a lot of undocumented problems, so if you don’t know how to start then this is maybe not the project for you. As far as my knowledge of the shell, well… Make a dos gui and use it :)

In response to very simple question
77c60eaca2812f5b7b91b03705fa64e3
0
Obunako 101 Jul 19, 2003 at 09:47

Using WSAAsyncSelect u can recive a message to a window procedure when u get some data, or other network event, about u socket. Try to use it !!! :nod:

In response to very simple question
F699ebb187331fdf7f7875320e3e7e3e
0
starboarder2001 101 Jul 19, 2003 at 06:12

I have another question…. :)

I am using WinSock.

When i call: recv() it waits at that line until it is sent something. Is there a way i can set the function to time out if nothing is sent after a few secs? I am writing a simple chat program..and i need it to check if something was recieved..and if it didnt then just contenue with the program.

//take input
//send input
//recieve text //i dont need it to wait here until it is sent something :\
//display text

In response to FPS counter
77c60eaca2812f5b7b91b03705fa64e3
0
Obunako 101 Jul 17, 2003 at 18:23

the vsync is not the problem, the vsync is disable :( .

In response to one texture after another
F923e021a633170fb10416df23dffddd
0
urika 101 Jul 17, 2003 at 10:28

solved,
the textue did not bind because of the code placing

In response to Creating gimbel lock
27340afba8e6bbd010c1e520a843e50f
0
moomin 101 Jul 17, 2003 at 10:02

As I recall gimble lock is created when all 3 axis rotations occur, this results in a overwriting of the values.

So try to do something that involves rotations along each plane simulatenously

In response to complied_vertex_array
6ad5f8c742f1e8ec61000e2b0900fc76
0
davepermen 101 Jul 16, 2003 at 21:29

all geforces and all radeons support it.. not sure about tnt’s..

but any other card is crap anyways in the sence of opengl support (matrox,voodoo..), and they should use mesa instead. mesa soon for sure has vob included..

and its about impossible to support newest and oldest cards in the range of opengl, remember its over 10 years old:D

just support geforces and radeons.. everyone can get one.. gf2mx you can get here nearly for free..

In response to complied_vertex_array
F33eec98e0fc761467c315aad881c035
0
Jesse_M 101 Jul 16, 2003 at 21:10

Are there any backwards compatibility issues with VBO? You would think that older hardware might not support it.

In response to FPS counter
Fdbdc4176840d77fe6a8deca457595ab
0
dk 158 Jul 16, 2003 at 20:37

You probably have VSYNC on, which will cap the framerate.
Turn it off (if its not already off) and see if it makes a change.

In response to textures
F923e021a633170fb10416df23dffddd
0
urika 101 Jul 16, 2003 at 12:41

thank u! ,i found the answer myself though (the white thing of course) :blush:

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

Recent Tags

indie × 4
game-development × 4
ios × 3
android × 2
mobile × 1
macos × 1
physics-engines × 1
native × 1
music × 1
sound × 1
multiplayer × 1
networking × 1
testing × 1
game-programming × 1
design-patterns × 1
3d-engine × 1
shaders × 1
cross-platform × 1
gaming × 1
royalty × 1
game-design × 1
game-industry × 1
graphics × 1
mmo × 1
open-source × 1