Jump to content
COMBATSIM Forum

Recommended Posts

Well, it goes to show how much it helps having krycztij's viewer. :thumbsup:

By a bit of trial and error, the part of the 3 file dealing with that lip could be found quickly. I wouldn't have bothered if I had to start the game each time.

Link to post
Share on other sites
  • Replies 1.1k
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Posted Images

There's probably more to palettes than meets the eye....

Yes, I said that a little unprecise! I meant daytime palettes. Loading the palettes themselves is very easy (if someone compiles the viewer themselves, they just have to search and replace 1200pal.col in D3D9Renderer.hpp); the hard part is writing the parser for red****.ini to update the textures when the palette changes … I'll get that done when I have a little more time, though.

Well, it goes to show how much it helps having krycztij's viewer. :thumbsup:

By a bit of trial and error, the part of the 3 file dealing with that lip could be found quickly. I wouldn't have bothered if I had to start the game each time.

Nice to hear! And it looks great! I even considered implementing primitive selection, i.e. you move the mouse over the model and it is printed at what offset in the bytecode the triangle can be found. (The concept is quite easy, actually.) But then again, I don't have enough time for that. :rolleyes:
Link to post
Share on other sites

First of all, here's the current build with SSD support:

http://www.mediafire.com/?35ivwwphu5htreq

The support is very very unstable; the viewer will crash on all non-terrain SSD's and even with some terrain tiles. But some, like aden_j.ssd and desrefs1.ssd look great already — although there is no sorting of .3 files for rendering, so they overlap badly.

You can cycle the time of day via F2. At night, you can switch night vision on and off via N, and moonlit / moonless via F5. Currently, only the palettes are switched — red****.ini is NOT implemented yet, so only "red1000" textures will be used.

Also, I had to disable the auto distance. I'll re-implement it in an upcoming build.

At which flight levels does TAW change its palette? I guess it's

  • below 35k feet: ****pal.col
  • 35k–40k feet: al1_****.col
  • 40k–45k feet: al2_****.col
  • 45k–50k feet: al3_****.col
  • abobe 55k feet: al4_****.col

Am I correct?

Also, I need to correct myself again with that time of day stuff. But the results are really really promising this time and I'm 99 % sure it's final (see for yourself in the current build):


// 003F <time> <offset>

// If (1 << time of day) equals <time>, draw the submesh at <offset> - 2 B.

// Used to enable building lights and street lights at 22:00–06:00.


// 0040 <time> <offset>

// If a bitwise AND of (1 << time of day) and <time> evaluates nonzero, draw the submesh at <offset> - 2 B.

// Used to enable building lights at 20:00–08:00.


// 0043 <time> <offset>

// 0045 <time> <offset>

// If (2 << time of day) - 1 is above or equals <time>, jump <offset> - 2 B.

// Used to select shadows and to enable landing gear lights on planes at night.

Link to post
Share on other sites

Awesome! :thumbsup:

It's great that you can lay waste to a whole scene. :)

dstw1.jpg

I believe the altitude palettes are set in the redXXXX.txt files in the lev folder, eg this extract from red1000.txt:

loadpal

1000pal            0   40000 


loadpal

al1_1000           38000 44000


loadpal

aw2_1000           42000 52000	;was 48000


;loadpal

;al3_1000           46000 52000


loadpal

al4_1000           48000 160000	;was 50000

Link to post
Share on other sites

Awesome! :thumbsup:

/Keanu on

Whooaaaaahh!

/Keanu off

Thanks :)

It's great that you can lay waste to a whole scene. :)

Yes; currently, the same set of parameters is applied to all .3 files in the scene. This is yet going to change, but for now it is convenient because parameter changes are visible on a broad palette of models at once :)

I believe the altitude palettes are set in the redXXXX.txt files in the lev folder, eg this extract from red1000.txt:

loadpal

1000pal            0   40000 


loadpal

