News | Forum | People | FAQ | Links | Search | Register | Log in
Quake Custom Engines
Discuss modified Quake engines here, I guess. What engines do you use? What are the pros/cons of existing engines? What features would you like to see implemented/removed?
First | Previous | Next | Last
8-bit Is A Worthwhile Artistic Goal. 
A lot of players like/prefer the paletted look. Yes, I'm sure a lot of it is down to nostalgia, but that doesn't make it any less a legitimate reason to pursue the 8-bit look for artistic purposes. 
 
@spike - interesting. I didn't realize fte had these features out of the box. I'll revisit fte this weekend. Honestly, I can't recall why I switched to dp, I think it was an issue with q3 shaders or something. r_softwarebanding and r_renderscale are some tasty morsels. Is there presently a cvar to control the distance at which a mip is used? Are mips generated by the engine? If so, can I create mips manually to be used instead? If i recall correctly, fte supports fbsp?

@mankrip - It's very restrictive, yes. Sometimes that's a good thing. I am very fond of the idea of an 8bit software renderer. It's a romantic idea, I can see why it would be ultimately be dismissed as impractical by many.

4096 is a lot of colors. I'm currently using 16 shade textures... after lightmaps (some of which are colored) you end up with a fairly large range that just doesn't look right. It's neither 8bit or hi-fi graphics... it's sort of a cheap impression, but not genuine.

If this were magical christmas land, I would have a software renderer with a 512 color palette, or something along those lines. Would that even be? it's not 8bit, but not high color either (I think).

@kinn - I agree entirely. In my case, it's not really nostalgia. Some of my first Doom/Quake experiences where with DP and Doomsday. I later discovered software rendering and immediately preferred the look. There is something magical about it, almost like an animated painting... I can't quite put my finger on it. 
 
If so, can I create mips manually to be used instead?
A while back in the mapping help thread, Rick told me about a program called MipDip that supposedly allows you to replace the submips. You can find it on Quake Terminus. I tested it briefly but didn't understand how it works, I'll need to look into it more. 
 
@killpixel, sorry, forgot to mention that r_softwarebanding only works with paletted source textures, which means the feature has only really been tested with q1bsp+q2bsp+q1map(with wads). the engine doesn't generate any mips itself in this mode (so watch out for that too).
I could give you some workarounds for q3bsp, but its probably better if I just add palletization logic so that you won't have to tread so carefully... and get wads+wals working properly for paletteized mips.

anyway, the basic idea is that you use 'fte_program defaultwall#EIGHTBIT' in your shader (giving you glsl-based nonq3style shaders) with a 'map $colourmap' (which preprocesses the colormap.lmp), then fte pulls in the palette+lightmap+etc textures too.
for q1+q2, this already happens by default, but q3 content is much more likely to have shaders overriding things, and fte's explictness means you may want to modify those. 
#614 
If this were magical christmas land, I would have a software renderer with a 512 color palette, or something along those lines. Would that even be?

This is one of the possibilities I've studied for a long time, and it isn't worth it. The problem isn't just the size of the palette, it's the speed performance.

A 512 color palette would use 9-bit values for addressing. However, those 9 bits would have to be stored in 16-bit pointers. So, each color index variable would require twice the memory anyway, increasing the amount of cache misses. They would also require bigger color transformation tables and extra bounds checking, which would result in significantly slower performance.

I don't remember all the specifics, but when comparing all possibilities, I've realized that the best options would be to either use direct RGB color values (as Unreal does), or keep the renderer in 8-bit indexed color. And then, since a number of operations are faster to perform in 8-bit indexed color, due to dealing with a single index value instead of individual values for 3 color channels, I've decided to stay in 8-bit. 
And Thus 
mankrip became the dither master. 
 
@spike

forgot to mention that r_softwarebanding only works with paletted source textures

