[Warhammer Dark Omen Forum]

Warhammer Dark Omen Forum
Recent Posts

Hi,

great timing as I was just uploading a newer Mod Pack Jan 2020! Thanks to Dege's excellent dgVoodoo software and his recent Dark Omen graphical fixes, that Ghabry kindly applied into his darkpatch.dll, it now makes Dark Omen look even more amazing. So please now follow the new help fix guide

http://forum.dark-omen.org/index.php/topic,111.msg310.html#msg310

[ Attachment: You are not allowed to view attachments ]

[ Attachment: You are not allowed to view attachments ]

[ Attachment: You are not allowed to view attachments ]

Hi !
I'm following this forum since several years. I thank you Olly for your devoted work for this game and community.

Today, i try again to install the best warhammer game ever created. Unfortunally, I just hear the music, black screen. I think it's a reg issue but I did not find the file here. The 2020 mod link is broken.
Could you help me please ? Thank you !

Looking good, well done.

Hey gang, hope you all had a good Christmas and new year.
Hope you all didn't think i was gone forever but painting takes a lot of time, and i have something to show!

[ Attachment: You are not allowed to view attachments ]

I've almost finished them but i just wanted to show off the one part I must have spent the most time on getting as close the the source material as possible.

Just wanted to drop a quick note here so say thanks Ghabry. Your hard work is paying off and I'm successfully decoding the fonts and able to display them. I'm still working through some of the unknown parts which mostly seem related to glyph layout and positioning so I'm not ready to share anything yet.

I'll post back here with any of my additional findings on the unknown parts, plus a link to my decoder and also (hopefully) a surprise screenshot of my progress putting the .FNT (and other) decoders to use.

Sorry for taking too long, my config is the one that dege suggested, though im using Max FHD with MSAA and Anisotropy

also GDI hook enabled

Dark Omen running at 2560x1440 no shimmering of trees so looks amazing. Watch in the youtube's highest quality setting to see how beautiful it really is

https://www.youtube.com/watch?v=p455XLNjOj8

Cool find, can't wait to test it thanks, as always seen it but never knew we could interact with it.

Ever wondered how the lighting LIT file is created?
The tool is part of the engine!

Untested, no Dark Omen installed here but looks promising.
History: I found the array that contains the keyboard keycodes and then I found this function which reads numpad and other random keyboard keys, so this made me suspicious what it is.

Search in EngRel.exe for the byte sequence "33C0A3F4F04B00". Change the 33C0 to 9090.
Load a map. The lighting should be different, same as if the LIT file is missing.
Use all of the numpad, F, T, S, D, +, -, =, / (+, - and = try on both normal and num keyboard), LCTRL, RCTRL, Backspace, Numlock, Home, Insert,
Press Num-Enter to save the LIT file, you should see a chatmessage saying that the map was saved.

The save destionation is "j:\\paulb\\LiteEdit\\%s.lit". The path must exist, if you don't have a drive J: search this string and hex edit it to something you have (but don't make the path longer! Terminate with 0x00 byte). Only the %s is important.

I messed up the offset calculation.
Font height is determined in the header via:
Word @ Offset6 + Word @ Offset 8

Text width is calculated via: For every char in the text do:
Word @ Offset4 in the Header + Width from glyph info block + 1


More stuff just by looking at the file.
In the header:
The 0x1090 I mentioned earlier is in the header at offset 0xC.
Afterwards there are actually two color tables with 16 entries. You can see FF00FF00 twice. I guess one is for either "label disabled" or "label highlighted". Or a historic left over, seems to be two times the same but the code uses the 2nd color table.

Glyph info block:
I forgot that this is little endian byte order so the high byte is to the right.
Looking at this 16 byte per "glyph info" starting at 0x90 again you can see patterns:

Word at offset 12 (starting from 0) must be the offset in the pixel data. This number increments with each non-CD-glyph.

Proof: For MENBG the first value is 0x0 and last value is 0x56E0, with 0x1090 offset this gives 0x6770 which is almost the end of the file.

2 16bit-Values must be width and height. We know the offsets between the glyphs so this can be determined by trial and error:
E.g.:
0 to 10 is 16 width. Candidates are 1, 4, 3 and 8. 4 * 8 gives 32 and we have 4bit per color -> 16.
Same works for the other rows.
Result:
Word at offset 4 width.
Word at offset 8 height.
Word at offset 0 maybe enabled. For a few glyphs it is 2, but usually 0 when CD, otherwise 1.

Doesn't fully work for the last glyph:
There are 272 bytes left to file end but it takes 280. (bug in the file maybe)

That info should be enough to write scripts for handling these files.


Still unclear:
glyph info at offset 2: Maybe a bit field, could be partially determined by just unsetting bits and checking ingame what happens.
glyph info at offset 7: Must be width-related, usually equals width or width-1.
Header at offset A.