Index | FAQ | Search | Memberlist | Usergroups | Profile | Log in to check your private messages | Log in | Register

Makaqu Goto page Previous 1, 2, 3, 4 Next

| Inside3d Forums Forum Index -> Engine Programming

View previous topic :: View next topic
Author | Message
--- | ---
Lardarse Joined: 05 Nov 2005 Posts: 243 Location: Bristol, UK |

Posted: Sat Jun 05, 2010 7:19 pm Post subject: |

frag.machine wrote:

mk wrote:

leileilol wrote:
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?
_________________
<ekiM> Son, you're writing data structures your CPU can't cache.

Back to top |

mk Joined: 04 Jul 2008 Posts: 94 |

Posted: Sat Jun 05, 2010 9:40 pm Post subject: |

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.
_________________
Makaqu engine blog / website.
Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.

Back to top |

leileilol Joined: 15 Oct 2004 Posts: 1321 |

Posted: Sat Jun 05, 2010 10:29 pm Post subject: |

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)?
_________________

Back to top |

mk Joined: 04 Jul 2008 Posts: 94 |

Posted: Sun Jun 06, 2010 1:07 am Post subject: |

leileilol wrote:
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.

leileilol wrote:
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.
_________________
Makaqu engine blog / website.
Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.

Back to top |

Spike Joined: 05 Nov 2004 Posts: 944 Location: UK |

Posted: Sun Jun 06, 2010 3:13 pm Post subject: |

mk wrote:
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.

Quote:
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....
_________________
What's a signature?

Back to top |

mk Joined: 04 Jul 2008 Posts: 94 |

Posted: Mon Jun 07, 2010 3:38 pm Post subject: |

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.

Spike wrote:
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.

Spike wrote:
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.

Spike wrote:
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.

Spike wrote:
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.

Spike wrote:
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.
_________________
Makaqu engine blog / website.
Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.

Back to top |

Spike Joined: 05 Nov 2004 Posts: 944 Location: UK |

Posted: Mon Jun 07, 2010 8:04 pm Post subject: |

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
_________________
What's a signature?

Back to top |

mk Joined: 04 Jul 2008 Posts: 94 |

Posted: Wed Jun 09, 2010 4:00 pm Post subject: |

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

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

Done.

leileilol wrote:
- 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.

leileilol wrote:
- force 8-bit sound parameter

Would this be the same as the loadas8bit cvar?

leileilol wrote:
- proper sound attenuation

I'm not sure of what you mean.

leileilol wrote:
- 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.

leileilol wrote:
- 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.
_________________
Makaqu engine blog / website.
Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.

Back to top |

leileilol Joined: 15 Oct 2004 Posts: 1321 |

Posted: Wed Jun 09, 2010 8:45 pm Post subject: |

mk wrote:

leileilol wrote:
- 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.

mk wrote:

leileilol wrote:
- proper sound attenuation

I'm not sure of what you mean.

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

Back to top |

mk Joined: 04 Jul 2008 Posts: 94 |

Posted: Mon Jul 19, 2010 2:01 am Post subject: |

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

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

_________________
Makaqu engine blog / website.
Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.

Back to top |

reckless Joined: 24 Jan 2008 Posts: 390 Location: inside tha debugger |

Posted: Mon Jul 19, 2010 10:20 am Post subject: |

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 :S

Back to top |

Baker Joined: 14 Mar 2006 Posts: 1538 |

Posted: Mon Jul 19, 2010 7:20 pm Post subject: |

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.
_________________
Tomorrow Never Dies. I feel this Tomorrow knocking on the door ...

Back to top |

mk Joined: 04 Jul 2008 Posts: 94 |

Posted: Mon Jul 19, 2010 8:20 pm Post subject: |

Baker wrote:
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.

Baker wrote:
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.
_________________
Makaqu engine blog / website.
Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.

Back to top |

Sajt Joined: 16 Oct 2004 Posts: 1026 |

Posted: Tue Jul 20, 2010 1:05 am Post subject: |

Baker wrote:
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.

mk wrote:
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
_________________
F. A. Špork, an enlightened nobleman and a great patron of art, had a stately Baroque spa complex built on the banks of the River Labe.

Back to top |

Baker Joined: 14 Mar 2006 Posts: 1538 |

Posted: Tue Jul 20, 2010 6:40 am Post subject: |

mk wrote:

Baker wrote:
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 [Qwalk SVN and Qwalk homepage] ...
image.c

Code:
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.
_________________
Tomorrow Never Dies. I feel this Tomorrow knocking on the door ...

Back to top |

Display posts from previous:

| Inside3d Forums Forum Index -> Engine Programming | All times are GMT Goto page Previous 1, 2, 3, 4 Next
Page 2 of 4

Jump to:

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Powered by phpBB © 2004 phpBB Group