OK most of you won't know what TM2 is, but it's a second generation terrain Tile Matrix for EAW, which allows for things like beaches and cliffs. It was written by Will Gee, who created the original TM for EAW, which we still use today.

I'm not sure where we got to with this project, but Will did send some test files, which he thought would work, but I don't think they were ever tested.

Is there anyone out there who would like to have a look at this now?

It's one of the last major changes to the game, which with 512 tiles make the terrain look far more realistic.

I posted a bit on this topic again at the Coders Forum in the old thread about it.

The tests showed the TM2 does work at least to break the 64 tile barrier.
The key point my readme to wit:


It just needs time for someone to get back to this issue in the code.

This is the pic ingame proving that the barrier was broken, since the 64th tile (center 4 tiles of pic) in the 4 orientations rendered:


...Pleas note the proper place for the technical details is the Coders forum as the matter requires programming and posting of code to understand

Hi Roy.

Thanks for the reply, but as there is no code work to do, and the project was at a dormant stage, so I felt this was the place to try and get this project going again.

At the Coders forum, no new people can get involved, so this is exactly the right place to discuss this project.

I'd forgotten you'd tried it and made that post, but like several ideas, which were on the go at the time of the release of 1.28E, once the EXE was released, we all wanted to take a break from coding projects. Well, a lot of water has passed under a lot of bridges, so maybe it's time to bounce a few ideas around again?

Yes of course, np.
I should say that theorectically greater than 64 tiles should work. It's never been done by any of us, and Will did not
leave any more details about any tests he did, other than to say he checked the code and it should be working.
My test used 64 tiles, which works because that .exe reads the EAW.tm2 (and .tt2) which has 2 bytes data for every tile location,
in theory this could allow for some 65,535 (256 x 256 - 1) (or FF FF in hex) combinations, e.g. possible tiles.
(correction.. some 16,000 + tiles since you have to divide by 4 for each orientation or direction)
That doesn't necessarily mean it is to use a huge number of tiles in a terrain yet, or the .exe would be able to load them all
in memory.
But it is highly likely in theory it should work to use more than 64 tiles, because only so many tiles show in visual range at any given time.
This seems to me it should work already without memory issues (at least with the 256 x 256 tiles) or minor ones,
since from my understanding only so many tiles in visual range are loaded into graphic memory at any one time.
When I looked at the code (which is extensive and monotonous - tons of lines related to the whole tile loading graphics
video code relations) that was the impression I got at least.

To test more than 64 tiles we would need an .exe coded for the tile names of the new tiles (tile = a terrain file) so the .exe can use them.
Then code a .tm2 with the tile number, etc.
If sucess then when one is at say at position x,y the 65th tile shows, etc. If that test works then on to more to see if the matrix is working, no memory issues, etc.

Then there are more things to address, like relation to the .tt2 (EAW_TTD.dat), and whatever else.
Then also see if it works with 512 x 512 tiles, etc.

Copy of a post made at coders a minute or two ago



Jel

So, I made a tool that reads the eaw.tm and writes a eaw.tm2 file.
I put in the option that every water tile (tile2 in all four orientations) could be recoded as tile 64 in the corresponding orientation.
I made more modifications to the exe, including increasing the tile numbers from 64 to 65 defining tile 64 (the 65th counting from 0) as "Jelly1.ter".
I copied the BNALCTY.TER and LRALCTY.TER from a winter terrain into the root folder and renamed them as BNJelly1.TER and LRJelly1.TER.

Then I flew a mission using he exe I had made.





Bingo! A wintery city where the sea should be

64 tiles are working - there's a lot more to do, expanding from 64, removing a hard coded list of tilenames, and fixing eaw_ttd.dat.


Jel

The exe gives an error message if the eaw.tm2 file is missing



Jel

Hi Tony.

So, we are on the verge of having a much more diverse terrain, but does TM2 allow you to fold a tile more than just by the 4 corners?

TM2 was supposed to make it possible to create cliffs, rounded hills and beaches, but I don't know if Will got that far.

I do not know how far Will got, but I just downloaded Ralf's code for his fix_08, added Will's code and compiled a new exe.
I had ETO_01 loaded, Planeset 2, plus the test eaw.tm2 and my "Jelly1" tile(#64)in the root folder:





The second screenie shows that it is working correctly.

Jel

An explanation for members who wonder what this is all about

The eaw world that we play on is a rectangle of 640x320 tiles, with the layout stored in a file named "eaw.tm".
This file contains 640*320 bytes, one byte per tile. The value of a byte runs between 0 and 255.

If the byte is 0 then the tile to be used is "BNField8.ter" or "LRField8.ter" depending on resolution, and the tile faces North.
If the byte is 1 then the tile to be used is "BNGrass.ter" or "LRGrass.ter" depending on resolution, and the tile faces North.
If the byte is 2 then the tile to be used is "BNWater.ter" or "LRWater.ter" depending on resolution, and the tile faces North.

However, in order to join tiles to make a proper tilemap each tile needs to be able to face East, South and West also. On the south of England many coastal tiles face South, but on the coast of France many need to face North. Others need to face East or West to create the curves in the coastline.
The original programmers achieved this by adding 64, 128 or 192 to the north facing value.
So tiles coded as 0-63 all face north, but a code of 64 is 0+64 so a "BNField8.ter" or "LRField8.ter" facing East.
A tile coded 200 means 200/64 which is 3 remainder 8 which identifies it as a West facing "BNField5.ter" or "LRField5.ter" depending on resolution.
So, because there is only a single byte of data, and the mathematical system used for orientation, we can only have a maximum of 64 types of tile.

Will Gee's work on the eaw.TM2 system allows four bytes of data, the first three being the tile number and the last being a 0, 64, 128, or 192 for the orientation.
This gives a maximum of 1099511627776 possible tiles - a slight increase on the previous max of 64

The eaw.exe that I am working on includes Will Gee's code and reads the "eaw.TM2" file and not the "eaw.tm" file. It has been able to read and display the 65th tile.
So the 64 tile limit is truly broken

Jel