zachman

hey guys
I'm drawing a skydome for my sky background, but I noticed that it's not matching up at the peak of the sphere, which in my case is the most important part. Any ideas as to what might be causing this and how I can fix it?
here's a pic of what it's doing:

here's a reference of the texture I'm using as well, so you understand what I'm doing

thanks in advance
Zach

Here's a little script I wrote for a project I was working on. Someone has probably posted this somewhere already, but you never know... and I'm to lazy to search to see if someone already has

Here's how it works. The script checks for a collision between two lines through the line segments of x1,y1 to x2,y2 and x3,y3 to x4,y4. The script then returns the x and y chords of the intersection between those two lines.

Remember that a line continues infinitely in either direction, and this script checks lines not line segments. This means that it can return a intersection beyond the lengths of the line segments given in the arguments.

There are two scripts, one returning the x choord, the other returning the y. They both take the exact same arguments. The script also assumes there is a collision. So this will not work for parallel or coinciding lines. Well, at least they're untested. The scripts are not meant to check if there is a collision, but rather where the collision happens.

linelineintersection_x()

/* LineLineIntersection_X(x1,y1,x2,y2,x3,y3,x4,y4)

Calculates the x coordinate of the intersection point of two lines from x1,y1 to x2,y2 and x3,y3 to x4,y4
This script assumes that there is an intersection, and the lines are not parallel or coinciding.

Remember that a line extends infinetly in either direction, unlike a line segment. So this script will treat
the segments given in the arguments as lines, so even if there would be no intersection between the segments,
this script will still return an intersection between the lines.
*/

return ((argument0*argument3-argument1*argument2)*(argument4-argument6)-(argument0-argument2)*(argument4*argument7-argument5*argument6))/((argument0-argument2)*(argument5-argument7)-(argument1-argument3)*(argument4-argument6))

linelineintersection_y()

/* LineLineIntersection_Y(x1,y1,x2,y2,x3,y3,x4,y4)

Calculates the y coordinate of the intersection point of two lines from x1,y1 to x2,y2 and x3,y3 to x4,y4
This script assumes that there is an intersection, and the lines are not parallel or coinciding.

Remember that a line extends infinetly in either direction, unlike a line segment. So this script will treat
the segments given in the arguments as lines, so even if there would be no intersection between the segments,
this script will still return an intersection between the lines.
*/

return ((argument0*argument3-argument1*argument2)*(argument5-argument7)-(argument1-argument3)*(argument4*argument7-argument5*argument6))/((argument0-argument2)*(argument5-argument7)-(argument1-argument3)*(argument4-argument6))

Hope someone finds a use for them
~Zach

Hey everybody
I've been working on a project lately, and I've run into some problems and need someone to take a second look and see if they can find what's wrong. Is anybody up to the challenge?

The code is for a dynamic shadow engine. I'm trying to put together a method to draw shadows that looks somewhat realistic and doesn't cost too awful much of a drop in fps. The technique is something similar to that of the "Shadow Volume" technique (http://en.wikipedia....i/Shadow_volume).

Basically the code creates rays from the light source through the outer points of the bounding box of a model. Then it finds the collision of those rays and the surface that the shadow is being drawn on. Using that data, you can create a primitive that is like almost like a bounding box for the shadow. Using a surface, you would draw the model flat in black, and then stretch the surface over the primitive as a texture. This, in theory, would give you a realistic looking shadow, and hopefully not at the cost a high drop in fps. This would also, in theory, allow you to create shadows for highly complex models, like a person, using the same memory and such as a simple cube shape.

I'm running basic tests on cubes because I don't need to use surfaces, and I can just get the main part of the code working, one step at a time. I've got the shadows displaying, but they're not displaying quite right. I think it may have something to do with how I'm drawing the primitive, but I could be wrong. There may also be something wrong with some of my calculations. I just need a second pair of eyes that outside the project. maybe someone will see something that I don't.

Here's a link to my project file: http://www.magicmang...ows_example.zip

if you have any questions, like how my code is supposed to work, or what exactly I'm doing in a certain segment or something, let me know.
Thanks in advance!
Zach

Ok. So I'm making my 3d game on my windows vista laptop. All the graphical effects that I made work perfectly as they should and look really nice. I just got a new desktop, with windows 7. When I run the game on my desktop, it's all messed up. It seems like the blending modes are not the same or something. Everything with an alpha transparency doesn't display right. The textures and particles that use transparency, where it should be fully transparent, are all blocky and look distorted. Almost like what a shockwave would look like.

I'm using gm7 at the moment for this, only because I just haven't found time to upgrade yet. I've tried running the project file from gm7 on both computers, as well as building the .exe file on the laptop and running it on the desktop. Both still run with the problems.

I'm thinking it might have something to do with the DirectX version or the graphics card or something along those lines. I had a similar type of problem with a game I play (Battlefield Bad Company 2) when it ran on the desktop. Every time an explosion went off it got all messed up. I reverted to DirectX 9, and it works just fine now. My desktop is DirectX 11, and my laptop is DirectX 9.

Does anyone have any ideas as to what might be the problem here? Is there a way to change the DirectX version from the game to see if that might be it? I just want to have this work, so that it won't look different on other people's computers.

Thanks
Zach

I'd like to try and do something like this for tilt factor. Kind of like you're playing through an old CRT monitor. The only place I've seen it done is in the game called greenTech. http://www.yoyogames...65934-greentech

I talked to the creator and he said he used an sphere/warp bubble like example off of 64digits.com, which I did find (http://64digits.com/...ew_game&id=1415)

I noticed it uses surfaces and primitives to get it to work correctly. I can use the SurfaceFix dll to be able to have surface functionality in 3d, but I really don't understand anything about primitives to be able to modify it at all.

I tried implementing it into my game and I couldn't get it to work correctly. I'm currently in 3d mode drawing on an orthographic projection.

Any ideas as to why it didn't work? Do I have to temporarily turn off 3d for it to work maybe? Is ortho projections not right for drawing it? If you have any idea as to how to get this to work that would be great.