 News | Forum | People | FAQ | Links | Search | Register |
Log in |
|
|
Quake animates BSP textures at 5 frames per second, the vanilla engine cycles the frames using bitmasks (so you can only have an animation with 2, 4 or 8 frames), and so on. BSP texture animation is a poor feature, but at the time its restrictions were needed.
Quake Mod For Doom
https://www.youtube.com/watch?v=AGurDc_c98M Would have been more authentic if the quake models had been converted to sprites instead of just transferred over. :)
Quake Mod For Doom
Quake 0.5 Pretty awesome, but using the models as models is a bit of a cop-out. However it makes for a good "what if Quake was released 6 months after Doom 2" concept. I've heard the problem was liquid brushes because of the distortion caused by the nature of the brush. But one way to counter this is just to not use the distortion effect if possible.
Another problem I've heard is textures not looping properly, somehow. I may be ignorant on this but even with GL texture filtering that wouldn't be a problem, because in general textures loop properly everytime. I'm just saying because it's wierd Doom can do that but not Quake. If I want texture filtering, I'll remove my glasses. GL engines take the "player checks his glasses" killquote too seriously.
It's weird that there would be any difficulty to do that in today's hardware rendering.
Render the liquid surface distorted as usual, while simultaneously rendering the lightmap surface without distortion, and applying it to the liquid surface's pixels (not texels) before blending. If fragment shaders are as powerful as software rendering, they can do that. The only difficulty with scrolling textures is the lack of a standard. I want to devise a very flexible implementation that interacts with the game's physics, so it will take a while and someone else may implement it their own way before. Previously, the main difficulty for both cases in the software renderer was the fact that the textures were combined with the lightmaps in the surface cache, so any texture transformations would also affect the lighting. Splitting the textures from the lightmaps makes the rendering slower, but it greatly improves the rendering quality and makes all sorts of texture mapping effects possible. With today's CPUs, that's a worthy tradeoff. You might want to distort the lightmap, like on the water surface.
I can imagine that looking pretty cool at the pixel lod. I've thought of some, but the water drawing is pretty heavy already.
All the features I've added to it are for solving map design limitations � lightmapped water allows for water properly fading to darkness in caves or tubes, molten texture mapping allows for seamless liquid texturing on complex shaped brushes, translucency allows for more gameplay possibilities, and so on. The poor translucency of the 8-bit software renderer, for example, limits the choices of textures that can be used on translucent surfaces, because some of them (e.g. the blue water in E2M1) loses too much color fidelity. |
|
|
|
|
|
| You must be logged in to post in this thread. |
|
| Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors. |