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

frozenLake's Pit of SRB2 Experiments

Status
Not open for further replies.
Eh, too much things placed in map to just get a single voxel, wonder how this goes with different more complex sprite.
 
To be fair, one could take my method with the things and make a script that makes a single object spawn a grid of them, based on a table fed into a function.
 
v6EvO2y.png


And thus, anything that could be considered to be game balance then died, in a horrible fire.
 
That settles it - when I'm finished moving, gr_md2 on will no longer save to config.cfg, and it'll set modifiedgame true. Sorry, everyone!
 
That settles it - My method to try and get you guys to stop blocking graphical replacements as client side wads was completely useless.

Edit: actually, what would be nice would be to combine /that/ with the added feature to stick MD2 Models inside of wads: and allow servers to force a rendering option. That way, we can force MD2 Models on people, like if you have an utterly massive giant robot that would not work with sprites.
 
Last edited:
You probably saw me staring at this thread last night, huh. I was trying to figure out a response for half an hour before I realised your post was just a hostile wishlist and that I didn't actually owe you a response, in the same way that so many of the ideas in the Suggestions thread never get followed up on. Your most recent post seems to be encouraging me, though (I think it was the word "now" being used that really ticked me off), and I'm bored out of my mind waiting for removal trucks to get going - so here goes.

The answer - for any potential new feature intended to only be a part of the main game's current* OpenGL implementation - is and always will be no. Software is the intended use case for the game, conveying the desired 1990's PC gaming look and feel. It's what happens when you play the binaries we provide without any changed settings, it's the one we design all the levels for, it's the one we take all the screenshots in and gifs and maybe videos if we get around to it. Software is the game as it's meant to be played, and we would never as a group encourage anything else.

This is why slopes only became "real" (ie - advertised as a feature we're using for the next major update and which modders can use whilst they wait) when Red made a Software implementation of them, despite SRB2CB (and SSNTails' Final Demo era slope test) existing long beforehand, and polyobjects didn't get flats for that long. Meanwhile, there are several new rendering features in 2.2 which either behave weirdly or plain don't work in OpenGL (horizon line, anchored Smiles-tails sprite sorting to be behind shields), yet they're considered ready for primetime.

But you're not just requesting a feature to make OpenGL better - you're suggesting a mechanism to make it mandatory which could be invoked whenever. That's awful, and opens up so many terrible cans of worms that cannot and will not be considered worth the effort to give even a tenth of an ounce of a shit about. And for what - you've made Brak a little larger than he is in 2.0's ERZ3 without using the dedicated mode. Why? What benefit does that serve? The lighting on the model is shoddy, so it just looks like it's up close but on the wrong layer. The blockmap doesn't handle collisions with super-large objects properly, so it's just a phantom. If you can't collide with it, why not put it in the skybox? Hell, maybe you could construct it out of multiple objects and manipulate them Treasure-style. There's a lot you can do to the engine without access to this rabbit hole.

Next time, use the Suggestions thread.

*If a talented rendering programmer comes along with a replacement which has 98% feature parity with Software, including palette shaders and Sonic's feet never getting cut off by floors, then we'll talk.
 
Last edited:
I'd also like to note that you could get quite close to that in both renderers now thanks to FOF slopes being a thing. You'll even have proper collision and everything, although with that level of detail you'd crush the framerate. If you don't use slopes you could even use polyobjects to make it move if you're really crazy.

This method just requires actual effort to do, which is why you haven't seen people do it.
 
To bring things away from stuff that is exclusive to OpenGL, I bring you... stuff that won't work in OpenGL due to it not reloading its palette for flash pals and per level palettes!

Recently, I have been working on creating alternate palettes, to act as a sort of high quality variant of colormaps. To give some examples...

rOhv1GU.png

Water palette, based on standard water colormap
4F0LZSe.png

A night time palette, based on a colormap Swift was using.
OCrLgn2.png

Palette based on RVZ lava. It ends up being a single color, though with multiple shades, due to how colormaps ending in Z behave.
9sVgKWM.png

Palette based on THZ goo. Same deal as the lava, as it also ends in Z.

I actually ended up making a tool to assist in creating these palettes, so if you are interested in it, look here and make a copy for yourself to edit. If you have any questions regarding it, go ahead and ask.
 
So a while back I threw together a GLSL shader that simulated how colormaps worked in software. Of course, it only works on one site, but the math itself is an exact match.

Code:
precision mediump float;
 
varying vec2 position;
uniform sampler2D webcam;
float value;

void main() {
  vec2 p = position;
  vec4 color = texture2D(webcam, p);
  float cmapr = 0.1;  // Hex R*Hex Intensity
  float cmapg = 0.25; // Hex G*Hex Intensity
  float cmapb = 0.4;  // Hex B*Hex Intensity
  float cmapv = 0.6;  // 1.0-Hex Intensity
  value = sqrt(color.r * color.r + color.g * color.g + color.b * color.b);
  color.r = (cmapr*value)+(color.r*cmapv);
  color.g = (cmapg*value)+(color.g*cmapv);
  color.b = (cmapb*value)+(color.b*cmapv);
  gl_FragColor = color;
}
Yeah, I'm pretty sure that this could be cleaned up by someone who wants to use this in a more useful fashion, but its really just a chunk of the sourcecode in an easier to understand fashion.
 
Last edited:
Status
Not open for further replies.

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

Back
Top