al1_1000           38000 44000


loadpal

aw2_1000           42000 52000	;was 48000


;loadpal

;al3_1000           46000 52000


loadpal

al4_1000           48000 160000	;was 50000

I see what they did there … and I hate it :( Color palettes are not supported by current hardware, so I cannot work with them. I must convert all textures to RGBC at loading … and if they actually interpolate the palettes in these heights, this means I must interpolate the textures whenever the height changes. Very very complicated to come by and very very slow.

BTW, if you don't want to mess with the different east/west palettes, you can load the D3D version for one set of colors.

Oh yes, E/W makes it even worse.

I don't know what to do yet. Implementing this will cause a whole lot of performance-critical, hard-to-maintain code. I must postpone it until I'm familiar with every detail of TAW's palette internals, and I'll consider the restrictions in future design.

As the Direct3D version is mentioned: I previously stated that I was very unsatisfied with AGP texture colors; but I've found Direct3D video footage of TAW on SimHQ a couple of days ago — and the AGP texture colors do indeed look like they do in the viewer. So, now I'm okay with how we interpret the AGP instructions. On the other hand, I'm a little disappointed with the red, green and blue missile trails … they just don't match TAW's look whatsoever. Those true-color textures have great potential for good looks.

Also: Doesn't Typhoon use .3 files, too? Anyone tried them with the viewer?

Link to post
Share on other sites

...Those true-color textures have great potential for good looks.

On that point, I am in total agreement :thumbsup: The new Custom TAW-Modern-Legacy-AGP PC build is coming along, however, the new ATI AGP video card, hand selected specifically to afford optimal appreciation for those true-color textures ;) , has failed already and we will have to solve that before installing the Viewer.

Also: Doesn't Typhoon use .3 files, too? Anyone tried them with the viewer?

IIRC, Typhoons models are in XML format.

Link to post
Share on other sites

Oh yes, E/W makes it even worse.

I don't know what to do yet. Implementing this will cause a whole lot of performance-critical, hard-to-maintain code. I must postpone it until I'm familiar with every detail of TAW's palette internals, and I'll consider the restrictions in future design.

As the Direct3D version is mentioned: I previously stated that I was very unsatisfied with AGP texture colors; but I've found Direct3D video footage of TAW on SimHQ a couple of days ago — and the AGP texture colors do indeed look like they do in the viewer. So, now I'm okay with how we interpret the AGP instructions. On the other hand, I'm a little disappointed with the red, green and blue missile trails … they just don't match TAW's look whatsoever. Those true-color textures have great potential for good looks.

The palettes used for D3D and Glide tiles are still the same 256 indexed color palettes. Its just that Glide supports E/W as well as altitude banding, whereas D3D doesn't. AFAIK, the colored missile trails are not palette related, but hard-coded. If you just use the D3D palettes (or for that matter, the 1000pal-1400pal Glide palettes, and the XXXXpal files in the "Colors - East-West Sky Transition Disabled (Glide Only)" mod, that should work as well without having to deal with altitudes or E/W transitions. I haven't discussed night (moon/nomo and nvg), so let me know if you want to open that can of worms.

Link to post
Share on other sites

Any idea what that block means? 2b50, 2b52, 2b58, 2b5e, 2b5f … these values are very close, but I can't see any sense in them.

Let us start back up with the 00A3 model. There has been a lull, so lets violate the void with verbosity and I’ll ask the apology for verbosity in advance.

2B or not 2B, that is the current question as it relates to the 00A3 type file header. I suspect the answer is probably similar to that for the question Krycztij proposed regarding the 0083/0087 LOD’s: “How do we know it's our fault if we don't find LOD's?”. So I will remark: How do we know it's our fault if we don't find Transitional Texture’s?

