How hard was it to make Srb2?

Status
Not open for further replies.
The current palette sucks, though. There's no real problem with 256 colors. The problem lies in the current palette's colors. Like I said, literal repetetive whites and blacks, and the "Dark Blue" at the bottom of the palette is so close to black that it doesn't matter. Honestly, one of them had 0 Red, 0 Blue, and 11 green. How many blacks and whites do we really need, as opposed to the purple, and the broken pink and green?
 
SSNTails said:
Segmint said:
So wait, the palette is so limited intentionally?!

Yes. Why do you think all old games (and even some pretty recent ones) are 256 colors?

If you are talking 16-bit games, then thats because sprites in 16-bit games usually only have up to 16 colors, with probably many different colors. In SRB2 though, many things usually end up taking around 25+ colors, with many of those having 2 or more of the same "color", but lighter/darker shades. Many sprites in old games only required around 5 or less of the same color(but with different shades), while SRB2 sprites might take up almost the entire 16 colors in one "color." Since SRB2 sprites need a lot of "the same color" for proper shading, we need to have the usually 16-long palette lines(some 8, Red is 24), which takes up a lot of space for 256 colors.

This is fine for a game like Doom, since games of that type of theme don't need a whole lot of colors, but in Sonic, you need a whole lot of colors, and while the classic games were able to be colorful with 64 colors on screen, thats because Genesis sprites only usually required around 5 of the same color. But like I said earlier, more colors are used just to make sprites look proper in SRB2.

I suggest maybe going with 65535(whatever the number is), and making it a miniature 16M, with only 256(or maybe even 128) colors per texture.
 
The Genesis had 512 colors, it's just that you could only use 64 of those colors at any given time. Still, it's a shame that this game is getting trounced by hardware that's nearly 20 years old.
 
Ritz said:
The Genesis had 512 colors, it's just that you could only use 64 of those colors at any given time. Still, it's a shame that this game is getting trounced by hardware that's nearly 20 years old.
Doom itself was developed when the Genesis was cutting-edge. :eek:
 
I quite like the jazz jackrabbit 2 idea.

Perhaps if you could run alternate palletes mid-game, maybe an entry in the levels header and character colours locked from change, it could maybe work.
 
I think most of you forget that a lot of the different shades of one color are needed for lighting.
 
I have one thing to say about the 256 color thing. If SRB2 became a 16-bit color game. The portable systems would be out of ram and it would run even slower than before.

Sonict
 
I've grown to get used to the pallete. There's times when I'd wish I could have more, or to be able to edit one color without it changing the entire game, but I then ignored it and tried to make the best of it.
 
SSNTails said:
I think most of you forget that a lot of the different shades of one color are needed for lighting.

Indeed. Exactly why purple, as it stands, sucks. I mean, come on, literal multiples #000000 & #FFFFFF and colors so damn close it doesn't matter? Why do we need these, as opposed to more purple shades?
 
Sonict said:
I have one thing to say about the 256 color thing. If SRB2 became a 16-bit color game. The portable systems would be out of ram and it would run even slower than before.
Big deal. SRB2 wasn't meant to run on anything but a PC.
 
Dark Warrior said:
Indeed. Exactly why purple, as it stands, sucks. I mean, come on, literal multiples #000000 & #FFFFFF and colors so damn close it doesn't matter? Why do we need these, as opposed to more purple shades?

I'm still waiting for my transtable generation program... You might want to go on the Legacy boards and ask about it, etc. If you can find one, I'll consider reworking the palette.

Ritz said:
Big deal. SRB2 wasn't meant to run on anything but a PC.

Yeah, but that doesn't mean we won't get complaints.

TBH, if we're going to go highcolor, we may as well drop software and go OGL-only, bringing it up to snuff. But since then we're in OGL natively, people are going to want 3d models. Then they'll want slopes. Do you see where this is going?

You have to pick a scope for your project when you start it, and stick to it.
 
SSNTails said:
I'm still waiting for my transtable generation program... You might want to go on the Legacy boards and ask about it, etc. If you can find one, I'll consider reworking the palette.
If you get me a transtable generator, I will rework the pallete, and you will add it to SRB2. >:(

EDIT: Jesus Christ hold me

I just realised that the my attempts at building the transtable with Photoshop were not failures, and that Neopal is the living example of that. You just load it with -file rather than with ADDFILE and it works!

AJ, you WILL add a custom pallete to SRB2 now, and I'm the one who's going to make it. >:D
 
Neo Chaotikal said:
I just realised that the my attempts at building the transtable with Photoshop were not failures, and that Neopal is the living example of that. You just load it with -file rather than with ADDFILE and it works!

AJ, you WILL add a custom pallete to SRB2 now, and I'm the one who's going to make it. >:D


...what? Maketh sense thee do not.
 
Well, I created the lumps by manually setting the transparency level on an overlaying layer, then had Photoshop do the calculations and round up the colors to the 256 color pallete. Just load up neopal.wad with -file and look at the couch in Zim's Base from afar. If you add it via ADDFILE, though, you'll see that the transparency values aren't reset -- the couch looks orange from afar. This is what caused me to think my manual method didn't work: I was testing with ADDFILE. But it does work, test it for yourself!
 
Neo Chaotikal said:
Well, I created the lumps by manually setting the transparency level on an overlaying layer, then had Photoshop do the calculations and round up the colors to the 256 color pallete. Just load up neopal.wad with -file and look at the couch in Zim's Base from afar. If you add it via ADDFILE, though, you'll see that the transparency values aren't reset -- the couch looks orange from afar. This is what caused me to think my manual method didn't work: I was testing with ADDFILE. But it does work, test it for yourself!

soo, this is a bugreport?
 
Well, it's not technically a bug, since you're not supposed to fiddle with the translucency tables on the fly, but if you can fix it, it'd be awesome.

While you're at it, PLAYPAL lumps loaded via ADDFILE take no effect in OpenGL mode. -file works fine, though.
 
Exactly. ADDFILE works fine in software, but not OpenGL. Is it a glitch, though? Or possibly something with the renderer itself that makes it impossible?
 
Status
Not open for further replies.

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

Back
Top