Monster Iestyn
Fangtastic
犬夜叉;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
犬夜叉;767243 said:It already is. Some of the hooks just don't seem to work with it omitted though.
You do realize that people can still use binds for cvars, right? And that skin is already a cvar?The "skin" command should be a cvar so that people won't use binds for it and yeah it's exactly the same as Sonic Heroes.
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%.
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.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
And FuryHunter is working on making Sonic Robo Blast 2 use hardware rendering instead of software rendering as default.Y'know, hardware rendering, not software.
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).Trouble with custom palettes is that it overrides the user's desired palette, and doesn't work in OpenGL.
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.Dunno where you got that idea.