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