Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

DarkBASIC Professional Discussion / Is the Intersect Object Function Broken in ver. 57?

Author
Message
G Man
19
Years of Service
User Offline
Joined: 17th Nov 2004
Location:
Posted: 24th Dec 2004 16:22
If so what alternatives are there?

Intel Pentium 4, 3.4GHz, 1280MB RAM, NVidia Quadro FX3000/256MB, 240GB HD, XP Pro
Lost in Thought
20
Years of Service
User Offline
Joined: 4th Feb 2004
Location: U.S.A. : Douglas, Georgia
Posted: 25th Dec 2004 09:18
It works for me but, Sparky's dll is much faster and better IMO.
http://forum.thegamecreators.com/?m=forum_view&t=31051&b=5

Chris64
19
Years of Service
User Offline
Joined: 16th Oct 2004
Location: San Diego
Posted: 25th Dec 2004 10:40
I had a problem with it when I scaled an object. Regardless of the scaling, the intersect would detect the objects original size.

With 1.055 and the same code worked fine.
Lost in Thought
20
Years of Service
User Offline
Joined: 4th Feb 2004
Location: U.S.A. : Douglas, Georgia
Posted: 25th Dec 2004 12:40 Edited at: 25th Dec 2004 12:41
Works here DBP 5.7


G Man
19
Years of Service
User Offline
Joined: 17th Nov 2004
Location:
Posted: 25th Dec 2004 14:43
Perhaps I should have been more specific with the problem I'm seeing...

I've loaded a .X level that I created (a simple room with a few obstacles to test my sliding collision). I used the "set object collision to polygons" for the map. I did this because simply being inside the level model would create a collision condition if I hadn't. Now when I use the "intersect object" function to determine the floor height (Y coordinate) the results returned are all over the spectrum, even when firing it against a flat floor section within the model.

Intel Pentium 4, 3.4GHz, 1280MB RAM, NVidia Quadro FX3000/256MB, 240GB HD, XP Pro
Chris64
19
Years of Service
User Offline
Joined: 16th Oct 2004
Location: San Diego
Posted: 26th Dec 2004 03:36
Lost in Thought, the scaling problem may have had something to do with the hardware. One computer has 55 and one has 57. the machine with 57 is a good gaming system, 55 is my convenient laptop...what I normally work on in front of TV...I was guessing that it was a version problem, but perhaps it's a hardware issue after all.
Lost in Thought
20
Years of Service
User Offline
Joined: 4th Feb 2004
Location: U.S.A. : Douglas, Georgia
Posted: 26th Dec 2004 03:41
If you are using an imported model it may be a loading error that has slipped in between the 2 versions. Did you try that code?

G Man
19
Years of Service
User Offline
Joined: 17th Nov 2004
Location:
Posted: 27th Dec 2004 03:04 Edited at: 27th Dec 2004 03:06
OK, Here is the code I'm working with. I'd really appreciate any help that anyone can give.

First let me explain the logic behind my sliding collision code.

Any player movement through a map is composed of a change in the X and Z coordinates of the player.

If a move to the new X & Z coordinates (NX,NZ), causes a collision condition, we will break the movement into its two components (X&Z) and give the player that portion of the move which does not create a collision condition. We do this by swapping in the old X & Z coordinates before the move (OX,OZ).

First we try positioning the player at OX, NZ. If that doesn't create a collision condition, then we have a valid move and exit the collision routine.

If it does however create a collision condition then we try placing the player at NX,OZ. Again, we test for collision. If a collision condition occurs, the player simply can not execute the desired move.

This all seems to work very well, except for two small (OK not so small) problems:

1. At each of the three locations (NX,NZ/OX,NZ/NX,OZ), we need to know where the floor is, so we shoot off an intersect object downwards to get the floor height (Y) but for some reason the code does not do this right and the player winds up getting stuck inside sloped obstacles, instead of walking up on them. HELP!!!

2. When walking into any south (-Z) facing wall in the test map, collision does not occur until the camera has passed through the wall. The sliding collision still occurs, but inside the wall. Everything works fine against any of the other walls, but the south facing ones just hose me up big time! Again, HELP!!!

What am I doing wrong?



Intel Pentium 4, 3.4GHz, 1280MB RAM, NVidia Quadro FX3000/256MB, 240GB HD, XP Pro

Attachments