For this discussion I will: 1. take up the defense of my previous 2BXX texture grid thesis, albeit, with new considerations for modifications, 2. Discuss the hardware-based Global Textures system in its current state of understanding, which has, heretofore been unimplemented, unbeknownst to the TAW community and 3. To propose an alternative to the standard palletized implementation of T.O.D. transitions in TAW, for possible use with the viewer.

The 33rd word (2bxx) in the 00A3 header points to the red****.ini [globaltextures] index.

The range of index numbers used in the current game files is limited to 32, 3d and 50 thru 66. 2b32 points to tex_21 and is used exclusively for the four files: island_1.3 – island_4.3.

2b3d points to tex_4 (sea) and is used only for sea, djibouti_e,j and o, aswan_t and aden_m.

2b50 thru 2b66 point to index numbers 80 thru 102. These index slots do not exist in the standard TAW red****.ini files [globaltextures] index, ie., they are not used in the normal standard game.

The appropriate expanded index list for implementation can be found in extracted file noname8319 (which is unused in any current TAW game mode) as follows:

noname8319

[dir]

TM=hardware.tm

[globaltextures]

1=cam3_9

2=cam3_10

3=plane_21

4=material

5=mattdead

6=mob_5

7=fx_4

8=cam3_22

9=cam3_23

10=fx_13

11=cam3_24

12=trg_11

13=cam1_7

14=cam1_9

15=plane_15

16=plane_16

17=cam1_10

18=cam1_20

19=TASKER2

20=cam1_22

21=cam1_23

22=cam1_24

23=plane_18

24=plane_1

25=plane_2

26=plane_3

27=plane_4

28=plane_5

29=plane_6

30=cam3_7

31=plane_8

32=MOB_3

33=MOB_4

34=TRG_1

35=TRG_2

36=TRG_3

37=TRG_4

38=plane_19

39=trg_17

40=cam2_7

41=Tex_52

42=cam3_20

43=exp_1

44=exp_2

45=exp_3

46=cam2_9

47=mob_1

48=cam2_10

49=cam2_20

50=tex_21

51=trg_16

52=tex_1

53=tex_2

54=cam2_22

55=exp_4

57=exp_6

58=cls

59=fx_3

60=scrf_twn

61=TEX_22

62=fx_ian2

63=scrf_ref

64=trg_14

65=trg_15

66=scrf_spc

67=TEX_22

68=cam2_23

69=cam2_24

70=cam4_7

71=cam4_9

72=cam4_10

73=cam4_20

75=cam4_22

76=cam4_23

77=cam4_24

78=cam2_26

79=cam4_26

80=tex_1

81=tex_2

82=tex_3

83=tex_4

84=tex_5

85=tex_6

86=tex_7

87=tex_8

88=tex_9

89=tex_10

90=tex_11

91=tex_12

92=tex_13

93=tex_14

94=tex_15

95=tex_16

96=tex_17

97=tex_18

98=tex_19

99=tex_20

100=scrf_gre

101=tex_23

102=tex_45


;201=exp1a

;202=exp1b

;203=exp1c

;204=exp1d

;205=exp1e

;206=exp1f

;207=exp1g

;208=exp1h

;209=exp1i

;210=exp1j

;211=exp1k

;212=exp1l

;213=exp1m

;214=exp1n

;215=exp1o

;216=exp1p

;217=exp3a

;218=exp3b

;219=exp3c

;220=exp3d

;221=exp3e

;222=exp3f

;223=exp3g

;224=exp3h

;225=exp3i

;226=exp3j

;227=exp3k

;228=exp3l

;229=exp3m

;230=exp3n

;231=exp3o

;232=exp3p

;

;251=halo1

;252=halo2

;

;322=sky0800

;323=sky1000

;324=sky1200

;325=sky1400

;326=sky1600

;327=sky1800

;328=sky2000

;329=sky2200

;310=sky0000

;311=skynvg

;

;341=alexp1a

;342=alexp1b

;343=alexp1c

;344=alexp1d

;345=alexp1e

;346=alexp1f

;347=alexp1g

