Talk:Dark Omen Wiki

From Dark Omen Wiki

(Difference between revisions)
Jump to: navigation, search
Line 137: Line 137:
The skills learnt here are enabling us to understand the Dark Omen engine, so that we may hopefully Alter Maps (Create a River Crossing or Import other Buildings) and combined with the existing Deployment Zone Mod, vary the Strategy on each Map.  
The skills learnt here are enabling us to understand the Dark Omen engine, so that we may hopefully Alter Maps (Create a River Crossing or Import other Buildings) and combined with the existing Deployment Zone Mod, vary the Strategy on each Map.  
Even perhaps incorporate Single player Maps into Multiplayer.
Even perhaps incorporate Single player Maps into Multiplayer.
 +
 +
To take all of those picutres of the Dark Omen Maps, I used the NewBoids engine.
 +
 +
It was made by Andy Buchanan (Original Dark Omen Programmer) and he includes his C++ Source Code, if it could help us in any way.
 +
 +
Although it is only a viewer not an Editor but it can tell us the information contained in a Map.
 +
 +
I can also overwrite his M3D files with Dark Omen M3D files, such as the houses or the 3D animated Heads and replace the skins/images with Dark Omen Textures.
 +
 +
http://home.clara.net/obi/oldprograms.html
 +
 +
http://img212.imageshack.us/my.php?image=weirdxj7.jpg
 +
 +
:)
 +
 +
 +
 +
Mikademus replies:-
 +
 +
Yes, I have used that source code. However, a Dark Omen battle is defined in the .PRJ files. They consist of 11 sections, of which his source only covers four (the BASE mesh (the surface), the WATR mesh (water), FURN files (uxtra 3D objects placed on the map) and INST (the instances of the objects)). That is, they can load and draw the map, however, the two largest sections of the project file are the TERR (presumable "terrain") and ATTR ("attributes"?) blocks (and four others), and we have no info about them.
 +
 +
My assumption atm is that the TERR block contains surface abstractions for pathfinding, elevation, traversability and difficulty, among other things.
 +
 +
Also, the ATTR block seems critical, but that is even more difficult to map.
 +
 +
 +
 +
Rob Replies:-
 +
 +
I figured out a bit of the ATTR block:
 +
 +
ATTR
 +
{
 +
char[4] 'ATTR'
 +
long BLOCK_SIZE
 +
long WIDTH_OF_MAP
 +
long HEIGHT_OF_MAP
 +
}
 +
 +
Then follows (width*height/2) bytes. Each tile has 4 bits of attributes and these are packed 2 to a byte.
 +
 +
Then there are 64 bytes, of which I can't make out much.
 +
 +
It looks like this is line-of-sight / accessibility information. attributes are 0 for 'ordinary' tiles, 2 for blocked ( i.e. unit can't move there ), 8 for passable water (such as fords), 10 (8|2) for impassible water.
 +
 +
There are probably more attribute values, its just a matter of looking at all the maps. I made a program which spits out the data as a bitmap, so I can just compare to the minimaps.
 +
 +
Back to top     
 +
 +
 +
 +
Mikademus responds:-
 +
 +
Excellent work. And good, solidly testable hypotheses. Have you already tried changing these values to see what happens in the game?
 +
 +
Olly and Community respond:-
 +
Thank You Both :)

Revision as of 02:07, 19 April 2008


by Mikademus...he is explaining to me how binary attributes are mapped to filenames.

"You might have noiticed that all the .M3D files have strange filenames, like "_7WATER.M3D"

the underscore indicates that the next character is a gfx effect directive Most water is "_7", there is one battle which water is "_6"


I'd like you to take a look at filenames. See this (from my source)]

code:

// Render flags for a model are provided, believe it or not, in // the model's filename. If the leading character is an underline // then the following is a hash for a binary attribute map where // // 00000 ( 0) = no flags // 00001 ( 1) = translucency // 00010 ( 2) = animate texture UV coordinates // 00100 ( 4) = transparency // 10000 (16) = *unknown* // // The hash depends on character // // '0'..'9': flag |= char - 48 (==> 0 .. 9) // 'A'..'Z': flag |= char - 55 (==> 10 .. 35) // 'a'..'z': flag |= char - 87 (==> 10 .. 35) // // The most common filename prefixes (actually, the only ones // present in Dark Omen) are: // // "_4": 00000100 (transparency) // "_6": 00000110 (transparecy and animated texture coordinates) // "_7": 00000111 (transparency, animated texture coordinates, and transparency) // "_K": 00010100 (transparency and unknown effect)


I don't know what the dec16 (bin10000) toggle does

