Jump to content
COMBATSIM Forum
Krycztij

TAW terrain format

Recommended Posts

Going back to the missile colours. I don't believe we'll see anything in Glide as the AGP stuff is D3D only, I think.

Share this post


Link to post
Share on other sites

Wow. That's one small eye-candy for a player, a giant leap for modderkind. :)

Congratulations :)

It wouldn't be fair to let this pass without notice! ^^

Great job as well with all the discoveries being made concerning the functionality of these opcodes, just to be even more fair and to congratulate on that as well! ;)

I'm sure many are following the thread closely and the work is definitely appreciated greatly!

Thank you sirs! :icon_salute3: Keep it up! :thumbsup:

Share this post


Link to post
Share on other sites

I can definitely say: 0037 controls fog. It might be some coefficient for the distance, or just the index of the fog color, or something more complicated. But it definitely has to do with fogging, at least in the glide version.

Great find!

On a practical note, I noticed that phenomenon with the A50 years ago and referred to it as "ghosting". Back then I played in glide mode exclusively and was rather surprised that no one playing in D3D (most players) could appreciate the effect despite my repeated inquiries and attempts to describe it. It seemed to have the effect of making the A50 much more difficult to locate in HVAA missions (F22 stealth configuration), despite knowing it was in the vicinity. The objective of the HVAA mission would be to penetrate enemy airspace, kill the A50 without detection and return safely. Trying to visually locate the A50, without an EMCON escalation, often proved extremely challenging until the ghosted image appeared. Therefore, I propose that, possibly, this "bug" was intentional for game play purposes, much like a cloaking device.

Share this post


Link to post
Share on other sites

DrKevDog, you may be right.

It's not particularly effective though, and the red HUD triangle tends to give it away long before it gets into visible range.

Share this post


Link to post
Share on other sites

@Eagle_Flight: Thank you, it's a real motivation :)

@DrKevDog: The problem is, the 2nd LOD does not use fogging at all — so the A-50 is clearly visible first, then (when the next LOD is toggled) the fog kicks in and fades out until you're close. If it was for cloaking, the 2nd LOD wouldn't be visible at all. I'm absolutely sure it's a bug :)

I've done a little work on the lights (you know, there are many more lights drawn now that I treat 003f-like instructions as calls) and came to several conclusions:

  • I was wrong with the 0039 draw street lights instruction. There is no number of street light pairs in the operand. And they're not drawn in pairs either. It was just a coincidence on the screenshot: The lights seemed to be paired because of the integer interpolation and the number of pairs was accidentially the same as in the operand.
    So, the instruction means draw a line with one small pixel transparent, one opaque, one transparent, … and I have no clue what the parameter means. The number of points is therefore dependent of the length of the line on the screen. The same instruction seems to be used for some parts of the HUD.
  • TAW does not have a distinct draw light instruction. It just draws points; the same instructions which are used for lights are also used for solid geometry, e.g. the holes in the LAU-68 launcher. The light attenuation (bright yellow -> dark red -> black) depends on distance and is hard-coded in the .3 files.
  • TAW seems to use two kinds of points:
    • small points (which look a little dark and bleached out on my system, I don't know if it's correct or a bug in the wrapper), which are used for streets and plane position lights
    • big points do not look bleached out here; they are used for signal lights on airports and at tall buildings.

    [*]I tried very hard to find any proof of additive blending, automatic attenuation etc which would have explained why TAW uses different instructions to draw similar lights, but I couldn't find anything.

So, here's my current interpretation:

  • 0033 <color> <position> draws a big point but is only used for signal lights on airports and such.
  • 0034 <color> <position> draws a big point, too. I have no idea what's the difference to 0033.
  • 0039 <unknown> <color> <position0> <position1> draws small points on the given line. The first word in the operand is not the number of points drawn; the game always places those two pixels apart. But interpreting it as the number looks correct on most models. It is possible that it was intended that way first and the programmers changed it later for performance or for simplicity. I'll stick to this interpretation until we found out what it really means.
  • 0095 <unknown> <color> <position> draws a small light.
  • 0096 does not seem to draw a light. I interpreted it as a light and desperately tried to locate these lights in 707.3, but I could not find any. They are drawn, but they are problably occluded by later geometry, so I don't think they're intended to be visible.

We'll have to suspend 0039 from the "solved and implemented" list. Well, that's science: making better mistakes tomorrow. :)

