Makaqu

[Lardarse]

Also for 8-bit colored lighting, you might want to look at the Vavoom engine. It's a quake-based doom port that uses quake's rendering as a base and has neat stuff implmenented in 8-bit color software, and even has new ASM code for drawing colored lighting surfaces in software.

Depending on how similar its rendering code is, it may be useful. But I already know more or less how to get the colored lighting to work:

Colored lights in software Quake. This is something I never imagined I would see someday. Awesome work, mk!

How are you doing that? Are you using a Q2-style colormap, or calculating colours on the fly?

[mankrip]

I'm actually using an additive blend colormap, which is a bit different from the weighted mean blend colormap that Quake 2 uses.

Makaqu's fog effect uses two blending passes. First it uses the lighting colormap to darken the color of each fog pixel according to how low its Z-buffer value is, and then it uses the additive colormap to blend the fog pixel with its corresponding display buffer pixel. Colored lighting may or may not be going to follow a similar route.

Adding support for more blend maps would also be a good idea, as it would allow the creation of more diverse effects.

[leileilol]

necessary flags could be adopted - EF_SUBTRACTIVE, EF_MULTIPLY and EF_MODULATE. Catching up to Unreal's blending

Also don't make every sprite additive. What if a project used sprites for items, signs and things like that (which is a good idea for doing things for a crappy system such as the dreamcast)?

[mankrip]

necessary flags could be adopted - EF_SUBTRACTIVE, EF_MULTIPLY and EF_MODULATE. Catching up to Unreal's blending

Actually, there's a lot of things wrong with the way that a lot of engines negotiate custom effects with the QC code.

I'd rather use a field called, let's say, .r_blend_mode to specify the blending mode, as well as reading its intensity from a field called .r_blend_level.

Using EF_ADDITIVE for additive rendering and .alpha for translucency simply doesn't make sense, but Makaqu will continue supporting them since they're what most mods uses. However, new effects should be accessed through better methods.

Also don't make every sprite additive. What if a project used sprites for items, signs and things like that (which is a good idea for doing things for a crappy system such as the dreamcast)?

Turn the Additive sprite blending option off in the Video menu, and then the engine will only use this effect on entities with the EF_ADDITIVE flag set.

[Spike]

Using EF_ADDITIVE for additive rendering and .alpha for translucency simply doesn't make sense

