[Open Assets] SRB2 - Community Build! - Full color Edition! (PNG)

This content may be freely modified and/or maintained by anyone.
Status
Not open for further replies.
Just for fun, remember those old topics where people had cool discussions about stuff? No, not just the ones from 2010, not from 2009, I'm talking about WAY back. The topics I used to read to get a sense of slopes and what people were looking for (it was such a loooong time ago ;-;). Now here's a look back at a recent slope topic to see what got accomplished with SRB2CB in its current state, and see where we should go from here.

http://mb.srb2.org/showthread.php?t=32907

I don't see the big deal of having no "real" slopes in SRB2.

And what are they good for?

lol

Slopes =/= Slope Physics

Give me those, and I won't care about 9001 stair slopes like in GFZ2.

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!

I belive we already have that; it's called a ramp sector.
That isn't like a slope at all; Ramp up just increases step up. By slope physics, I mean it makes you go slower upon going higher

check


, makes you faster upon coming down, slides you down slightly before you stop when you don't move,

check!

and jumping off a slope at an angle.

check!


Alright, now, where are the vector calculations to make you jump perpendicular to the slope's face?

Got it! SRB2CB uses the normal(vector) of the sector to jump perpendicular to the surface!


How about making you fly off a slope if you're running fast enough?

Got it! SRB2CB's slope catapulting can work rather well.


And how about slopes that change their planes irregularly?

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.

Stop trying to make slopes, guys, it's not possible, and if it is, bad hacks need to be applied to at least fake the feeling of it being a slope.

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.


You know, people have been talking about slopes in SRB2 for almost 10 years now. If 'it's possible', don't you think it would have been done by now?

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!)


All of the game code would need to be rewritten to use vectors instead of cartesian coordinates. The game is not designed to work like that AT ALL. The map format isn't even conducive to it. Just give up already.

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


1) Rendering: How to render flats and walls? "Everything" in SRB2 is rendered as vertical and horizontal planes.

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.

2) Collision: Collision is, say, what makes walls, floor and ceilings solid. If a wall doesn't have collision, player can go through the wall.

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:
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.

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


Hey, if you think it can be done, go ahead and do it. But all I've heard over 12 years is just talk with no action.

:)

Where do SRB2CB's 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


For a physics redo, the game needs:
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, that's basically my fleshed out idea of how to exactly implement a real slope system.

Any comments or corrections or suggestions to this idea?
 
Houston, we have a problem.
SRB2CB doesn't understand flats or skies nor textures GFZ3 and on.
Apollo 13, check if srb2cb.wad is in srb2 folder, where srb2cb.exe is.

---------- Post added at 09:54 PM ---------- Previous post was at 09:43 PM ----------

All these changes worries me a bit in a point: And our "SRB2 standard" maps? Is it still possible to convert them for this new EXE?
 
All these changes worries me a bit in a point: And our "SRB2 standard" maps? Is it still possible to convert them for this new EXE?

You have no reason at all to worry

1) Look at how SRB2CB is right now, don't I have a "regular version" and the experimental one for modders only?

2) There would never be anything that requires switching map formats, notice how I'm talking about just the technology here. It has nothing to do with making anything more difficult for mappers and content creators, I thought I made that clear?

---------- Post added at 01:06 AM ---------- Previous post was at 12:00 AM ----------

Edit:
You're really discouraging the fun from this for me.
Isn't it kinda unjustified to think you have the right to say "Woah, this isn't what I want, I'm worried."

Like, you didn't even try to read anything I was talking about, you weren't trying to add to the conversation, you just said "I'm worried" which basically meant "This isn't what I want"

Sometimes I try to cater to what others want even if I don't like programming XYZ, so I think it's more than fair if I want to work on something for myself that doesn't interest you.
It's impolite that you feel you're entitled to say what I can do with my free time.


A) You can keep any version forever, on your computer, unmodified, forever. It's not like you have to download new version. The old version you have will always be there.
B) You can fix it yourself(which is usually not an option with most other level designing engines):
Guess why SRB2CB started? Because I wanted to do things that the original developers didn't want to program! I knew nothing about how even simple programming worked, and I didn't even know what cartesian coordinates were when I first started! If things in SRB2CB truly bother you, there's nothing stopping you from branching off of this and making your own version that does exactly what you want.
 
Last edited:
Out of curiosity, why haven't you started from scratch on your own engine instead of trying to do these kind of modifications on the SRB2 engine? (or is that what you plan to do?). I don't know much about programing, but it seems like it would be better to start from scratch since you have more control, and you don't have to deal with the baggage from the old engine. I have to say that what you have done so far is impressive.
 
You're really discouraging the fun from this for me.
And you're just overreacting. I just made a question about a legit worry: when SRB2 was about to go 2.0, people worried about their maps getting "unsupported" for SRB2ME and the devs "kindly" provided a lvlconverter. You're proposing big change in the engine, therefore my question is legit.

If such a minor worry or question is discouraging the (or your) fun or whatever, I don't know what I'm doing here in this thread. :S

