• Do not use Works in Progress as a way of avoiding the releases system! Works in Progress can be used for sharing early betas and for getting suggestions for improvement. Releases of finished content are not allowed in this forum! If you would like to submit a finished addon, click here for instructions on how to do so.

The Ramp Project *update as of 7/5/06*

Status
Not open for further replies.
Sort by date Sort by reaction score
Antiporcupine

Antiporcupine

Member
Okay, I know I've been AWOL for a few days, since I joined, but I had to move from DSL to Dial-up this past weekend, and my laptop isn't taking it too well. Anywho, I've had some time to think, and I have some ideas for tackling the most complex addon to the game:

Inclines, ramps, and loops.
I'm serious.

As I said in my intro, I know the programming language, and I am rather good at math, so I really want to give this a try. I won't be able to do this by myself, so I'm hoping that someone can help with the ideas and such. Here's what I have so far (sit tight, there's a lot here).

First, we need to define an inclined sector and its slope. I thought of two methods of adding an incline to a sector: either as a property of the sector itself, or as a linedef. I like the first idea better, because I'm not yet used to linedefs, and don't know if, say, multiple linedefs can be used on one sector, or if linedefs affect ceilings, or such like that. For the purposes of this discussion, assume that a slope is a direct property of a sector.

Anywho, assume I'm using DoomBuilder. When the Sector dialog box pops up, there would be a number of new field values that concern slopes. I am thinking a total of 8 new fields here, four for the floor and four for the ceiling of the sector, as I want both to have slopes. The four fields to each will say something like: "_'a'_z for _'b'_x and _'c'_z for _'d'_y". What this means is, for every 'b' fracunits the player (or any other object) moves in the x direction, it will rise 'a' fracunits in the z direction; and for every 'd' fracunits it moves in the y direction, it will rise 'c' units in the z direction. That will define the slopes of the floor and the ceiling. For simplicity, the four fields can range from 0 to 5, and the z values can be negative so that the slopes can be in any direction. If nothing is entered in these slots, then the system will have as default "0 z for 1 x and 0 z for 1 y", which is completely flat, so that the existing maps (which do not even include these fields) can still work (I love backwards compatability).

Now, before I continue, I want to define a few terms. The words "floor", "ceiling", and "linedef" are used already to refer to the bottoms, tops, and sides of sectors. The new terms I want are: "Ground" is where the player and other objects stand upright; it can be flat or relatively shallow slopes. "Roof" is the opposite of "ground"; it is the upside-down equivalent. "Wall" is (and this is important) vertical OR steep slopes, the slopes between "ground" and "roof". As, say, Sonic runs around a loop, he starts on the ground, then runs up on a wall, upside-down across a roof, back down on another wall, and then is back on the ground again. Grounds, Roofs, and Walls do not need to be flat, and some walls are defined as very steep sector floors or ceilings; that is why I needed to define these things. I am not quite sure yet how steep something has to be to become a wall, but I think something like "3 z for 1 x" or something like that.

Hokay, now that we know how to create, define, and save the slopes of the sectors, we need to know how to actually run the game with them. Knowing how the original Sonic the Hedgehog games worked, here's what I want to do: Sonic, Tails, and Knuckles can all walk and run on the ground. When the ground becomes steep enough to be called a wall, Knuckles and Tails can no longer just run on it, but they can spindash up it, and Knux can climb on it. When it becomes a roof, Knux can no longer climb on it either; it is then limited to spindashing or running as Sonic -- Sonic and other speed types can run on walls and roofs. There is also something to note about spinning and running: if Sonic is running, and the path curves downwards, he will run on the path as usual, but if he is spinning, he will fly off the path when it curves downwards.

Having looked at the code (WARNING: things are about to get very technical), I think that this shouldn't be terribly difficult to implement. As far as I can tell, MOBJ stands for Moving Object (can someone confirm/deny?), and it directly has MOMX MOMY and MOMZ for three-axis momentum. The way that I defined the slopes above, the program could be set up so that MOMZ changes with MOMX and MOMY depending upon the slopes, so when, if a slope is defined "2 z for 5 x and 1 z for 3 y", MOMZ would be 2/5 MOMX + 1/3 MOMY as long as the object is running on the sector. The difficult part here would be the difference between ground, wall, and roof, as there would need to be some way to signal when a slope is too steep or too shallow; plus, when Sonic is running on a wall, MOMX and MOMY would need to be found in terms of MOMZ, not the other way around. (Okay, hopefully end of technicalities.)