Login to view attachments
Lost in Thought
20
Years of Service
User Offline
Joined: 4th Feb 2004
Location: U.S.A. : Douglas, Georgia
Posted: 27th Dec 2004 04:02
I do not know why but I cannot get intersect object to work at all with your code not even on DBP made objects

G Man
19
Years of Service
User Offline
Joined: 17th Nov 2004
Location:
Posted: 27th Dec 2004 04:10
So you see what I'm up against then... It should work, but it doesn't...

Intel Pentium 4, 3.4GHz, 1280MB RAM, NVidia Quadro FX3000/256MB, 240GB HD, XP Pro
Lost in Thought
20
Years of Service
User Offline
Joined: 4th Feb 2004
Location: U.S.A. : Douglas, Georgia
Posted: 27th Dec 2004 04:43
I'm trying something and I'll get back to you as soon as I get it finished.

Lost in Thought
20
Years of Service
User Offline
Joined: 4th Feb 2004
Location: U.S.A. : Douglas, Georgia
Posted: 27th Dec 2004 05:27
Try this code. It fixes the ramp bug but makes a new bug ( you can't walk off of the platform when on top ) Really the main things I changed were the get ground height formula and added mouselook with movement and strafing.


I'm sure you can modify it a bit to fix those bugs. If not post back and we'll see what we can come up with.

G Man
19
Years of Service
User Offline
Joined: 17th Nov 2004
Location:
Posted: 27th Dec 2004 08:05
I've looked at your code. I'm still trying to figure out why you can't walk off the edges of raised platforms (odd that), but does anyone have an idea why the collision is detected so late on south facing walls?

Intel Pentium 4, 3.4GHz, 1280MB RAM, NVidia Quadro FX3000/256MB, 240GB HD, XP Pro
Lost in Thought
20
Years of Service
User Offline
Joined: 4th Feb 2004
Location: U.S.A. : Douglas, Georgia
Posted: 27th Dec 2004 08:28 Edited at: 27th Dec 2004 10:16
You can't walk off the edge because right now your code has no gravity (it places the object at the ground level everywhere it goes) and it is trying to drop below the raised floor before it actually gets all the way off it. So, it is actually inside the raised floor while testing and thinks it is colliding on the x and z axis. I have no idea where the south collision problem is coming from.

[edit] Change the sync rate to 10 and change the move object speeds to 20 and you can walk off it. This will show you what I mean.

[edit2] I do not know what is causing your south wall problems but this seemes to patch it. Change the very last of that code to this.


[edit3] There is also another bug with this code (caused by fixing the south wall error). If you walk into the south east corner of the raised platform (straight towards the corner) you can see through it instead of the south wall

G Man
19
Years of Service
User Offline
Joined: 17th Nov 2004
Location:
Posted: 27th Dec 2004 11:26
I've figured out why you can't walk off the end of the ramp...

When you drop off the end, the collider impacts the end of the ramp (it bumps the back of its head so to speak), causing the routine to reset the character's position back up onto the ramp.

Re-reading your last post, I guess this is what you're trying to say... right?

Intel Pentium 4, 3.4GHz, 1280MB RAM, NVidia Quadro FX3000/256MB, 240GB HD, XP Pro
Lost in Thought
20
Years of Service
User Offline
Joined: 4th Feb 2004
Location: U.S.A. : Douglas, Georgia
Posted: 27th Dec 2004 11:45 Edited at: 27th Dec 2004 11:57
Yes. You will probably have to check at least 3 points for the ground to fall correctly once you set up your gravity. The more points you check the more accurate it is. The more complex your level is the more accurate it will need to be. You may even have to modify the code to check the y values as well. I would not put it past being a DBP bug as the problem with the zsouth walls. DBP's collision has come a long way since I first bought it but, it is still a bit dodgy. I messed around with DBP coded sliding collision for ages trying to find a method as accurate and fast as Nuclear Glory Collision. I failed so I bought NGC 2.03 for $15. I still use DBP collision for small projects but anything complex I use NGC.

[edit] I believe you can do it with just 1 check for the ground like you are doing if you do more checks to chekck for y movement as well as x and z. This will however allow you to "float" on the very edge of raised platforms. The extra checks will fix this but it is where I found most of my slow down problems with DBP built collision.

Lost in Thought
20
Years of Service
User Offline
Joined: 4th Feb 2004
Location: U.S.A. : Douglas, Georgia
Posted: 27th Dec 2004 13:12 Edited at: 27th Dec 2004 13:57
Here is a version that will allows you to walk off of the platforms but you still have the southwall error. I also removed a couple of intersect object commands that didn't seem to be needed.


I'll keep looking into the south wall problem.

[edit] I don't know why you can get closer to the south wall than the rest of the walls but changing the camera range to .01, 3000 makes it so you can't see through them.



If I remember correctly quake1 had this same error. You could get closer to the east walls though.

G Man
19
Years of Service
User Offline
Joined: 17th Nov 2004
Location:
Posted: 27th Dec 2004 14:14 Edited at: 27th Dec 2004 14:31
I thought of altering the near end of the view frustrum already. So I log in here to tell you that I think I have a solution, only to find that you already are chasing down the same trail. In a more complex map, this algorythm seems to work pretty well. Nearer inspection would place the troublesome walls to the east (+x) rather than the north btw. Odd that! Setting the near clipping plane to .1 seems to have eliminated a large portion of the looking through walls problem, until your angle of coincidence is very close to the angle that the wall is running.

The extra intersect object commands were intended to retrieve the actual floor height at each new position that you are trying for collision. Honestly, it was shoved in there for a bit more precision and to avoid circumstances where the floor height might vary wildly in close ranges.

Attached is a somewhat more complex level if you want to keep playing with it...

This is seeming to be a rather simple solution to sliding collision. What do you think? While not pixel perfect, it does address the issue nicely albeit with a somewhat broad brush...

Thanks for your help btw!

Intel Pentium 4, 3.4GHz, 1280MB RAM, NVidia Quadro FX3000/256MB, 240GB HD, XP Pro

Attachments

Login to view attachments
Lost in Thought
20
Years of Service
User Offline
Joined: 4th Feb 2004
Location: U.S.A. : Douglas, Georgia
Posted: 27th Dec 2004 14:30 Edited at: 27th Dec 2004 14:41
Always glad to help when i can. I have ran into this before long ago. Odd indeed about the walls changing . Try this code with the new level. I'll tweak it a bit more before going to bed.


[edit] Better version


[edit2] Also a little hint on that level. If you made it in CSHOP you will definitely want to convert over to using APEX's .CSM loader. It breaks it up into limbs so it auto hides a lot of unseen polys.

G Man
19
Years of Service
User Offline
Joined: 17th Nov 2004
Location:
Posted: 27th Dec 2004 14:48
That works really well. There was only one place that I saw any oddities. There's a few seams that aren't completely sealed in that hastily constructed test level. If you slide along one of those unsealed seams it allows the collider to intrude into the wall, trapping the collider. That's fixed by making good levels instead of hastily constructed tripe.

Just out of curiosity, what's your frame rate on this code?

Intel Pentium 4, 3.4GHz, 1280MB RAM, NVidia Quadro FX3000/256MB, 240GB HD, XP Pro
Lost in Thought
20
Years of Service
User Offline
Joined: 4th Feb 2004
Location: U.S.A. : Douglas, Georgia
Posted: 27th Dec 2004 14:50 Edited at: 27th Dec 2004 14:51
I'm really tired now but tomorrow I will convert this over to Sparky's collision dll. It is much faster than DBP's intersect object command and it's free for anyone to use. Yeah this could be a simple solution though it has been done before many times. nx# / ox# sliding collision has been around for a while. Most people just keep the code to themselves and the ones who do share it post it here and it gets lost in the forever growing posts that follow it just as this post eventually will Good night and good luck.


104 FPS with that code.

G Man
19
Years of Service
User Offline
Joined: 17th Nov 2004
Location:
Posted: 27th Dec 2004 14:54
No, I made it in Deled. It's just a batch of sewer pipe prefabs that I made and threw together quickly into a test level. If this were a production level, I'd strip off all of the outside polys that the player would hopefully never see.

Intel Pentium 4, 3.4GHz, 1280MB RAM, NVidia Quadro FX3000/256MB, 240GB HD, XP Pro
Lost in Thought
20
Years of Service
User Offline
Joined: 4th Feb 2004
Location: U.S.A. : Douglas, Georgia
Posted: 27th Dec 2004 14:58
There is one thing you will find about DBP's built in collision commands. They do not register a collision if you go completely through the object (change the move object speed to 50 and you'll see what I mean) thats why I bought NGC in the long run. It should be fine as long as your movement speed is less than your objects diameter.

