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

SRB2 in ZDoom

Status
Not open for further replies.
Hey. Probably none of you know me, nor do any of you probably care, so I'll get right to the point.

Legacy sucks. It was just a huge mistake; it's Fragglescripting is completely obsolete and is translated slowly, Legacy is never updated, and there would've been so much more potential using ZDoom. For one, in ZDoom, you could've done just as well as anything the SRB2 Legacy can do, and more, without touching the Source code. Another few things, ZDoom's ACS Scripting is much more powerful and more comprehensible, has many more great BooM effects and many of it's own, including slopes, DECORATE monsters (without need of changing the source code), BEX DeHackEd extensions (e.g. more monster codepointers, Railgun effects, object scaling for hi-res objects). Also, ZDoom supports alot of Hexen-native effects, including Polyobjects, and in ZDoom you can "hijack" weapons and items from other games supported by ZDoom, as long as you include the required resources for that weapon, and you can modify them with ZDoom's internal "DEHSUPP" lump. So, in conclusion, it was a mistake from the very start to use Legacy for SRB1 and 2. Why would you chose Legacy over ZDoom anyway? It was just an assload of work that you could've saved just by using ZDoom.

Which brings me to the point of this post. I am willing to convert SRB 1 and 2 directly to ZDoom for those who want me to, and add more detail to the maps, and whatnot. And before anyone says that I don't know what I'm talking about when it comes to level design, I've created maps with well over Legacy's allowed limit of 32,768 of each object type (we're talking like 55,000 sectors here) and that is just one more reason that I'm willing to convert everything to ZDoom (and add some more "stuff") for those who want me to. Also, ZDoom has much better handling of floor heights below 0.

So, are any of you that work(ed) on SRB1 and 2 interested at all in this? If so, I'm an expert in DooM's map format and alot of ZDoom's effects.. So, give me a buzz... :wink:

And if you want to know what I call my tools of the trade...

Map editing : Doom Builder (3D mode rules!)
Lump management : XWE

And here's some info on a brand new node format in ZDoom...

VERTICES: Infinite
LINEDEFS: 65,536
SIDEDEFS: Infinite
THINGS: Infinite
SEGS: Infinite
NODES: Infinite

Yep, you read that right. ZDoom allows for maps with absolutely no limits on map size except for 64K linedefs.

Also, just a question... Why is there no texture alignment at all in SRB 1 or 2?
 
Well, judging from my detections, you're either a lamer or a moron, because everyone knows that porting this game to ZDoom would be an insane amount of work that no one in their right mind would attempt.

However, for the sake of the 0.1% chance that you actually are sincere, I'll tell you why we use Legacy:

There are many reasons we use Legacy instead of ZDoom. First off, SRB2 uses incredibly high usage of floor over floors, or 3D floors, or whatever the hell you want to call them. From what I understand, ZDoom's defining feature is its ability to have slopes, not FOFs (floor over floors). While having slopes would be a nice feature that we would definitely appreciate, the ability to have platforms above other platforms opens up much more design space than slopes ever would. We also have 3D water blocks that allow us to do the water effects and an insane amount of other things we use on a regular basis, like translucency effects, which are admittably broken in OpenGL mode. ZDoom does not have ANY of these features to the best of my understanding. We are not looking for customizability features from a scripting perspective as much as we are looking for customizability from a level and coding perspective.

Also, remember that this project was started in 1998, and there has been an incredible amount of work done on the code in general. Porting SRB2 over to ZDoom would require moving all of that work into a different engine for absolutely no reason whatsoever. The choice of Legacy over ZDoom was strictly because Legacy had the features that we wanted, and had nothing to do with ease of coding or whether we could create cool little effects without changing the source code.

Not to mention that at this point, Legacy has all of the features we could possibly need. The only major limitation we have is the 128K blockmap limit, which I've noticed you have conviently left out, since you're using Zennode just like everyone else, because that's one of the limitations of the original WAD format. Since adding the level of detail of a few of the maps in SRB2 would kick it above the 128K blockmap threshold, you can't possibly do what you're saying you can do unless you have some miraculous solution to the blockmap issue, which some of our coders are already working on with the Legacy engine. Since that's the major limitation we have, I see no reason to switch to an engine which has the same limitation when we're already working on a workaround in our current engine.

The thing that really makes me amused about your post, however, is the whole idea of porting SRB1 to ZDoom. Do you even know what SRB1 IS? It's an ancient 2D Click and Play game with more bugs than a natural park. It's an ancient example of what one man could do with motivation and drive, and is not a playable game by today's standards at all. Unless ZDoom has a really l33t 2D mode that is vastly better than Legacy's, and has really amazing FOF support to allow for the vertical level designs, there isn't a way in HELL you could port SRB1 to Doom at all. And then there is always the question of whether you would want to.

On the topic of your legitimate question, why there is no texture alignment in SRB2's levels, it is a simple issue of priorities. Our priorities are the levels themselves, and not whether or not all the textures line up. We align the textures when it is necessary to make a section look correct, but other than that, we simply leave them as they are. In doing so, it actually often looks better because it has a more natural wilderness feel when the textures don't align right, because in real life they don't.

In other words, if my assumptions are correct, stop trolling and get out of here. If not, I hope my above post explains the decisions to use Legacy over ZDoom adaquately enough.
 
OK, first, my intention was never to flame anything or anyone, and not to intentionally troll. And by the way, there's much more than one way that you can port a sidescroller to ZDoom. And also, I do not use ZenNode, I use ZDBSP, which supports infinite everything except 64K Linedefs, which in theory would set a limit on Sidedefs as well (128K). In terms of "You use ZenNode just like everyone else," This is quite far from true. There are literally hundreds of different nodebuilders out there, some include DeepBSP, GLBSP, BSP, WARM, DMapEdBSP, and of course, iDBSP (ancient port of iD's own nodesbuilder). And in case I didn't note it in my post, ZDoom does indeed support 3D floors. It's called "Transfer Heights" and in combination with either a "Deep Water" thing placed in a Dummy sector, or Bridge things with appropriate Z heights, you can create 3D floors just as well as Legacy can or deep water the player can swim in, just like Legacy. Not just that, but since ZDoom doesn't even use Doom's native map format, so there's much more than Legacy's Doom format tricks that are allowed. Stuff like colored lighting, a score system, and even an entire RPG system with player levelups and whatnot can be possible in ZDoom's map format that Legacy's Fragglescript simply will not allow.

