500 Post Club!

Posts: 974
From: Philadelphia, PA U.S.A
Registered: Mar 2003

I have a first person game with 11 levels. But all of the enemies in each level and the bonuses, etc. are mostly the same. What changes is the scenery. I have a skybox that is a child of the pivot that turns opposite your turns so the sky is perfect and you don't notice it....you can go 1 million miles in any direction.

I am finished with level 1. I have one huge plane that is the ground and hills in the "main" part of level one. I was going to free all entities except the plane. But if I put a small civilization for level two some 10,000 units along the z axis, when you get there, none of level one would be rendered. It's still in memory, and the textures are too, but no polygons to render.

I think if I keep my surface count low, this is doable. Even if I run into trouble, I can always free towns that are further than 10,000 units away, and load them again once they get closer ,far before they are actually in view.

I know it's taboo to "load" anything during movement and game play, but I don't imagine this being much of a pause, since when you are between villages, you don't see much but just land. The new villages would load or unload when they are way past the rendering point.

Any see any potential problems with this model? suggestions?

            

500 Post Club!

Posts: 601
From:
Registered: Aug 2001

If you don't normalize your world regularly, you will end up getting graphics problems when you get far away from 0,0,0.

A plane can be textured, but it can't be shaped.

>I know it's taboo to "load" anything during movement and game play, but I
>don't imagine this being much of a pause, since when you are between
>villages, you don't see much but just land. The new villages would load
>or unload when they are way past the rendering point.

When you load and unload on the fly, you risk defragmenting memory.

This may not be evident on a freshly booted PC, but for one which has been used for a few hours and then you load up the game, it could mean that every time you load or unload, Windows will swap memory to disk making it excruciatingly irritating to play the game. The less memory you use, the less chance there is that the user has problems.

However, dynamic resource management works well if you design it with lowspec machines in mind.

Andy

            

500 Post Club!

Posts: 974
From: Philadelphia, PA U.S.A
Registered: Mar 2003

quote:

---

If you don't normalize your world regularly, you will end up getting graphics problems when you get far away from 0,0,0.

---

Could you clarify this a little? This intrigues me as well. How do you normalize your world?

I am DEFINATELY programming with low specs in mind. No question about it! But I would like to do this dynamic resource management thing. If [quote]
"When you load and unload on the fly, you risk defragmenting memory",
[quote], then what is the best way to pause the game while new things are loaded and unloaded? I guess I really need to know this even for the "old" model of changing levels, which I have done up to this point by putting a 2d bitmap on the screen (a "curtain") while some entites are freed and others loaded. Please advise!!!!

            

1,000 Post Club!

Posts: 1917
From: Louisville Kentucky
Registered: Aug 2003

------------------
http://propagandamatrix.com/multimedia_priorknowledge_911roadtotyranny.html

               

500 Post Club!

Posts: 974
From: Philadelphia, PA U.S.A
Registered: Mar 2003

I need to know what that means. I'd hate to build several villages miles away from world center just to find later that it causes problems on certain machines.

AND, what's the best way to 'clean house' and change levels in terms of memory management? Its easy to do in general but I need to make sure I'm doing it for optimal performance!!

            

500 Post Club!

Posts: 785
From:
Registered: Sep 2003

You should be able to set your x,y,z to be radically big as long as you aren't trying to still see 0,0,0 (or some other very remote distance from your camera) as well. That's my understanding of it, though I haven't tried it to such a degree, so if anyone knows otherwise- jump in.

If you're not dynamically de-allocating & re-allocatng memory, but internally clearing & filling, then Windows silliness becomes much less of an issue- but obviously the way Blitz works you're going to have some things you just have to do 'however', and possibly marathon level streaming might be an issue on some machines or after extended durations. You just have to test it & see I guess. Good luck to you.

------------------
This time around all the limits will be cut loose...
First release yourself. Let our dreams be as one if mankind is to evolve.
Teach your children the way, that they may understand.

