Problems with slopes and sprites

Usurper · 07-17-2001, 09:47 PM

I'm coding in a very rudimentary particle system. I'm just trying to get little fireballs and debris and whatever I have time to toss in move in an arc and bounce once or twice. I've got non-bouncing little debris working fine, and the coding is cake, so this shouldn't be a big deal. However, I can't get them to behave properly on slopes. Depending which direction I'm sloping them, they'll either fall through the slope to the sector's official floor height or float above the ramp, again at the sector's official floor height. Last I checked, enemies could walk up slopes without problem (I tried making them 'enemy' useractors as well as notenemy), and projectiles strike the ground midslope...what painfully simple thing am I missing?

alejandro · 07-18-2001, 04:45 PM

this may be a bug in build, because you can slope a sector but it has only one real height. i think you can make some continuous sectors (such as stairs) but sloping all floors, it may look as a single sloped sector but the particles will stand at the height of each sector, and will look more realistic

bye

cyborg · 07-18-2001, 06:27 PM

Erm, yes alejandro. Whatever your point was.

Usurper, the problem with slopes your experiencing is essentially down to your coding somewhere. I made bouncing sparks for the original Eduke demo remember? They were a lot of fun bouncing all over the place but when it came to the slope it treated it just as if it were flat because it bypassed the internal routines and forced the particle to occupy a position in space. To get the particle to bounce physically correctly you'd need to gather the angle from the slope. This is possible as the freezer ray demonstrates by accurately bouncing off slopes with the correct angle. What I've yet to figure out is what the mathmatical relationship between the hinum and the shape of the sector is that will give the angle of the slope.
The other problem is also calculating the z position of the floor of the slope at any point. With the angle of the slope this would be fairly easy given the perpendicular displacement from the first wall as this will form a right angled triangle from which the height can easily be derived using trigonometry.
If you figure these things out then you can use the original code in the esamp that forces a particle's position and use the refinement to give accurate bouncing for the slopes.

Usurper · 07-18-2001, 07:16 PM