In short, I'm just saying that I think there's a few things about SRB2 that could've been done better, and maybe it could be a cool side-project for the SRB2 team or as a fan-project.

Also, if you want to check out these nodesbuilders for yourself, check here: http://www.doomworld.com/classicdoom/utils/editors.php#nodesbuilders
And finally, as an example of what can be done in ZDoom that Legacy can not even load, check this site: http://www.wadsinprogress.info/index.php?a=listwads&wad=41
Plus, ZDoom was out by 1998. IIRC, it was at v1.12 or so. Now it's at 2.0.63a, just for random useless information. http://www.zdoom.org

EDIT: Also, yes, I do know that I said SRB1 used Legacy. My mistake.
 
Well, it appears the assumption may have been wrong for once. Thank god...been a while since it wasn't some moronic troll.

First off, I am aware of the fact that there are more nodesbuilders than Zennode, but the thing I was referencing was more the limitations of the WAD format than anything else. If ZDoom has changed the format entirely, that fixes the problem, while of course adding a whole new can of worms to add issues with other areas.

The thing is, though, is that we really have no major need for any of the features outlined. They are cool from a Doom level designer's standpoint, but from a standpoint of creating a fangame, they're rather trivial compared to the hassle that we would have of having to teach everyone the new tags and changing every map in the game to go with the new standard. For example, I don't even know what fragglescript IS, unless you're talking about our rather simple system for giving the game data on what sky, music and similar information to use for a custom map, and that's a feature that Legacy supposedly supports. Never mind features that actually DO something. Our copy of Legacy is so butchered at this point that it's basically completely different, with weather effects and linedef executors, a sort of in-level scripting that basically replaces buttons and linedef triggered events. Legacy does have colored lighting as well, both as flares in OpenGL and as a colormap for both display modes.

The absolute major reason I don't want to change to ZDoom, however, is that it would sidetrack the team even more than it already is. Needless to say, the chances of actually finishing SRB2 at all are rather low, and having to switch engines would pretty much put the nail in the coffin in terms of the feasibility of getting the game itself done at all. We simply have enough trouble getting people the drive to complete what we already have on our plate, never mind if we add a whole new issue into the picture. There is no question that ZDoom is prettier and more powerful at this point. When SRB2 was being planned, ZDoom did not have FOFs, deep water, or any other major features that were important towards the project. If the project was being planned today it probably would have been done in ZDoom or Quake 2. However, it was planned in 1998, and as such is running Legacy, which although it may be outdated, is a decision too deeply rooted in the community to change at this point.
 
