Suggestions

Does it need a purpose?
If I might interject, we seem to be talking about feature creep. Here's the problem with feature creep: with every feature that is added for a modder's convience, an extra inconvenience is created for whoever maintains the source code. When mandatory game changes are made, extra compatibility issues need to be addressed for optional features, and additional bugs need to be fixed. It's the reason old unused game modes get removed, and why some people are just fucking tired of having OpenGL around.

This is not to say that having secondary colors as a base feature in SRB2 modding is necessarily a bad idea or unworkable; I know too little of the source code to make that judgment from a technical standpoint. But it's important to weigh the benefits against the potential for future headaches. As Mystic has explained, modders have already created workarounds to allow for the kind of palette changes they need, so there isn't a lot of incentive to work the feature into vanilla. There might be more incentive if someone were to demonstrate a clean, easy way to work in secondary colors that isn't likely to break in the future.
 
Last edited:
Here's the problem with feature creep: with every feature that is added for a modder's convience, an extra inconvenience is created for whoever maintains the source code. When mandatory game changes are made, extra compatibility issues need to be addressed for optional features, and additional bugs need to be fixed.

The suggested method for adding the secondary colors feature is to set up a secondary swappable palette color. Now, for the sake of the argument, let's say that the actual implementation of creating a second swappable palette color is actually quite simple—which it theoretically should be, since we already have color swapping code—in this case I don't think there'd actually be anything to maintain at all. Currently, an object's skin color is stored as a variable, which can also be set to SKINCOLOR_NONE to signify no color change. Adding a second color would merely add another variable to this mix. Apart from that and the assumed minor source code change, I can only see one large disadvantage: the need for a default secondary color to be established.

For primary color changing, the default startcolor is green. This usually isn't an issue, except for objects that need green as part of their regular palette—which STILL isn't much of an issue unless it also needs to change the color of a different part of its body. This is why character skins can set their own startcolor, so that the game can change a different color while keeping the green parts intact (such as Knuckles in 2.0). However, no such variable exists for actual objects yet. If a secondary color were to be added, this would almost certainly be a necessity, because it creates the issue of sprites lacking green but containing the default secondary color only changing color when the secondary color is changed. This adds a whole new detail complexity where many sprites have differing values for startcolors and prefcolors. (Though, this whole issue can probably be worked around by having the secondary color feature only apply to players.)

So yeah, that's my way of thinking about the two sides of the argument—again, all under the assumption that implementing secondary colors would not be painfully difficult. If it is in fact not as simple as I think it is, then yes, maintaining the new feature may be an issue.

As Mystic has explained, modders have already created workarounds to allow for the kind of palette changes they need, so there isn't a lot of incentive to work the feature into vanilla. There might be more incentive if someone were to demonstrate a clean, easy way to work in secondary colors that isn't likely to break in the future.

Also, the current method for modding secondary colors in is really inefficient, as you first of all have to make a whole separate set of sprites, and then in game they're rendered as separate overlay objects.

The idea behind my above quote was that adding secondary colors as a vanilla feature is actually the "clean, easy way to work in secondary colors that isn't likely to break in the future." Not that the current method is unclean at all; the only big issue with it is that it requires an extra set of sprites to be made, which is hardly ever really worth doing.
 
I have to agree that I would highly prefer having an internal, colormap based method instead of the overlay method that my mod uses. Especially when you get involved with stuff like speed shoe after images where it wouldn't change color if you have an overlay.

Question is, if we did have startcolorb and colorb in vanilla, would this result in model_blendb for opengl being a thing? Because that does seem like a logical consequence, if support is carried over.

Problem is that its a slippery slope. Have a second color range? Great, now add a third. and a fourth.
 
It's clear that nobody who actually knows how the game handles colour remapping internally has offered their two cents, so I guess I'm here to clear things up.

k0dgVCc.png


Here's the 2.2 palette in its current state. This is loaded into the game via the PLAYPAL lump. It consists of 256 indicies.

0M5RzBW.png


Here's a visual representation of how SKINCOLOR_BLUE is stored in memory (in actuality, it's a 256-long string of numbers - but the visual representation helps better). There are 29+(9*5) = 74 different non-SKINCOLOR_NONE skincolour slots in use in 2.2 at the moment. That number is squared when secondary colours are enabled, to 5,476 slots (and that's not taking into account full remaps such as the Brak boss pain flash, either). That is 1,401,856 8-bit numbers in a row, sitting in memory, most of them unused at any given point in time.

This is a feature I want, so never say never - but it's not technically feasible given the current implementation of skincolours.
 
Last edited:
Honestly, something I'd like to see, is for recording demos in multiplayer to become supported. That way, after you have finished recording, you could replay the demo and view the game in spectator mode.
 
There are 29+(9*5) = 74 different non-SKINCOLOR_NONE skincolour slots in use in 2.2 at the moment. That number is squared when secondary colours are enabled, to 5,476 slots (and that's not taking into account full remaps such as the Brak boss pain flash, either). That is 1,401,856 8-bit numbers in a row, sitting in memory, most of them unused at any given point in time.

Wait, what? Why do you need to add more slots? Is it impossible to program a skin to convert two different colors to two completely different colors using separate variables? I don't really know anything about the source code, but I always thought that if it is possible to change one range of colors on a sprite to another range that it would be feasible to do the same to another range on the same sprite.

EDIT: Oh never mind, I get it now.

EDIT 2: Ah, but then how do player skins with different startcolors work?
 
Last edited:
They take up more space! Startcolor was a mistake.

(I will note that I made a mistake in the post above and they're "cached" whenever you change skin or change colour, not always stored. That still means that you use more memory if you change skincolours a lot, at least.)
 
Last edited:
Problem is that its a slippery slope. Have a second color range? Great, now add a third. and a fourth.

It's very rare for any character design to consist of more than two dominant colors, so I don't think this is a fair argument.
 
It's just a lot of work for very little gain. Hence why I was pointing out the marginal benefit of the feature. Nobody outside of original character do not steal children cares if you can change the color of Sonic's shoes.
 
True-color multi-threaded software renderer please. GZDoom added it this year, and I believe it would be a nice addition for SRB2.
 
You are aware that we are not GZDoom and do not have an even similar codebase, correct? We can't just port over their rendering code to make that happen, even if we wanted to.
 
Not really sure if this would be wanted (definitely not needed), but I think it would be nice if SRB2's data files (rings.dta, player.dta, zones.dta, music.dta, patch.dta) were put into a subfolder like /data on installation as to lessen the mess of files in the folder already.

SRB2 can already load its .dta files from a subfolder; all that would have to change is that the installer would need to just put the files in a different location, which I'm sure is not hard at all. 2.2 would be a perfect time to do this change.

Preferably we would even go further and allow the rest of the files (srb2.srb, the DLLs, autoexec.cfg, config.cfg, gamedata.dat, md2.dat, and the save files) to be loaded from subfolders, but I'm not sure how feasible going that far would be.
 
Last edited:
You are aware that we are not GZDoom and do not have an even similar codebase, correct? We can't just port over their rendering code to make that happen, even if we wanted to.

I'm aware that they both have different codebases. I was using GZDoom as an example of a port with that feature.

Who knows? It might be possible someday, even if it takes a long development time.
 
I hate this part of RVZ.

Can we all agree that this part of RVZ is bullshit? I can't get through it without using the wind shield, Knuckles and Tails and more. Maybe just raise up the ceiling a bit more, then we're good. Because it's bullshit for Sonic players, it's just that much of a dick move.
 

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

Back
Top