HEXEN II community work and discussion

[jeank]

inkub0: , for you i added contrast slider and fix statusbar and crosshair displacement if screen size changed or tab pushed.
And fix alpha for transparent textures if bloom disabled.

[Seven]

Hello Jeank,

You really did it !
Some days ago I wrote about this statusbar bug.
Now you corrected it already...

Thank you very much.

Best wishes,
Seven

[WhiteMagicRaven]

Here is some HeXen II coding guides.
Download

[somebodys_kid]

Wow! Just Wow!! Many, many thanks to everyone who is still working on making Hexen II better. This is one of my favorite games ever and the time and effort all of you are putting into it is inspiring. Keep up the good work.

[jeank]

Hi to all one more tme

I remove bad bug with lightmap if mummy use fire in egypt levels, so if you play jsHexen2 in egypt levels, that useful update v1.19_02.

??????.?????

[Korax]

Is that mummy bug a generic Hexen2 bug?

[jeank]

No, that was only in jsHexen

[Korax]

Heres a quick list of the major changes for the coming UQE 1.14:

- added underwater (liquid contents) viewport warp effect
- replaced liquid surface warp with Quake2 liquid surface warp
- added colored light support using .lit files for color information
- improved alias model lighting
- reduced minimum viewmodel (weapon) light level
- improved external texture loading (removed forced .wal loading)
- improved external sprite texture loading
- added external sky texture loading for classic layered skies
- disabled tjunction (co-linear) removal
- added model transform (movement/rotation) interpolation
- added external luma (fullbright) texture loading
- removed capped 72 FPS rate limit


Using external textures now is a breeze, all thats needed is decompressing the texture pack to a [base]/textures/ folder and youre done!

Replacing model and sprite textures with external ones a little bit more tricky. I've read what everyone said regarding it, but for me it makes much more sense splitting these textures into two seperate folders... /models/ and /sprites/. I think it'll be simpler for artists to understand too.

There was quite a few logical changes to the way UQE handles external textures. Most importantly .wal textures are not forced anymore. Whats also new is the ability to turn on/off the generation of normalmap textures for internal or external textures. An external normalmap texture will take precedence over generating one. Normalmap rendering can also be turned on/off. Generating and rendering them is now two seperate cvars. If luma textures are found it will load them and render those. Rendering luma textures can also be turned on/off.

With regards to textures there are only two things I'm not certain of. I'm not sure how to render "bump" textures (the code) and also not about which ones takes precedence if both "bump" and "norm" is found.

Another thing 'm not sure of is, even though I've implemented interpolation, it only seems to affect MDL models, not brushmodels ( like the rotors of the windmill ). Is there a way to smooth them out, or is it server-logic causing their jerky movements?

For me one of the nicest additions is uncapping the framerate of the engine. The gameplay is WAAAY smoother now!

Here's a screenshot of 3 things in action:
1. The new 0.8 texture pack
2. Luma textures (green alpha tga test)
3. High FPS rate (cheap GT220)


Here's what happened to some of the cvars:

renamed:
gl_bumpmap > gl_normalmap_generate

new:
gl_interpolate_transform
gl_normalmap_render
gl_lumatex_render
cl_maxfps
sv_fps

other:
r_fps now saving to config

[Baker]

Another thing 'm not sure of is, even though I've implemented interpolation, it only seems to affect MDL models, not brushmodels ( like the rotors of the windmill ). Is there a way to smooth them out, or is it server-logic causing their jerky movements?

I know little about the Hexen 2 game except to the extent that it is a Quake-family engine. I've tried the demo in the past, but beyond that ... well, anyways ...

That being said, if the jerky movement is an issue I'd guess it is the protocol precision for angles being limited to bytes due a discussion here:

Inside3d Forums :: View topic - Avirox's Rotation Tutorial Adapted to NetQuake

Again this is just a guess, Spike could probably post confirming or denying.

Some of you should consider registering and posting at Inside3d.com, where a wealth of Quake series engine coding hangs out.

[Seven]

@ Korax

thank you for your detailed list.
I must ask, because I dont read something about it:
- Is it now possible to have Bloom in every resolution (not only 1024*768 ) ?
Your Bloom looked good in 1.13, but it was a pity, that it only worked with one resolution.
- Is it now possible to change resolution in-game ? (in 1.13 it worked with "-width"...)

Thank you for your effort and great work Korax.

Seven

[WhiteMagicRaven]

I See FTEQW have interpolation of Brushes?
I am registered at inside3d.com.

[Korax]

I've checked that link and applied the code suggestion to smooth out brush rotations but it crashes the server with: "Illegible server message".