G Man
19
Years of Service
User Offline
Joined: 17th Nov 2004
Location:
Posted: 27th Dec 2004 15:03
I'm aware of that, the collision only registers if it is checked while the objects are in contact.

Intel Pentium 4, 3.4GHz, 1280MB RAM, NVidia Quadro FX3000/256MB, 240GB HD, XP Pro
G Man
19
Years of Service
User Offline
Joined: 17th Nov 2004
Location:
Posted: 27th Dec 2004 15:08
I look forward to seeing the Sparky version. I'm not suffering from speed issues yet, I'm pulling about 480 FPS, but not everyone has the horsepower that we do.

Once we get this ironed out, I'll drop it over in the code repository for anyone to use.

Thanks again for the help!

Intel Pentium 4, 3.4GHz, 1280MB RAM, NVidia Quadro FX3000/256MB, 240GB HD, XP Pro
Lost in Thought
20
Years of Service
User Offline
Joined: 4th Feb 2004
Location: U.S.A. : Douglas, Georgia
Posted: 27th Dec 2004 15:11 Edited at: 27th Dec 2004 15:18
Cool. The sparky version should be faster. I'll test tomorrow.

[edit] I get 270 fps with no collision in that level 116 with our collision setup. Thats a big collision slowdown. Just for kicks I'll makea NGC V2.03 and V3.01 test tomorrow as well. I'll post the code and results.

I just tested though and those 3 intersect object tests only dropped it 24 fps so sparky's may not be much faster. They sure have sped up intersect object alot since I used it last.

G Man
19
Years of Service
User Offline
Joined: 17th Nov 2004
Location:
Posted: 27th Dec 2004 15:50
That second level only has 2304 poly's BTW...

Intel Pentium 4, 3.4GHz, 1280MB RAM, NVidia Quadro FX3000/256MB, 240GB HD, XP Pro
Lost in Thought
20
Years of Service
User Offline
Joined: 4th Feb 2004
Location: U.S.A. : Douglas, Georgia
Posted: 27th Dec 2004 21:42
DBP and Action3D Reducer reports the second level at 4608 triangles for the second level and 162 for the first level. Those polys aren't quads are they?

G Man
19
Years of Service
User Offline
Joined: 17th Nov 2004
Location:
Posted: 28th Dec 2004 00:19
No I think it's triangulated (pretty sure of it).

Intel Pentium 4, 3.4GHz, 1280MB RAM, NVidia Quadro FX3000/256MB, 240GB HD, XP Pro
G Man
19
Years of Service
User Offline
Joined: 17th Nov 2004
Location:
Posted: 28th Dec 2004 02:53
So have you had a chance to translate this over to use the Sparky DLL? I have it (the DLL), but haven't yet wrapped my head around it... Seeing it in action would speed up that process.

Intel Pentium 4, 3.4GHz, 1280MB RAM, NVidia Quadro FX3000/256MB, 240GB HD, XP Pro
Lost in Thought
20
Years of Service
User Offline
Joined: 4th Feb 2004
Location: U.S.A. : Douglas, Georgia
Posted: 28th Dec 2004 03:52 Edited at: 28th Dec 2004 10:13
Sorry I'm still at work. It'll be a least 5 more hours before I can play with it.

[edit] At home now. Starting to convert to Sparky's, NGC 2.03, and then NGC 3.01.

[edit2] Sparky's version (Sorry it took so long. People just won't leave you alone sometimes )



I get 5 more FPS with this code than the original.

G Man
19
Years of Service
User Offline
Joined: 17th Nov 2004
Location:
Posted: 28th Dec 2004 10:40 Edited at: 28th Dec 2004 10:51
Could it be the "object collision()" function calls that are eating up the clock?

Oddly enough, I lost about 30 FPS running this version... Down to 447 FPS... Go figure!

Intel Pentium 4, 3.4GHz, 1280MB RAM, NVidia Quadro FX3000/256MB, 240GB HD, XP Pro
Lost in Thought
20
Years of Service
User Offline
Joined: 4th Feb 2004
Location: U.S.A. : Douglas, Georgia
Posted: 28th Dec 2004 10:55 Edited at: 28th Dec 2004 10:56
I actually gained more than that. Final stats are.

Original = 104
SParky's = 121
NGC V2.03 = 121 - 164 (depending on environment)
NGC V3.01 = 138 - 148 (depending on environment)