Love is a power. Compassion a gift. No one need be empty.
No one need be scared.

               

500 Post Club!

Posts: 974
From: Philadelphia, PA U.S.A
Registered: Mar 2003

Veteran Member

Posts: 328
From: Reston, VA United States
Registered: Jun 2002

------------------
-=[ M A S T E R S Dev ]=-
http://www.3d-design.0catch.com

               

500 Post Club!

Posts: 974
From: Philadelphia, PA U.S.A
Registered: Mar 2003

Well, I DID notice some very weird problems as I got further and further away from 0,0,0. I created an island and two bridges, one going to an island northwest, another to an island northeast.

Both bridges were identical. Yet the bridge to the northeast,the geometry is perfect in Max, but in Blitz somehow the mesh got flipped so the bridge is upside down. Weird.

But worse than that, when I take the good bridge, I finally get to the northwest island. And its fine, but certain collisions with steep objects allow me to pass through walls,hills, barriers, and start falling. in the world center, the collisions are perfect no matter how steep the object is.

My hunch is that the subtle flaws and/or irregularities in the collision calculations get magnified the further you get from world center. This "floating point precision" problem was alluded to by both Biofellis and Andy and I think the problem may be pretty bad, at least on my system.

This "remote" island I'm speaking of is at about 33,000 on the z axis and 20,000 on the x axis. Not that far, but apprently far enough to start having problems.

            

500 Post Club!

Posts: 601
From:
Registered: Aug 2001

1) that 3D coordinates are only correct to 6 digits, meaning that when you get far away from the center of your world, everything is just a little bit away from where it should be, and when you try moving it somewhere, it will seem to jump around.

2) that things which are further away is drawn on top of things which are closer. This is because far away things may be so close to each other, that the lack of z-buffer accuracy makes them appear to be at the same place.

1) can be rectified by normalizing your cameras position every once in a while... If you are at 10000,10000,10000, then you simply move everything -10000,-10000,-10000, so that the camera is now at 0,0,0. This way everything stays where it is in relation to each other, but is moved closer to the origo.

by the way, 10000 is just a fictitious number, use whatever works for your world. I generally have 2 lists of entities... One for entities withing distance of sight and one for all other entities. I then move entities from one to the other based on how far they are from origo. Then when I normalize, I normalize all of the entities in sight in one loop, and then the others, a few at the time every second or so until all are done.

This way you can still have thousands of entities, but only have to normalize a maximum of perhaps 50 in one frame. Since rendering the scene is usually very costly on slow PC's, you could also take the first half in one frame, leave out the rendering, then take the other half in the second frame and then render... This is great as you usually won't notice it.

>"When you load and unload on the fly, you risk defragmenting memory",
>[quote], then what is the best way to pause the game while new things are
>loaded and unloaded? I guess I really need to know this even for
>the "old" model of changing levels, which I have done up to this point by
>putting a 2d bitmap on the screen (a "curtain") while some entites are
>freed and others loaded. Please advise!!!!

If you want serious drm, then you need to create a systen to manage the things you load and free, and which can load and free entities while the game is in progress.

>...Guess what happened...

I told you so

I have done alot of research on how to actually make a large, detailed world, and have built the first 2 or 3 very capable terrainsystems for my self... If you really want to make it realistic it will be difficult, but if you need just a plane, it's really just about keeping the numbers manageable.

Andy

            

500 Post Club!

Posts: 974
From: Philadelphia, PA U.S.A
Registered: Mar 2003

|edit|

so this must mean that the town that was at the world center, what do you do with that? scoot it out of the way? I have 11 towns so I'll have to write a bringtocenter() function and a removefromcenter() function to scoot stuff around accordingly.

|/edit|

[This message has been edited by Nmuta (edited 10-23-2003).]

            

500 Post Club!

Posts: 785
From:
Registered: Sep 2003

