SRB2 Message Board  

Go Back   SRB2 Message Board > Sonic Robo Blast 2 > SRB2 Discussion

Reply
 
Thread Tools Search this Thread
Old 05-24-2017   #5701
Rob
Administrator
 
Rob's Avatar
Default

I really can't believe I am about to say this, but one use that immediately comes to mind is Shadow.

Being able to set a secondary color means that you can have his spintrail be gold/yellow and his main skin change colors. Or alternatively have his red highlights be swappable along with his main color.

This is a purely aesthetic use, mind, but still a use.
Rob is offline   Reply With Quote
Old 05-24-2017   #5702
Mystic
チェン!
Administrator
 
Mystic's Avatar
Default

The thing is, that aesthetic use can already be modded in as far as I know. The question here is what the purpose for the feature is in vanilla. Shadow isn't in vanilla, so making him look better isn't a good justification.
Mystic is offline   Reply With Quote
Old 05-24-2017   #5703
Potatosack
funyn menme
 
Potatosack's Avatar
Default

I am curious, though. Would it be possible to have multiple prefcolor ranges?

In terms of 'how much work would it be', that is
Potatosack is offline   Reply With Quote
Old 05-24-2017   #5704
h0is
Pepperoni Secret
 
h0is's Avatar
Default

Maybe add colorable shoes to the vanilla trio, like the secondcolor wad?
__________________
People are like slinkies, they're boring until you push them down the stairs.
h0is is offline   Reply With Quote
Old 05-25-2017   #5705
Lach
hop
 
Lach's Avatar
Default

Quote:
Originally Posted by Monster Iestyn View Post
Though that said, it'd probably require you to set two ranges of colors to remap to other colors. That might be a tricky thing for character makers to sort out, potentially.
If there were to be two color ranges and a character only needs one, the creator can just set the second startcolor to a color that is nonexistent on his/her sprites.

Quote:
Originally Posted by Mystic View Post
The thing is, that aesthetic use can already be modded in as far as I know. The question here is what the purpose for the feature is in vanilla.
Does it need a purpose? Having additional features isn't totally unnecessary if the users get some enjoyment out of them. That said, there are many users who would get more enjoyment out of not having secondary colors. It might be distracting in team gamemodes, and it'll likely accentuate the already popular SRB2 trend of creating recolor fan characters, which some people will like and others definitely not. Though, I guess for team gamemodes you could always choose to set it to the team color in the same fashion as the primary color, which in fact would make team gamemodes even more consistent.

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.

That said, I'm personally not really for nor against secondary colors. But if setting up secondary colormaps isn't difficult, I don't think there are a whole lot of negatives to it.
Lach is offline   Reply With Quote
Old 05-25-2017   #5706
Rapidgame7
Rookie modder
 
Rapidgame7's Avatar
Default

Just like objects with MF_FRET gets their black color parts on their sprites switched to white, could there be a mobj variable to allow sprite palette indexes to be changed, just like colormaps for the HUD but for sprites?
Just like mobj.color but for all/any colors in a sprite.

Also, could colormap userdata structs be editable? Sometimes I do need to change more colors than just the green colors on a HUD patch.
__________________
Ever tried to start a project until you find out it's too complicated then you abandon it
Rapidgame7 is offline   Reply With Quote
Old 05-25-2017   #5707
CobaltBW
I do things sometimes
 
CobaltBW's Avatar
Default

Quote:
Originally Posted by Lach View Post
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.
__________________
~CobaltBW

Check out my soundcloud profile for music stuff

Last edited by CobaltBW; 05-25-2017 at 04:43 AM.
CobaltBW is offline   Reply With Quote
Old 05-25-2017   #5708
Lach
hop
 
Lach's Avatar
Default

Quote:
Originally Posted by CobaltBW View Post
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.

Quote:
Originally Posted by CobaltBW View Post
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.
Quote:
Originally Posted by Lach View Post
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.
Lach is offline   Reply With Quote
Old 05-25-2017   #5709
frozenLake
 
frozenLake's Avatar
Default

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.
frozenLake is offline   Reply With Quote
Old 05-25-2017   #5710
toaster
トースタちゃん
 
toaster's Avatar
Default

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.



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.



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.
__________________
Quote:
<fickle> giant robo-hood that rips the map apart with her bare hands

Last edited by toaster; 05-25-2017 at 01:43 PM.
toaster is offline   Reply With Quote
Old 05-25-2017   #5711
ProtoBlur
Sweet!
 
ProtoBlur's Avatar
Default

Quote:
Originally Posted by ProtoBlur View Post
Would it be possible to allow 2P save files?
I hate to do this kind of thing but I'm pretty curious.....
ProtoBlur is offline   Reply With Quote
Old 05-25-2017   #5712
frozenLake
 
frozenLake's Avatar
Default

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.
frozenLake is offline   Reply With Quote
Old 05-25-2017   #5713
Lach
hop
 
Lach's Avatar
Default

Quote:
Originally Posted by toaster View Post
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 by Lach; 05-25-2017 at 05:59 PM.
Lach is offline   Reply With Quote
Old 05-25-2017   #5714
toaster
トースタちゃん
 
toaster's Avatar
Default

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.)
__________________
Quote:
<fickle> giant robo-hood that rips the map apart with her bare hands

Last edited by toaster; 05-25-2017 at 06:56 PM.
toaster is offline   Reply With Quote
Old 05-25-2017   #5715
CobaltBW
I do things sometimes
 
CobaltBW's Avatar
Default

Quote:
Originally Posted by Nomekop View Post
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.
__________________
~CobaltBW

Check out my soundcloud profile for music stuff
CobaltBW is offline   Reply With Quote
Old 05-26-2017   #5716
Potatosack
funyn menme
 
Potatosack's Avatar
Default

So skincolors are just poorly implemented and we could get secondcolors if they were done right?

coolbeans
Potatosack is offline   Reply With Quote
Old 05-26-2017   #5717
Mystic
チェン!
Administrator
 
Mystic's Avatar
Default

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.
Mystic is offline   Reply With Quote
Old 05-26-2017   #5718
Ritz
cornstar
 
Ritz's Avatar
Default

Need "Copy frontside floor/ceiling slope from line tag's floor/ceiling" actions so that we can merge FOF slopes with sector slopes.
__________________
http://funkvessel.tumblr.com/
Ritz is offline   Reply With Quote
Old 05-30-2017   #5719
Voros
 
Voros's Avatar
Default

True-color multi-threaded software renderer please. GZDoom added it this year, and I believe it would be a nice addition for SRB2.
Voros is offline   Reply With Quote
Old 05-30-2017   #5720
Rob
Administrator
 
Rob's Avatar
Default

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.
Rob is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Some suggestions..... Konata123 SRB2 Discussion 3 03-30-2011 03:01 AM
I want some suggestions/reviews, please. Shadow Hog Outdated Releases (0.X & 1.X) 22 10-31-2006 01:45 AM
Question about a few 1.1 suggestions SSNTails Help 11 01-07-2006 04:27 AM
My suggestions RenegadeC Help 41 10-18-2005 09:51 PM


All times are GMT. The time now is 08:09 AM.


Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2018, vBulletin Solutions, Inc.