Jump to content

Back to TFX1

Recommended Posts

3 minutes ago, mikew said:

I'd supply a screenshot, but my video card packed up when running TFXplorer in full screen mode...totally coincidentally I'm sure. :)


Now is not a good time to be trying to buy a new card due to this cryptomining crap. Not only the prices through the roof, but there's nothing more powerful than a GTX1060 in stock where I normally buy my equipment. :angry:

Even that should be more powerful than the GTX590 it will be replacing, with the added bonus that it supports Vulkan that TFXplorer will soon be using.


Sorry for your loss! TFXplorer does put a lot of pressure on the GPU driver (not on the GPU itself, though). I know because I’m looking at this code right now – and wondering, how will I ever get this code hidden behind a proper, Vulkan-compatible interface?! :( The 3 shape renderer really is one of the ugliest problems I ever had to solve.


But anyway, that’s some good work you’ve done on the randomization. I bet you’ll get it right eventually!

Share this post

Link to post
Share on other sites
3 hours ago, mikew said:

Going back to the randomization process, I thought I 'd try to rearrange the data so the tiles are already randomized before starting TAW/TFXplorer.

TAW has 6 places where there is a rand value greater than 1. These increase the number of ssd tiles used to 1016 from the 999 tiles indexed in the env file in the unmodded game.

So, I changed the .lst file so that the env could use indices 0-1015, so there's now a 1:1 relationship.

Then I had to remap the indices in the .env file so that all the non-randomized tiles worked as before. For example, if the original index pointing at a set of 4 files was 41, I shifted the old 42 to be 45 in the new map. Thus giving space to use 42,43 &44 for the previously unused tiles that I can now point at by replacing each instance of 41 by a random values in the range 41-44.




I do hope you can continue your research, it's very interesting that it did not work and I would think it most helpful to know why.

Buying a new card is tricky these days and I've lived this far without the cryptomining feature, I'm just grateful for my powerful dedicated AGP instead..LOL!

Share this post

Link to post
Share on other sites
16 hours ago, DrKevDog said:

I'm just grateful for my powerful dedicated AGP instead..LOL!

AGP cards must be even more popular, as I can't find a new one anywhere. :rofl:


Now I'm really stumped. The tile to the south og Gondor (where we spawn in TFXplorer) is called desrtm_1.ssd. There are 3 other files associated with it for randomization, desrtm_2.ssd etc.

These are all pretty much identical if I look at them in 3View


..and they are completely flat as far as I can tell.


If I try my randomized env/lst/asc files, I get the result in the lower picture.


That looks like a completely different tile.


The obvious concusion is that I'm getting the indexing wrong, but I've scanned through both the original and new env/lst pairs and established that:

1. Where there is no randomization, the ssd name pointed at each of the 160000 tiles is identical between original and new.

2. If a tile is randomized, the ssd name only differs by the last latter from the original.


Is is possible that TFXplorer can be influencing this somehow?



Share this post

Link to post
Share on other sites

I’m somewhat surprised as well. I once experimented with randomization in TFXplorer, but I think (hope?) I removed all of the artifacts.


I don’t have time right now to investigate it, but if you can compile your own TFXplorer, you can check for yourself:

  1. open TFX\TFX Terrain.cpp
  2. navigate to somewhere around line 130, in the middle of tryToLoadTFX3Terrain()
  3. below the index out-of-range error, there should be a line tile.toSupershapeOrNull = toSupershapeOrNull;
  4. click where the red dot is in this image, this creates a breakpoint:
  5. right-click the breakpoint, select Conditions…:
  6. in the way too tiny edit field in the badly positioned dialog, enter x==123 && y==456
  7. of course replace this with actual tile coordinates you’re interested in – you’ll have to check the for loop a few lines above, because IIRC, TFX transposes or mirrors the data …!
  8. hit enter
  9. make sure you have selected the Debug version in the menu bar
  10. hit F5 to start debugging and wait a moment – the debugger will break into your desired tile
  11. hover the mouse above the toSupershapeOrNull variable; name information will appear
  12. if it’s a cloud tile, hit F5 again to skip forward to the terrain … I changed this code a lot here so I can’t say for sure whether terrain or clouds load first :(
  13. if that’s the wrong tile, hover over the supershapes variable (and click the tiny arrow to expand) or over the currentTileIndex variable to get more information. If supershapes, for some reason, does not display as a list like it does in this snapshot, go to the next step and type supershapes.toBeginning,3000 in the window:
  14. if that list is too long to read in a sane way, go to the menu and select Debug -> Windows -> Watch -> Watch 1, then type the variable names in the lines
    (you can check the raw indices typing toIndices,160000 and switch to hexadecimal display in the right-click menu!)
  15. If that still doesn’t make any sense, report back!


Sorry for forcing you into C++ debugging, but isolating the renderer screwed up so many things here that I can barely get the engine loading …

Share this post

Link to post
Share on other sites

I am so sorry for wasting your time. Once I got my graphics card working, I dug out an old utility that converts the map info into an excel sheet.

Running it on my files, I get this:


So, the tile to the south of the runway is dunesi_3.ssd and opening it in 3View shows that it's the same as I get in TFXplorer.


It looks like I've made the same logic error in the conversion and my verification script, although I have no idea what it can be :(

I'll resign if you want...

Share this post

Link to post
Share on other sites

It’s okay; that post may be handy for the next problem :) Did you check


3 hours ago, Krycztij said:

7. […] you’ll have to check the for loop a few lines above, because IIRC, TFX transposes or mirrors the data …!


because I remember there was something odd about the map’s memory layout (mirroring or 90° rotation or something like that) and it was hard to figure out.

Share this post

Link to post
Share on other sites

Yes, it's a bit of a nightmare.

I'm looking at map level, where the ssd indices in the .env file start at the north west corner, and form a raster going towards the south. For everything else, the world origin is the south west corner.

I have no ides how each tiles' local X,Z corrdinates relates to the world. When I made a crude 9-tile viewer back in 2008, I remember just changing signs until I got what I was expecting to see. :)

If I open a TAW tile ssd in 3View, and don't touch the viewing angle, we are looking at the tile from the north...if that's any help.


This was just going to be a quick exercise to see what TFX1 (which would benefit the most) looked like with tile randomization. :rolleyes:

Share this post

Link to post
Share on other sites

A bit of a delay while I had to do some work, but I found the offending part of my code. Here's part of the yugoslavia map with randomization as seen from a great height.


IMHO, it looks more varied than TAW, at least at this scale.

Most of the dots are caused by the use of a non-TFX1 palette.

Share this post

Link to post
Share on other sites

Well, having TFXplorer to visualize things certainly makes all the difference. :)