;348=alexp1h

;349=alexp1i

;350=alexp1j

;351=alexp1k

;352=alexp1l

;353=alexp1m

;354=alexp1n

;355=alexp1o

;356=alexp1p

;357=alexp3a

;358=alexp3b

;359=alexp3c

;360=alexp3d

;361=alexp3e

;362=alexp3f

;363=alexp3g

;364=alexp3h

;365=alexp3i

;366=alexp3j

;367=alexp3k

;368=alexp3l

;369=alexp3m

;370=alexp3n

;371=alexp3o

;372=alexp3p



[preloadsupershapes]

[loadcluts]

clutlist.txt


[bands]

256


[transtxtr]

A=(0,0)

B=(95,0)

C=(95,95)

D=(0,95)


E=(96,0)

F=(191,0)

G=(191,95)

H=(96,95)


I=(0,96)

J=(95,96)

K=(95,191)

L=(0,191)


M=(96,96)

N=(191,96)

O=(191,191)

P=(96,191)


[dircluts]

taxiways=49			; brown runways

roads=2

railways=3

north=198			; grey runways

Note: the TM directory called is “hardware”, the expanded [globaltextures] section, the modified [transtxtr] section and the inclusion of the AGP sky texture index. Another important piece to this puzzle can be found in file noname12452: noname12452
TRANSTXTR GLOBAL NUMBERS


99=tex_2080=tex_1

81=tex_2

82=tex_3

83=tex_4

84=tex_5

85=tex_6

86=tex_7

87=tex_8

88=tex_9

89=tex_10

90=tex_11

91=tex_12

92=tex_13

93=tex_14

94=tex_15

95=tex_16

96=tex_17

97=tex_18

98=tex_19
I believe this eludes to the fact that the listed index slots are used for transitional textures (TRANSTXTR)in the Global Textures environment. Approximately one year ago I was able to obtain partial initial implementation of the hardware based Global Textures system on an AGP available platform. The task was fairly robust and evolving when, unfortunately, I was sidetracked to more urgent SSD developments. It requires the correct configuration of the first eight [globaltextures] index slots, the activation of the true colors sky textures system and a substantial modification of the red****.ini, .txt an TM directories. The implementation appears to convert control of environmental T.O.D. transitions from the current 8-bit palette control to a broader hardware based process using the AGP sky textures. A basic description of the process is as follows: Global textures system activation is a method used to provide textures to the game world environment on a global wholesale scale. The standard ordering of textures for 3D objects in the TAW environment is generally through either the .3 files use of file header textures where the name of the texture file to be used is declared in the file header and accessed directly from the TM folders -or- by the .3 file utilizing the texture index files (redxxxx.ini), to initialize the textures. If the initialization file is not accessible then the global textures system can provide textures for the world environment for that T.O.D. . It appears that the global texture system is not active in TAW by default and must be manually configured. The standard order of function of the in-game texture acquisition process in TAW involves first, the executable (f22.dat) (_f22.exe) accessing the .txt file (redxxxx.txt) which, in turn, accesses the .ini file (redxxxx.ini) The executable initiates the process at game loading by accessing two .txt files (red0800.txt and red1000.txt) which are loaded at the start of the game: DGROUP:0063199C aEnteringGamema db 'Entering GameMain.',0Ah,0 ; DATA XREF: sub_44DF7C+C o DGROUP:006319B0 aNoMouseDriverP db 'No mouse driver present.',0 ; DATA XREF: sub_44DF7C+42 o DGROUP:006319C9 align 4 DGROUP:006319CC aRed1000 db 'red1000',0 ; DATA XREF: sub_44DF7C+59 o DGROUP:006319CC ; sub_44DF7C+68 o ... DGROUP:006319D4 aRed0800 db 'red0800',0 ; DATA XREF: sub_44DF7C:loc_44E026 o DGROUP:006319D4 ; sub_4525C8+F0 o DGROUP:006319DC aLev db '\lev\',0 ; DATA XREF: sub_44DF7C+BD o
DGROUP:0064C234 aGlobaltextures db '[globaltextures]',0Ah ; DATA XREF: DGROUP:off_6DB7EC o

