Why is so difficult to make a slope?

Status
Not open for further replies.

Kim the Fox!!!

What am I doing here?
Don't take it to the bad side, but why about to study the other games tech and applying it on SRB2? It could be cool.
 
It's not difficult. Check SRB2Cineblast's SVN, there's a port of ZDoom's plane alignment code (the logic behind the slopes) and rendering slopes in hardware mode would be trivial. Using 3 things in a triangle formation (the same setup as in Wizard engine), you could find their cross product, then use it to alter x, y, and z momentum when jumping, thus allowing for slopes physics.

It's not a hard recipe. All the ingredients are there - all it takes is to put it together. I might well even do a modification to Cineblast and use existing slope rendering code in conjunction with stair sectors to produce a passable slope.

As for ramp physics, the triangle method given earlier allows a very high jump if done at the right point, actual ramp physics would be difficult to imitate.
 
inb4 every active SRB2 developer mocks you

It's not that simple. Enemy thinkers would most likely cease to function when tracking a player on a slope. ZDooM's(GZDooM's actually) slope code is static. And besides, OGL is buggy enough already. I'd think the priority would be to fix the bugs we already have then add such a potential can of worms.

Unless you're talking about software mode, in which case fuggeditaboutit.
 
Well, why don't we find out who's right? Let's see if he can get slopes supported in Cineblast.
 
Did I hear "Slopes"? If Cinefast can pull it off I'll have no need for my psudo Slopes.
 
Well, I'll bet that even if slopes become possible, I'd hazard a guess that they'll be so much harder to make than pseudo-slopes that they won't get used much.
 
I guess we'll just wait and see...I'll look forward to Cinefast's slopes if it comes through.
 
inb4 every active SRB2 developer mocks you

It's not that simple. Enemy thinkers would most likely cease to function when tracking a player on a slope. ZDooM's(GZDooM's actually) slope code is static. And besides, OGL is buggy enough already. I'd think the priority would be to fix the bugs we already have then add such a potential can of worms.

Unless you're talking about software mode, in which case fuggeditaboutit.

and use existing slope rendering code in conjunction with stair sectors to produce a passable slope.

Yeah. Somehow I doubt a renderer change of all things would cause enemy thinkers to stop functioning. And the slope physics wouldn't even be remotely related to any disturbance. Also, I'm aware, and you word it as if GZDoom has slopes but ZDoom doesn't. Wrong, ZDoom has them and renders them in software mode.

And even if my current idea of stair sectors which look like slopes and have slope physics was unacceptable, Eternity Engine is getting slopes coded, considering PolyObjects which are rather complex were ported from it, slopes should be trivial.

Also, OGL is not buggy. That's Software. OpenGL's problem is a lack of implementations. (For example, fog). And the slope rendering code doesn't require more than ten lines of code or so.
 
I love how everyone is so worried over the implementation of slopes, yet not one person has thought about the implications of their inclusion.

There's a very good reason why we never finished coding slopes. Think about it.
 
Last edited:
...aside from a bit of physics rewriting and the probable need for more sprites, can't say as I can think of one myself.
 
Both of which fall under implementation.

Ok, let me put it this way: How would the inclusion of slopes affect SRB2?
 
...aside from a bit of physics rewriting and the probable need for more sprites, can't say as I can think of one myself.

Or sprite rotation. Or better yet, keep as ZDoom does it and do nothing. If we all stood perpendicular to slopes we'd fall off with even a fairly low gradient.

Spazzo, it allows for more variety in levels. It allows for a closer approximation of the classic Sonic games. It could even allow loops.

Some will say, "SRB2's already fun and featureful enough in 3D mode".

They may be right, but now let's see 2D mode - a 2D sonic game just does not work right without at least slopes. It turns it from a Sonic game to some sort of Mario-esque variant when it's all flat.
 
Does a closer approximation to the 2D classic games equal a more enjoyable 3D experience?

SRB2's 2D mode was intended to be an extra trinket. It was never intended to be a full-fledged simulation of the classic games, nevermined a full-fledged feature on its own.

What I'm trying to get you to realize is just how much slopes would change the game. We'd have to redesign the single and multiplayer campaigns, we'd have to fake the physics for a game genre that relies on physics perfection, and we'd be complicating an already complicated set of mapmaking tools (not to mention losing 5 years of development to incorporate their use proficiently). All of this, so that maps can have hills instead of plateaus. Does that sound like a worthwhile use of time to you?


Those are the implications. You can't just think about what new things they bring to the table -- you have to consider how a change like this would affect the entire SRB2 ecosystem, so to speak. We may as well switch engines if we go that path.
 
Last edited:
Ok, let me put it this way: How would the inclusion of slopes affect SRB2?
Map makers would have a way of adding vertical variation to their levels without resorting to repetitive jumping, springs, or fake slopes using tiny stairs (cough).
Does a closer approximation to the 2D classic games equal a more enjoyable 3D experience?

SRB2's 2D mode was intended to be an extra trinket. It was never intended to be a full-fledged simulation of the classic games, nevermined a full-fledged feature on its own.

What I'm trying to get you to realize is just how much slopes would change the game. We'd have to redesign the single and multiplayer campaigns, we'd have to fake the physics for a game genre that relies on physics perfection, and we'd be complicating an already complicated set of mapmaking tools (not to mention losing 5 years of development to incorporate their use proficiently). All of this, so that maps can have hills instead of plateaus. Does that sound like a worthwhile use of time to you?


Those are the implications. You can't just think about what new things they bring to the table -- you have to consider how a change like this would affect the entire SRB2 ecosystem, so to speak. We may as well switch engines if we go that path.
If anybody truly followed that logic, we would have no such thing as Egg Rock Zone. There was a time where reverse gravity, zoom tubes, and hell, something as simple as a linedef executor didn't exist.
 
Since when are loops a good thing?

Since Sonic The Hedgehog for the Mega-Drive.. They are the true symbol of Sonic. That you can blister through landscapes at such speeds that you can make gravity your bitch and leave solid ground. That is why Loops are important.

Furthermore - redesigning maps would not be necessary. And editing wouldn't get complicated much - Cineblast's slope logic code is as simple as applying a linedef special to the linedef that borders two sectors of a different height, and tagging those sectors to a control linedef that actually sets the slope. It's not complex.
 
Priorities, Neo, priorities. Of course we'd love to be able to seamlessly integrate slopes into the SRB2 experience! We just don't have any plans to proceed with that massive undertaking at this time. We're investing our efforts into more resource-efficient features and additions.

EDIT:
Cinefast said:
Since Sonic The Hedgehog for the Mega-Drive.. They are the true symbol of Sonic. That you can blister through landscapes at such speeds that you can make gravity your bitch and leave solid ground. That is why Loops are important.

I think Neo put it best:

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.
 
Status
Not open for further replies.

Who is viewing this thread (Total: 1, Members: 0, Guests: 1)

Back
Top