Share this post


Link to post
Share on other sites

Speaking of lights, I had another look at 0094 and the following sequence from f22usa2.3 controls the formation lights (?) on each side of the F22's tail. The viewer was very useful here since it showed 'Parameter 0011' (17 decimal) turning these on and off.

4306; 00480011    ;

4307; 00210000000a    ; If Parameter 0011 = 0 then jump to line 4310

4308; 002100010028    ; If Parameter 0011 = 1 then jump to line 4313

4309; 0000    ;

4310; 0047000000040051002c006c002c006c003000510030    ;UV Coords: 81,44 108,44  108,48  81,48

4311; 002f0004021f02200221021e    ; Texture = cam3_9

4312; 0000    ;

4313; 0027000a0032    ; If Distance >10 then jump to line 4320

4314; 00470000000400510030006c0030006c003400510034    ;UV Coords: 81,48 108,48  108,52  81,52

4315; 00070010    ; If 0007 flag set, jump to line 4318

4316; 002f0004021f02200221021e    ; Texture = cam3_9

4317; 0000    ;

4318; 0094001effd8    ;

4319; 0000    ;

4320; 00070010    ; If 0007 flag set, jump to line 4323

4321; 00030091021f02200221021e    ; Flat Shaded Quad, Palette:145  Vertices: 543,544,545,542

4322; 0000    ;

4323; 0094001effee    ;

4324; 0000    ;

I interpret this as follows:

When 'Parameter 0011' is zero, the lights are on, and the result is simply a texture. If 'Parameter 0011' is 1 then the lights are off and the result is either a texture if the '0007 flag' is true/false, or the 0094 opcode is invoked if the opposite. I imagine that 0094 creates some sort of dim light effect, but I've forgotten the command to turn these lights off in-game.

Share this post


Link to post
Share on other sites
When 'Parameter 0011' is zero, the lights are on
I see it the other way around: When #0011 is zero, the lights are off. In the texture, the dark version is four pixels above the light one — so I'm pretty sure that line 4310 renders the lights off and 4314 renders them on. Then 0027 decides (based upon distance) whether the lights are to be rendered via texture or, if the viewer is too far away, not. If not via texture, 0007 decides whether to draw them as a flat-shaded quad or as a 0094, whatever that means.

At this point, I don't understand why we don't see the bright texture version in the viewer. I hope I didn't screw up the distance check :(

Unrelated:

// 005D <unknown> <color> <position> <radius>

// Draw a semi-transparent flat-shaded sphere of the color at palette index <color> and a radius of

//	<radius> at the <position>'th position.