DGROUP:0064C234                 db '1=global_1',0Ah

DGROUP:0064C234                 db '2=global_2',0Ah

DGROUP:0064C234                 db '3=global_3',0Ah

DGROUP:0064C234                 db '4=global_4',0Ah

DGROUP:0064C234                 db '5=global_5',0Ah

DGROUP:0064C234                 db '6=global_6',0Ah

DGROUP:0064C234                 db '7=global_7',0Ah

DGROUP:0064C234                 db '8=global_8',0Ah,0

DGROUP:0064C29E                 align 10h

The 00A3 files 2BXX textures appear to provide the terrain texture transitions when the Global Textures system has been activated. The currently identified transition textures called could be mapped using my previously posted 2BXX texture grid, however, confirmation of the correct textures remains to be accomplished before assuming the need for a modification. I suspect these additional transition textures are used for texture blending when used with the default textures when the G.T. system is activated.

I believe this is a method, which could provide a more modern T.O.D. environment mode for the TAW game, and it would be interesting to see if we could get this thing fully implemented for improvement of the new viewer, however, I must add that these are my independent findings and I’ve been wrong before ;)

If after the initial game loading, a T.O.D. other than 08:00 or 10:00 is requested by the player, the specific redxxxx.txt file must then be loaded from the levels (lev) folder. The redxxxx.txt file will then point to the specific redxxxx.ini file to be used at that requested T.O.D., and which is declared in the top of it's file content in the init3d lines: 'init3d_file redxxxx.ini'. The redxxxx.ini file contains the texture indexes and points to the T.O.D. specific TM file where the needed textures are stored. If for some reason the game cannot find or access the .ini file it will begin to request the global textures (which are not loaded at game start). There are at least eight global textures known at this entry: _f22.exe
Link to post
Share on other sites

IIRC, Typhoons models are in XML format.

Oh, that's a pity. They looked so nice to me.

@DKD: Wow. I'm very drunk right now so I don't really understand what yu mean, but I dig the thought of an undiscoverd material system. I guess I will have to read jour text many times tomorrow to understand what's goung on, but I'm really interested in visualizing unused TAW features! Awesome! Really, I want to sqzeeze out every byte of information we get from the .3 files. If you get the viewer up and urnning you may notice that I run it with deluxe treatment like premultiplied alpha, linear color space shading, high texture filtering quality etc to suppress typical glide wrapper flaws like color bleeding. The best is just good enough for precious TAW.

But you really do need to get your system running and re-activate that TOD system – I can work much better when I see screenshots with what you mean ;) I'm also very interested in the TOD textures you're talking about (I don't have anything like that in my extracted files). Having a reference systm which shows TAW in the way it was meant to run would also help with the transparency instructions, which have only been partly decoded through softewear mode! It would be a great help at decoding everything.

Coincidentially, I'm currently workjing on the material system; i.e. 3\RED****.INI. (Time of day works with the latest build already, but only considers palettes, shaddows and lights, not re-loading of RED****.INI and according textures.) What I found out so far (cna't rearticulate it here, so I just paste my code comments):


// Shown by tests with "3\RED0600.INI". Exceeding this length will crash TAW.

Size const maximalSectionNameLength = 105;

// Shown by tests with "3\RED0600.INI". Exceeding this length by one character will make TAW quit with an error message;

//	exceeding it by more than one character will crash TAW.

Size const maximalPropertyNameLength = 19;

// Shown by tests with "3\RED0600.INI". Exceeding this length by one character will make TAW quit with an error message;

//	exceeding it by more than one character will crash TAW. This is NOT true for "3\RED****.INI" values which begin with