EF_ADDITIVE and alpha 0.5 will add half of what EF_ADDITIVE and alpha 1 will add. In terms of what it asks the renderer to do, it makes perfect sense.
EF_ADDITIVE is the opposite of the implicit 'EF_MODULATE', which has the value 0. Alpha is just the amount (yup, modulate+alpha1 is non-transparent, but that's only special in that some engines might optimise it, and in doing so ignore alpha channels in 32bit texture replacements).
At the hardware level it makes perfect sense.

I'd rather use a field called, let's say, .r_blend_mode to specify the blending mode, as well as reading its intensity from a field called .r_blend_level.

From an engine perspective, I'd rather use shaders, although I agree that indicating selections is more awkward. Can always use different skins (and thus shaders).
From a modding perspective, I'd rather the engine directly support whatever particular special effect I wish to use, pulling inputs from whatever fields my mod provides to tune the effect to the desired scale/range.
I dislike EF_ADDITIVE too.
DP has some additive-sprites extension that pre-dates EF_ADDITIVE, I think. Basically if the sprite name starts with some character, its additive by default, which doesn't result in any potential protocol conflicts or anything.
If you do wish to add such a field, then I would recommend that you add it in a way that is compatible with halflife maps, as a couple of engines already support that. I can't remember the names, and certainly not the values...
In other news, I really have no idea what the heck I would use any other blending mode for (other than modulate, modulate-with-alpha-1, and additive). At least as a modder. If I did want them, then I'd probably need a lot more stuff to go with them

Regarding coloured lighting, while its impressive, I think you need to change the palette. Quake's palette isn't really suited to anything other than varying shades of brown....

[mankrip]

What doesn't make sense is for EF_ADDITIVE to be a bitflag.

Using bitflags to define blend effects allows the QC coder to set multiple blend modes simultaneously, despite the renderer only being able to use one of them at a time.

Thus, it would be better to use it as a simple index, stored in a specific field created for this, just like .movetype.

EF_ADDITIVE and alpha 0.5 will add half of what EF_ADDITIVE and alpha 1 will add. In terms of what it asks the renderer to do, it makes perfect sense.

Makaqu already does this on the EF_SHADOW blend mode, but this functionality is not something the QC coder can easily deduce. Their naming conventions have no obvious correlation.

Furthermore, the naming convention for .alpha refers to the intensity of the alpha channel, but the software renderer doesn't actually use an alpha channel for blending.

By the way, making .alpha work in conjunction with EF_ADDITIVE in Makaqu would add an extra blending pass to the renderer, which could slow it down as much as Makaqu's fog effect does. If I implement this behavior, there should be a menu option to disable it.

I dislike EF_ADDITIVE too.
DP has some additive-sprites extension that pre-dates EF_ADDITIVE, I think. Basically if the sprite name starts with some character, its additive by default, which doesn't result in any potential protocol conflicts or anything.

I'd rather implement a definition-file system similar to Doomsday's.

If you do wish to add such a field, then I would recommend that you add it in a way that is compatible with halflife maps, as a couple of engines already support that.

Yes, I never mapped for Half-Life, but I'll take a look into it when Makaqu gets more stable.

In other news, I really have no idea what the heck I would use any other blending mode for (other than modulate, modulate-with-alpha-1, and additive).

One of the modes I'm definitely going to add will only apply additive blending to the fullbright pixels, so the viewmodel weapons can have additive muzzleflashes. Using additive blending on fullbright colors and weighted mean blending on non-fullbright colors could also be useful for explosion sprites. This will be possible thanks to the software renderer blending the pixels through a lookup table.

By the way, this sounds somewhat similar to the modulate+alpha1 you mentioned, maybe we're thinking of similar effects.

Regarding coloured lighting, while its impressive, I think you need to change the palette. Quake's palette isn't really suited to anything other than varying shades of brown....

16/24/32-bit rendering should make things prettier, though I'll keep supporting the 8-bit mode on all effects.

[Spike]

sprites are generally fully fullbright. this may be an issue with explosions. otherwise that would probably be a nice touch.

modulate-with-alpha-1=opaque, the default rendering mode that any engine supports.

keep 8-bit mode by all means, but add some way to replace the palette without killing all existing maps!

just make sure it doesn't run as slowly as fte's software renderer did. :s

[mankrip]

Taking a look at this list to see what I can do...

- bring back the brown menu background tint quake v1.01 and earlier had
- old quit messages

Done.

- emulate "tweaked" VGA modes by horizontally stretching pixels by two to make a synthetic 320x480 resolution (when the video mode is actually using 640x480 to draw it)
- render the end1/2.bin in ascii mode on quit
- "framerate chopper" which is a dynamic FPS cap that only renders a variable fraction of your fps on the screen for emulating the speeds and sound of a much slower computer
- re-addition of the -sspeed parameter

Will do.

- force 8-bit sound parameter

Would this be the same as the loadas8bit cvar?

- proper sound attenuation

I'm not sure of what you mean.

- simulate the skinheight 200px crash for models

No, although "developer 1" console warnings to detect files that don't follow the standards would be nice.

- re-enable the direct connect and modem multiplayer buttons (to lead to a TCP-IP simulation of them)

Not much of a point, but could be an optional feature triggered through a cvar.

[leileilol]

- force 8-bit sound parameter

Would this be the same as the loadas8bit cvar?

no, loadas8bit just loads wav files as 8-bit regardless of 16-bit samples or not. This is only useful for memory limited systems (i.e. 8mb, 12mb, and the godly crappy Dreamcast 24mb)

force 8-bit sound would just make Quake do MIXING in 8-bit, gaining some speed on slower, SLOWER CPUS at the expense of a low noise floor. It will also load all sounds as 8-bit as well.

DOSQuake had this feature but was excised in WinQuake, along with -sspeed for some reason.

- proper sound attenuation

I'm not sure of what you mean.

DOSQuake had different attenuation ranges for sound effects than WinQuake/GLQuake did.

[mankrip]

Silly question, why am I getting these warnings when compiling every file?

Code: Select all

cl : Command line warning D4025 : overriding '/W1' with '/W2'
vid_win.c
cl : Command line warning D4025 : overriding '/W2' with '/W1'

[revelator]

left over variable from a previous compiler. had that thing also when switching to newer msvc, what sucks is that to get rid of it you have to hand edit the project files

[Baker]

Mk, since you are basically "Mr. Software Renderer extreme" ...

Fruitz of Dojo port on OSX actually has 4 options in the software render to size the 2D giving it the ability to do the console and HUD as 320x240 while in 640x480. [The specific options: 1x1, 2x1, 1x2 and 2x2.]

Keeps the console and the text size from becoming tiny in, say, 1280x1024 mode.

Just giving you some ideas. I might take a crack at it after I clear my "queue".

That is, if Makaqu doesn't already do this ... I don't see it as an option but you've got quite a bit of goodness packed in your engine ...

Another idea ... support loading 24-bit skyboxes, paletting the images to 8-bit upon load. QWalk might have some ready to go or near ready to go code for this. But this would allow a software renderer to play Q1 single player releases with a skybox without requiring software renderer-specific media --- just load the same same skybox that the GL engine would use.

[mankrip]

That is, if Makaqu doesn't already do this ... I don't see it as an option but you've got quite a bit of goodness packed in your engine ...

It still doesn't, but it's on my list:
http://makaqu.tumblr.com/post/761866550

Currently I'm going to reimplement the background menu tinting and the screen color shifting effects through recalculation of the color shading maps, and then I'll implement dynamic resizing of the round particles (which will take the screen aspect and the screen dimentions in consideration).

After that I want to work on the drawing functions of the GUI. However, there are also some final touches to be done in other features I've been working on recently, such as the chase camera, and it may be a good idea to finish those before moving on to the GUI work.

Another idea ... support loading 24-bit skyboxes, paletting the images to 8-bit upon load. QWalk might have some ready to go or near ready to go code for this. But this would allow a software renderer to play Q1 single player releases with a skybox without requiring software renderer-specific media --- just load the same same skybox that the GL engine would use.

This should be implemented, mainly because I also want to implement support for 24/32-bit video modes in the engine.

However, I'm thinking about not supporting 16-bit color modes, mainly because each color in the Quake's palette is comprised of a 24-bit (8+8+8) RGB scale, and there's no way to translate that to 16-bit without losing some color.

There's also a nice explanation about video color modes here, with the same conclusion.

Plus, in 24-bit we can quickly translate the colors with no need for additional lookup tables, so it should be easier to implement and maybe a bit more memory efficient than a 16-bit rendering would be.

[Sajt]

Fruitz of Dojo port on OSX actually has 4 options in the software render to size the 2D giving it the ability to do the console and HUD as 320x240 while in 640x480. [The specific options: 1x1, 2x1, 1x2 and 2x2.]

Keeps the console and the text size from becoming tiny in, say, 1280x1024 mode.

This is what's been holding up GoldQuake progress for months. It turned out to be a lot more annoying than I had anticipated. GoldQuake supports arbitrary scaling of 2D elements (vid_conwidth and vid_conheight I think), but I still haven't figured out all the nuances in the scr_vrect stuff and sbar clearing (especially being initially unfamiliar with that part of the engine). Not that I've been spending much (any) time on it. Someday I'll finish that feature.

Currently I'm going to reimplement the background menu tinting and the screen color shifting effects through recalculation of the color shading maps, and then I'll implement dynamic resizing of the round particles (which will take the screen aspect and the screen dimentions in consideration).

GoldQuake has this too, free menu tinting using a second colormap

[Baker]

Another idea ... support loading 24-bit skyboxes, paletting the images to 8-bit upon load. QWalk might have some ready to go or near ready to go code for this. But this would allow a software renderer to play Q1 single player releases with a skybox without requiring software renderer-specific media --- just load the same same skybox that the GL engine would use.

This should be implemented, mainly because I also want to implement support for 24/32-bit video modes in the engine.

I took a few minutes to download Sajt's Qwalk source [[url=svn://svn.icculus.org/qshed/trunk/qwalk]Qwalk SVN[/url] and Qwalk homepage] ...

image.c

Code: Select all

image_paletted_t *image_palettize(const palette_t *palette, const image_rgba_t *source_diffuse, const image_rgba_t *source_fullbright)
{
	bool_t palette_has_fullbrights;
	image_paletted_t *pimage;
	int i;

	if (!source_diffuse && !source_fullbright)
		return NULL;

	pimage = (image_paletted_t*)qmalloc(sizeof(image_paletted_t) + source_diffuse->width * source_diffuse->height);
	if (!pimage)
		return NULL;
	pimage->width = source_diffuse->width;
	pimage->height = source_diffuse->height;
	pimage->pixels = (unsigned char*)(pimage + 1);
	pimage->palette = *palette;

	palette_has_fullbrights = false;
	for (i = 0; i < 8; i++)
		if (palette->fullbright_flags[i])
			palette_has_fullbrights = true;

	if (source_diffuse && source_fullbright)
	{
		const unsigned char *in_diffuse = source_diffuse->pixels;
		const unsigned char *in_fullbright = source_fullbright->pixels;
		unsigned char *out = pimage->pixels;
		for (i = 0; i < pimage->width * pimage->height; i++, in_diffuse += 4, in_fullbright += 4, out++)
		{
			if (in_fullbright[0] || in_fullbright[1] || in_fullbright[2])
				*out = palettize_colour(palette, palette_has_fullbrights, in_fullbright);
			else
				*out = palettize_colour(palette, false, in_diffuse);
		}
	}
	else if (source_diffuse)
	{
		const unsigned char *in_diffuse = source_diffuse->pixels;
		unsigned char *out = pimage->pixels;
		for (i = 0; i < pimage->width * pimage->height; i++, in_diffuse += 4, out++)
			*out = palettize_colour(palette, false, in_diffuse);
	}
	else if (source_fullbright)
	{
		const unsigned char *in_fullbright = source_fullbright->pixels;
		unsigned char *out = pimage->pixels;
		for (i = 0; i < pimage->width * pimage->height; i++, in_fullbright += 4, out++)
			*out = palettize_colour(palette, palette_has_fullbrights, in_fullbright);
	}

	return pimage;
}

@Sajt ... I really like the way you code. Ended up browsing through GoldQuake a bit too looking at the extensions you added, etc. And was curious about the tint thing.