NGC V2.03 code


NGC V3.01 code


Wanna hear something strange. NGC V2.03 is actually faster than NGC V3.01. When you disable the octree optimization in 3.01 it only runs at 58 FPS.

Lost in Thought
20
Years of Service
User Offline
Joined: 4th Feb 2004
Location: U.S.A. : Douglas, Georgia
Posted: 28th Dec 2004 10:58
Yes DBP's object collision functions are eating the clock alot. I think when they fix NGC V3 it will be way faster as it should be with the octree optimization.

G Man
19
Years of Service
User Offline
Joined: 17th Nov 2004
Location:
Posted: 28th Dec 2004 11:21
I think TGC must be hitting the indigenous D3DX.Intersect function. That's probably why it went a bit faster using the DBPro "Intersect Object" function for me. I think my graphics card is pretty optimized for DirectX.

I wonder what frame rates someone with a little less horsepower would get with the various interations of this code... Say 1GHz, 512MB RAM, with a 64MB Gfx card...

Intel Pentium 4, 3.4GHz, 1280MB RAM, NVidia Quadro FX3000/256MB, 240GB HD, XP Pro
Lost in Thought
20
Years of Service
User Offline
Joined: 4th Feb 2004
Location: U.S.A. : Douglas, Georgia
Posted: 28th Dec 2004 11:25
I can quickly find out. My bro has a machine with those exact specs 1.0 gig athlon (original athlon not xp), 512MB DDR200, Gforce4 MX440 64MB. I'll run tests and report back.

Lost in Thought
20
Years of Service
User Offline
Joined: 4th Feb 2004
Location: U.S.A. : Douglas, Georgia
Posted: 28th Dec 2004 11:41
On My Bro's machine.
Original = 68
SParky's = 88
NGC V2.03 = 82 - 129 (depending on environment)
NGC V3.01 = 99 - 123 (depending on environment)

G Man
19
Years of Service
User Offline
Joined: 17th Nov 2004
Location:
Posted: 28th Dec 2004 11:48
Heck that's respectable. That gives you a few clock ticks to fool with AI and other stuff. I mean anything over about 30 ought to do right? I'll just hack in some delta adjustments - we'll drop it over on the code repository as a joint venture!

Intel Pentium 4, 3.4GHz, 1280MB RAM, NVidia Quadro FX3000/256MB, 240GB HD, XP Pro
Lost in Thought
20
Years of Service
User Offline
Joined: 4th Feb 2004
Location: U.S.A. : Douglas, Georgia
Posted: 28th Dec 2004 12:03
Cool. But remember at that level size with 30 FPS the movement code speed could easily get past the object's diameter and cause the going through the wall error. We may have to find a way around that as well. Probably with the intersect object checks wor wall errors.

G Man
19
Years of Service
User Offline
Joined: 17th Nov 2004
Location:
Posted: 28th Dec 2004 12:13
I was thinking of limiting the maximum movement speed to the collider's size... So in other words, if your machine's too slow, you're simply going to poke along, but a reasonably fast machine should hang just fine.

I mean at 30FPS, the collider is 32 quants wide. In order for a single frame's step to exceed 32 quants, the player would be clipping along at more than 960 quants per second. If you equate a quant to an inch (the rough scale we've been working on) that's a velocity of ~54.5 MPH. That's a pretty stiff speed for a guy to be running without bionics involved

That should do for an initial version of the code. Sure there's a lot of prettiness that could be worked in. For example there's no jumping code. It's a good starting point for someone who just wants to drop the name of their new level into the code and do a walk through. It's a starting point.

Intel Pentium 4, 3.4GHz, 1280MB RAM, NVidia Quadro FX3000/256MB, 240GB HD, XP Pro
Lost in Thought
20
Years of Service
User Offline
Joined: 4th Feb 2004
Location: U.S.A. : Douglas, Georgia
Posted: 28th Dec 2004 12:24
Yeah but this is the computer world. If you can't run 70MPH you just can't make it in this industry J/K I think that is a very good code for a starting point to learning sliding collision.

G Man
19
Years of Service
User Offline
Joined: 17th Nov 2004
Location:
Posted: 28th Dec 2004 12:36
I'll pretty it all up with more comments and stuff (in case you didn't notice, I like comments)... make it easy to understand.