//	'txtr', 'gour', 'colr' or 'flat'.

Size const maximalValueLength = 35;


// An INI file as used by Total Air War.

// For a general introduction to INI files, see http://en.wikipedia.org/wiki/INI_file.

//	Tests with "3\RED0600.INI" indicate the following extensions:

//		— Nothing is case sensitive.

//		— Blank lines are permitted.

//		— Sections may appear more than once.

//		— Comments are not limited to the beginning of lines.

//		— The left handside of the equals sign may be preceded by whitespace of arbitrary length.

//		— Properties can have no value assigned (in this case, the equals sign is omitted).

//	Limits for property names:

//		— Property names are not case-sensitive.

//		— If a property name begins with an alphabetic character, it may be followed by up to 18 alphabetical

//			characters, underscores or digits.

//		— If a property name begins with a digit, it may be followed by up to 18 digits.

//	Limits for values:

//		— Any whitespace at the right handside of the equals sign becomes part of the first value.

//	There are no constraints for section names (apart from the maximal length).

This is very hard. E.g. TAW considers whitespace in INI values, but not at the end of values, because that would interfere with the carriage return characters before line feed. Hard to write considering all features and and flaws.

There is much more to find out, I guess TAW has hard-coded treatment of every specific section (i.e. the texture coordiantes exceed the maximal name length, and copying them to another section will make the game crash) so all this will be very hard. But I'm on it :icon_salute3: Just keep the information on texture transitions etc. coming; although I'm short on time at the moment, the more I know and the more detajled my overview is the faster I will get all that implemented when time for these features eventially comes. It all interacts, and in perfect world I would consider all upcoming features in current code already so I don't ever have to re-write anything. But TAW is too complex for me to work out alone through looking at extracted files, and I really need all of you to squeese that knowledge into my brain ;)

Link to post
Share on other sites

A quick update on three more resolved opcodes:

0024/0025 is the same as 0021/0022, but with calls instead of jumps.

0077 is the same as 004B (setting up a transformation for sprites), just without a call. (It is used immediately after calls, so the 0008 0077 combination could be replaced with one 004B. However, 004B also checks an unknown flag and 0077 doesn't. This may all be legacy, though.)

Link to post
Share on other sites

I did not yet have enough time to resume work on .3 headers, SSD's and 3\RED****.INI, but I did work on some details:

  • implemented the 0024, 0025 and 0077 instructions; removed the seperate 0024 / 0025 parameters (useless now)
  • implemented out-of-bounds checking of XYZ indices against the expected vertex count
  • implemented new error messages and error handling (in order to prepare full terrain rendering)
  • object-space-to-view-space transformation is now performed on the virtual processor, not in the renderer (in order to prepare fog)
  • LOD's are now chosen by the object's projected Z value, just like in TAW (was distance-based before)
  • implemented a new transformation stack; should be closer to TAW's implementation now (much faster, too)
  • culling decisions are more precise now
  • fixed a bug with time of day in single-texture files (i.e. runways)
  • fixed a bug with wrong LOD's being chosen
  • reduced memory consumption by 20 %
  • improved performance by 50–400 % (depending on scene)

The download includes the current build and source code:

http://www.mediafire.com/?a2iyovidb9gvzv5

I couldn't test it with all models yet, so you should copy the previous version.

Link to post
Share on other sites

One unconvenient thaught I'd like to mention:

It's possible that TAW actually performs a two-phase interpretation of .3 files. I noticed the game crashing right at startup if I invalidated instructions in certain ways, and loading with crashes when the model actually comes in sight when I modified the instructions in other ways. I guess all jumps are validated at startup, and so are the ranges of color values.

The important thing is that this requires parsing the entire file. This could easily be combined with finding the individual LOD's, and this could be the explanation why there are no offsets for certain .3 types.

I guess we're chasing ghosts when we try to find LOD offsets in all headers :(

I can implement this. Actually, it would make the virtual machine a whole lot easier to maintain and faster. But this would require much research by changing operands and seeing if the game crashes — I guess that would be very time-consuming and quite boring :/ I'll see what I can do.

Link to post
Share on other sites

The thought had crossed my mind when dealing with the 0083/0087 files, that the LOD offsets might make sense if the files were compressed in some way when reading them into memory. Have no real proof though except that I can't make the numbers add up as they are. :)

Thanks for the updated build. It's getting better and better. :thumbsup:

I've missed a few days, so need to catch up....

...and I'd forgotten about DrKevDog's AGP textures. Seems like years ago I rendered a couple of the sky textures together with a modified newhoriz.3 file. The textures are 24 bit colour, but would likely end up looking blocky if there wasn't some smoothing mechanism.

newhoriz39.jpg

Link to post
Share on other sites

...and I'd forgotten about DrKevDog's AGP textures. Seems like years ago I rendered a couple of the sky textures together with a modified newhoriz.3 file. The textures are 24 bit colour, but would likely end up looking blocky if there wasn't some smoothing mechanism.

That looks improved. It's still not completely clear how the video series is supposed to interact with the expanded AGP skybox. I was getting a bit frustrated with trying to confirm the function of the 8 byte section following the 2BXX in the 00A3 files, so I switched tasks and reconstructed a legacy AGP platform (max=1X AGP :lol: ). I deleted all the red****.ini files in the 3 folder and game-activated noname8319 by removing the AGP index edits and renaming it hardware.ini. For testing purposes I am attempting to keep the files consistent with only those suggested in 8319's index, however, the game demands the hardcoded files (seamap1, nvnoise, nvdot, and dust.raw) be included additionally. The lighting and textures are interesting and I hope to observe the T.O.D. transitions later. What I need now is a screen capture program compatible with a win98 OS, anyone have such a thing? :)