From the extracted TFX files, we can get some place names:


The places aren't categorized like in EF2000 and TAW's campaign.trg file though.

Share this post

Link to post
Share on other sites

Just write down every little thing you find out; no matter if short or unclear. I’ll come back to it and implement it once the time has come.

Share this post

Link to post
Share on other sites

For each of the TFX1 maps, there's a file like 'dat/somalia.txt', from which this an extract:

29 99 25 9 13 14
144 104 25 9 13 14
136 105 25 9 13 14
143 105 25 9 13 14
144 105 25 9 13 14
140 106 25 9 13 14
141 106 25 9 13 14
142 106 25 9 13 14

Big cities may have 20 or so entries

So in this case, I've guessed a mean value for the position of Mogadishu to put into campaign.trg that TFXplorer expects in TFX3 mode.

40 29 99 0 "Wajir"
40 144 106 0 "Mogadishu"
40 136 105 0 "Afgoi"

Do you really want to implement that sort of thing in TFXplorer?
I suppose it would be good to read in the original dat file and produce labels fom the original data, but IMHO it's not worth the effort.

Share this post

Link to post
Share on other sites
On 3/1/2018 at 3:01 PM, mikew said:

Do you really want to implement that sort of thing in TFXplorer?


Eventually, why not? It started as a tool to make us understand the TFX games and it will always be. Plus, soon terrain logic will be separate from the simulation core, so we can implement whatever we want without polluting the rest of the engine.

(Nice that you mention place names. I’m currently writing an API for borders, because borders.txt has to be removed from the simulation core as well. I could use the above TFX 1 information to implement cities with area instead of point size …)

Share this post

Link to post
Share on other sites

Sounds good!


I haven't achieved much recently, but have tidied up the 'F22 in a TFX1 theatre' mode a bit.


