HEXEN II community work and discussion

[szo]

@szo,
Hi, does your engine supports external textures (.tga, .png...) now?
In the last version I tried there was no support.

No, not yet.

[Seven]

Thank you Spike and szo for your comments about the movement speed. I fully understand.
Then I will continue using sv_maxspeed "400" to prevent this.
As far as I understand you, 400 is also the default cl_forwardspeed and cl_sidespeed in Hexen2.


Also Thank you Spike for explanation of the fte particle system and fteextensions + H2 support.
I will try to use vanilla nq syntax/code and see if I can do something in H2...

Very interesting for me to read, that you even made a "DP-imitation" feature for effectinfo.txt in FTE for Quake.



Hello Mathuzzz,

Regarding your transparency question on models:
In DarkPlaces this is absolutely possible. You only need external .tga texture and you can withit make your model partial transparent.
I just tried it with the grunt´s skin and it worked out of the box.
In FTE´s Hexen2 it doesnt work (I tried it with the spider skin and a_torch skin). Which most probably is due to a missing cvar setting. Otherwise I see no reason why FTE should not be able to do it like DP does it. Spike will most probably have the hint


That is one of the reasons why I love Jeank´s jshexen2 extended engine so much.
It has the best particle effects I ever saw in a Hexen2 engine.
He even used that transparent model affect you mentioned by default on his flame models

I tried to make a screenshot that shows it (you see it better in-game ...).
It looks fantastic.



Here some of his screenshots I just found:




It is really a pity that his model code does not allow us to use external ones like in some other H2 engines.
I remember your thread over at inside3d about the HUD-weapons (ported from Heretic) that doesnt work in jshexen2.
If he would still be here with us, he would surely be able to fix it.
Maybe I will try to email him


Regarding sprite animations/usage.
They are handled and animated very similar like models.
You can loop them like a flame model for example.
dpmod has some sprite torches for example.
The "small mod compilation" extended it one step further and added selectable torches (model/sprite/particles).

Best regards,
Seven

[Mathuzzz]

I completely agree. jsHexen was always on the top of my list. It would be really great if he would continue with his work.

[Spike]

@Mathuzzz, works for me...

@seven, flames (and various explosion sprites) should probably be additive rather than blended, for dp/fte you can get that with self.effects |= EF_ADDITIVE; flag before calling makestatic.
regarding transparency in fte - fte loads the (default) shader before the texture rather than the other way around (texture first is pointless if the shader doesn't use that texture), and doesn't then hack the shader based upon what channels there are in the default texture (because that would be evil and would break things that use the alpha channel for things other than transparency via glsl). setting the entity's .alpha will still hack the shader blend mode and sort order though, but only on entities that have that field set because there really isn't any clean way to do it and its mandatory for every single mod that uses .alpha (or ef_additive, of course)...
I've updated fteqcc, Index of /moodles/fteqcc which should fix the miscompilation crashes.

[szo]

I've updated fteqcc, Index of /moodles/fteqcc which should fix the miscompilation crashes.

I gave this one a try to see whether it compiles our hcode, it seems
like you have an issue with loop{} constructs: it is a feature in hcc
which is actually an optimized version of while(1){} or do{}while(1)
with the always-true condition eliminated. (and I do love that one.)

[KrossX]

2.) UQE-Hexen2 V1.16
I know that my Windows XP is old, but that it doesnt get supported anymore out of the box is suprising
V1.14 still works with XP, so I am using this version (it works with Razumen´s mod Ravenhurst as it seems).
Thank you KrossX for uploading a "WinXP" build of V1.16, but the necessity of Visual C++ VS2012 Runtimes makes me still hesitate.

How so? It's just runtimes. Shared libraries needed for software compiled with Visual C++, so you might have a bunch of them installed already. Though usually programs would come with them and install them along the main program itself.

[Spike]

@szo/seven, at the top of global.hc, add:

#ifdef FTEQCC
//make sure the output uses the right instruction set and crc.
#pragma target hexen2
//hexen2's thinktime keyword is supported but not by default (sadly changing the target to h2 does not currently auto-enable it, unlike via the commandline. its an ordering thing)
#pragma keyword enable thinktime
//keywords that fteqcc has no official support for
#define loop for(;;)
#define until(x) while(!(x))
//and because we're too lazy to fix the numerous warnings...
#pragma warning disable F304
#pragma warning disable F305
#pragma warning disable F306
#pragma warning disable F307
#endif