Anyway- food for thought.

------------------
This time around all the limits will be cut loose...
First release yourself. Let our dreams be as one if mankind is to evolve.
Teach your children the way, that they may understand.

Love is a power. Compassion a gift. No one need be empty.
No one need be scared.

               

500 Post Club!

Posts: 974
From: Philadelphia, PA U.S.A
Registered: Mar 2003

The calculations work perfectly as long as you are withinn 10,000 units of world center but after that things get screwy.

I think Andy is right. I know he's right actually.

But yeah, Biofellis it may be because there is a greater need for floating point accuracy in my collision system then yours. My collisions work at VERY high speeds at world center but I can just drift into sand dunes at 30 K units away when I'm walking very slowly. So yes, it is a math issue.

I would imagine it may even effect your system at greater distances and with steep enough hills. It's something I will certainly test.

[This message has been edited by Nmuta (edited 10-23-2003).]

[This message has been edited by Nmuta (edited 10-23-2003).]

            

500 Post Club!

Posts: 601
From:
Registered: Aug 2001

You move that -10000,-10000,-10000 as well... That way everything stays where it is supposed to be, but the camera never moves beyond a certain 'safe' distance from the origo. Basically in stead of moving around your world, you move the world around you...

If you start trying to 'scoot things out of the way', you will be making more work at the price of great complexity and slowdown. Just move it like everything else... Believe me, simplicity is often the best way to go.

>I have 11 towns so I'll have to
>write a bringtocenter() function and a removefromcenter() function to
>scoot stuff around accordingly.

Actually you just need the first function... Ideally you just normalize everything in view first, and then a few of the remaining entities at a time until they have all been moved.

Frame 1: move the houses in view - 25 entities moved
Frame 2: move entities not in view - 5 moved
Frame 3: move entities not in view - 5 moved
Frame 4: move entities not in view - 5 moved
Frame 5: move entities not in view - 5 moved
Frame 6: move entities not in view - 5 moved
Frame 7: done

The following piece of code should do it... PLEASE UNDERSTAN that this is 'Crap Code TM (C) (R)' and although you can use it as you please, you can most certainly do better yourself. This is from my first study into flight simulation 2 years ago, so I only needed a functional terrainsystem in order to study the physics and undercarriage.

;***********************************************************'
num_ent=10 ; number of entities
dim mesh(num_ent)
fieldsize=5000

.housekeeping
mx = 0.0
my = 0.0
mz = 0.0
If EntityX(player_pivot)>5000 Then
PositionEntity player_pivot,EntityX(player_pivot)-fieldsize,EntityY(player_pivot),EntityZ(player_pivot)
mx = -fieldsize : my = 0.0 : mz = 0.0

EndIf

If EntityZ(player_pivot)>5000 Then
PositionEntity player_pivot,EntityX(player_pivot),EntityY(player_pivot),EntityZ(player_pivot)-fieldsize
mx = 0.0 : my = 0.0 : mz = -fieldsize
EndIf

If EntityX(player_pivot)<-5000 Then
PositionEntity player_pivot,EntityX(player_pivot)+fieldsize,EntityY(player_pivot),EntityZ(player_pivot)
mx = fieldsize : my = 0.0 : mz = 0.0
EndIf

If EntityZ(player_pivot)<-5000 Then
PositionEntity player_pivot,EntityX(player_pivot),EntityY(player_pivot),EntityZ(player_pivot)+fieldsize
mx = 0.0 : my = 0.0 : mz = fieldsize
EndIf

For q = 1 To num_ent
MoveEntity mesh(q),mx,my,mz
Next
Return
;*******************************************************

Andy

            

Veteran Member

Posts: 150
From:
Registered: Oct 2003

500 Post Club!

Posts: 779
From: Sherbrooke, Quebec, Canada
Registered: Jun 2003
ICQ: 26677455