Intel Pentium 4, 3.4GHz, 1280MB RAM, NVidia Quadro FX3000/256MB, 240GB HD, XP Pro
G Man
19
Years of Service
User Offline
Joined: 17th Nov 2004
Location:
Posted: 28th Dec 2004 14:50
This patch of code:



introduced an odd glitch. If you walk directly at a corner, the wall becomes sticky, holding the player against the wall until another corner is encountered. I've been wrestling with it for a while... It's driving me wonky! I think it needs to be moved somewhere inside of the nested if structure because we're altering the X position without testing to see if it generates a collision condition when combined with the new Z position. Am I making sense or rambling incoherently?

I've tried this code:



which seems to work with one small exception. If you happen to be sliding along the wall and run over a poorly sealed seam in the map (i.e there's a crack and consequently no poly to intersect off of), you wind up suddenly outside the map falling upwards into infinity.

Intel Pentium 4, 3.4GHz, 1280MB RAM, NVidia Quadro FX3000/256MB, 240GB HD, XP Pro
Lost in Thought
20
Years of Service
User Offline
Joined: 4th Feb 2004
Location: U.S.A. : Douglas, Georgia
Posted: 28th Dec 2004 14:52 Edited at: 28th Dec 2004 14:53
I was already working on that lol Try this code.



[edit]
I went back to testing on the old map as it is more solid and has more different types of collision in it.

G Man
19
Years of Service
User Offline
Joined: 17th Nov 2004
Location:
Posted: 28th Dec 2004 15:33
That seems to have fixed the sticky wall issue. The portion where you calculate newzsouth# seems to be superfluous (or are you seeing issues with south/north facing walls that I'm not?) as it works just as well without it (saving a few ticks). I am noticing an apreciable decrease in frame rate though when running this code against the sewer level.

I've hacked in a butt-load of commenting but now I'm getting sleepy. I'll throw together a better complex test level tomorrow and post it for you to play with (one without holes and a scadzillion hidden polys).

This is fun! Thanks for the help!

Intel Pentium 4, 3.4GHz, 1280MB RAM, NVidia Quadro FX3000/256MB, 240GB HD, XP Pro
G Man
19
Years of Service
User Offline
Joined: 17th Nov 2004
Location:
Posted: 28th Dec 2004 15:39 Edited at: 28th Dec 2004 15:42
Oh, before I go to sleep, here's the code with delta calcs, comments and a few other tidbits:



Intel Pentium 4, 3.4GHz, 1280MB RAM, NVidia Quadro FX3000/256MB, 240GB HD, XP Pro
Lost in Thought
20
Years of Service
User Offline
Joined: 4th Feb 2004
Location: U.S.A. : Douglas, Georgia
Posted: 28th Dec 2004 22:46 Edited at: 28th Dec 2004 22:49
Yeah I was having a few north/south wall errors at slightly higher speeds. Though that was with the sewer level and may have been a building bug. I'll give it a test when i get home as I am running about 1 hour late for work and just woke up You can also change that code a bit to disable west wall testing as it may have been a building error as well.



This will only test the extra intersect object while moving east. I am saving both versions as I may use that N/S/E/W checks to enable moving faster than the object's diameter without going through exterior walls

[edit] In your code what does

If newxsouth# > (*3)

do?

G Man
19
Years of Service
User Offline
Joined: 17th Nov 2004
Location:
Posted: 29th Dec 2004 00:33
Heck if I know... You typed it! I was wondering that myself.

Intel Pentium 4, 3.4GHz, 1280MB RAM, NVidia Quadro FX3000/256MB, 240GB HD, XP Pro
Lost in Thought
20
Years of Service
User Offline
Joined: 4th Feb 2004
Location: U.S.A. : Douglas, Georgia
Posted: 29th Dec 2004 04:24
That is if newxsouth# > ((object size x(2)/2)*3) in all of my codes Must be a copy error.

G Man
19
Years of Service
User Offline
Joined: 17th Nov 2004
Location:
Posted: 29th Dec 2004 04:38
The compiler didn't complain... I'll fix it in my copy of the code... Harumph!

shouldn't that read something like:



...of course in the commented version I renamed that variable to make the code a little more understandable...

Intel Pentium 4, 3.4GHz, 1280MB RAM, NVidia Quadro FX3000/256MB, 240GB HD, XP Pro

Login to post a reply

Server time is: 2024-05-19 18:55:12
Your offset time is: 2024-05-19 18:55:12