Suggestions

犬夜叉;767243 said:
It already is. Some of the hooks just don't seem to work with it omitted though.

Unless I'm mistaken, the ones that DO work are:

MobjSpawn
MobjFuse
MobjThinker
BossThinker
BossDeath
MobjRemoved
 
Have a boss for Arid Canyon Zone, and Red Volcano Zone. The Arid Canyon Zone boss should have an earthquake at a curtain time (It's optional.)
 
I'm wondering how feasible it would be to implement a simplified version ZDooM's brightmaps in the software renderer- portions of sprites and textures which, thanks to another lump provided in the file, have portions of them rendered without any colormaps or brightness changes overlayed.

phKSGUf.png
YMgDccz.png


As an example specification. On the left is an example texture from Flipside Frenzy; let's say its lumpname is CASIAD1. On the right is an example brightmap; let's say its lumpname is B0000001.

A BRITEMAP lump would contain the text "Texture CASIAD1 B0000001". This informs the renderer that when this texture is to be rendered, the portion corresponding to the white pixels on the brightmap graphic lump is not to be processed in any way beyond perspective. This includes colormaps, brightness, and translucent flats/textures- although the latter could be disregarded if it's not technically feasible. The before and after are included in the .gif below, with some other textures (not provided here) also having brightmap effects applied.

FbixMuS.gif
 
Last edited:
I'd suggest that the SF_SUPER flag should allow other players that are not sonic to become super, and instead have a flag called SF_SUPERFLY to let the other players decide if they want their super to float. This would be more useful for 2.2 since supers are being removed from match and ctf.
 
I know this same conversation been gone over half a million times, but I think this situation is unique enough to be worth dredging this up. It is really bizzare that all this effort's been put into the super forms in 2.1 patches (Tails super transformation sprites and palettes weren't in the original release, while Knuckles got a new palette in the original build while I forget when his transformation sprites were introduced) when now we're just going to drop Super characters entirely from Multiplayer, leaving those effectively unused.

I'm wondering how feasible it is to have it so once you beat a Singleplayer savefile with all Emeralds as a non-Sonic character to say [CHARACTER] can now become SUPER [CHARACTER] for that save file after the credits, giving an extra benefit to replaying old save files and beating the game multiple times? It might be confusing with Co-op in the mix, though, which is why I'm reluctant to get behind this idea 100%.

Copypasted from another topic.
 
Last edited:
I'm wondering how feasible it would be to implement a simplified version ZDooM's brightmaps in the software renderer- portions of sprites and textures which, thanks to another lump provided in the file, have portions of them rendered without any colormaps or brightness changes overlayed.

http://i.imgur.com/phKSGUf.pnghttp://i.imgur.com/YMgDccz.png

As an example specification. On the left is an example texture from Flipside Frenzy; let's say its lumpname is CASIAD1. On the right is an example brightmap; let's say its lumpname is B0000001.

A BRITEMAP lump would contain the text "Texture CASIAD1 B0000001". This informs the renderer that when this texture is to be rendered, the portion corresponding to the white pixels on the brightmap graphic lump is not to be processed in any way beyond perspective. This includes colormaps, brightness, and translucent flats/textures- although the latter could be disregarded if it's not technically feasible. The before and after are included in the .gif below, with some other textures (not provided here) also having brightmap effects applied.

http://i.imgur.com/FbixMuS.gif
Well, if we are strictly talking software renderer, you could just define a custom palette with certain entries acting as dedicated "fullbright" entries, and in the corresponding COLORMAP lump, alter the lighting drop-off accordingly.

Also, brightmaps is a GZDoom thing, not a ZDoom thing. Y'know, hardware rendering, not software.
 
Trouble with custom palettes is that it overrides the user's desired palette, and doesn't work in OpenGL.

Also, you're right, woops- although I was aware of it being a GL only feature in that source port, which is why I specifically asked whether a software implementation was feasible and not just for a direct port of the GLDEFS stuff.
 
Trouble with custom palettes is that it overrides the user's desired palette, and doesn't work in OpenGL.
Strictly speaking, you're the one making the map; you can impose whatever palette you want for said map, and not concern yourself with users overriding them with separate custom palettes (if they are, they're doing it wrong).
 
There has never been any serious discussion about slopes in vanilla at any point. Dunno where you got that idea.

tl;dr: No.
 
Dunno where you got that idea.
He got the idea from FuryHunter working on making vanilla Sonic Robo Blast 2 use (a greatly optimized) OpenGL as the default renderer, and Sonic Robo Blast 2 Community Build has OpenGL as the default renderer, with slope support (both rendering, collision, and speed/jump/spin manipulation depending on angle), so FuryHunter has been asked if slopes was to be a supported feature, although I don't remember if FuryHunter has answered that.

TL;DR: There has been one or two questions about including slopes in vanilla in the recent time. (But no serious discussions.)
 
I don't know if it was suggested before, but can you make the " Total Play Time" counter add your time spent with wads too? I know it's something really minor, but it would be nice to see it.
 
Furyhunter was actually actively interested in slopes in the software renderer. That lasted two weeks and he is now a broken man.

(granted, the opengl renderer isn't any better but at least he can outright replace that)
 

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

Back
Top