I'm hoping to get data regarding TAW's use of the 2BXX lines and especially looking to see how/if the [TRANSTXTR] translations are active and observable.

Link to post
Share on other sites

...and I'd forgotten about DrKevDog's AGP textures. Seems like years ago I rendered a couple of the sky textures together with a modified newhoriz.3 file. The textures are 24 bit colour, but would likely end up looking blocky if there wasn't some smoothing mechanism.

Oh, I'm a little disappointed now. These looks exactly like vertex colors :(

@DKD: Sounds awesome! :icon_bow: Maybe you can find an ancient Fraps version somewhere, like 1.9d?

I've implemented the parser prototype and it works well; I could remove Mike's LOD table and everything is still rendered fine. But I'm very tired now and I'll need to clean up tomorrow, so no new build for this day.

Also, I've found out what the first word in the .3 file (the negative one) is for:

As mentioned earlier, TAW does not choose LOD by actual distance to the viewer. Rather, the model is projected into the viewer's coordinate space, and then its coordinate on the Z axis (its distance from your XY screen plane) is looked up in the LOD table.

This has a great side effect: It's automatic culling. Whatever is behind you is not drawn, because it has a negative coordinate on your Z axis and LOD distance ranges are not negative.

But this can be unconvenient, too. If you are, for example, right above a model and look alongside, parts of the model are expected to be visible still. But the model has a zero or negative Z coordinate and is therefore culled. That's not desired.

And this is where the first word comes into play. It's simply the minimal 'distance' to which a LOD is visible. Since it's negative with roughly the model's diameter, it is impossible that the model is culled by accident.

So: If the first three words of a .3 file are -100, 250, 500 then it means LOD #0 is visible at -100 <= Z < 250 and LOD #1 is visible at 250 <= Z < 500.

By the way: Here's an updated comparison of pormonk.3 with software rendering vs. 3View. There's perspective correction missing in software mode, that's why the texture is slightly displaced (we don't want that because it would distort textures if we came close). I guess for mobile unit rendering, we're already as close to the original as it gets :thumbsup:

