Suggestions

Basically, he means that the stretch command only stretches our default view (8:5 widescreen) to a non-widescreen resolution, not to a wider widescreen.
 
There should be a flag for floating objects that adjusts their height relative to the floor height of the sector they're in, so we can have rings and stuff on moving platforms.
 
I have a bunch of requests that I'm certain likely have all been asked before, and all would be fairly large projects so I wouldn't expect them to be added soon. They are all features from other Doom source ports that I think would be very useful for SRB2 modders to have available. The reason I'm asking for them is because I have a big Sonic fan game project that I'm planning that would require a lot of features, and the engine that I have most experience with is the Doom engine; I'm currently debating whether to use GZDoom or SRB2 as my engine of choice. It would be entirely 2D platforming. I have half functioning engines working for both, but I would like to end up using SRB2 to help support a fellow Sonic fan game, and one I've grown up with since the early 2000's. If I can get what I need out of SRB2 and not GZDoom (Which has a few severe flaws that are putting me off that SRB2 doesn't have) then I will use it for sure.

Anyway, the requests. I don't know as much about SRB2 modding so some of this may already exist, but here goes...

.pk3 files: A much easier way of storing and working with data then all lumped into one giant list. I feel like this is something SRB2 might already have but i haven't seen documentation on it, and couldn't find any on the wiki. The project I have in mind will be enormous if my current plan sees fruition and require a boatload of new resources, likeyl even a custom .exe eventually. pk3's are becoming more common throughout Doom source ports due to easily organizing all the data into separate folders and subfolders, making changes relatively easy and pain-free.

True-color renderer for software mode: Not a necessity, and a huge pain to get working, so I wouldn't expect this one. There wouldn't be a need for a COLORMAP anymore if this was implemented, and the palette restriction would be lifted too.

Ditching flats: ZDoom and Eternity, among other source ports I can't think of, can put patches and textures on the floors in addition to walls, making flats obsolete as a file type to use. SRB2 is leaning farther and farther away from the original Doom code, and already supports different sizes of flats than just 64x64. There isn't really any reason to keep flats around as being separate from textures.

Upgrade to UDMF map format: What can I say? The UDMF map format is simply superior. The ability to rotate any texture alone, whether on floors/ceilings or on walls, is extremely useful. I imagine this would be a hell of an undertaking though and require a very updated or entirely new map editor to go with it though so I'd understand if this took a long time to implement if it ever was. Not to mention that all the mappers would have to get used to how much more complex it is, but once they did it would be much more flexible.

Of these all the .pk3 thing is the one that I and many others would benefit the most from. If these have already been discussed I would like to at least read over the reasons they may have been rejected or shelved.
 
True-color renderer for software mode: Not a necessity, and a huge pain to get working, so I wouldn't expect this one. There wouldn't be a need for a COLORMAP anymore if this was implemented, and the palette restriction would be lifted too.

Dunno about the other stuff, but the devs already said that they use the palette to ensure the game looks the way they want it to look so they probably aren't interested getting rid of it.

https://mb.srb2.org/showpost.php?p=767012&postcount=22 (from a discussion about whether OpenGL should or should not use a palette like the Software renderer does)

Mystic said:
SRB2's visual design is intended to approximate the style of the 2D Sonic games in 3D. Our old, Doom-based engine is actually an asset here, providing us with an authentic, old graphical style from the early days of 3D gaming. Think of this like the intentionally retro styled games that have become popular recently, where the developers intentionally use dated visuals and styles to make the game look much older than it actually is. The only difference is that in our case the project is just so old that our engine isn't faking it; it really IS that old.

One of the tools to maintain our visual design is our limited palette. While the palette limitations started out as a simple technical limitation, at this point they're a major part of our visual design.

That said, this was 2 years ago so I don't know, maybe they did change their stance on this. Doubt it, though.
 
Nope, still the same as ever.

PK3, ditching flats, and UDMF would be pretty nice to have though.
 
Last edited:
I have a big Sonic fan game project that I'm planning that would require a lot of features, and the engine that I have most experience with is the Doom engine; I'm currently debating whether to use GZDoom or SRB2 as my engine of choice. It would be entirely 2D platforming.
If you're talking 2D as in completely flat 2D graphics, a Doom-type engine is completely overkill for that and you'll hit a bunch of limitations. You'd be better off using a generic 2D engine and writing the exact game logic you want; if SRB2's made you a Lua fan I can vouch for https://love2d.org/ from the little bit of experience I've had with it.

Either way, one thing to keep in mind about any suggestions you preface as such is, while any suggestion can be implemented if it benefits the game, SRB2 is a game first and foremost and engine-related suggestions that aren't directly benefitting us are unlikely to be pursued.

True-color renderer for software mode:
Our reasoning for not doing this has already been explained above, so I won't bore you with repetition.

