Well, there have been a few WIP slopes in the past, but none of them have ever gotten anywhere significantly stable and with working physics.
Slopes
- Thread starter Virt
- Start date
- Status
I'm just not seeing how you could coax the software renderer into drawing sloped terrain, short of rewriting it from scratch. I mean, if we were working exclusively with OpenGL, I could see it happening, but software already looks awkward when you tilt the camera at less-than-conservative angles; it's not really meant for anything other than Doom.
So? I still want to see how zdoom does it, regardless of compatibility. Besides, You got polyobjects into SRB2 some how and Doom Legacy never even had them. Heck, for sometime before 2.0 was announced I though that Polyobjects were a Zdoom only thing.
*Starts looking for a C++ book*
That's why it will be the last thing to tackle.
My plan:
Target 1: Render Slopes
Target 2: Collision if not obtained in step 1
Target 3: physics based off of my psudoslope physics experiments.
Target 4: more refined Slop Physics.
Last edited:
MechaS3K
NEVAR FORGET
I wish you the best of luck glaber. I hope your crazy plan works. Because the nuts-and-bolts of SRB2, the slopes rendering of ZDooM, and the multiplayer infrastructure of Skulltag combined successfully can only lead to an epic win.
EDIT: *reads ZDooM slopes wiki article* This might not work as well as I hoped. First of all, all slope calculations are done at load-time, so no moving slopes. You need to mess around with scripting to make a basic slope. And in some cases you need to manually specify the height of each vertex to do what you want.
EDIT: *reads ZDooM slopes wiki article* This might not work as well as I hoped. First of all, all slope calculations are done at load-time, so no moving slopes. You need to mess around with scripting to make a basic slope. And in some cases you need to manually specify the height of each vertex to do what you want.
Last edited:
I only grabbed Skulltag's source because of the software slope rendering.
This is the topic got me looking into Skulltag's source: http://mb.srb2.org/showthread.php?t=33026&highlight=Skulltag
This is the topic got me looking into Skulltag's source: http://mb.srb2.org/showthread.php?t=33026&highlight=Skulltag
SSNTails
What part of 'RETIRED' don't you understand?
There's a source port known as Eternity that flies under the radar. This is where I got the polyobjects from, and improved upon them. Eternity also has portals - I just never got around to doing those.
Having written a game with slopes, do you really think I don't know what I'm talking about?
Loops suck and are overrated. If you force the player onto a path, they're just cutscenes. If you don't, then players fall off the sides. If you fence the sides so players can't fall off, they're just not fun either (see Sonic R).
It's an example of a great mechanic in 2D gameplay not working in 3D.
pffftthahahahaha
MechaS3K
NEVAR FORGET
What exactly do you mean by portals?
Cue
ALAM STOP BREAKING THE S
Portal Portals...
Yeah, glaber, you're only just reading a C++ book and think you'll be able to pull off slopes? You're aiming too high, and I mean this in the nicest way possible, the best programmers in this community haven't pulled off slopes properly, and you haven't even started learning it...?
Also, SRB2 is in C, not C++.
Ah slopes... ah loops...
A tad late but: a slope wouldn't work like a conveyor. A conveyor belt has a horizontal force that carries the mobj, while a slope itself doesn't have any force. What you see in Sonic Classic's slopes are friction and gravity working against player's movement.
Interestingly, people say that slopes and loops are doable but they don't say (or propose) the method of how the software will handle the slopes and how the software will detect collision between the mobj and the slopes' floor/ceiling.
Proposing slopes to be implemented without giving any feasible idea or method of how to do it properly is a tad pointless. If someone believes it's possible with current system, just be kind and give us a proof.
I saw that slopes can be rendered: nice; but with no collision: bad. It's like stepping on fake floor, I saw it. I could give ideas of a method for slopes as well, but... since I'm not totally sure of how the software detects the collision between the mobj and the floor in a map, I don't feel like doing so.
To be frank (if it was doable) simple wedge-like ramps are more than enough. Loops and other 3D meshed bodies would be too much eye-candy in SRB2.
A tad late but: a slope wouldn't work like a conveyor. A conveyor belt has a horizontal force that carries the mobj, while a slope itself doesn't have any force. What you see in Sonic Classic's slopes are friction and gravity working against player's movement.
Interestingly, people say that slopes and loops are doable but they don't say (or propose) the method of how the software will handle the slopes and how the software will detect collision between the mobj and the slopes' floor/ceiling.
Proposing slopes to be implemented without giving any feasible idea or method of how to do it properly is a tad pointless. If someone believes it's possible with current system, just be kind and give us a proof.
I saw that slopes can be rendered: nice; but with no collision: bad. It's like stepping on fake floor, I saw it. I could give ideas of a method for slopes as well, but... since I'm not totally sure of how the software detects the collision between the mobj and the floor in a map, I don't feel like doing so.
To be frank (if it was doable) simple wedge-like ramps are more than enough. Loops and other 3D meshed bodies would be too much eye-candy in SRB2.
Last edited:
I guess I really don't know what I'm talking about. So I'll shut-up about slopes now.
*Quietly goes back to his corner.*
Portals in srb2 would seem like a very good idea to me.
Great for making a boss with a path that looks like it never ends.
It's just an extra effect of the Teleport linedef type, activated with Effect 3 flag.
- Status