HEXEN II community work and discussion

[Korax]

Seven,

I think the bug regarding jsHexen is it loads the cached GL mesh models.
Look under the /data/ and /portals/ folders for one called "glquake" or "glhexen" and delete it, then restart the engine.

The model format between the original and the mission pack is slightly different or it writes and loads these MS2 files differently. Something towards that extent.
In UQE I solved this by just generating & loading up these meshes in-memory, thus completely skipping the HDD steps.

I'm obviously guessing what the problem is, but according to me it seems related to the meshing code.
I'll bet the loading the mission pack the bug will go away in this case, but it'll depend which game you load first when generating the MS files from scratch the second load will be buggy.

[szo]

I posted newest uHexen2 (Hammer of Thyrion) source code, as well as
Windows (Win32 and Win64) and Mac OSX test builds from the SVN at:
http://uhexen2.sourceforge.net/devel/
There is still time before I do an official 1.5.7 release, however
testing to see if there is any regression against the former release
would be welcome.

ChangeLog (as of today, may change later on) :
- Music: Support for FLAC codec. (edit the makefiles to enable it when
compiling, if necessary.)
- All platforms, gameplay, mission pack: fixed an hcode bug which would
make the spiders seemingly invincible for a difficulty-depending time.
- SDL mouse/kbd input: Fix for a rare freezing issue.
- OpenGL: minor gamma updates.
- Utils, hcc: Added a command line option "-os" to compact the strings
heap by eliminating duplicates. some minor revisions.
- Minor fixes, tidy-ups, safeguards elsewhere in the sources.

[webangel]

Thanks for your effort Seven, good to hear jeank is willing to look into this problem.

jeank back in business?

[Mathuzzz]

Thanks for your effort Seven, good to hear jeank is willing to look into this problem.

[Seven]

Hello Korax,

I played around with your engine recently.
Well, my XP could only run v1.14 (v1.16 was missing some runtimes), and I noticed that the complete view/world is blurred.
I could not find the option to turn it off, as I accidently pushed the button right beside "p" on my german layout. That turned it off.
I suggest to disable this "blurring" on default setting, as it changes the visual too much.

Regarding bloom:
Please do not rip it out of your engine code. I (as well as others) always enable a slight bloom (not too much). That makes Hexen more mystical.
You should of course disable these things by defaut, but do not get rid of them completely.
Small things like these sometimes make the difference, when a player chooses his favorite engine...




Hello Mathuzzz,

I was able to contact Jeank
He is still the same helpful and kind person that he always was.
He is renovating (overhaul) his house at the moment, so time is precious and rare at the moment.
We talked about this issue (as I know you are planning to implement some of these into your mod):

FTE:


UQE:


DP:


jshexen2 (bug):


When he has a free time, he will look into it.
The only thing I could find out until now is, that it is not the verts limit in glquake. Also much smaller/simplier models behave same this.

Well, it is not a critical bug at all, as we do not have many external replacement models yet...
But it is good, to know that Jeank is still "available" (somehow).

Best wishes,
Seven

[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.

[Seven]

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

[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/

[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!

[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.

[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]

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]

@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...)

[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.

[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.