Finally, we have the problem of showing graphics with slopes. I know very little about displaying graphics, so I don't know how we could get a sloped ground to appear on the screen. However, the sprites I can handle better. There is another reason only Sonic can run on walls and roofs; that is so we don't need that many more sprites than we already have. Because Tails and Knuckles cannot run on walls and roofs, we only need animations for running on ground slopes, which we already have - no more sprites for flying and climbing characters! We already have all of the spin animations we need for essentially all angles. For Sonic, however, things become interesting: as far as I can tell, we need three sets of running sprites: running on ground, running on wall, and running on roof. My idea is, make a buffer of images using versions of the ones we already have. For instance, when Sonic is running on a roof, we could use the same sprite animations that he has for running on ground, only upside down. In this case, we could (WARNING: technical again) create a number of frames called PLAYc1, PLAYc2c8, and so forth, inside the program itself, that consist of the first running frames PLAYQ1, PLAYQ2Q8, and so forth, loaded and turned upside down by the program. Then, when we need to display the necessary frames, the program would load that buffer and display the upside-down frames.

When Sonic is on a wall running, the buffer is slightly more complicated. In this case, I think we should have the three left-side-view frames be identical, and using one of the ground running frames, just turned sideways. The same goes for the right-side-view. In other words, we would have:
PLAYd1 is a top-view running frame,
PLAYd2, d3, and d4 are the same running frame, tilted sideways and using whatever frame is necessary,
PLAYd5 is a bottom-view running frame,
and PLAY d6, d7, and d8 are another running frame, the opposite from d2, d3, and d4.
For the side views, we would have the old ground running frames, using, say, PLAYQ3 and Q7 as the side frames when Sonic is running straight up or down on a wall, and, say, PLAYQ1 and Q5 for running straight to the left or right. Complicated, I know, but it means that we would only need top-and-bottom-view running frames added to the existing frames that are already drawn for Sonic. Since there are four frames for running, and we need four sets of each (top-vertical, top-angle, bottom-vertical, and bottom-angle), we need sixteen more frames. However, in Sonic's case, the "special ability" frames are not used, and there are 48 available slots, so we can easily place these extra sixteen there and have room to spare.

There. I know that was complicated as heck (took me two hours to write up), but I think that it is a pretty good start on tackling the whole ramps-and-loops detail. Any constructive comments would be greatly appreciated, and if you don't understand something (pretty likely here) I can try to explain it better. I haven't actually started to do any of the work yet; I'm still trying to understand the code that exists, but I should be able to start soon. Hey, thanks for reading, and I hope this works!
 
IIRC, there was a slopes EXE that only rendered slanted floors, but it was slow as heck. However, that might help you to make your own graphic drawing code, or something. Meh, I'm not that knowledgable when it comes to programming code. Might even say I know jack squat.
 
You can ask Shuffle/Alam/JTE/SSN where the old slopes code is back for 1.09. It WAS done, but it was commented in the end. Apparantly it was rather glitchy and lagged quite a bit, and only worked in OpenGL. If you think you can better that section of the code, please, by all means. ;)
 
Well the problem isn't in the math. It's in the way SRB2 renders everything. It's a very old software rendering engine which wasn't built to draw sloped floors; Heck, the floor and ceiling textures aren't even in the same format as the wall textures are, they're just the pixels...

You can probably make slopes in SRB2, sure, but you probably won't be able to draw them; Running up invisible slopes, anyone? The SRB2 slope exe not only runs slowly, but it only works in OpenGL mode and it only renders the front side (the slope's surface)...

As for defining the slope in the map, I really like how ZDoom does it; Just set a linedef to "Make the front sector slope down to here" and it calculates everything itself; All you need to do is give it a top height and a bottom height and tell it if it's sloping the floor, the ceiling, or both.
 
The interesting part of that post is the running on walls, seeing as they are rendered in software and OGL.

And I think it would rock, and new frames might not be needed, as the running frames could just flipped 90 degeress.
 
I'd actually see a problem with the software renderer trying to draw up the flips, Ree. I think that if he did want slopes in software, it would need to have those extra sprites there to keep it running at a (relatively) smooth rate. I mean, the slopes themselves would probably have issues with software. Moreso trying to redraw those sprites in another angle.
 
