Blogs - Hanfling

The big deal about minor detail is that it sums up to give the atmosphere and feeling which people love about a game. It's something quite subtile. You won't notice if minor details are missing or are done wrong, but in the end it will make the difference.

A good example is the paper trash in Deus Ex floating around. While working on it to make it more fit for networking in HX (using a bNetTemporary approach) it saw in code that once the paper stops moving its animation is changed from deformed and beeing randomly rotated to just been flat and dropping. Never noticed this ingame. So i did go ahead and load up Deus Ex and watched it. After that non continous transition it even dropped at a too high speed. I can't even remember having noticed it before, but now it feels wrong. So i started to improve it. In the end, it is more smooth, and I kinda like it seems to unfold when getting closer to the floor.

For comparison: Deus Ex Version HX Version

In the end i spent working a few hours on improving a feature which I haven't even noticed before and probably nearly nobody else. Was it worth it? -- Yes.

I've beeing working for a while on an OpenGLDrv for UnrealEngine 1 games, but until recently the main focus was just to supply a OpenGLDrv which does work for Nerf and NerfEd, but has now shifting towards building a reliable up to date OpenGLDrv using OpenGL 4.4 feature set.

While this sounds in the first place like just adding shaders and buffers and maybe fancy postprecessing the main development effort is right now to sort out old issues, and i keep stumbling across more and more of them. The most prominent are: MipMaps and and linear vs. non linear light.

To start in chronological order i stumbled upon following article which instantly reminded me of the either to dark or white blurred rendering in UE1 games:
Gamedevelopment.tutsplus.com

The next thing i did is actually trying to load the lightmaps and textures as sRGB textures with varying results depending on the game. For all games it results in lighting and fogging locking really bad and having huge steps, but it guess that is just related to the storage format of the texture and can be be solved. However in Unreal, partially in Nerf it did feel "more right" then uploading the textures as RGB. The Unreal 1 flyby map got some decent bluish tone, while the the water in the cannon was not overbright, which kinda feeled "more right". But for DeusEx it actually does not make that huge difference at all. But that might actually be related for the game developed later with the issue in mind or simply they did a poor job, as DeusEx graphics were really poor compared to what was possible with UE1 (Unreal, Rune, Wheel of Time). That was actually the start where i started to really question the Unreal 1 community paradigma "GlideDrv is how it was supposed to look". To skip a bit ahead of time i found yesterday this youtube video which shows Unreal 1 beeing played with SGLDrv on a PowerVR PCX-2:
Youtube.com
This bluish tone again! Sadly the video does not show the water. So why i'm so excited about this. The conversation between sRGB and RGB is expansive to do on the CPU, but they opted to do that for some 200 Mhz PC, so they must have had a pretty damn good reason for doing so. The first explaination is that it was intended to look that way, but was to expansive, so they dropped or never implemented it for the other render devices. The second explaination is that they made a change to the lighting system so it yielded RGB and not sRGB anymore, but they missed updating the SGLDrv.
However if anyone does have a PowerVR PCX2 around I'm glad about screenshots of that water and other stuff or if you sent me the card by mail, seems kinda hard to find.

The next thing i discovered while working on my OpenGLDrv for KHG (after finally figuring out why i always got a black screen for that game) was that they previously seem to have used BGR8 instead of BGRG7 lightmaps. So next thing i tried was to skip that BGRA7777 -> BGRA8888 resampling (e.g. you get half the color values as before), sth. i wanted to get rid of anyway. To my supprise the game didn't turn out to be utterly dark, but yet again i ran into some rendering bugs, however my subjective impression was that the whole scene gained a better visibility, the dark areas were better visible, with lower gamma, and you didn't need to turn the gamma that high to make them visible where the other parts would have turned out overbright.

Afterwards i tried to combine both approaches, but it turned out that they it seems like the cancel each other to some degree. One explanation might be that you can think of the * 0.5 multiplication of the values as a taylor approximation of a gamma correction.

However, if you feel like your head is exploding now, you feel exactly like me, and I will cover the mipmapping issues in a later article.

I just wrote some commandlet as part of the Revision Framework to dumb the contents of a package called RevisionListObjectsCommandlet.

G:\Development\Revision\System>rfcc listobjects FreeClinic
Package FreeClinic
Package   Brick
Texture     FC_Atrium_A
Texture     FC_AtriumWall
Texture     FC_Wall_05
Palette     Palette1
Palette     Palette3
Package   Concrete
Texture     FC_PlainCeiln
Texture     FC_Wall_01
Texture     FC_Wall_02
Texture     FC_Wall_03
Palette     Palette25
Palette     Palette29
Package   Metal
Texture     FC_Sign_01
Palette     Palette2
Package   Paper
Texture     FC_EyeTest
Texture     FC_poster_A
Texture     FC_Services
Palette     Palette11
Package   Textile
Texture     FC_BedTop_A
Palette     Palette41
Package   Tiles
Texture     FC_MainFloor
Palette     Palette39

In the right column the Object name is displayed while in the first column the Class of the Object is displayed. The indention is to display in which relation the Objects are, e.g. The Texture FC_Atrium_A has the outer object Brick (called group in this case), which in turn has the package FreeClinic as outer, which is the actual texture package. As a minor note: Groups are actually of class Package.

Things get even more interessting when looking at Packages with unreal scripts inside:

Class            RevisionRootWindow
Function           ApplyRootWindowSettings
FloatProperty        InhardcodedHeight
FloatProperty        InhardcodedWidth
FloatProperty        InhMargin0
FloatProperty        InhMargin1
IntProperty          InhMultiplier
FloatProperty        InvMargin0
FloatProperty        InvMargin1
IntProperty          InvMultiplier
ByteProperty         InwinHAlign
ByteProperty         InwinVAlign
FloatProperty        Inx
FloatProperty        Iny
BoolProperty       bMenuMainSinglePlayerOnly
Function           ClampMousePosition
Function           ConditionalBindMultiplayerKeys
StrProperty          Alias
IntProperty          i
StrProperty          keyBuySkills
StrProperty          keyKillDetail
StrProperty          KeyName
StrProperty          keyScores
StrProperty          keyTalk
StrProperty          keyTeamTalk
IntProperty        ForcedMaxScale
FloatProperty      HorizontalDivisor
Function           InitWindow
Function           ModifyNewChild
ObjectProperty       NewKidOnTheBlock
ObjectProperty       NewParent
Function           MutateClientScriptClass
ClassProperty        InClass
ClassProperty        ReturnValue
Function           MutateNewChild
ClassProperty        DesignatedClass
ObjectProperty       NewParent
Function           ResizeRoot
ObjectProperty       Canvas
IntProperty          hMult
IntProperty          vMult
TextBuffer         ScriptText
FloatProperty      VerticalDivisor

It also has commandline switches to change the output, e.g. Björn wants to list all Pawn Classes used inside a map which are displayed by PathName and not just their name, so he would run sth. like:

G:\Development\Revision\System>rfcc listobjects -cp -co 00_Training pawn
DeusEx.Doctor
DeusEx.JaimeReyes
DeusEx.JosephManderley
DeusEx.MedicalBot
DeusEx.MIB
DeusEx.RepairBot
DeusEx.ScientistFemale
DeusEx.ScientistMale
DeusEx.Secretary
DeusEx.UNATCOTroop
DeusEx.WaltonSimons