Blockmap limitation is fixed already. Since January.

Darkhaven3: If you're serious, take a look through p_spec.c and p_user.c and tell me what in those files ZDoom DOES support... I expect it'll be a pretty short list. The fact is, we've added tons of features.

I know about the bridge thing. You can't have any idea how much we've used/abused our FOFs, though. Can your transfer heights be used to make a platform that can be jumped up through but also stood on, with no visible sides, with translucency and an adjustable alpha value? Because I just coded that in. And all I did was throw together a bunch of flags that were already working.

How about a translucent colormapped Mario platform conveyor belt, only visible from the inside, that bounces you backwards if you walk into the side and moves up and down while casting a shadow and when you spindash into it crumbles and floats and bobs on 3D water in a pool suspended in midair below until it returns to its original position after 15 seconds? How fast can you code THAT?? I could have it working in fifteen minutes!

Anyway, the point I'm trying to prove is: You can be a ZDoom zealot all you like, but we have stuff ZDoom doesn't. Lots of it.

If you have programming skill, you could definitely be useful working on the existing codebase (assuming you can overcome your hatred of Legacy). Talk to Alam, Logan, orospakr, or me in #srb2 on irc.accessirc.net about it.

Sorry you were called a troll. See, we had a guy in here about a year ago who claimed to be Simon Howard aka fraggle, and it turns out he was just some nut. I spoke to the real fraggle on MSN, and he had no idea who I was. (He also randomly decided to ignore me after a couple conversations... weird fellow.) Why'd you stop using DETH?
 
SRB2 doesn't have Fragglescript.

Boom's "Transfer Heights" feature won't give you the full effect of 3D floors because you can't see the 3d floor plane and the plane underneath it at the same time, which would introduce some very fascinating artifacts. Using THINGS for the player to step on to simulate multiple floors doesn't work either, especially if you want that 3d floor to have a special sector type, or have it move up and down.

ZDoom was out in 1998, but it didn't have much of what it is now.
 
Yeah, then we'd have 2 SRB2s, people could have a choice of what they want ^_~

"Hmm, I don't feel like playing this one right now, I think I'll play the slopey one!"
 
SSNTails said:
SRB2 doesn't have Fragglescript.

Boom's "Transfer Heights" feature won't give you the full effect of 3D floors because you can't see the 3d floor plane and the plane underneath it at the same time, which would introduce some very fascinating artifacts. Using THINGS for the player to step on to simulate multiple floors doesn't work either, especially if you want that 3d floor to have a special sector type, or have it move up and down.

ZDoom was out in 1998, but it didn't have much of what it is now.

Yes, it would make for some interesting effects :P Also, using THINGS the player can walk on works fine. In ZDoom in Hexen format, THINGS can have a pre-set height above ground. Also, Floorbobbing can be done quite well with Transfer Heights, in fact it works especially well with fake water. However, where Transfer heights fails, there's other alternatives. For example, a bunch of intertwined linedefs with either a solid color as a middle texture or a good-looking complex texture to simulate solid floors, but then floorbobbing won't work...

EDIT: Actually that's possible. With the use of scrolling textures and maybe one ACS script...
 
SRB2 also supports object heights up to 4095 units. SRB2 supports all of the things mentioned natively, and all that is needed to do them is a simple control sector or in the case of a few really complex ones, two or three control sectors. This makes it incredibly easy to do things like, say, floor over floor over floor over floor over floors, which are things we do all the time.
 
i must admit, the thought of srb2 with some of zdoom's newer features does sound good but the thats out of the question

legacy has been so heavily modified its almost unnoticable that it once used a doom engine,
playing srb2 for the 1st time i was thinking to myself for ages... its too hard to believe that this used to be a doom engine...

infact its so different that trying to separate them so you can add it to zdoom (or whatever) would be the equivlent of ripping someones head off and several other limbs so you can glue it to someone elses body then hoping that they live

it would basically require a complete code rewrite


bleh and so ends my pointless ranting
 
Darkhaven3 said:
Also, using THINGS the player can walk on works fine. In ZDoom in Hexen format, THINGS can have a pre-set height above ground.

Yeah, I added that to SRB2 without having to change the Doom map format by using the magical world of bit shifts. A kind of "bad" thing by moving to Hexen maps is that you lose the large variety of level editors that you can use. Granted, there are several Hexen editors, but there is a greater choice of Doom ones. Trust me, I've resisted several times to make my own map format.

Also, Floorbobbing can be done quite well with Transfer Heights, in fact it works especially well with fake water.