I'm not sure why that happens, the updates makes sense and all.

The bloom code did not change. I'm thinking of rewriting it to fix that issue of it not working on higher resolutions, although I'm not sure if is going to be a quicky or not at this stage.

Changing the resolution in-game will be quite some work to do. I will have to look at that and see if its do-able in decent time.

[jeank]

Korax: you can very easy replace your bloom code!
Just take bloom from FTE source, that code work only from one external call, fully compatible with our ports and work proper under higher resolutions.

I just take bloom module from FTE (Spike, thanks for source! ), quickly made little changes and run completed bloom with ten minutes.
And one more time - respect to Spike, his graphical part of engine and range of supported games impress me.
And i believe sometime FTE can be looks like darkplaces engine.

[Korax]

@Baker
I've looked at the topic you suggested... it seems like you posted it too, and I found another topic in that post which suggested the following change:

#define PRIVATE_PROTOCOL_OK   (sv.active && cls.state != ca_dedicated && !cls.demoplayback && !cls.demorecording && svs.maxclients == 1) 

void MSG_WriteAngle (sizebuf_t *sb, float f) 
{ 
#ifdef SMOOTH_SINGLEPLAYER_TEST 
   if (PRIVATE_PROTOCOL_OK) 
      MSG_WriteFloat (sb, f); 
   else 
#endif    
   MSG_WriteByte (sb, ((int)f*256/360) & 255); 
} 

. 
. 
. 

float MSG_ReadAngle (void) 
{ 
#ifdef SMOOTH_SINGLEPLAYER_TEST 
   if (PRIVATE_PROTOCOL_OK) 
      return MSG_ReadFloat(); 
   else 
#endif 
   return MSG_ReadChar() * (360.0/256); 
}

I tried it but it kept on crashing. So I found that commenting "sv.active" sorted it out. I'm not exactly sure what effect that would have, but I'm pretty sure that "sv.active" changes somewhere between writing and reading the angles.

So, I've changed the code to look like this:

void MSG_WriteAngle (sizebuf_t *sb, float f)
{
	// jkrige - rotation smoothing
	if(/*sv.active &&*/ cls.state != ca_dedicated && !cls.demoplayback && !cls.demorecording && svs.maxclients == 1)
	{
		// jkrige - round to nearest value, rather than rounding toward zero
		if (f >= 0)
			MSG_WriteShort (sb, (int)(f*(65536.0/360.0) + 0.5) & 65535);
		else
			MSG_WriteShort (sb, (int)(f*(65536.0/360.0) - 0.5) & 65535);
	}
	else
	{
		// jkrige - round to nearest value, rather than rounding toward zero
		if (f >= 0)
			MSG_WriteByte (sb, (int)(f*(256.0/360.0) + 0.5) & 255);
		else
			MSG_WriteByte (sb, (int)(f*(256.0/360.0) - 0.5) & 255);
	}
	//MSG_WriteByte (sb, ((int)f*256/360) & 255);
	// jkrige - rotation smoothing
}
.
.
.
.
.
float MSG_ReadAngle (void)
{
	// jkrige - rotation smoothing
	if(/*sv.active &&*/ cls.state != ca_dedicated && !cls.demoplayback && !cls.demorecording && svs.maxclients == 1)
	{
		return MSG_ReadShort() * (360.0 / 65536.0);
	}
	else
	{
		return MSG_ReadChar() * (360.0 / 256.0);
	}
	//return MSG_ReadChar() * (360.0/256.0);
	// jkrige - rotation smoothing
}

Any ideas?


@jeank
I've downloaded the code and I'll check out its blooming code today and see how it renders in UQE.

[Baker]

Well, you can do an experiment with that code to see if it solves the issue in a local game just as a mental experiment, but there are about 10 reasons that you wouldn't want to use that code.

Including it would break compatibility with just about everything Hexen 2 that isn't using your engine.

I was providing some information that would probably key you in to my guess of 1 or 2 things that could be what the issue is. Of course, if FTEQW has interpolation of brush models [does it? I don't think it does, but Spike has about every feature imaginable in FTEQW so maybe it does], that might be what you are looking for.

What might be a good idea is posting this topic in the Inside3D engine forum:

Inside3d Forums :: View topic - Better way to do this?

More expert eyeballs looking at an issue and contributing issues is always a better thing and Inside3D has a number of very experienced engine modders.

[Trying to do complex engine development thoughts except player beta testing here is kind of rough, the forum format and volume buries and obfuscates conversions far too quickly usually. Inside3D on the other hand, all you get are veteran modders reading your posts.]