I see what Alejandro means. It's more passable than long slopes, but it'd be a huge hassle to carve up every slope in the map (which I'd have to do if I wanted enemies and/or exposions to make use of the particles). Not a bad idea though.

I know what you mean about the heinum stuff, James. I considered trying to figure out the maths, much as I hate them. If I understand it right, I'd have to detect the xy pos of the firstwall, the heinum, then....well, some formula should be determinable from that. I'm horrible at non-algebraic advanced math, and not all the special with algebra to begin with. So if it requires sin or cosine, I'm lost.

My code is fairly simple and uses move rates and actioncounts to determine what arc to move in, rather than defining coords. Figured just moving a sprite would cause it to be blocked by slopes, but alas.... Perhaps this is where an eduke request would be appropriate.

cyborg · 07-18-2001, 08:20 PM

You'd have to use fall to get it to work correctly with slopes in your method.

And yes it would require some fairly advanced maths to calculate. I'm sure the routines are somewhere in the build source but I feel it might take less time for me to try and figure out the relationship by experiement and inference.

[ 07-18-2001: Message edited by: cyborg ]

Usurper · 07-19-2001, 01:43 AM

Thanks, fall did make the particles detect the slope properly. It didn't have a noticeable affect on the arc either. I could probably even make it bounce at a larger or smaller angle based on heinum, but considering I'm not using a mathematically sound arc to begin with, it's probably not worth the trouble. [img]images/icons/smile.gif[/img]

Nailed · 07-19-2001, 07:52 PM

You guys got me interested - where can I download the Duke/Build source?

Usurper · 07-20-2001, 01:21 AM

Sadly, you can't get the Duke3d part of the code, just the engine and Silverman's test game. Ken's code is at http://www.advsys.net/ken/

You can get the latest files for the win32/linux port in-progress at http://icculus.org/BUILD/

07-21-2001, 03:00 PM

Exactly how are you creating those arcs?

Usurper · 07-21-2001, 03:56 PM

It's pretty primitive, as I've said, but I don't know trig. It haven't finished the bounce code yet, so that's ommitted. You'll need eduke, unless you want to tweak it. Enjoy.

I should probably note that this base code itself isn't quite finished. There'll probably be another two sets of movement rates for the appearance of a more random velocity. The ceilingdistl code will eventually make it bounce off the ceiling rather than instantly die. Etc. etc.

[ 07-21-2001: Message edited by: Usurper ]

cyborg · 07-22-2001, 09:13 AM

Usurper, I do have to ask why on earth you're using such a long winded method?

Usurper · 07-22-2001, 08:53 PM

It just seemed the easiest way. I'm probably being dense, but what's a simpler method without setting the x/y/z coords?

Usually, I'm just happy when the code works the way I want it to. [img]images/icons/smile.gif[/img]

cyborg · 07-23-2001, 12:16 PM

<blockquote>quote:<hr>Originally posted by Usurper:
It just seemed the easiest way. I'm probably being dense, but what's a simpler method without setting the x/y/z coords?
<hr></blockquote>

The only problems come when you want to set the xy cords. To get the right direction you need to use trigonometry to work out the x and y displacement for a certain horizontal velocity at a certain angle. You don't need to worry about this in the z direction.
Now in your code you could take this approach but then it gets more complex detecting walls and floors.
Put simply there is no simple way of improving that code but the code can only be improved by imcreading the table of values to allow more possibilities. Eventually there will come a point where it is simply uneconomical to continue along this path.
It would be a lot easier to effect collision detction for walls with a looping system (it is possible to make one but it's ludicrously long winded). Floors are far more simple because it's easy to tell which sector the actor is in (although Build is not immune from confusion as you and I well know). So figuring out the slope mathmatics would make part of your code a lot more straightforward.

Usurper · 07-23-2001, 06:51 PM

I'm surprised wall detection is even feasible. The way I read Ferry's con guide, it seemed that ifawayfromwall only returned true when the actor was near or on a red line. And I didn't think wall detection was working in eduke. Ifnotmoving won't return true if the actor can still move vertically. Granted, I should probably test ifawayfromwall myself and make sure, but the wall detection has been the thing that's stumped me most.

cyborg · 07-23-2001, 07:56 PM

When I say wall detection I mean doing it myself. The best way of doing this would be to test the path of the particle before it moves to see which walls (if any) it will cross.
Doing this would require use of the map structure which is fully accessable but of limited use when it comes to walls without looping functions. You see the way Ken designed it it's fairly simple to get the information about the wall you want but you have to start from the sector's first wall and work your way round.
The way this method would work would be to calculate the graident of each wall and see if the particle's x and y cords lie beyond it's inward facing boundary. It's not actually as complex as it sounds, it's a simple use of applied inequalities.
I really am going to have all this down somewhere.

Manson · 09-05-2001, 07:30 AM

you could calc the height of the sloped floor by getting the coords of the firstwall, get the dist from the actors pos to the wall (math_way - I'm sure Cyborg knows it) and then it's simple trig -calcs

BTW: how 'bout just calculating the height of the actor depending on how much 'power'/'energy' it has? Like when you're coding a grenade_launcher?

cyborg · 09-05-2001, 11:02 PM

<blockquote>quote:<hr>Originally posted by Manson:
you could calc the height of the sloped floor by getting the coords of the firstwall, get the dist from the actors pos to the wall (math_way - I'm sure Cyborg knows it) and then it's simple trig -calcs<hr></blockquote>

Waste of an actor but there's no reason that shouldn't work - I'd rather find a pure maths way.

<blockquote>quote:<hr>BTW: how 'bout just calculating the height of the actor depending on how much 'power'/'energy' it has? Like when you're coding a grenade_launcher?<hr></blockquote>

Eh? Explain what you mean. Be careful with your terms. Power and energy are specific things. Power represents energy per second. The energy of the projectile as it's fired from a grenade launcher doesn't affect the shape of the path it follows, only the size of the parabolic arc. There are many types of energy at work, the kenetic energy of the initial firing propells the object but it's potential energy in a gravitational field is what brings it to the ground.
Using a route based on energies would be far more complex, not simpler.

07-21-2001, 03:00 PM	#9
Guest Guest	Re: Problems with slopes and sprites Exactly how are you creating those arcs?

07-17-2001, 09:47 PM	#1
Usurper	Problems with slopes and sprites I'm coding in a very rudimentary particle system. I'm just trying to get little fireballs and debris and whatever I have time to toss in move in an arc and bounce once or twice. I've got non-bouncing little debris working fine, and the coding is cake, so this shouldn't be a big deal. However, I can't get them to behave properly on slopes. Depending which direction I'm sloping them, they'll either fall through the slope to the sector's official floor height or float above the ramp, again at the sector's official floor height. Last I checked, enemies could walk up slopes without problem (I tried making them 'enemy' useractors as well as notenemy), and projectiles strike the ground midslope...what painfully simple thing am I missing? __________________ Meadhall of the Comitatus \| RTCM

07-18-2001, 04:45 PM	#2
alejandro	Re: Problems with slopes and sprites this may be a bug in build, because you can slope a sector but it has only one real height. i think you can make some continuous sectors (such as stairs) but sloping all floors, it may look as a single sloped sector but the particles will stand at the height of each sector, and will look more realistic bye

07-18-2001, 06:27 PM	#3
cyborg	Re: Problems with slopes and sprites Erm, yes alejandro. Whatever your point was. Usurper, the problem with slopes your experiencing is essentially down to your coding somewhere. I made bouncing sparks for the original Eduke demo remember? They were a lot of fun bouncing all over the place but when it came to the slope it treated it just as if it were flat because it bypassed the internal routines and forced the particle to occupy a position in space. To get the particle to bounce physically correctly you'd need to gather the angle from the slope. This is possible as the freezer ray demonstrates by accurately bouncing off slopes with the correct angle. What I've yet to figure out is what the mathmatical relationship between the hinum and the shape of the sector is that will give the angle of the slope. The other problem is also calculating the z position of the floor of the slope at any point. With the angle of the slope this would be fairly easy given the perpendicular displacement from the first wall as this will form a right angled triangle from which the height can easily be derived using trigonometry. If you figure these things out then you can use the original code in the esamp that forces a particle's position and use the refinement to give accurate bouncing for the slopes. __________________ You lose.

07-18-2001, 07:16 PM	#4
Usurper	Re: Problems with slopes and sprites I see what Alejandro means. It's more passable than long slopes, but it'd be a huge hassle to carve up every slope in the map (which I'd have to do if I wanted enemies and/or exposions to make use of the particles). Not a bad idea though. I know what you mean about the heinum stuff, James. I considered trying to figure out the maths, much as I hate them. If I understand it right, I'd have to detect the xy pos of the firstwall, the heinum, then....well, some formula should be determinable from that. I'm horrible at non-algebraic advanced math, and not all the special with algebra to begin with. So if it requires sin or cosine, I'm lost. My code is fairly simple and uses move rates and actioncounts to determine what arc to move in, rather than defining coords. Figured just moving a sprite would cause it to be blocked by slopes, but alas.... Perhaps this is where an eduke request would be appropriate. __________________ Meadhall of the Comitatus \| RTCM

07-18-2001, 08:20 PM	#5
cyborg	Re: Problems with slopes and sprites You'd have to use fall to get it to work correctly with slopes in your method. And yes it would require some fairly advanced maths to calculate. I'm sure the routines are somewhere in the build source but I feel it might take less time for me to try and figure out the relationship by experiement and inference. [ 07-18-2001: Message edited by: cyborg ] __________________ You lose.

07-19-2001, 01:43 AM	#6
Usurper	Re: Problems with slopes and sprites Thanks, fall did make the particles detect the slope properly. It didn't have a noticeable affect on the arc either. I could probably even make it bounce at a larger or smaller angle based on heinum, but considering I'm not using a mathematically sound arc to begin with, it's probably not worth the trouble. [img]images/icons/smile.gif[/img] __________________ Meadhall of the Comitatus \| RTCM

07-19-2001, 07:52 PM	#7
Nailed	Re: Problems with slopes and sprites You guys got me interested - where can I download the Duke/Build source?

07-20-2001, 01:21 AM	#8
Usurper	Re: Problems with slopes and sprites Sadly, you can't get the Duke3d part of the code, just the engine and Silverman's test game. Ken's code is at http://www.advsys.net/ken/ You can get the latest files for the win32/linux port in-progress at http://icculus.org/BUILD/ __________________ Meadhall of the Comitatus \| RTCM

07-21-2001, 03:56 PM	#10
Usurper	Re: Problems with slopes and sprites It's pretty primitive, as I've said, but I don't know trig. It haven't finished the bounce code yet, so that's ommitted. You'll need eduke, unless you want to tweak it. Enjoy. I should probably note that this base code itself isn't quite finished. There'll probably be another two sets of movement rates for the appearance of a more random velocity. The ceilingdistl code will eventually make it bounce off the ceiling rather than instantly die. Etc. etc. [ 07-21-2001: Message edited by: Usurper ] __________________ Meadhall of the Comitatus \| RTCM

07-22-2001, 09:13 AM	#11
cyborg	Re: Problems with slopes and sprites Usurper, I do have to ask why on earth you're using such a long winded method? __________________ You lose.

07-22-2001, 08:53 PM	#12
Usurper	Re: Problems with slopes and sprites It just seemed the easiest way. I'm probably being dense, but what's a simpler method without setting the x/y/z coords? Usually, I'm just happy when the code works the way I want it to. [img]images/icons/smile.gif[/img] __________________ Meadhall of the Comitatus \| RTCM

07-23-2001, 12:16 PM	#13
cyborg	Re: Problems with slopes and sprites <blockquote><font size="1" face="Verdana, Arial">quote:</font><hr>Originally posted by Usurper: It just seemed the easiest way. I'm probably being dense, but what's a simpler method without setting the x/y/z coords? <hr></blockquote> The only problems come when you want to set the xy cords. To get the right direction you need to use trigonometry to work out the x and y displacement for a certain horizontal velocity at a certain angle. You don't need to worry about this in the z direction. Now in your code you could take this approach but then it gets more complex detecting walls and floors. Put simply there is no simple way of improving that code but the code can only be improved by imcreading the table of values to allow more possibilities. Eventually there will come a point where it is simply uneconomical to continue along this path. It would be a lot easier to effect collision detction for walls with a looping system (it is possible to make one but it's ludicrously long winded). Floors are far more simple because it's easy to tell which sector the actor is in (although Build is not immune from confusion as you and I well know). So figuring out the slope mathmatics would make part of your code a lot more straightforward. __________________ You lose.

07-23-2001, 06:51 PM	#14
Usurper	Re: Problems with slopes and sprites I'm surprised wall detection is even feasible. The way I read Ferry's con guide, it seemed that ifawayfromwall only returned true when the actor was near or on a red line. And I didn't think wall detection was working in eduke. Ifnotmoving won't return true if the actor can still move vertically. Granted, I should probably test ifawayfromwall myself and make sure, but the wall detection has been the thing that's stumped me most. __________________ Meadhall of the Comitatus \| RTCM

07-23-2001, 07:56 PM	#15
cyborg	Re: Problems with slopes and sprites When I say wall detection I mean doing it myself. The best way of doing this would be to test the path of the particle before it moves to see which walls (if any) it will cross. Doing this would require use of the map structure which is fully accessable but of limited use when it comes to walls without looping functions. You see the way Ken designed it it's fairly simple to get the information about the wall you want but you have to start from the sector's first wall and work your way round. The way this method would work would be to calculate the graident of each wall and see if the particle's x and y cords lie beyond it's inward facing boundary. It's not actually as complex as it sounds, it's a simple use of applied inequalities. I really am going to have all this down somewhere. __________________ You lose.

09-05-2001, 07:30 AM	#16
Manson	Re: Problems with slopes and sprites you could calc the height of the sloped floor by getting the coords of the firstwall, get the dist from the actors pos to the wall (math_way - I'm sure Cyborg knows it) and then it's simple trig -calcs BTW: how 'bout just calculating the height of the actor depending on how much 'power'/'energy' it has? Like when you're coding a grenade_launcher? __________________ The NightStrike... >> www.nightstrike.tk a working EDuke 2.1 mulitiplayer MOD - finaly

09-05-2001, 11:02 PM	#17
cyborg	Re: Problems with slopes and sprites <blockquote><font size="1" face="Verdana, Arial">quote:</font><hr>Originally posted by Manson: you could calc the height of the sloped floor by getting the coords of the firstwall, get the dist from the actors pos to the wall (math_way - I'm sure Cyborg knows it) and then it's simple trig -calcs<hr></blockquote> Waste of an actor but there's no reason that shouldn't work - I'd rather find a pure maths way. <blockquote><font size="1" face="Verdana, Arial">quote:</font><hr>BTW: how 'bout just calculating the height of the actor depending on how much 'power'/'energy' it has? Like when you're coding a grenade_launcher?<hr></blockquote> Eh? Explain what you mean. Be careful with your terms. Power and energy are specific things. Power represents energy per second. The energy of the projectile as it's fired from a grenade launcher doesn't affect the shape of the path it follows, only the size of the parabolic arc. There are many types of energy at work, the kenetic energy of the initial firing propells the object but it's potential energy in a gravitational field is what brings it to the ground. Using a route based on energies would be far more complex, not simpler. __________________ You lose.