How would you also move the collision with the floor? You'd need to program the THINGS as a special case to follow the height of the control sector, and even then, I doubt Zdoom treats standing on the top of a THING the same as standing on top of a floor. (I.e., you may not move smoothly along with it).

However, where Transfer heights fails, there's other alternatives. For example, a bunch of intertwined linedefs with either a solid color as a middle texture or a good-looking complex texture to simulate solid floors, but then floorbobbing won't work...

Middletextures can only be drawn from the floor-up, or the ceiling-up. This would require the use of *massive* textures in some areas to paint the sides of a platform.


Even though Legacy definitely doesn't have the perceived flexibility of some other source ports, that's exactly the reason I chose it - because of the lack of outside customization, the code is very clean, fast, and simple to start from. Most source ports have customization features that are better suited to only a First Person Shooter. This is actually why I requested SoM to leave the #defines in for Fragglescript when he added it to Legacy so I could easily remove it. Without all that extra code overhead and garbage in the way, getting started and maintaining was a lot easier.
 
SSNTails said:
Also, Floorbobbing can be done quite well with Transfer Heights, in fact it works especially well with fake water.

How would you also move the collision with the floor? You'd need to program the THINGS as a special case to follow the height of the control sector, and even then, I doubt Zdoom treats standing on the top of a THING the same as standing on top of a floor. (I.e., you may not move smoothly along with it).

Since, when using Transfer heights, both the control sector and the effected sector use the same tag, a very very simple scripted event (1 line) can be used to do this. Also, ZDoom treats walking on top of THINGS the same as walking on top of a sector, given their radii are less distance apart than the player's radius.

However, where Transfer heights fails, there's other alternatives. For example, a bunch of intertwined linedefs with either a solid color as a middle texture or a good-looking complex texture to simulate solid floors, but then floorbobbing won't work...

Middletextures can only be drawn from the floor-up, or the ceiling-up. This would require the use of *massive* textures in some areas to paint the sides of a platform.

Hello? Y offsets?


*SoM*? THE SoM? As in, the one who helped make Mock2?
 
But you see, Darkhaven, the fact that you have to mention all sorts of features like that means that it's way too complex to be practical. Legacy FOFs are simply a control sector with the ceiling and floor being the top and bottom of the block. All that you then need to do is tag the control sector to the target sector and you're done. No objects, no workarounds, no complexity. The fact that it isn't complex is VERY beneficial to the project because it means that it is very easy for new level designers to learn how to use all of the features that SRB2 supports, which is a tremendous help towards extending the life of the game.
 
Actually, alot of stuff like what I mentioned can be done just as well in DOOM2.EXE, but ZDoom just adds a simple frontend for those effects, since they (1) bend the engine to the point of "breaking" alot of the times, and (2) these effects are usually difficult to acheive to people new to mapping for Doom-based games. For example, 3D bridges; they require somewhere around 12 dummy sectors to work, and if you get it just slightly off you get one motherfucker of a HOM. Y offsets, however, have stayed the same since Doom1. You are right in more than one case, however, such as polyobjects and rotating flats.
 
Here's a basic example of how simple I'm talking about.

fof.png

Here is a sample map demonstrating an FOF. The object there is a player start so the map will load and the extra sector around the stage both makes it look better and keeps Sonic from being able to thok outside of the stage.

SRB20000.png

SRB20001.png

What the map looks like in-game. Note that no objects were used, and no extra features were used. It just loads and acts right. You can stand on the top, look at the FOF from all sides, and do whatever you want to it. The light level below the FOF is the light level of the control sector, so shadows are very easy to create. No texture offsets, objects, or other features are used in the creation of the FOF. This is just a normal FOF, but we can use invisible, translucent, intangible, water, and many other things through this exact same process. Making them move requires a few more control sectors, but that's it. If I wanted to change its size mid-level, a few linedef executors could do that. This is what I mean by simplicity. Anyone can understand how to make an FOF in SRB2, without any prior knowledge, because it's just easy.

Pardon my ignorance if I'm wrong, but I'd assume ZDoom cannot do a FOF without a tad more effort than that.
 
This really all depends on what you call "more effort". In ZDoom, you place a "K2 Bridge" thing, set it's Radius, add a Z height, and you have a 3D bridge. However, to make it more realistic, you need to add linedefs to cover up the invisibility of the bridge and add a control sector for "Transfer Floor brightness".
 
I'd like to see you move SRB2 to ZDoom, Darkhaven. I'd like to see how it turns out!
 
Status
Not open for further replies.

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

Back
Top