But what to do about the objects in the TFX1&2 worlds that I can fly right through?
While I'm sure the appropriate TFX1&2 SSD handling for COLLISION_BOXES can be added to TFXplorer, I was just going to convert the SSDs to TFX3's format.
But then, I thought it would be better to extract the 'vital data' from all the terrain SSDs making it easier to rebuild them with extra objects or repackage the data in a new format. I already started doing this for TFX3 some years ago.


Then, there's the data used by higher levels that looks like it started in the sSD, but is in fact baked in the exe, like building type,damage tolerance level, airbase taxi nodes etc.


Will the upcoming API deal with any of this, or will we keep the SSD format for now?

Share this post

Link to post
Share on other sites

I don’t write the API with any specific format in mind – it’s a code API (note 1). The terrain plugin must implement a handful of functions like “does this ray hit the terrain, and if so, which material or object is there?”, and then physics work automatically. All our current code is moved to a TFX terrain plugin. This implements the functions using SSD’s COLLISION_BOXES, SSD’s COLLISION_TRIANGLES, and 3’s texture transformation in the header (note 2).


Nothing will change there. However, once the API is finished and all TFX traces are removed from the simulation core, I’ll implement a second terrain plugin with a new format, most likely VRML. Nothing of it is coded yet, so all I say is preliminary and I’ll gladly listen to your wishes. I imagined:

  • Tile-based, again (there is little way around this if you want to support arbitrary terrain sizes).
  • Per tile, one VRML file with one or more objects in it.
  • Each object has one specific material. Materials should probably use predefined names.
    So if you want to make a desert with a small lake in it, you probably have to write in VRML
    • a height map with “sand” material
    • a planar polygon with “water” material
  • Terrain collision information *should* be generated automatically from the visuals. If you desperately need to override it, you could insert an object group with a special name, e.g. starting with COLLISION_, I guess.
  • Interactive/destroy-able buildings could be realized by adding Inline nodes to the terrain VRML files, where each building is an individual VRML file.
  • VRML files for buildings should be in the same format, but should use the COLLISION_ feature more often.
  • Each VRML file should be accompanied by an INI file with some data on damage tolerance etc., but
    1. I have not yet thought about the individual properties we need (e.g. I want fire/explosive damage separate from impulse damage)
    2. we probably can embed them directly into the VRML file as well using a WorldInfo node
  • Further data can be embedded into VRML using named objects.
    E.g. place an empty object with the name TAXI_OBJECT_1 at a specific XYZ in the airfield tile, and I’ll know it’s taxiing.
    (I know DCS does this as well, e.g. the spawn positions for missiles are encoded as named empty objects in the 3DS file describing aircraft.)
  • This will be very slow to process on loading, so I’ll likely add a cache system with a binary format in API-optimal encoding. You should not care about this.

One more statement regarding damage etc. in the API: Building handling is very immature in TFXplorer. We have the animated windsock, we have buildings that can be destroyed using COLLISION_BOXES (still crashes randomly), and that’s it. No interconnections, no accurate collision detection, no nationality. Current API:

  • allows to create a building at a specific place in a tile
  • allows to assign collision boxes (even in the wrong coordinate system because I never got to repair it; I will soon)
  • expects three callback functions for
    1. timer (e.g. the windsock’s is “call me every n seconds so I can update my animation”)
    2. rendering
    3. on hit (e.g. TFX buildings’ is“spawn an explosion in my place and update my .3 parameter #7”)

I’ll improve it but currently it’s not high-priority. E.g. I’d like to add electricity nodes so destroying a power plant will black out nearby cities etc.


I’ll add nice class diagrams about the API structure when it’s done. But right now things are still changing and it would be a waste of time.


Note 1: I can’t tie the terrain to a specific format anyway, because we’d probably like to use procedural generation or web-streamed content at some point in the future – i.e. the data is not yet existent when the game starts! Binding it to arbitrary code instead of arbitrary data makes much more sense from that point of view.

Note 2: This is necessary to differentiate grass, sand, and water in COLLISION_TRIANGLES. I don’t use it now, but prototype code from ~3 years ago is in place and awaits activation. Priorities …

Share this post

Link to post
Share on other sites

Ah good, the API is too deep into the code for me to worry about. :)


I'll play around with the current terrain then.

Today's master plan was to use Blender to manipulate objects on a tile. It uses a different coordinate system to TFX though, and it has the dreaded Python3 as its scripting engine with all the unicode problems that come with it. :angry:

Share this post

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now