------------------
GoSsE Korupted - gosse@nuloen.com
Nuclear Loaded Entertainment
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Wandering Knights - Hack'n'Slash RPG
Nuclear Nibble 3D & Blasto 3D - Classic Arcade Remakes

               

500 Post Club!

Posts: 785
From:
Registered: Sep 2003

Anyway, happy that you got it sorted out, one way or the other.

------------------
This time around all the limits will be cut loose...
First release yourself. Let our dreams be as one if mankind is to evolve.
Teach your children the way, that they may understand.

Love is a power. Compassion a gift. No one need be empty.
No one need be scared.

               

500 Post Club!

Posts: 974
From: Philadelphia, PA U.S.A
Registered: Mar 2003

I already started trying to implement that, just to see if it would work. I got the mouselook working with this new concept! Yeah!

Right now I keep falling though the floor, so I have to adjust the process of calculating collisions with the pivot and the ground, which was a heavily 'PIVOT-CENTRIC' method. But this new idea intrigues me and I think it may work.

It's just weird, the thought of it. Instead of moving a person, you are moving several tons of land and buildings and enemies!!!! Yet in terms of rendering, the computer doesn't really know the difference I suppose. It would still be the same number of polygons moving just as fast in the same direction. The whole concept of 3D in general is such an interesting illusion.

            

Veteran Member

Posts: 163
From: Australia
Registered: Aug 2001
ICQ: 5813735

------------------
Current project: FRUITY CAVES / DRAGON'S GOLD / UNDERTHREAT / FATAL DANGER / TANKZ / ADRacer

www.inventivedreams.com/dream

               

500 Post Club!

Posts: 974
From: Philadelphia, PA U.S.A
Registered: Mar 2003

btw, keeping the player at 0,0,0 all the time as MSW suggested is proving to be a little too tricky to implement given my current engine's set up, so I think I might use your way, with the grid.

|edit|

Andy, I just tried implementing that system. It works generally, but there is a little "jump" when the "shift" happens that is quite noticeable. And when the switch happends, it throws you off by about 40 units or so which can be the difference between being in a door and not in a door.

Here is the code I used. I had to put the "moveentity" command inside the conditional "if" statements, because when left outside of the statments, (run every loop) I experienced severe slowdown. I also had to rename mx, my,mz, etc because I already use those variables.

I run housekeeping from the main loop.
Function housekeeping() fieldsize#=2000 mmx = 0.0 mmy = 0.0 mmz = 0.0 If EntityX(pivot)>fieldsize Then PositionEntity pivot,EntityX(pivot)-fieldsize,EntityY(pivot),EntityZ(pivot) mmx = -fieldsize : mmy = 0.0 : mmz = 0.0 MoveEntity land,mmx,mmy,mmz EndIf If EntityZ(pivot)>fieldsize Then PositionEntity pivot,EntityX(pivot),EntityY(pivot),EntityZ(pivot)-fieldsize mmx = 0.0 : mmy = 0.0 : mmz = -fieldsize MoveEntity land,mmx,mmy,mmz EndIf If EntityX(pivot)<-fieldsize Then PositionEntity pivot,EntityX(pivot)+fieldsize,EntityY(pivot),EntityZ(pivot) mmx = fieldsize : mmy = 0.0 : mmz = 0.0 MoveEntity land,mmx,mmy,mmz EndIf If EntityZ(pivot)<-fieldsize Then PositionEntity pivot,EntityX(pivot),EntityY(pivot),EntityZ(pivot)+fieldsize mmx = 0.0 : mmy = 0.0 : mmz = fieldsize MoveEntity land,mmx,mmy,mmz EndIf End Function ;housekeeping

[This message has been edited by Nmuta (edited 10-24-2003).]

            

500 Post Club!

Posts: 601
From:
Registered: Aug 2001

Is it always 'off' at 40 units?
How many entities are you moving at one time?
Is your collision averaging or using old and new positions?

