Soo....... a slopes in SRB2 topic for the 100+th time. But this time it's different, now it's with ACTION, not just talk.
We can skip the whole "is it possible/software/opengl" part and skip straight to the implementation, and the complications slopes introduce. Remember this is EXPERIMENTAL, as in, it never has to be anything more than a test engine just to finally say that it was possible, the non-sloped gameplay of regular SRB2 is not in jeopardy at all.
Brainstorm, suggest math, ideas, and have an open, civil discussion!
Background:
If you've been in this community for any amount of time, you'll know how much people have asked for slopes in SRB2. SRB2CB is the most recent attempt and might serve as something of a "Step 1" for a Sonic style slope/loopidy loop engine in SRB2.
OLD topics:
2006, this is antiporcupine's old topic from a long time ago, it was like one of the first attempts at slopes in SRB2:
http://mb.srb2.org/showthread.php?t=18359
Other attempts:
http://mb.srb2.org/showthread.php?t=27589
This topic did the opposite - it tried porting something of SRB2's nature to GZDoom
http://mb.srb2.org/showthread.php?t=31725
All talk:
http://mb.srb2.org/showthread.php?t=33743
http://mb.srb2.org/showthread.php?t=31066
http://mb.srb2.org/showthread.php?t=32488
Now here's a look back at a recent slope topic to see what got accomplished with getting slopes in SRB2, and let's see where we should go from here.
http://mb.srb2.org/showthread.php?t=32907
lol
When I first read this, not sure exactly what this person meant, but I knew it meant more than just smoothed stairs, give some slope characteristics to help the gameplay!
check
check!
check!
Got it! SRB2CB uses the normal(vector) of the sector to jump perpendicular to the surface!
Got it! SRB2CB's slope catapulting can work rather well.
Wasn't exactly sure what this meant, but you can make a slope of any "irregular" arbitrary angle, and slopes that can update and move irregularly, so this is probably a check.
Not sure exactly how this user meant "bad hacks" but there is definitely some math involved with SRB2CB's implementation, and definitely some fixed approximations. Whether or not this counts as a "bad hack" I'm not sure. I assure you though, a majority of SRB2 is full of similar hacks where things are defined specifically without being programmatically/mathematically "correct". Though in the realm of bad hacks, SRB2CB's slope implementation tries to be as unscrippted as possible i.e. going off a ramp doesn't need any "invisible launch off ramp spring" or anything like that.
It's not "worth it", but it's not impossible, not just for a half-way vector implementation but a serious 360 degree redesign of the movement code. It just takes a lot of time and effort, and for most cases it's simply unnecessary for the amount of work it takes, plus the nature of the map editor and the game's common use of sprites make it impractical, but "true" slopes are certainly not impossible.
SRB2 isn't designed for a 360 degree kind of sonic gameplay - I mean from just the sprites, which is a core characteristic of this game, you can tell it wasn't really designed for 360 degree twist/loop gameplay.
But then again, it's not impossible to render slopes in software mode, and not because of ZDOOM, but because of Quake 1, a related engine that has software mode with 360 degree view support. When I say related, the code is very different but if you know what you're doing you can certainly substitute SRB2's Doom Engine renderer for a more advanced Quake version with real 3D rendering support (even MD2 model support!)
This part is true, essentially, slopes that were REALLY used everywhere wouldn't make sense for this type of game. It's possible, but not practical.
Now if doing it just for the heck of is an option, then let's continue ;)
--------
And for even more "for the heck of it"-ness, let's assume we want slopes in software mode in addition to OpenGL mode
The renderer can be rewritten by processing all level geometry in real 3D and rewriting software mode to be a true Quake-style polygonal renderer. This can be done using Quake engine code, knowledge of how software renderers work and vector math is a must though.
We're lucky here because of the Doom Engine's setup, we don't really have to rewrite the collision code. We can do it they way all the other Doom source ports do it, which is just insert slopes right into the wall collision code, just with more fine accuracy.
But we don't have to worry about this since SRB2CB already has an implementation, it just needs more fixing.
By the way, this is where SRB2CB got its slope math from, it wasn't a direct port at all though and required effort. Eternity's slopes only render for software mode and have no collision at all. I had to make slopes work for the opposite - with SRB2's quirky OpenGL renderer, add in the collision myself, then make some basic slope physics on top of that :P
:)
Where should slopes go from here?
A) Make them work in software mode
B) Leave them as is and just fix/improve on them under the notion of people don't need a full 360 degree Wizard 2 like engine
C) All of the above just for the heck of it
How to redo the movement code for slopes:
Delta time - this is huge because this is why SRB2 can lag SO bad, it processes things at 35FPS regardless of how fast the computer is running it, so you get intense lag when there's lag.
Doubling the FPS is even MORE impossible because then you get 2X the lag if the game lags at all!!
Delta time is simply a time based movement system where all movement is divided by update speed, this would be a helpful thing to do for a good vector implementation, BlitzSonic and SonicGDK both use this kind of time system.
Walk on walls.
Doing this is important to true loop capabilities, you want the game to be able to handle running on walls. But it's not that simple is it?
The issue is - you need vectors and translations of movement. XYZ is not the way to do it.
Now even though this is math, it's much simpler than it sounds.
A vector can be thought of as a "3D line", they have other uses but this is one of them.
So how would this help us with movement?
We can use a vector to represent the direction of the player, this is cool because we can represent the line in 3D. Think of how you can move the camera's angles in SRB2's first person mode, you can look in one direction and shoot a weapon to make it travel in that direction. Imagine the direction of it being a 3D line aka a vector.
So the nature of vectors is that we can move them around and rotate them yet still have the "same" vector.
The player is moving forward, you got a straight line showing his direction. When you press forward on the keyboard, he goes forward.
Uh-oh, we have 45 degree slope here, the player is going in the same direction, but he's ON the slope.
Right now SRB2CB makes the player move the same way on a slope as if he was on flat ground, but the player shouldn't do that, he shouldn't just speed through a slope like that!
Let's use a vector, now the game knows the player wants to move 10 units forward, we can represent this as a straight line, but now we're on a slope! The player still WANTS to move at the same speed but not in the same direction anymore, what happens now?
Wonderful vector math. Take that vector that would have made you move 10 units forward on flat ground, and now rotate it 45 degrees upward. Our vector now moves us 5 units forward, and 5 units upward at the same time! We've moved along the slope by not just moving forward but also upward with the tilt of the slope!
Just to test this, disable all the SRB2's gravity and friction just to test if the math works by itself, when it does, then AWESOME.
Using this same method of rotating the desired movement vector, we can handle walls too! The player would want to move 10 units forward on flat land, he's on a 90 degree wall now, that translates to 10 units upward since we're moving straight up the wall.
Now this is with all other forces disabled, this is just testing our movement along walls and floors. So now we should be able to stick to walls and slopes using correct movement code.
Also, our collision system will help us not go through walls and floors even if we don't move perfectly along the surface to the point where we weren't colliding with it. This is an important concept to grasp, because SRB2CB's slopes abuse this collision aspect. This is why you can move up a slope, not because the movement system makes you move up, but because its abusing that you can't go through a slope. This is essentially treating slopes like step-up stairs and is why the character goes disproportionately fast on steep slopes. Switching to a true vector based system wouldn't have this problem, and could handle movement on slopes even without direct XYZ collision to fall back on.
Right now SRB2CB doesn't use vectors for the movement code to properly translate for example, a desired forward movement of 10 units on a flat land to something like 5 units forward, 5 units up on a slope of 45 degrees. It's this movement translation that would make a real slope system where catapulting off a slope IS because you were moving on the up axis. SRB2CB only approximates this.
So with that movement system redone to support slope and do real slopes where desired horizontal movement gets translated to vertical movement in the player's final movement, the player would then be able to properly move along slopes and walls if no other forces were acting on him.
Now for the second most important part
Gravity, Normals, and Friction.
Once the vector based movement translation system is done, this is relatively simple. The player's desired movement vectors can stay the same, but the player has a different set of final movement vectors.
Remember how say, a desired movement of 10 units forward, translates to 10 units forward on flat ground, but like 5 units forward, 5 units up on a 45 degree slope? The place the player actually will move to is the final movement vector, and this is after the player's movement has been translated. Now with gravity and friction, we don't just translate the player's movement, but we actually change it.
Gravity would be a constant vector of force that goes downward. The force of gravity is added to the player's movement vector every frame. (TODO: Find out how the force of gravity should change over time when an object is falling)
Gravity would be the NATURAL force that gives slopes their traits. The friction of the player being on the slope and the force of gravity is what makes it so you can go faster when running down a slope. The friction between the object on a slope and the slope's surface and the force of gravity would be what makes the sliding down a slope happen.
Going slower up a slope is because of the weight of the object and again, the force of gravity. The weight of an object effects how fast it can go up slopes (TODO: Assign everything in the world a weight property to go with the new physics system). Heavy objects go up slopes slower, and gain more speed going down slopes (TODO: Wait, is that right? Because of the "objects fall at the same speed" thing, does that mean that heavier objects DON'T have more speed when going down a slope?")
So gravity would be the natural vector force that makes the slope physics really work.
Going off ramps would mean that you really HAD the inertia to go upward because of that "translate 5 units forward 5 units up" example, and gravity would be the force that allows you to go down at not just keep traveling in the same direction.
----
So yeah, to start off the topic, that's basically my fleshed out idea of how to exactly implement a real slope system.
Please post comments, strong criticism, or corrections, or suggestions to this idea.
We can skip the whole "is it possible/software/opengl" part and skip straight to the implementation, and the complications slopes introduce. Remember this is EXPERIMENTAL, as in, it never has to be anything more than a test engine just to finally say that it was possible, the non-sloped gameplay of regular SRB2 is not in jeopardy at all.
Brainstorm, suggest math, ideas, and have an open, civil discussion!
Background:
If you've been in this community for any amount of time, you'll know how much people have asked for slopes in SRB2. SRB2CB is the most recent attempt and might serve as something of a "Step 1" for a Sonic style slope/loopidy loop engine in SRB2.
OLD topics:
2006, this is antiporcupine's old topic from a long time ago, it was like one of the first attempts at slopes in SRB2:
http://mb.srb2.org/showthread.php?t=18359
Other attempts:
http://mb.srb2.org/showthread.php?t=27589
This topic did the opposite - it tried porting something of SRB2's nature to GZDoom
http://mb.srb2.org/showthread.php?t=31725
All talk:
http://mb.srb2.org/showthread.php?t=33743
http://mb.srb2.org/showthread.php?t=31066
http://mb.srb2.org/showthread.php?t=32488
Now here's a look back at a recent slope topic to see what got accomplished with getting slopes in SRB2, and let's see where we should go from here.
http://mb.srb2.org/showthread.php?t=32907
lol
When I first read this, not sure exactly what this person meant, but I knew it meant more than just smoothed stairs, give some slope characteristics to help the gameplay!
check
check!
check!
Got it! SRB2CB uses the normal(vector) of the sector to jump perpendicular to the surface!
Got it! SRB2CB's slope catapulting can work rather well.
Wasn't exactly sure what this meant, but you can make a slope of any "irregular" arbitrary angle, and slopes that can update and move irregularly, so this is probably a check.
Not sure exactly how this user meant "bad hacks" but there is definitely some math involved with SRB2CB's implementation, and definitely some fixed approximations. Whether or not this counts as a "bad hack" I'm not sure. I assure you though, a majority of SRB2 is full of similar hacks where things are defined specifically without being programmatically/mathematically "correct". Though in the realm of bad hacks, SRB2CB's slope implementation tries to be as unscrippted as possible i.e. going off a ramp doesn't need any "invisible launch off ramp spring" or anything like that.
It's not "worth it", but it's not impossible, not just for a half-way vector implementation but a serious 360 degree redesign of the movement code. It just takes a lot of time and effort, and for most cases it's simply unnecessary for the amount of work it takes, plus the nature of the map editor and the game's common use of sprites make it impractical, but "true" slopes are certainly not impossible.
SRB2 isn't designed for a 360 degree kind of sonic gameplay - I mean from just the sprites, which is a core characteristic of this game, you can tell it wasn't really designed for 360 degree twist/loop gameplay.
But then again, it's not impossible to render slopes in software mode, and not because of ZDOOM, but because of Quake 1, a related engine that has software mode with 360 degree view support. When I say related, the code is very different but if you know what you're doing you can certainly substitute SRB2's Doom Engine renderer for a more advanced Quake version with real 3D rendering support (even MD2 model support!)
This part is true, essentially, slopes that were REALLY used everywhere wouldn't make sense for this type of game. It's possible, but not practical.
Now if doing it just for the heck of is an option, then let's continue ;)
--------
And for even more "for the heck of it"-ness, let's assume we want slopes in software mode in addition to OpenGL mode
The renderer can be rewritten by processing all level geometry in real 3D and rewriting software mode to be a true Quake-style polygonal renderer. This can be done using Quake engine code, knowledge of how software renderers work and vector math is a must though.
We're lucky here because of the Doom Engine's setup, we don't really have to rewrite the collision code. We can do it they way all the other Doom source ports do it, which is just insert slopes right into the wall collision code, just with more fine accuracy.
But we don't have to worry about this since SRB2CB already has an implementation, it just needs more fixing.
SSNTails said:
By the way, this is where SRB2CB got its slope math from, it wasn't a direct port at all though and required effort. Eternity's slopes only render for software mode and have no collision at all. I had to make slopes work for the opposite - with SRB2's quirky OpenGL renderer, add in the collision myself, then make some basic slope physics on top of that :P
:)
Where should slopes go from here?
A) Make them work in software mode
B) Leave them as is and just fix/improve on them under the notion of people don't need a full 360 degree Wizard 2 like engine
C) All of the above just for the heck of it
How to redo the movement code for slopes:
Delta time - this is huge because this is why SRB2 can lag SO bad, it processes things at 35FPS regardless of how fast the computer is running it, so you get intense lag when there's lag.
Doubling the FPS is even MORE impossible because then you get 2X the lag if the game lags at all!!
Delta time is simply a time based movement system where all movement is divided by update speed, this would be a helpful thing to do for a good vector implementation, BlitzSonic and SonicGDK both use this kind of time system.
Walk on walls.
Doing this is important to true loop capabilities, you want the game to be able to handle running on walls. But it's not that simple is it?
The issue is - you need vectors and translations of movement. XYZ is not the way to do it.
Now even though this is math, it's much simpler than it sounds.
A vector can be thought of as a "3D line", they have other uses but this is one of them.
So how would this help us with movement?
We can use a vector to represent the direction of the player, this is cool because we can represent the line in 3D. Think of how you can move the camera's angles in SRB2's first person mode, you can look in one direction and shoot a weapon to make it travel in that direction. Imagine the direction of it being a 3D line aka a vector.
So the nature of vectors is that we can move them around and rotate them yet still have the "same" vector.
The player is moving forward, you got a straight line showing his direction. When you press forward on the keyboard, he goes forward.
Uh-oh, we have 45 degree slope here, the player is going in the same direction, but he's ON the slope.
Right now SRB2CB makes the player move the same way on a slope as if he was on flat ground, but the player shouldn't do that, he shouldn't just speed through a slope like that!
Let's use a vector, now the game knows the player wants to move 10 units forward, we can represent this as a straight line, but now we're on a slope! The player still WANTS to move at the same speed but not in the same direction anymore, what happens now?
Wonderful vector math. Take that vector that would have made you move 10 units forward on flat ground, and now rotate it 45 degrees upward. Our vector now moves us 5 units forward, and 5 units upward at the same time! We've moved along the slope by not just moving forward but also upward with the tilt of the slope!
Just to test this, disable all the SRB2's gravity and friction just to test if the math works by itself, when it does, then AWESOME.
Using this same method of rotating the desired movement vector, we can handle walls too! The player would want to move 10 units forward on flat land, he's on a 90 degree wall now, that translates to 10 units upward since we're moving straight up the wall.
Now this is with all other forces disabled, this is just testing our movement along walls and floors. So now we should be able to stick to walls and slopes using correct movement code.
Also, our collision system will help us not go through walls and floors even if we don't move perfectly along the surface to the point where we weren't colliding with it. This is an important concept to grasp, because SRB2CB's slopes abuse this collision aspect. This is why you can move up a slope, not because the movement system makes you move up, but because its abusing that you can't go through a slope. This is essentially treating slopes like step-up stairs and is why the character goes disproportionately fast on steep slopes. Switching to a true vector based system wouldn't have this problem, and could handle movement on slopes even without direct XYZ collision to fall back on.
Right now SRB2CB doesn't use vectors for the movement code to properly translate for example, a desired forward movement of 10 units on a flat land to something like 5 units forward, 5 units up on a slope of 45 degrees. It's this movement translation that would make a real slope system where catapulting off a slope IS because you were moving on the up axis. SRB2CB only approximates this.
So with that movement system redone to support slope and do real slopes where desired horizontal movement gets translated to vertical movement in the player's final movement, the player would then be able to properly move along slopes and walls if no other forces were acting on him.
Now for the second most important part
Gravity, Normals, and Friction.
Once the vector based movement translation system is done, this is relatively simple. The player's desired movement vectors can stay the same, but the player has a different set of final movement vectors.
Remember how say, a desired movement of 10 units forward, translates to 10 units forward on flat ground, but like 5 units forward, 5 units up on a 45 degree slope? The place the player actually will move to is the final movement vector, and this is after the player's movement has been translated. Now with gravity and friction, we don't just translate the player's movement, but we actually change it.
Gravity would be a constant vector of force that goes downward. The force of gravity is added to the player's movement vector every frame. (TODO: Find out how the force of gravity should change over time when an object is falling)
Gravity would be the NATURAL force that gives slopes their traits. The friction of the player being on the slope and the force of gravity is what makes it so you can go faster when running down a slope. The friction between the object on a slope and the slope's surface and the force of gravity would be what makes the sliding down a slope happen.
Going slower up a slope is because of the weight of the object and again, the force of gravity. The weight of an object effects how fast it can go up slopes (TODO: Assign everything in the world a weight property to go with the new physics system). Heavy objects go up slopes slower, and gain more speed going down slopes (TODO: Wait, is that right? Because of the "objects fall at the same speed" thing, does that mean that heavier objects DON'T have more speed when going down a slope?")
So gravity would be the natural vector force that makes the slope physics really work.
Going off ramps would mean that you really HAD the inertia to go upward because of that "translate 5 units forward 5 units up" example, and gravity would be the force that allows you to go down at not just keep traveling in the same direction.
----
So yeah, to start off the topic, that's basically my fleshed out idea of how to exactly implement a real slope system.
Please post comments, strong criticism, or corrections, or suggestions to this idea.