2czgqx.gif

Link to post
Share on other sites

So: If the first three words of a .3 file are -100, 250, 500 then it means LOD #0 is visible at -100 <= Z < 250 and LOD #1 is visible at 250 <= Z < 500.

Brilliant!

That z-axis projection insight is certainly paying dividends. :)

Link to post
Share on other sites

By the way: Here's an updated comparison of pormonk.3 with software rendering vs. 3View. There's perspective correction missing in software mode, that's why the texture is slightly displaced (we don't want that because it would distort textures if we came close). I guess for mobile unit rendering, we're already as close to the original as it gets :thumbsup:

2czgqx.gif

Just need to create that aliasing effect, and you'll be there. ;)

Awesome job! :beer:

Link to post
Share on other sites

Okay, I've got a blocking problem here:

rwyend26.3


0177; 00270bb80986    ; If Distance >3000 then jump to line 553

...

0551; 0088000400cb00cc00cf00cd    ; Transparency = trg_11

0552; 0000    ;

0553; ffff    ;

0554; 002000200020    ;

As you can see, the 0027 jump goes straight to Nirvana. My parser does not consider FFFF being part of the bytecode (nor the number of vertices at an LOD's beginning nor the 0020 0020 0020 footer at line 554) and won't let the file pass.

What are we going to do now? Is FFFF a valid opcode after all, meaning something like "abort immediately"? How many of these jumps are in the files? Has anyone checked how the game behaves in such a situation?

Edit: Okay; I've tested it in-game and FFFF indeed is a valid instruction meaning abort immediately. I've implemented it that way.

Link to post
Share on other sites

Not much to report today. The problem with 2BXX is persisting and not headed toward anything like nirvana. I created colored TM markers and substituted them in for index slots 80-99. Not a trace of them found in the game :rolleyes:

Here are the first screens from the Global Textures puzzle:

AGPSKY (note the sun, appears to be one of the explosion textures, I'll have to troubleshoot that one)

F222011-07-1404-51-42-17.jpg

F222011-07-1403-43-43-07.jpg

F222011-07-1404-51-23-00.jpg

Link to post
Share on other sites

Great :o It does look much better than I expected …

I'm currently parsing the entire SS\SSINFO.FN, and here's what I found out so far:

  • 002E and 0047 (fetch texture positions) can actually expect negative texture positions. Therefore, I'll omit range checking completely (whenever I define a new range, I'll find a file exceeding it a few days later). There's also occurances where they only fetch two positions (I thought it would be at least three because there are no textured lines).
  • 0098 (set coverage level) can expect negative values, too. (The values are negated anyway, so they're actually positive.) 3\TIPTRAIL.3 is an example.

Link to post
Share on other sites

Is anyone, like … gettin' jealous? :P;)

overviewu.png

I just hacked this down. Another three or four releases will pass until we can explore the terrain like that, it's very unstable and disables the other viewer features, but it's a great proof of concept. What I've noticed so far is:

  • The viewer crashes sometimes because one of the .3's actually uses a texture base position of 280 at night — meaning it was written for higher texture resolution.
  • Texture filtering is causing ugly lines on the terrain. I've chosen a perspective where it's hard to see, but it's really ugly in action.
  • There's one tile not covering up with its neighbors. This could have something to do with the "randomization index".
  • Performance is bad. (30 fps for 20×20 tiles and 3× higher LOD on a high-end system.) I'm running the debug build, which performs hundreds of checks in real-time on each model and the release build will be faster, but it's too slow already in my opinion.
  • Memory usage is O.K. — with all SSD's and 3's loaded into memory, it's roughly 80 MiB.

Need some sleep now … going to come back when the Sun sets ;)

Edit: Sorry, couldn't resist implementing horizon, sun and stars:

scnr.png

The shadows of some objects point to the wrong direction. Those of the town in the screenshot, however, are alright.

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