I also don't really know the difference between "translucency" and "transparency", as they use the words in Dark Omen.

//////////////////////////////////////////////////////////////////////////////////////

Could you rename some files and see if you figure out what effect it toggles?"

(So I have started to use the Dark Omen Map Viewer to see the effects it has when I rename the Water files)


This is B2_07 and its _6WATER.M3D

syl6mh6.th.jpg

This is B2_07 but with it re-named as _7WATER.M3D and the other file _6WATER.M3X renamed to _7WATER.M3X

syl7oy4.th.jpg

and finally this is renaming to _KWater

sylkte8.th.jpg


The results can't be seen in these pics but _K actually stop the water flowing.

// "_K": 00010100 (transparency and unknown effect)

unknown effect = Stops animation of water flowing

Ok, final piece here]

After 9 they use letters, so A is 10, B is 11 and so on.

Thus

"_A" --> 01010 (== dec 10) "_B" --> 01011 (== dec 12) "_C" --> 01010 (== dec 13) and dec 16 == 010000

so _K == 20 == 00010100 == the unknown at pos 16, and transparancy at pos 4



So working on this priciple, under the Guidance of Mikademus (many thanks) I then replaced all _4 with _K and vice a versa, on the First Mission

1stmissionallkand4swappeu5.th.jpg


It effected the Trees


Now i renamed all M3D files to begin with _M and this is the result on the first mission.


1stmissionallswappedtomyn7.th.jpg


The closest tree has moving textures.


"Ah, only one tree was animated? That explains why all water is contained in

a single mesh. It would indicate that the UV coordinates of one instance only of the same model is updated, or something Again, a strange limitation of the format/system"

Now we know how the 16-value bit works, and we understand texture coordinate animation a bit better, but the difference betwteen transparency and translucency is still unknown



Now with renaming with _6 all the M3D files.

1stmissionallswappedto6yq0.th.jpg

it created Black under the Tree's Branches.


A change from K to 6 turned off the colour keying


My Next mission will be to start up my 2 old Win98 pcs with Nvidia Geforce2mx 32mb and FX5200 128mb pci cards and play Dark Omen in glorious 3D, to test the difference between "translucency" and "transparency", as they use the words in Dark Omen.

(I think Darkmancer plays in 3D on XP)



Summary:-

The skills learnt here are enabling us to understand the Dark Omen engine, so that we may hopefully Alter Maps (Create a River Crossing or Import other Buildings) and combined with the existing Deployment Zone Mod, vary the Strategy on each Map. Even perhaps incorporate Single player Maps into Multiplayer.

To take all of those picutres of the Dark Omen Maps, I used the NewBoids engine.

It was made by Andy Buchanan (Original Dark Omen Programmer) and he includes his C++ Source Code, if it could help us in any way.

Although it is only a viewer not an Editor but it can tell us the information contained in a Map.

I can also overwrite his M3D files with Dark Omen M3D files, such as the houses or the 3D animated Heads and replace the skins/images with Dark Omen Textures.

http://home.clara.net/obi/oldprograms.html

my.php?image=weirdxj7.jpg

)


Mikademus replies:-

Yes, I have used that source code. However, a Dark Omen battle is defined in the .PRJ files. They consist of 11 sections, of which his source only covers four (the BASE mesh (the surface), the WATR mesh (water), FURN files (uxtra 3D objects placed on the map) and INST (the instances of the objects)). That is, they can load and draw the map, however, the two largest sections of the project file are the TERR (presumable "terrain") and ATTR ("attributes"?) blocks (and four others), and we have no info about them.

My assumption atm is that the TERR block contains surface abstractions for pathfinding, elevation, traversability and difficulty, among other things.

Also, the ATTR block seems critical, but that is even more difficult to map.


Rob Replies:-

I figured out a bit of the ATTR block:

ATTR { char[4] 'ATTR' long BLOCK_SIZE long WIDTH_OF_MAP long HEIGHT_OF_MAP }

Then follows (width*height/2) bytes. Each tile has 4 bits of attributes and these are packed 2 to a byte.

Then there are 64 bytes, of which I can't make out much.

It looks like this is line-of-sight / accessibility information. attributes are 0 for 'ordinary' tiles, 2 for blocked ( i.e. unit can't move there ), 8 for passable water (such as fords), 10 (8|2) for impassible water.

There are probably more attribute values, its just a matter of looking at all the maps. I made a program which spits out the data as a bitmap, so I can just compare to the minimaps.

Back to top


Mikademus responds:-

Excellent work. And good, solidly testable hypotheses. Have you already tried changing these values to see what happens in the game?

Olly and Community respond:- Thank You Both :)

Personal tools
communication