regarding runtimes, imho either the program has a formal installer (that requires admin+uac annoyances), or the libc should be statically linked to the binary.
just depending on random dlls to already exist on the user's system is rather folly especially as most other programs try to avoid requiring system privileges to install nowadays.
not even vista+7(or presumably have the 2012 runtimes installed by default. they don't even have 2005 runtimes. How the heck they still manage to be so bloated I have no idea. Really though, the issue is that there are many different revisions of each runtime that it would be too awkward anyway.
statically linking does impose certain restrictions on apis of course, like enforcing the 'allocator frees' rule. such is the cost of ensuring dependancies are identical to the one they were compiled against.
incidentilly, mingw links against the msvc5 or so runtime, which IS officially part of windows.

Edit: I'll add support for those extra two keywords at some point using the same enable rules as thinktime, if only so that -TH2 works a bit better without code modifications.

[szo]

@szo/seven, at the top of global.hc, add:

#ifdef FTEQCC
//make sure the output uses the right instruction set and crc.
#pragma target hexen2
//hexen2's thinktime keyword is supported but not by default (sadly changing the target to h2 does not currently auto-enable it, unlike via the commandline. its an ordering thing)
#pragma keyword enable thinktime
//keywords that fteqcc has no official support for
#define loop for(;;)
#define until(x) while(!(x))
//and because we're too lazy to fix the numerous warnings...
#pragma warning disable F304
#pragma warning disable F305
#pragma warning disable F306
#pragma warning disable F307
#endif

This is useful to know if using fteqcc, thanks.

[...] incidentilly, mingw links against the msvc5 or so runtime, which IS officially part of windows.

It links against msvcrt.dll by default, yes. (now if I could make m$vc to do the same I might even start thinking about liking the thing...)

[Mathuzzz]

Hey Seven,

about the transparency. Hexen 2 must have some kind of transparency in the vanilla game, otherwise how would they make the web thing. I looked a bit into hc, but didn´t figure it out, yet.

[szo]

Hexen 2 must have some kind of transparency in the vanilla game, otherwise how would they make the web thing. I looked a bit into hc, but didn´t figure it out, yet.

It does have it of course, and not just with opengl but with software rendering as well. It mostly depends on models' flags. See the engine source.

[Mathuzzz]

It does have it of course, and not just with opengl but with software rendering as well. It mostly depends on models' flags. See the engine source.

OK, I managed to. However entire texture, even the parts which are not transparent on the texture, is partially translucent, with that ugly greyish borders.

[Spike]

anything still using palettes is annoying to work with. :s
of course, if the engine is using the desired blend modes due to the selected model flags, a replacement texture will avoid all the palette-related issues with full 32bit precision (assuming the format used is in fact 32bit and not eg a jpeg, of course).
hurrah for things being broken in software renderers!

[szo]

For your reference, I had generated source code to all known hexen2 progs version for reference, no additional modifications or fixes or anything, but source to Raven's several versions of hexen2/hexenworld progs. See here:
http://sf.net/projects/uhexen2/files...hcode_archive/

Updated my hcode archive. See here:
http://sf.net/projects/uhexen2/files...hcode_archive/

[Seven]

Hello Spike and szo,
Thank you for new fteqcc build and new hccode archive.

[Korax]

I'm thinking about it to remove the bloom code from the next update to UQE Hexen II. I'm not overly impressed by the results and I've been thinking that having bloom in the engine is a deviation from what I've set out to do with the whole UQE project; that is to produce a engine mod that is as close as possible to the original look & feel.

Maybe adding bloom is stepping over that line.

I'll probably implement an improved version of 2D scaling that scales according to the vertical screen resolution rather than the horizontal. Its working out pretty well with my work-in-progress UQE Quake II. I'm treating UQE Quake II in an absolute purist fashion, kinda taking a page from Chocolate Doom with the minimum required visual improvements and maximum required fixes.