try this... REMEMBER, I am not able to run this on my work PC, so it may not work at all, but you see the general idea.

Global test=3
global num_ent_half=num_ent*.5

Function housekeeping()

fieldsize=2000
mmx% = 0
mmy% = 0
mmz% = 0

If EntityX(pivot)>fieldsize Then
mmx% = -fieldsize : mmy% = 0 : mmz% = 0
MoveEntity pivot,mmx%,mmy%,mmz%
test=1
EndIf

If EntityZ(pivot)>fieldsize Then
mmx% = 0 : mmy% = 0 : mmz% = -fieldsize
MoveEntity pivot,mmx%,mmy%,mmz%
test=1
EndIf

If EntityX(pivot)<-fieldsize Then
mmx% = fieldsize : mmy% = 0 : mmz% = 0
MoveEntity pivot,mmx%,mmy%,mmz%
test=1
EndIf

If EntityZ(pivot)<-fieldsize Then
mmx% = 0 : mmy% = 0 : mmz% = fieldsize
MoveEntity pivot,mmx%,mmy%,mmz%
test=1
EndIf

if test=2 then
For q = num_ent_half to num_ent
MoveEntity mesh(q),mmx%,mmy%,mmz%
next
test=3
endif

if test=1 then
For q = 1 To num_ent_half
MoveEntity mesh(q),mmx%,mmy%,mmz%
next
test =2
endif

end function()

then add this where you render

if test=3 then
RenderWorld
endif

Does it help in any way?

Andy

[This message has been edited by Andy (edited 10-24-2003).]

            

500 Post Club!

Posts: 974
From: Philadelphia, PA U.S.A
Registered: Mar 2003

To clarify: the "jump" doesn't happen at first. The first time the "housecleaning" function was called (I called it at 2000 units)...it worked beautifully. Seamless! I noticed a very very small tick but it was nothing a user would ever really notice.

Then after that, I started noticing the "40 unit" lack of accuracy, which was not exactly 40 but about that. And sometimes worse than others.

But thinking about it, wouldn't you have to temporarily disable collisions on the pivot and the scene in order for them to translate effectively? I think so. Maybe that's what caused the shift... a slight collision between the pivot and the scene as they are "shifted" around.

But most likely I think its a math problem. I will try your new code.

            

500 Post Club!

Posts: 601
From:
Registered: Aug 2001

That's how it works here atleast!

>Then after that, I started noticing the "40 unit" lack of accuracy, which
>was not exactly 40 but about that. And sometimes worse than others.

Strange!

>But thinking about it, wouldn't you have to temporarily disable
>collisions on the pivot and the scene in order for them to translate
>effectively? I think so. Maybe that's what caused the shift... a slight
>collision between the pivot and the scene as they are "shifted" around.

I think you might be on to something. Positionentity and moveentity works the same and are both susceptiple to collision problems...

Try disabling collisions alltogether, just to test...

>But most likely I think its a math problem. I will try your new code.

Just remember that the new code works as I first described... It moves the pivot and half the entities, then leaves out rendering that frame, then moves the other half of the entities and renders again... If you feel the tick is bigger this time, then you could change the

if test=3 then
RenderWorld
endif

back to

Renderworld

Good luck.

Andy

            

500 Post Club!

Posts: 974
From: Philadelphia, PA U.S.A
Registered: Mar 2003

It was the collisions. In my function, I disable collisions on both the player and the scene before the "warp" and enable them afterwards.

The whole process in virtually seamless and now I can have huge worlds hundreds of thousands of units big and the player pivot never goes past 2000 units in any direction. I used the same code I posted above, with the collision disable/enable stuff added.

Thanks, Andy. This was an excellent idea.

            

500 Post Club!

Posts: 779
From: Sherbrooke, Quebec, Canada
Registered: Jun 2003
ICQ: 26677455