Isn't it kinda unjustified to think you have the right to say "Woah, this isn't what I want, I'm worried."
It is not unjustified.

And I was just saying I'm a bit attached to the classic concept. Not against you nor your ideas (Besides, I said once and now again: SRB2 lacks a lot of classic concept, I'd say SRB2 is not classic nor advanced, it's sui generis). Really, I wasn't clear here:

"I rather prefer that things we have now work smoothly."
... because neither SRB2 vanilla nor your EXE work smoothly. Have you noticed visual glitches that 2.0 has (which didn't exist in 1.09.4)? Have you noticed how the camera works horribly (idem)? Have you noticed how the player gets stuck in the "outmost" walls (idem ibidem)? Have you at least visited the bug report section? These bugs are so damn annoying!

(When you fixed partially the stupid wall collision, you got my hopes up. When you fixed the camera issue, Fawfulfan almost worshiped you)

I just said I don't miss the wall walking for said reason, not that I'm against it. I can get along with it as much as I've done with some things in SRB2 that I don't agree with (and I don't feel like or comfortable talking about it). And please, don't say I don't have this or that right; it's already enough for me some of SRB2 staff saying "it's not a democracy; it's a dictatorship".... and now you too? :P

It's impolite that you feel you're entitled to say what I can do with my free time.
.....???!!!

Still, I was just showing my point of view and it doesn't mean you need to do or change anything for me. You're not my employee. You can do whatever you want for your fun as much as I can say whatever I want to say for my fun. Dealt?

People lots of times have said "I don't like this and that crap in your maps" and I never said "Would you feel entitled to say what I can do with my free time?".

If you don't want me to say anything that would or could or might go on different direction of your plans for your free time (which I don't feel "entitled" to control over), I'm out.
 
Last edited:
Maybe I did overreact, I didn't mean to sound so harsh. You seriously have to power to fix anything you want though:

You can fix anything you want by editing the source code, it's available to you.

I think you'd be more satisfied having control over your code, because then you can stop with the "dictator" stuff, it's just not existent because you can fix/change/add anything you want yourself.

Kalaron said:
Isn't it kinda unjustified to think you have the right to say "Woah, this isn't what I want, I'm worried."
Ezer.Arch said:
It is not unjustified.
I posted an idea and you told me you were worried.
You skip the WHOLE POST and start saying "you're worried" that it will somehow effect the version of SRB2 that you want. You already know I said I wouldn't put anything radical as the main release of this mod, we've discussed it for a billion times, this is why I'm saying it's unjustified.


Ezer.Arch said:
And you're just overreacting
you repeatedly PM me whenever I say anything that could potentially be a serious concern with changing the game engine. You take this too seriously, I was tired of hearing you state the same "I'm worried" again after we've talked about it for so long, we've discussed this already. I said "you're taking the fun out of things" because you repeatedly post and PM me that so many things concern you.

It's just a game, this is just a mod, if you're really so interested, you'll be more satisfied if you fix things yourself. I do not mean that in a rude way at all, it's the same thing that I did when I wanted to see something change.
 
Last edited:
(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?")

That's only true when you don't take air resistance into account. In a vaccum, a feather and a marble will fall at the exact same rate, but in air, the feather will float down slowly. The same deal goes with liquids and other gases too. And if an object is lighter than what it's in, it will float to the top, which is why air floats in water and helium floats in air.

Since the majority of SRB2 does NOT take place in a vaccum, heavier objects will move down slopes faster. If you really want to, you can take the no-air sector type used in Eggrock and make it so everything falls at the same rate, but most people won't really notice or care.

Though that does raise a pressing issue; air and liquid density. But maybe that's going a little too far.
 
Last edited:
I thought heavier objects would "fall" at a higher rate than lighter objects because of the gravitational force, no matter wether it's vacuum or not... Also, a feather will not just "float" because it's lighter, but also because it's aerodynamic... I think?
 
Guys. What the hell does air resistance have to do with things rolling down a slope.

Unless we're talking about something so light that it gets blown away by wind, like a leaf or a feather, then everything is going to roll down as fast as friction lets it. You know, the rounder and smoother, the faster it goes, the pointier and rougher, the more it's likely to get stuck on stuff and slow down? Not exactly rocket science.
 
Better yet, put it in your autoexec.cfg, so you don't have to turn it off again every time you want to play. ^^
 
Worth saying, I finished my others projects up for the meantime, and am starting to seriously tinker with Community Build.

I think I'll make a level called "Coral Spires", just to get a feel for how it works.
 
Thanks. As for some of the base single player levels, on my computer, Deep Sea Zone Act 2 and the lava zone become unplayable, for some reason. As in, they have too many colormaps, and the max is 60. Is there a fix for that?
 
Last edited:
I don't know if this is happening to other people, sometimes I add a few bots to the level and when I reach the next level, some of them are stuck to the wall? Can someone fix this?
 
Status
Not open for further replies.

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

Back
Top