.pk3 files:
Upgrade to UDMF map format:
These are both things that have been requested internally, and there's a modicum of interest in making them happen, but as you've said already, each of these is a huge undertaking. There just isn't enough benefit in doing them for us to justify the effort required.

Ditching flats:
Out of all your suggestions, this is the one that's most likely to be implemented. You'd probably still be limited to square power-of-two sizes for flats depending on the exact implementation, since changing lower-level span rendering code can be a pain (I think there are some ASM functions for those in the code, yuck), but just hacking something into the flat loader to convert textures shouldn't be too difficult.
 
Thanks for the replies! I thought I had read about the reason there is no true-color software mode somewhere on the forums before, in fact that was the exact same post, I'd just forgotten. That and UDMF wouldn't be high priority things I'd need, UDMF would be marginally more useful and I think it may be more fun working with a restricted palette. Textures instead of flats would be nice to have but not necessary either. The only thing I'm really hoping for is .pk3 support, that type of organization would be a blessing. I'm certain I can't be the only one who thinks this either.
 
Make the 1-up a sound effect instead of a Tune like some mods already do so that it doesn't override whatever music is currently playing.

I always think it's rather annoying when that happens.
 
One quick suggestion to Analog mode, camera turning speed should be lowered while Gliding, Similar to the way it works with Rouge and Knuckles in Sonic Adventure 2, I Know this isn't gonna fix all problems with analog controls but It'll at least make the Gliding characters slightly more controllable in analog mode.

For Boss stages, The camera should be locked and aimed only at the boss, If more than 1 boss are present at 1 act, The camera should follow only the nearest one.
 
I keep on telling people that would be a minor upgrade for one use case and a huge downgrade for a ton of other ones.

The vertexes slope copying has no reference when lines aren't involved, so you have to arbitrarily duplicate/match up equivalents of your work over multiple sectors. And because the vertices have to be the corners of the sector, creating slopes with vertices based on geometry outside of the sector is impossible - which makes FOF slopes much more difficult for no good reason. It also forces your level geometry to be cut into triangles, even if you just want to make a tilted octagon plane or something. It'd also kill what little support for dynamic vertex slopes we have, since vertices aren't modifiable.

So no. It would be much worse for most use cases, and only slightly better for the only use case ZDooM engineered these for (because it doesn't have FOF slopes, let alone vertex ones).

Unless vertexes can be free standing in UDMF, in which case that's just using a seperate type of object as a reference for this and it's still kinda stupid.

So nyah.
 
Last edited:
Different tools for different situations. Linedef slopes are quick and easy for general ground use, but they're terrible for geometry that isn't aligned at 45 degree angles because the direction of the slope must always be perpendicular to the slope linedef, so no lateral tilts. Vertex things are precise and support dynamic geometry, but they're a pain in the ass to use because you can't rotate or duplicate them without having to re-tag every object, which also means having to temporarily offset things that are overlapping each other so they're not fighting for priority in the editor. If I want to make a bowl or a sphere, where's the solution in-between that doesn't take 3 hours to set up?

Also I was under the impression ZDoom or some other variant supported both visual vertices and vertex slope things, is that not true? If visual vertices really do preclude the use of things, couldn't we just, like, code it to not do that? Also the copy slope actions would be infinitely more useful if they literally copied the slope instead of simply extending a slope over disjointed geometry anyway.
 
Last edited:
ZDoom's vertex things only worked on the corners of triangular sectors and didn't do any tagging, essentially being the UDMF vertex slope conceit without the benefit of being able to put additional properties in the vertex struct. It's reasonable that you'd want these as well, but whenever I hear people advocating for the ZDoom method, it betrays a lack of thought about how ZDoom's editing features have been shaped by its lack of FOFs, and how SRB2 - by nature of being a more vertically demanding game concept - requires alternative solutions. If we did consider it relevant and feasible to add UDMF at some point (and then actually went and did it), it'd be kinda easy to make vertex slopes happen the way you want... but then their complete inability to work for FOFs would be a mess if you wanted to put a path underneath that bowl at some point.

Getting "copy slope" to behave like you'd want it to, by the way? As desirable as that sounds, how could you actively determine what height the slope should be at? The extending-the-plane-outwards is the only possible way to do this without involving some extra information, like, say, a new vertex slope thing to "anchor" it vertically. Which has been proposed but we've been too busy to get around to doing, sorry.
 
This may be fairly difficult to implement, but could 3D mode and 2D mode have different physics? I would love to see the platforming of 2D mode actually resemble Classic Sonic gameplay. As is I'm going to have to look into lua scripting to rework it into something decent for what I want to achieve.
 
Do you mean like speedcaps from the classics or something? I'm pretty sure I asked that at one point and was told it was impossible to do.
 
No, well maybe partially, just stuff like how quickly sonic and co come to a start/stop, some of the air physics being off, the spindash basically never losing speed after letting go unless hitting a wall, etc.
 

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

Back
Top