Verified with simpsmok.3 and software renderer. I implemented 0060, too, but I can't confirm that it works — I just don't reach it in car.3, no matter how I set the flags :(

Share this post


Link to post
Share on other sites

Ah, well it was about 20 hours ago that I was looking at the 0094 stuff. Memory not what it was. :(

Will try again later.

I've just done a scan for 0060 and it's only used in:

car.3

crate.3

para.3

It appears in a block at the end of these files. On inspection of the parsed code, I also can't see how these blocks can be reached as there is no jump to the start of them unless the code 'falls through'.

Theoretically, the 0060 should be invoked when 'Parameter 0004' is 0,1,2 or 3.

Share this post


Link to post
Share on other sites

In my version of the viewer, when Parameter 0011 is 0, the light texture is there but dark. When I set it to 1, nothing visible is drawn, hence my confusion....

Share this post


Link to post
Share on other sites

Got it. The problem wasn't the distance — it was 0007 being a call, not a jump. Here's the current version:

http://www.mediafire.com/?7lh72kxmfk5db77

Consider that there is a whole lot of bugfixes, about ten new opcodes, new light rending, shadows visible, AGP textures (on/off via F4), sprites, spheres and due to 0007 there may be new problems with some models like the parachutes. I didn't test any other model than f22usa2.3 with another parameter than #17, so you should back up the old version.

Share this post


Link to post
Share on other sites

Awesome! I could sit here for hours looking at this. SS23 particularly cool since I've never seen one in a firing position in-game. :thumbsup:

A couple of issues which weren't there before:

We seem to have lost use of the left arrow for decrementing the parameter index.

The viewer seems to rapidly change between LODs at certain times. Load c_store.3 to see what I mean.

Share this post


Link to post
Share on other sites

Yes, the "previous parameter" key didn't work properly and I didn't feel like fixing it, so I disabled it. Remind me of fixing it right before the next release, please ;)

I know the LOD problems; there are two, actually:

The first one you mentioned is a back-effect (I don't know the English word for it) in the auto distance adjustment: The viewer adjusts the distance relative to the largest model coordinate (the very top-left number in the viewer). If this is huge, the viewer is placed farther away and therefore, a lower LOD is chosen for the next frame. But this LOD has smaller coordinates (probably because shadows are missing), so the camera is auto-adjusted closer. So, on the next frame, the higher LOD is chosen again and it starts all over.

I don't know how to fix it; I could just use the largest coordinate ever encountered. But this interferes with problem #2:

Some files, like c17.3, look empty, but the distance is just auto-adjusted very far away. If an unknown vertex is encountered, even on hard-to-spot things like lights, it is set to a very large position (something like 2000). I set it to zero first, but you wouldn't notice glitches then. So if you see a blanc screen, have a look at the top-left number and see if it is very large. If so, zoom in. These sometimes appear with certain parameters only; tornado.3 with open canopy is an example :/

Problem #2 should fix itself when all jumps and calls are decoded. Problem #1 should be easy to solve then.

Oh, and there are some very difficult transformations. chalange.3 with a non-zero parameter #1 is an example, c17.3 also. I didn't have time to look for unknown instructions or anomalies, though. If they are present, the files might be very convenient sandboxes :)Edit: t80.3 and zsu_23_4 look misplaced / mistransformed, too.

Also: smbblt1.3 is pretty now that sprites work :thumbsup:

Share this post


Link to post
Share on other sites

Also: smbblt1.3 is pretty now that sprites work :thumbsup:

Yes, it does. It would be even better with an automatic looping feature. ;)

I noticed something strange when investigating 0094 earlier. This is from f22usa2:

4307; 00210000000a ; If Parameter 0011 = 0 then jump to line 4310

4308; 002100010028 ; If Parameter 0011 = 1 then jump to line 4313

4309; 0000 ;

4310; 0047004600040051002c006c002c006c003000510030 ;UV Coords: 81,44 108,44 108,48 81,48

4311; 002f0004021f02200221021e ; Texture = cam4_9

4312; 0000 ;

4313; 0027000a0032 ; If Distance >10 then jump to line 4320

4314; 00070026 ; If 0007 flag set, jump to line 4318

4315; 00470046000400510030006c0030006c003400510034 ;UV Coords: 81,48 108,48 108,52 81,52

4316; 002f0004021f02200221021e ; Texture = cam4_9

4317; 0000 ;

4318; 0094001effd8 ;

4319; 0000 ;

4320; 00070010 ; If 0007 flag set, jump to line 4323

4321; 00030091021f02200221021e ; Flat Shaded Quad, Palette:145 Vertices: 543,544,545,542

4322; 0000 ;

4323; 0094001effee ;

4324; 0000 ;

I get no effect if I change the texture index in blue, and the associated quad is drawn using the texture index in red. No idea why...

In this case, it doesn't matter since the values are the same, but it may explain why a wrong texture appears in the viewer as in type23.3

...and I still haven't found out what 0094 does.

Share this post


Link to post
Share on other sites

Well, 4315 is only executed is 0007 is not set. But if I switch off 0007 in f22usa2.3, it is not rendered at all. It's just three shadow polygons then. No Idea on how to reach it …

I just parsed through the thread to see if I forgot something, and I saw you saying (page 10): "From memory, 008D is the same as 008E but for triangles instead of quads." and for some reason, I responded "Done." Must have gotten confused there; I did not implement it. Any more information on 008D? Because 008E's format is

// 008E <vertices> for each <vertices>[<index>]

and I don't see how this can be applied to 008D, which expects four words in its operand …

Share this post


Link to post
Share on other sites

Well, 4315 is only executed is 0007 is not set. But if I switch off 0007 in f22usa2.3, it is not rendered at all. It's just three shadow polygons then. No Idea on how to reach it …

I just parsed through the thread to see if I forgot something, and I saw you saying (page 10): "From memory, 008D is the same as 008E but for triangles instead of quads." and for some reason, I responded "Done." Must have gotten confused there; I did not implement it. Any more information on 008D? Because 008E's format is

// 008E <vertices> for each <vertices>[<index>]
and I don't see how this can be applied to 008D, which expects four words in its operand …
What I recall, regarding, 008D is that they are all triangles containing the same basic format (// 008D <vertices> for each <vertices>[<index>]) except that, unlike 008E, they occur in the aircraft models exclusively and they are used to map a given texture to multiple polys: mig27.3
0052000C000C0010

005300040148FFCC000000000000FFCC0000003400000000000000340000

006100040148

0062014C00000000FEB6

0075014C

00470000000300FA004600FA000100E10001008D000301480149014C

008D00030149014A014C

008D0003014A014B014C

008D0003014B0148014C

003F00800004

0000

0095000F00040148

0000

0052000C000C0010

005300040148FFCC000000000000FFCC0000003400000000000000340000

006100040148

0062014C00000000FD30

0075014C

008D000301480149014C

008D00030149014A014C

008D0003014A014B014C

008D0003014B0148014C

003F00800004

0000

Also, regarding the 0037 'bug', you may be right on that issue, however, I find it interesting that the opcode feature is found only in the adversarial AWACS aircraft. There were other curious in-game experiences I had with that bug that give me pause and yet, the specifics escape me now, and not to belabor the point regarding this marginal opcode, but I find it curious that the same bug existed in EF2000 and remained uncorrected in ADF and TAW:

EF2000-A50.3

0062007F0011FFE7001D

0066FFC6

0064FFDE

0066003A

0068002EFFF4

0066FFDE

0064FFC6

00660022

0068001D0011

0066FFBC

006900040022

0065FFF8

0067FFDE0004

00640044

0063FFE3FFFDFFFA

00650006

0068FFF6000B

0065FFFA

00610012007F

0037001C

004CBABAC000

0080007F00870089

Share this post


Link to post
Share on other sites

Okay, I understand the format now. I couldn't believe there was actually a useless 3 in the first operand :)

I doubt it's the same as 008E:

36328165.jpg

I guess it means drawing a semi-transparent triangle. I could, however, not determine the color: it's not textured, it's not #3 (which is green). If I use the last triangle's color, then it's correct if seem from behind, but wrong if seen from the front:

wrcol.jpg

Any ideas?

I guess the fact that it only appears in (jet?) aircraft models indicates that the color is hard-coded somewhere around #20 …

Edit: Looks alright with palette color 152, which is used for exhaust according to the Wiki. I consider it solved:

// 008D 0003 <position>[3]

// Draw a semi-transparent flat-shaded triangle with palette color #152. Used for afterburners.

Share this post


Link to post
Share on other sites

OK, but I'm still a bit uncertain about this. Here is the afterburner part of ef20001.3. Note that there is a 0047 textured triangle described at line 1515, with the triangle coordinates correponding to the area I marked in red at the top right of texture cam3_9.tm.

cam3_9_big.jpg

I was wondering whether then the 008d is a transparency using this pattern. The 0047 line is only reached when 'parameter 0003'=1, but it makes sense that the afterburner will always pass through 1 on it's way to 3 thus setting the texture for all states.


1505; 00480003    ;

1506; 002100010010    ; If Parameter 0003 = 1 then jump to line 1510

1507; 002100020090    ; If Parameter 0003 = 2 then jump to line 1524

1508; 0022000200fe    ; If Parameter 0003 > 2 then jump to line 1537

1509; 0000    ;

1510; 0052000c000c0010    ;

1511; 005300040124ffc3000000000000ffc30000003d000000000000003d0000    ;

1512; 006100040124    ;

1513; 0062012800000000fe7c    ; Vertex :296  X=0  Y=0  Z=-388

1514; 00750128    ;

1515; 00470000000300fa004600fa000100e10001    ;UV Coords: 250,70 250,1  225,1

1516; 008d0003012401250128    ;

1517; 008d0003012501260128    ;

1518; 008d0003012601270128    ;

1519; 008d0003012701240128    ;

1520; 003f00800004    ;  If 003f (Time??) test(128), Jump to line 1522

1521; 0000    ;

1522; 0095000f00040124    ;

1523; 0000    ;

1524; 0052000c000c0010    ;

1525; 005300040124ffc3000000000000ffc30000003d000000000000003d0000    ;

1526; 006100040124    ;

1527; 0062012800000000fcb0    ; Vertex :296  X=0  Y=0  Z=-848

1528; 00750128    ;

1529; 008d0003012401250128    ;

1530; 008d0003012501260128    ;

1531; 008d0003012601270128    ;

1532; 008d0003012701240128    ;

1533; 003f00800004    ;  If 003f (Time??) test(128), Jump to line 1535

1534; 0000    ;

1535; 0095000f00040124    ;

1536; 0000    ;

1537; 0052000c000c0010    ;

1538; 005300040124ffc3000000000000ffc30000003d000000000000003d0000    ;

1539; 006100040124    ;

1540; 0062012800000000fae4    ; Vertex :296  X=0  Y=0  Z=-1308

1541; 00750128    ;

1542; 008d0003012401250128    ;

1543; 008d0003012501260128    ;

1544; 008d0003012601270128    ;

1545; 008d0003012701240128    ;

1546; 003f00800004    ;  If 003f (Time??) test(128), Jump to line 1548

1547; 0000    ;

1548; 0095000f00040124    ;

1549; 0000    ;

Share this post


Link to post
Share on other sites

I was wondering whether then the 008d is a transparency using this pattern.

Well, I doubt that. First of all, the MiG 27 model uses a completely different texture, as you see on the screenshot above. Second, the texture changes with the afterburner strength (a weak afterburner in the MiG 27 model will use the camo pattern, while others use the exhaust pattern). Finally, I don't see the pattern in the game either:

ef2r.png

I have no idea what the 0047 is good for in this specific place, but I don't think it has to do with the afterburner. Interesting, though: 0095 being called at a certain time of day only. It becomes more and more apparent that it has something to do with glare, maybe around bright light sources at night. I couldn't see any effect in the game, though :( And that Eurofighter misses a point light, too.

Share this post


Link to post
Share on other sites

Here's the mig27 afterburner code and it seems identical to the EF2000's with the same texture cam3_9, assuming that the index 0000 is actually being used. While there is some camo on this texture, the area defined by the coordinates is the spotty area at the top right of the texture.


1908; 00480003    ;

1909; 002100010010    ; If Parameter 0003 = 1 then jump to line 1913

1910; 002100020090    ; If Parameter 0003 = 2 then jump to line 1927

1911; 0022000200fe    ; If Parameter 0003 > 2 then jump to line 1940

1912; 0000    ;

1913; 0052000c000c0010    ;

1914; 005300040148ffcc000000000000ffcc0000003400000000000000340000    ;

1915; 006100040148    ;

1916; 0062014c00000000feb6    ; Vertex :332  X=0  Y=0  Z=-330

1917; 0075014c    ;

1918; 00470000000300fa004600fa000100e10001    ;UV Coords: 250,70 250,1  225,1

1919; 008d000301480149014c    ;

1920; 008d00030149014a014c    ;

1921; 008d0003014a014b014c    ;

1922; 008d0003014b0148014c    ;

1923; 003f00800004    ;  If 003f (Time??) test(128), Jump to line 1925

1924; 0000    ;

1925; 0095000f00040148    ;

1926; 0000    ;

1927; 0052000c000c0010    ;

1928; 005300040148ffcc000000000000ffcc0000003400000000000000340000    ;

1929; 006100040148    ;

1930; 0062014c00000000fd30    ; Vertex :332  X=0  Y=0  Z=-720

1931; 0075014c    ;

1932; 008d000301480149014c    ;

1933; 008d00030149014a014c    ;

1934; 008d0003014a014b014c    ;

1935; 008d0003014b0148014c    ;

1936; 003f00800004    ;  If 003f (Time??) test(128), Jump to line 1938

1937; 0000    ;

1938; 0095000f00040148    ;

1939; 0000    ;

1940; 0052000c000c0010    ;

1941; 005300040148ffcc000000000000ffcc0000003400000000000000340000    ;

1942; 006100040148    ;

1943; 0062014c00000000fbaa    ; Vertex :332  X=0  Y=0  Z=-1110

1944; 0075014c    ;

1945; 008d000301480149014c    ;

1946; 008d00030149014a014c    ;

1947; 008d0003014a014b014c    ;

1948; 008d0003014b0148014c    ;

1949; 003f00800004    ;  If 003f (Time??) test(128), Jump to line 1951

1950; 0000    ;

1951; 0095000f00040148    ;

1952; 0000    ;

While the same tranparency might be used for all 3 afterburner states, the geometry is different, which will stretch the texture by different amounts.

I'm only mentioning this since I'm still somewhat confused by my earlier experiments with f22usa2 while looking for an answer to 0094. There, the texture used with 'parameter 0011'=1 was the same as that defined when 'parameter 0011'=0, but with the correct texture coordinates. You can see these lights in the cam3_9 texture above.

The only way I can explain this is if all parameters start off at zero to initialize the model state, then incremented to the wanted value.

Your explanation seems to work, so there's no point in dwelling on this....but I'm a bit uneasy about it. Time will tell if I'm just being paranoid. :)

Share this post


Link to post
Share on other sites

As far as I remember, you need 2 Mavs to destroy a dam in TAW. The first discolours it, then the second breaks the dam and floods the valley.

The viewer shows that there are many intermediate stages which I'm not sure are used in the game. The spray produced as the dam is breaking is most impressive. :thumbsup:

dam1.jpg

Share this post


Link to post
Share on other sites

Yes, it looks great :) So many details …

But I'm so desperate with the ref_** models.

First of all, the textures are drawn transparent in the game, but they're drawn solid in the viewer. Looks like my "002D draws solid" theory breaks down.

Even worse is: DrKevDog, you were right with 0083 and 0084. It's not bad that you're right; it's bad that 0083 is so difficult to implement ;) It selects a portion of a texture from two UV coordinates. This portion is to be repeated if any UV in the next triangles exceeds it until 0084 is reached and resets the rectangle to the whole texture. There is no way to implement this cleanly or quickly. I didn't even know any API ever supported such a command -.-

I might have to allocate a scratch texture, fill it with the portion, dirigate the texture commands to the scratch texture, manipulate the UV coordinates, … this will take like, forever and it will likely be a huge performance hit.

Share this post


Link to post
Share on other sites

Mikew,

That is a very significant change from what is rendered normally. Looks very nice, wonder what needs to be done to implement the intermediate steps?

Krycztij,

Okay, many of the Mosk (yes, that's the way they spelled it) and Villa building files use 0083/0084 extensively. The texture is generally TRG_19.tm and is a modular texture which would lend itself to that format:

TRG_19

NONAME89.jpg

I'm working on understanding how or why the portion is to be repeated if any UV in the next triangles exceeds it and how the decisions are made within the texture unit?

Mosk1.3

00620000FFE2FFEAFFD8

006B003C0009

00660050

0064FFC4

00650016

0064003C

0066FFB0

0064FFC4

00750000

006100070009

000819D4

002703E8168E

002703E800DE

002E0000000400200060003F0060003F007F0020007F

002F0004000B000A00090000

00830020008000200020

002E0000000400000000004000000040004000000040

002F000400000009000E000F

0084

00830000006000200020

002E0000000400000000008000000080004000000040

002F00040009000A000D000E

0084

00830020008000200020

002E0000000400000000004000000040004000000040

002F0004000A000B000C000D

0084

00830000004000200020

002E0000000400000000008000000080004000000040

002F0004000B0000000F000C

0084

0000

:popcornsmilie:

Share this post


Link to post
Share on other sites

I have a prototype implemented. To render a texture portion uvMin/uvMax, one must compute the interpolated texture coordinates via uv = uv mod (uvMax - uvMin) in the Pixel shader. This works well on mosk1.3's front, but not on its back:

moskx.jpg

I guess the algorithm is fine, but I'm picking wrong texture positions. Any information on how the texture portion is encoded in 0083? I interpreted the operands as min and max instead of base and dimensions. It works fine now. Another two solved & implemented:


// 0083 <uBase> <vBase> <uDimension> <vDimension>

// Limit texture sampling to the given portion (given in pixels). Out-of-bounds accesses are tiled. This is achieved by

//	computing sample positions through uv % (<uDimension>, <vDimension>) + (<uBase>, <vBase>).


// 0084

// Sample the whole texture again. Used to terminate 0083 blocks.

62 fully implemented, 29 somehow understood or just not yet implemented in the viewer, 8 fully unknown to us.

Share this post


Link to post
Share on other sites

62 fully implemented, 29 somehow understood or just not yet implemented in the viewer, 8 fully unknown to us.

Splendid! :thumbsup:

Anything in particular that I should look into? I've lost track a bit over the weekend.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...