------------------
GoSsE Korupted - gosse@nuloen.com
Nuclear Loaded Entertainment
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Wandering Knights - Hack'n'Slash RPG
Nuclear Nibble 3D & Blasto 3D - Classic Arcade Remakes

               

500 Post Club!

Posts: 974
From: Philadelphia, PA U.S.A
Registered: Mar 2003

500 Post Club!

Posts: 601
From:
Registered: Aug 2001

yep... And it wasn't even mine! I first saw it described in the AMOS 3D manual 10 years ago... It makes you wonder how many interesting timesaving wonderful ideas have been lost in time...

Andy

            

1,000 Post Club!


Contributing Author

Posts: 4911
From: Doncaster!!
Registered: May 2002

When a computer represents a "float", the maximum number that it stores doesn't mean the largest number, it infact means the highest number of digits, or rather, bits used.

(For demonstration's sake, I'll display this in decimal form so that it's easier.)

Let's say that this number can only go so high as 327657. That means we can only use 6 digits. It also means that 327657.1 gets rounded to 327657 automatically. Now, we could say 3.27657 no problem because we're still using 6 digits. But 32.7657493548 would be rounded to 32.7657

Gettit? That's why you should keep stuff close to the centre. The smaller the number, the higher the decimal accuracy you get. It works the same with variables too, and any other precision values in Blitz.

------------------
Please visit MUSCLE-POWER.net
Games: Blow Football - Duck Blitz - Electrobat - Veemee Arena - SPRINGY
Apps: SuperStick Fighter/Animator - Easy 3D Terrain Designer - Flare Designer/Animator - BMP Fontlib

               

500 Post Club!

Posts: 974
From: Philadelphia, PA U.S.A
Registered: Mar 2003

The coolest thing about this "huge world" model I have (now that you never actually wander too far from 0,0,0) is that you can really put lots of polygons in there, as long as the "villages" are far apart enough so that too much is never rendered at one time.

The only real limitation is watching your surface count and your textures, which can eat up your video memory. Even this can be solved by dynamically freeing parts of the world that are really far from the pivot.

[This message has been edited by Nmuta (edited 10-25-2003).]

            

500 Post Club!

Posts: 785
From:
Registered: Sep 2003

Graphics3D 640, 480, 16, 2 SetBuffer BackBuffer() AmbientLight 255, 255, 255 SeedRnd MilliSecs() camDefault = CreateCamera() CameraClsColor camDefault, 60, 110, 160 CameraZoom camDefault, .75 MoveEntity camDefault, 0, 1.5, 0 objShadow = CreateSphere(8) EntityAlpha objShadow, 0.3 EntityColor objShadow, 0, 0, 0 ScaleEntity objShadow, 0.6, 0.1, 0.6 plnGround = CreatePlane() EntityAlpha plnGround, 0.9 EntityColor plnGround, 85, 85, 85 plnMirror = CreateMirror() MoveEntity plnMirror, 0, -0.1, 0 Meshes = 1024 Dim objMeshes(Meshes) For i = 0 To Meshes Select Rand(1, 4) Case 1 objMeshes(i) = CreateCube(camDefault) Case 2 objMeshes(i) = CreateSphere(8, camDefault) Case 3 objMeshes(i) = CreateCylinder(8, True, camDefault) Case 4 objMeshes(i) = CreateCone(8, True, camDefault) End Select ScaleEntity objMeshes(i), Rnd(0.2, 0.4), Rnd(0.2, 0.4), Rnd(0.2, 0.4) MoveEntity objMeshes(i), Rnd(0, 8) - 4, Rnd(1, 8), Rnd(2, 10) RotateEntity objMeshes(i), Rnd(0, 360), Rnd(0, 360), Rnd(0, 360) EntityColor objMeshes(i), Rand(0, 255), Rand(0, 255), Rand(0, 255) Next Color 0, 0, 0 HidePointer While Not KeyDown(1) tmrStart = MilliSecs() MoveEntity camDefault, 0, 0, 200000 RenderWorld If total = 0 Then total = 1 End If Text 0, 0, total + "ms | " + 1000 / total + "FPS | " + TrisRendered() + " tris" Text 0, 15, EntityX(camDefault) + ", " + EntityZ(camDefault) Flip total = MilliSecs() - tmrStart Wend

------------------
This time around all the limits will be cut loose...
First release yourself. Let our dreams be as one if mankind is to evolve.
Teach your children the way, that they may understand.

Love is a power. Compassion a gift. No one need be empty.
No one need be scared.

               

1,000 Post Club!

Posts: 3488
From: GLD, NL
Registered: Apr 2002

500 Post Club!

Posts: 974
From: Philadelphia, PA U.S.A
Registered: Mar 2003

this has been quite an interesting study! Learned a lot.

            

Elite Member


BlitzCoder VIP
8Bit Retro Co-Winner
3rd Place!

Posts: 147
From: Ohio
Registered: Nov 2001

One headache I ran into was weird effects happening when I got further and further from the sun, as well as a loss of accurate floating point values as my sizes got smaller. I couldnt make my scale larger as that just magnified the distance problem and I couldnt decrease my scale as it made my smaller bodies (Running in the size range of .000001 or smaller) have problems.

Thanks to Andy for his sollution and provided example code and for Nmuta for posting his alterations of it so that this slow programmer could see it in 2 different lights and understand what plugged in where. When first suggested to me that I needed to change my system from moving my person thru the solar system to moving the solar system around the person ... well ... i was a bit daunted, but this post allowed me to cope with it and the change turned out rather simple. I definatly spent less time changing my system than I did looking for answers to why it was acting so odd.

Thanks again fellas and *BUMP* on this post because others might gain from it as well.

------------------
High Voltage - Emerald Miner - AutoBattler
Come give us a Look See at :
http://public.w3site.us

               

Veteran Member

Posts: 256
From:
Registered: Jan 2004

Instead of moving the camera and all, have a function that can rotate, move, etc every entity except the players?

               

1,000 Post Club!


Contributing Author

Posts: 1407
From: California, US
Registered: Nov 2001

------------------
Jonathan Nguyen
world_creator@hotmail.com

Single-Surface Particles Lib. | Depth of Field and misc. Effects | Mesh Rain Tech Demo
Terrain Conforming Grids | Vertex Alpha Demo | Anti-Aliased Lines

               

500 Post Club!

Posts: 601
From:
Registered: Aug 2001

I aim to please As I said it wasn't even my idea.

>I dont have B3D but wouldnt this work for "normalizing":
>Move the world, not the player?

yes, but it isn't that easy. You would end up having to write code to do everything that B3D does already and add overhead.

>Instead of moving the camera and all, have a function that can rotate,
>move, etc every entity except the players?

At the cost of complexity and speed. The way described above weighs in at just a few lines of code and works, whereas rewriting B3D's movement, rotation and collision code will add hundreds of lines and slow the program.

Simple beats complex almost every time. This is propably the single most dificult concept for new programmers to understand, but it is vital to the process.

Andy

[This message has been edited by Andy (edited 07-30-2004).]

            

1,000 Post Club!


Contributing Author

Posts: 1407
From: California, US
Registered: Nov 2001

------------------
Jonathan Nguyen
world_creator@hotmail.com

Single-Surface Particles Lib. | Depth of Field and misc. Effects | Mesh Rain Tech Demo
Terrain Conforming Grids | Vertex Alpha Demo | Anti-Aliased Lines

               

500 Post Club!

Posts: 601
From:
Registered: Aug 2001

But it doesn't solve the problem - the errors due to floating point inaccuracy and Z-buffer inaccuracy are still there.

Andy

            

500 Post Club!

Posts: 974
From: Philadelphia, PA U.S.A
Registered: Mar 2003