:( I was afraid of that. The one thing that I don't know how to do myself is the one thing that's going to cause the problems. I don't even know the difference between OpenGL and ... whatever we use that isn't OpenGL. Jason, like I said, perhaps linedefs would work too. I just wasn't sure. I came up with my method by limiting things to only a few select slopes, but a more generic type thing can help. I just also hear quite a few people complaining that SRB2 and ZDOOM are incompatible, so I'm hesitant to use those methods. I can't figure out why walls and floors are so different; we see walls at hundreds of different angles, but can only see floors and ceilings from a few. Oh, and does anyone actually have the EXE? And any source code I need with it? Thanks.
BTW, has anyone ever come close to a loop/inversion type of deal? I think that what I have came close, and I remember reading somewhere that the primary obstacle there was the sprite thing, which I already (tried to) explain.

EDIT: Sorry, missed the last two posts. Dark, what I meant was, when the program first starts or something, have those sprites handy in their own buffer, once it is obvious that they will be needed later. I'd think that by having them ready, it would actually cut down on time. The primary thing I was attempting here was, no more sprites than absolutely necessary, and as little extra drawing as possible. And ree-c: Yes, we would need some new frames, at least to look nice. Think that if you were in multiplayer mode, and you saw someone running on a wall, you would see the top of their head. That's the frames that need to be added.
 
XD.
I only sent the code.

If you're looking for slopeswin.exe, give me a bit of time to upload it.

Note that the code above is the original 1.09 code. The slopes are still commented.

EDIT: Slopeswin.zip

Two things you should note:
1) I do not have the code for slopeswin.exe. Again: You can find it commented in the 1.09 code.
2) There has not been a level designed for use with the slopes. There also won't be, because it's outdated.
 
You know... That just might work.
Well most of it anyway, no clue how rendering the slopes could be accomplished. My favorite part is the fact that you would only need about 8 new sprites per character, and only that if it's a speed-thok character.

Edit: Oh, and in case you care, OpenGL mode renders everything as 3d models, software does... soemthing else. OpenGL is highly superior but requires the kind of non-crappy graphics card that my computer dosen't have. :(
 
Dark Warrior said:
XD.
I only sent the code.

If you're looking for slopeswin.exe, give me a bit of time to upload it.

Note that the code above is the original 1.09 code. The slopes are still commented.

EDIT: Slopeswin.zip

Two things you should note:
1) I do not have the code for slopeswin.exe. Again: You can find it commented in the 1.09 code.
2) There has not been a level designed for use with the slopes. There also won't be, because it's outdated.
Click to expand...
You need to make a wad with that so there will actually be a slope in the level. I'm not sure what the special linedef number is, search the code for SLOPENESS (I think that was it).
Also, I believe mobj stands for map object, I could be wrong though.
Edit: Actually, gimme a sec, I'll whip up a wad real quick.
Edit2:
Alright, I compiled a newer exe, DarkWarrior's doesn't work with the current version of SRB2.
The linedef special is 243, the control sector's ceiling defines the top of the slope, the floor is the bottom.
Here's the exe and the wad with a slope in it:
http://home.comcast.net/~mlmars/slopes2.zip
I'm not sure why, but if there are alot of sectors in your view, the framerate dies a TON, even if there isn't a slope in the level. A good example of this is to go to the spikes in GFZ2.
 
Sorry for the double post, I've already edited the last one like.. five times..
Find
Code: 
if(sector)
		{
#ifdef SLOPENESS
			size_t q;
			for(q=0; q<sector->linecount; q++)
			{
				if(v3d->x == sector->lines[q]->v1->x>>FRACBITS)
				{
					if(v3d->z == sector->lines[q]->v1->y>>FRACBITS && sector->special == 16384)
					{
						v3d->y += sector->lines[q]->v1->z>>FRACBITS;
						break;
					}
				}
			}
#endif
		}
If you add && sector->special == 16384 to if (sector), it will eliminate the lag that you get from tiny sectors. I'm not entirely sure why this wasn't done in the first place, perhaps a reason I don't know.
New exe:
http://home.comcast.net/~mlmars/slopes2.zip
 
Uh, KoF, there's still the problem of the slopes not being solid, and the fact that none of the surfaces except for the slope's floor itself is drawn.
 
http://home.comcast.net/~mlmars/slopes3.zip
Here's "sorta working" slopes.
By sorta working, I mean that you can walk on them, but you cannot jump, and they only work if you place the right side of the slope on 0 on the x axis.. It's hardly useful in the actual game, but it was a little fun to make :).
Note: You also can't jump on 'em, and don't bother spinning, you don't speed up while going downhill. Also, you get stuck sometimes if you run too fast. X_x
 
It may still be glitchy but that is awesome. :eek: :eek: I would help, but I have no knowledge on the subject.
 
Status
Not open for further replies.

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

Back
Top