I do use indexed/paletted textures (not quake's palette). though this might not be what you mean?

@mankrip

This is one of the possibilities I've studied for a long time, and it isn't worth it. The problem isn't just the size of the palette, it's the speed performance.

I had a feeling...

So, I really have 2(ish) options: 8bit (with all it's limits) or some sort of post-processing shader.

I don't understand how it works, but a glsl shader seems like a brute force method that's not as accurate as a true 8bit renderer. I imagine it functioning like the way I do it in Photoshop: The scene is rendered, then "palettized", then sent to the display.

@mugwump

thanks for the link to the glsl shader... I've messed with that and a couple other shaders in DP and never got them to work. They either don't work at all or end up looking all messed up... :/ 
 
a glsl shader seems like a brute force method that's not as accurate as a true 8bit renderer. I imagine it functioning like the way I do it in Photoshop: The scene is rendered, then "palettized", then sent to the display.

AFAIK, that's exactly this.

The "correct" way would probably be to quantize textures to a global 8-bit color palette, generate 8-bit color transformation tables (lighting, blending, etc.) from the palette, and apply them using a fragment shader.

Faithfully replicating Quake's lighting is more complicated, because lightmaps should be upscaled 16x with bilinear filtering, and then quantized to 64 levels. Those 64 levels are then used to index the 64 levels of the color shading map (colormap.lmp). 
 
AFAIK, that's exactly this.

That isn't desirable IMO, though it may seem trivial to others.

Not only does it seem inefficient, the pre-palettized scene is just an approximation and sometimes won't look the way it's intended once palettized. 
 
Designing for software rendering is partially about defining the intended looks, and partially about accepting the resulting looks. 
Look At Gz Doom Shader's 
#621 
Sorry, I meant to say "that", not "this". I'm not a native English speaker. 
 
Daemon engine supports Q3 maps and 3D color look up tables which could get you very close I think. In this case you could just take the look up table and apply the palette to it. Otherwise I guess you could do it a la deferred rendering and render lighting and albedo separate and then return the resulting index of lighting + albedo for every pixel, you'd only need 16 bits to store all that. Might be more true to quake's approach but I doubt the average player would notice the difference between the two, especially if you go low-res ("oh this looks like an *old* computer game").

It's probably easier to make a palette whilst doing art, only adding colors to the palette when you really need to, less is more and all. 
 
#622 - that seems to be the case.

#623 - I'm familiar with that. I think it's since been assimilated by the latest gzdoom build as "tonemapping".

#625 - I think I've come across that engine before, I think it was developed for a particular game? Something natural selection-esque IIRC. I'll have to give it another look. Thanks for the lead. 
Out Of Curiosity 
Is there an existing GL engine that accurately fakes the software look? 
 
Qbism super8 I think.

quakespasm with all the graphics settings nerfed.

https://www.youtube.com/watch?v=RtDBQ333KEo 
 
Quakespasm is not 8bit. 
 
I thought super8 was a software engine? Besides, I tried super8 and it fucked with so many basic things that I never wanted to open it again (weird particles, stupid weapon swaying etc, and it had some pointless palette-bend on by default which screwed up all the colours. 
 
quakespasm with all the graphics settings nerfed.

I'm talking about an emulation of how the software engine takes the texture pixel and the lightmap and then uses a LUT (quake's colormap) to output a colour still in the quake palette. There's something about the final look which is just magical to me, and it's not just nostalgia talking :} 
Mark_v Software Mode? 
I am sure that Mark_V has a winquake style version now? Not tried it a great deal but might be worth checking out 
 
MarkV WinQuake looks great but is a software engine and thus I get single digit framerates on modern maps.

I was just hoping someone may have tried to emulate the software look using a modern graphics API, that's all. 
 
Well, I know you don't like DP but Nahuel recently uncovered a GLSL shader for DP that aims to emulate the retro look. I haven't tried it so I don't know how accurate it is, but you might want to give it a try. You can find it here: http://quakeone.com/forums/quake-mod-releases/finished-works/12469-hgszs-retro-quake-glsl-retro-shaders-darkplaces.html
Note that the 2016 DP builds break this shader, so Seven has fixed it (scroll down to post #10 for link). 
Kinn 
Read baker's last post in the mark v thread. I just shat myself with excitement. 
 
Read baker's last post in the mark v thread. I just shat myself with excitement.

Wait.

What.

Windows WinQuake through Open GL for KillPixel

You mean that? Because if that means what I think it means, then consider my dungarees dung'ed and my breeches browned also! 
Also 
damn just realised a few posts up people are talking about FTE doing this - I'll have to have a look. 
First | Previous | Next | Last
You must be logged in to post in this thread.
Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors.