Mikew’s Palette Editor.

Mikew,

have you ever uploaded your tool for public use? Also if you have some time now I have request to be able to import each of the palette row from *.act format. Along with leaving import from BMP as it is now left unchanged.

Polak

have you ever uploaded your tool for public use?

No

Polak

Also if you have some time now I have request to be able to import each of the palette row from *.act format. Along with leaving import from BMP as it is now left unchanged.

That shouldn’t be a problem. Can you send me an example of an .act file that you are generating?

Here is example of ACT for 16 colors row. No header just values.

Unused spots have 00.

3 bytes per each color (RGB)

Black also 0,0,0 white 255, 255, 255

31 39 4d 30 3b 4e 34 3f 52 2b 37 4b 2d 39 4c 32 3d 4f 38 43 55 28 35 49
3c 48 5a 58 61 6f 44 50 60 2c 3e 52 72 7b 85 20 35 4b 26 3b 50 2f 44 5a
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

OK, thanks.

So, there will be 16 colours in your .act file. These will be put into the chosen palette row in the same order that they are in the file.

I think I did something similar with the 1×16 .bmp file … but that was a while ago.

Thank you Mike, received and already promptly used.

Result: quick sky mod beta version here. Just save your original palettes.

My TAW skies beta1

… and the hits just keep on coming!

First thing I tried was my least favorite use of color in TAW, 2000 (8PM). Damn, even water looks better now!

One glitch I noticed was some of the MFD symbols are now too dark to see, but I know this is a quick … beta. I’m only mentioning the MFD colors because I didn’t know they were tied in to the COL files. Interesting.

Anyway, it’s all coming together … 🙂

The purple and pink demons have been exorcised …

Obviously what is missing from this model of the sky is the sun flare. Colors of the sky around the sky are not the same as those on the opposite side of the horizon. I was hoping that TAW’s west and east palettes could add some spice to the model, but it was not to be. The model is very primitive and no special or realistic effects can be brought to life here.

Changing colors of the day sky could be represented better if time interval was more frequent.

Even setting aside my version of colors at 20:00, I cannot understand at all what compelled DID’s artists to use those violets for the same scene of sunset. But as they say the beauty is in the eyes of the beholder.

Even terrain looks better now …

Polak, I’m not asking you to do it if it takes too much time, but just tell me, is it possible to put some gloomy colors in there?

Like what you fudged here?…

Other gloomy pics …

Polak

I cannot understand at all what compelled DID’s artists to use those violets for the same scene of sunset. But as they say the beauty is in the eyes of the beholder.

Ya gotta wonder … 🙂

Wow, nice work!

A couple of technical issues have arisen though. On my PC with the 2000 palette, I get the following:

The sun (or is it moon?) appears to have gone black, as has the clock in the bottom left corner and parts of the plane symbols in the radar displays.

I really need to make that scanner to find where all the palette positions are used …

The most surprising thing was that I was expecting to see a big change in colour with altitude as the palette transitioned to the al1/2/3/4_2000 palette, but I saw no such thing. Does that mean these alternative palettes have nothing to do with altitude?

mikew

The sun (or is it moon?) appears to have gone black, as has the clock in the bottom left corner and parts of the plane symbols in the radar displays.

By error or earlier experimentation I have inadvertendly changed in palette 2000pal.col color of position 254 to black. More interesting is why I had no problem with this and neither had Mark.

Changing palette with altitude seems to be also abandoned idea.

Reminder also that if you want to change size of the sun – play with the value of bogus here:
red2000 file found in lev folder.

;────────────────────────────────────────────────────────────────────────

setsun
bogus 400 270 5 25

increasing 400 10 fold changes the sun to about real size.

PS. It is pretty fascinating for me to know that in each sec we are receiving about 4 lbs of light mass from the sun. Light from the sun takes over 8 min to reach us here, but its reflection from the moon only 1 sec. Also coincident that the size of the moon and sun as seen from earth is nearly identical – pretty unique situation.

mikew

All that you touch all that you see
All that you taste all you feel
All that you love all that you hate
All you distrust all you save
All that you give all that you deal
All that you buy, beg, borrow or steal
All you create all you destroy
All that you do all that you say
All that you eat everyone you meet
All that you slight everyone you fight
All that is now all that is gone
All that’s to come and everything under the sun is in tune
but the sun is eclipsed by the Moon.

😁

Ok, I’m done farting around with work work (I’ve plotted my future for the next year), now it’s time for me to get back to TAW work!

Got your email, will look at it tonight. Also try to finish and release the Texture program, and setup Polak’s recent mods for TAWC. Guess we have ups and downs ’round here, this definitely feels like and UP moment right now!

Polak

Changing palette with altitude seems to be also abandoned idea.

Isn’t there a gamma correction control somewhere? Maybe the alternative palettes are used for that.

MGonzales

Got your email, will look at it tonight. Also try to finish and release the Texture program, and setup Polak’s recent mods for TAWC. Guess we have ups and downs ’round here, this definitely feels like and UP moment right now!

Yea, things have been coming together quite quickly this year. 🙂

I’d appreciate any advice you can give regarding VB. At the moment this is pure research, but if I can structure things in the right way from the start it will make things easier when you take over the code to produce the next tool. 😉

mikew

Yea, things have been coming together quite quickly this year.

Well … as quickly as we would like perhaps.

But, I must agree that there were some significant discoveries and progress considering how TAW likes to keep its secrets despite the fact that the files are out on the open for considerable length of time already. To outsider it may appear rather turtle tempo but they simply cannot see all of the complexities.

So like a radar we nearly completed significant part of full sweep around, but the question should be tought out carefully now what to hit next or again to give this little more visible push.

Polak

what to hit next

Is it time yet?

Ref: New Mission Editor, work has officially begun! By MGonzales
http://www.simhq.com/forum/ubbthreads.php?ubb=showflat&Number=2476674#Post2476674

Is that project off the modders list?

The mission editor work has certainly begun, but I believe we dropped it down the list of things to do since TAWBC seemed to be fulfilling most current requirements.

I can’t speak for the others, but my main problem is time. I already have two jobs plus normal houshold chores so am limited with what I can do. So, I tend to dabble in various areas of TAW as time permits, and on subjects that I find interesting at the time.

It is my private opinion, that getting higher resolution of the TAW’s world map would allow us to further refine it and create more realistic flight and combat environment. I would love of being able to create even little more detailed maps and more detailed world. Flying times and ranges could be made also more realistic.

On that basis new attempt of new Mission Editor would definetely make a lot of sense. At this point though I also feel that TAWBC does the task quite well. It can be too improved, no doubt.

mikew

I’d appreciate any advice you can give regarding VB. At the moment this is pure research, but if I can structure things in the right way from the start it will make things easier when you take over the code to produce the next tool. 😉

mikew, the program works fine and it’s really cool how you substituted a TAW object. I believe I know what you want regarding passing parameters, let me fool around with it this weekend to see what I can come up with. The first thing I’m going to do is dissect the program to understand exactly what it’s doing, but I’ll be starting from scratch again while expanding my VB horizons. I’m learning there’s a lot more to VB than I ever knew existed, for example I never looked into using VB for graphics work. I’ll holler if I have any questions.

Hawkx, as mikew said above, nothing has been abandoned, it’s just a matter of priorities and time. The Mission Editor will be a long time in the making regardless, but it’s important to have a theater map-based program (as mentioned by Polak), so this project won’t be abandoned.

Mark

RGR, So I’ll not hold my breath re: The Mission Editor

mikew,

We talked about this over a PM, then it stalled. Probably due to your time constraints.

Not the best topic for answering this question, but regarding your TAW BC simple utility & Polak’s What’s next? question. Plus, when you can find the time.

Is your simple utility project off the table?

If you were to come up with that simple utility,
I assume It would make the text hacks for our Repair my F22 option.
I use this option every day when using the TAW BC Wizard mission generator.
It’s a pain & there is always a chance for an error when I trade the mission over ICQ.
If this option is not installed just right, TAW BC will change the hack back to no repair.
As a starter your simple utility project could end with that option.

If you were to come up with that simple utility, Next,
Maybe you could include a choice of Protagonists & Allegiances?
That is how we can use all 8 countries in the TAW map.
Those hacks are included in the TAWBC Advanced Combat.TBC file.

Less important is how we use the TAW BC custom loadout feature.
The custom loadout thing saves time from using the TAW BC custom loadout feature, but a real pain that we have a workaround for now.

My questions & topics don’t seem to fit the projects most modders are working on.
I will monitor your posts, but stop adding my 2 cents. Thanks for humoring me.

Sorry Hawk, I thought you were talking about the Mission Editor project I started.

mikew, I vaguely remember the discussion, we need some kinda program to load a TAWBC generated mission and make changes to it? If so, what exactly did you have in mind?

EDIT: If I’m understanding correctly (which seldom happens … lol), this shouldn’t be that big a deal. we’re talking about using a UI to do a search and replace, right? Or is it more complicated than this?

Mark, Sorry,

Maybe you cought me in mid edit.

Thanks for asking about mikew’s TAW BC simple utility

For the reason,
ref; The Repair my F22 option.
http://www.simhq.com/forum/ubbthreads.php?ubb=showflat&Number=2488143#Post2488143

For the how,
Ref this topic; How to repair your F22 without quitting your mission.
http://www.simhq.com/forum/ubbthreads.php?ubb=showflat&Number=2485990#Post2485990

Look into it when you can find the time. Thanks.

Hawkx

Mark

RGR, So I’ll not hold my breath re: The Mission Editor

Not unless you can hold it for a long long time! 😉 But I did say up front (several times) that this wasn’t a weekend job, nor a two week job, nor even a two month job. And who knows how far we’ll get or what’ll end up with? <shrug>

But we already have Battle Commander so we’re good to go NOW, except for a little tweaking you guys are doing. For the short term, a program which automatically edits a TAWBC mission is a lot more doable and will probably always be desirable. With mikew’s guidance, I will look into to this. Thanks for the links.

Hawkx, I’ll answer a bit later … it’s been a tough day. 🙁

Sorry to hear that mikew, you might want to change the smiley by your name for a while. 🙂

Hawkx, I’m re-installing TAWBC right now and I’ll start looking over it tonight. But to be clear so that we have no miss-understandings … 🙂

I’m not really interested in mission making (SP or MP), I’m just thinking that it probably isn’t that big a deal to make a program which loads TAWBC output (assuming it’s all text-based), provide the user with a dialog box or two for selecting a loadout, a couple check boxes for the other stuff you want added/changed in the file, etc. and then saving the file with your desired settings. We can even move/copy files wherever we them if necessary, stuff like that. It’ll be a TAWBC add-on.

So if I can help with this I’d be happy to, despite your comment to Neph on his 4/1 joke, Who needs modders with you on this BB. j/k 😁. But I’m slow so you’ll need to be patient (i.e. I said I’d have the Texture Manager program finished every night for like the past two weeks now … lol).

Mark,

There I go again, I guess. Re: Who needs modders with you on this BB (Meaning Nephilim)
You may know that I was just kidding Neph about how he helped with our little hack.
We both know you are all busy working on different mods. At that time I did NOT have much hope for success in getting a simple Repair my F22 hack to work. April fools day got in the way, but as luck would have it … That was the day that we actually did it.

Now by reading other topics & posts, I am so encouraged that I started a fact simile of what mikew’s simple utility may look like. See new topic, Flying TAW with the SimHQ Option Utility.
No rush as usual, but I feel it could be used by anyone that wants to try any, TAW BC mission, SP or MP, that isn’t just one of the scripted TAW missions.

Some here like to fly H2H & dogfight. The Repair my F22 hack will work with any of the MP missions or in any of the SP missions. That means you could dogfight in any of the MP locations or use the Repair my F22 hack in any of the Custom Mission slots.

You could dogfight anywhere, get shot down & just respawn to go on with the fun.
No time limits to your made up dogfight game. You will even get a score when you quit.

Yo Hawkx!. California? I guess the surfing conditions aren’t so good today, so you’re giving us a hard time here instead. 😉

All TAWBC’s output is in text form, therefore a tool can be used to read TAWBC’s output, modify it, then apply it to TAW. What I did with my experiment is read in the M file in the M folder. This gives the filenames for each of the missions in the multiplayer section. These files can then be scanned to see whether PLAYER RESTART 1 and report back accordingly. This technique can be used for any of the parameters in the xDL files.
There are problems though. Unless comprehensive error checking is used, the system is likely to crash as was the case when I sent the first version to Hawkx.

mikew

Yo Hawkx!. California? I guess the surfing conditions aren’t so good today, so you’re giving us a hard time here instead. 😉

Ouch. 🙂

Ah, Sorry Hawkx … I got a bit carried away.
11 hours working, then 6 hours drinking. Actually, it’s been quite a good day. 🙂

mikew

11 hours working, then 6 hours drinking. Actually, it’s been quite a good day.

Suggest in the opposite order and then in balance TAW moding. Funny my day was very lousy.

… and stay out of the water Hawk!

mikew, I’ll have some of that please! Maybe when I get back from dinner and book shopping. I hope I find that book or one like it. See ya’ll later.

MGonzales

mikew, the program works fine and it’s really cool how you substituted a TAW object. I believe I know what you want regarding passing parameters, let me fool around with it this weekend to see what I can come up with. The first thing I’m going to do is dissect the program to understand exactly what it’s doing, but I’ll be starting from scratch again while expanding my VB horizons. I’m learning there’s a lot more to VB than I ever knew existed, for example I never looked into using VB for graphics work. I’ll holler if I have any questions.

As a temporary solution, I’ve saved the 3D coordinates, converted from the .3 file, in a data file which the Cube3d program reads in at startup.

Using the information from tluxor.3, which is the tile on which Luxor airbase is built, some more questions have arisen.
This tile bacically consists of the background terrain tex_2 on top of which that built up look from scrf_ref is added. Since the Y coordinates for these textures are the same, the game must somehow know that scrf_ref is displayed on top of tex_2 (Z-buffering). This must be described in the .3 file somewhere. I’ve cheated in the following picture and given scrf_ref a slightly higher Y coordinate value.

The black areas in the picture should be transparent so that the underlying tex_2 is seen. To do that I think I need to implement and use an alpha channel in the tm2bmp process.

The answer, I think, is in redsea.asc

mikew, I didn’t find a VB graphics related book last night, but I did find Windows Game Programming for Dummies in the Clearance section at a Books-A-Million. It includes the DirectX SDK v8.1, but also covers DirectX 7. So far it’s been an interesting read, the Dummies books usually have good background information on the origin and evolution of things (i.e. includes info and pics of Wolfenstein 3D and the original DOOM and why they were so important) which is the main reason I bought it (only $15.00).

Tomorrow I’m going to try other bookstores, also some Goodwill stores. I’d LOVE to find some books on the same DirectX version that TAW was developed under (5.2?)!

I’m finding books like this one for $1.30 + $4.00 S&H …

Inside Directx (5.2) …
http://www.amazon.com/Inside-Directx-Microsoft-Programming-Bradley/dp/1572316969

I might place several orders tonight if I keep finding books for ~5.00 total.

Luxor tile in red.asc carries this description:

\sh\TARGETS\STATIC\AIRFIELD\LUXOR\
0 80 80 16 80 80 16 16 16 16

80-denominates unique tile Luxor, but there must be information somewhere else that Luxor is the base with xyz number of buildings positioned at ab,cd,ef coordinates and they all lay on the texture scruff. Probable that info could be in SSD (?)
16-denominates arable_m tile which is simply agricultural tile with no transitions of any kind.

The above is always counted vertically in grid 3×3 and first 0 is omitted. So Luxor tile should look like this:

808016
808016
161616

Or in another words Luxor base is 2×2 (80) sorrounded by arable from south and east. It does not correspond with your model above where arables are on NE an SW corners and grid division is rather like 4×4 and not 3×3.

Later I will present to you configuration of Ryadh tile which consists of 9 cluster tiles each containing 3×3 subtiles.

Here.
Counting each tile in vertical rows of 3. 3×3 all 9 tiles gives pretty clear picture of 79 sitting on the Desert tiles (3) with 21 roads entering 79 from North and South.

It could be though that the above is utilised for the Moving Map and not the World.

This is useful to know. So that means as long as the numbers match up, there should be no problem with putting the tiles next to each other?
My theory is that this is used as a consistency check during the design phase, since everything except the first line can be deleted from redsea.asc without affecting the game.

Polak

but there must be information somewhere else that Luxor is the base with xyz number of buildings positioned at ab,cd,ef coordinates and they all lay on the texture scruff. Probable that info could be in SSD (?)

Yes, I’m fairly sure that information is given by the ssd. I’m slowly trying to be able to display multiple objects of which Luxor Airbase contains about 30.
The tluxor.3 file is one of the files referenced in luxor.ssd and gives the basic tile consisting of the underlying arablm witrh some scruff on it. It looks like that this scruff can be turned on and off by one of the options, maybe Airfield Detail.

From this rendering, I don’t see any particular difference between the 80 and 16 segments:

Here is perhaps interesting analysis of the picture above. Scruff being underlayment of the Luxor Base and itself resting on the Arable background consists of many tiles. This information perhaps is also somewhere.

For now the picture is upside down. If mikew could rotate his pic perhaps reseamblance would be more visible. On purpose I did not apply all tiles.

EDIT: that F in lower left is mistake – it should be really E but like all other tiles it has to be rotated 90° counterclockwise and then flipped vertically. I dounno for now why. Perhaps because the I rotated the mikew’s picture.

I’ve got something flipped somewhere in my above image. here’s an ingame screenshot of this tile looking from the south … Hmmn, I need to think about this.

This is tough. As Polak points out, I can get my picture from a couple of posts back to match the real game picture if I rotate it clockwise 90 deg and flip it vertically.
I’m having trouble figuring out what is going wrong. My money at the moment is that I have misinterpreted the 0,0 texture coordinate as upper left, where it maybe should be lower left.

There are many things that can be swapped to get the right end result though.

Since this is straight forward with N-S Orientation I can recognise all tiles quite easy.

I assume since in your 3D rendering of hadha.3 on Luxor tiles you took the info straight from the 3 file, then all that jigsaw puzzle info about layout of the scruff must be presumable there.

Thanks, that was quick. 🙂

Where did you get those scruff squares in your Untitled-1 image above?
If it was from my tm2bmp program, have you flipped anything?

Yes, the tluxor.3 file contains the background arable and scruff. The hanger is from hdha_180.3 … just experimenting.

Scruff texture is one of the terrain texture. This one is called scrf_ref.tm or something like that. I have put the grid on the texture because I knew it had those small tillets inside with all outside, inside corners and middles.

Now I did not need to flip anything. Each TM texture is always orientated N-S.

But where exactly is the infor in 3 how those tilettes are sequenced? Are there coordinates mentioned anywhere?

Polak

But where exactly is the infor in 3 how those tilettes are sequenced? Are there coordinates mentioned anywhere?

In tluxor.3, the 0047 lines give the reference to to scrf_ref, the texture coordinates and which vertices to use.
The coordinates for the background arable texture (tex_2) are given in the 002E lines.

Coordinates would be a combination of multiplications of 48.

mikew

the 0047 lines give the reference to to scrf_ref, the texture coordinates and which vertices to use

How does this loook exactly? Are all tiles listed? What vertices exactly?

This example isn’t from tluxor but shows the general idea.

0047 0006 0004 0000 0040 003F 0040 003F 007F 0000 007F 0088 0004 0017 0018 0016 0015

There’s a 0047 line for each square with a possible 16 squares on one terrain tile. The background arable texture is defined as 32 triangles.

0006 maps to the texture name in redsea.ini (at least I hope it does, I don’t have the details in front of me).
I think the 0004 indicates that there are 4 sets of texture coordinates.
After this comes the texture coordinates for the .tm. X can be 0-255, Y can be 0-191.

X_____Y___Vertex
0000 0040 0017
003F 0040 0018
003F 007F 0016
0000 007F 0015

I’ve use X and Y, but I suppose the proper terms for textures is U and V.

The 0088 gives some information about how to display the texture, in this case 0088 means use a transparency mask. Then another 0004 giving the number of vertices, followed by the vertex index numbers.
The vertices are defined by the 006x lines.

From tluxor.3, decoding the 006x lines gives us the following 25 vertices making up this terrain tile:

0 -1024 100 1024
1 -512 100 1024
2 0 100 1024
3 512 100 1024
4 1024 100 1024
5 1024 100 512
6 -512 100 512
7 0 100 512
8 512 100 512
9 -1024 100 512
10 -1024 100 0
11 -512 100 0
12 0 100 0
13 512 100 0
14 1024 100 0
15 1024 100 -512
16 -512 100 -512
17 0 100 -512
18 512 100 -512
19 -1024 100 -512
20 -1024 100 -1024
21 -512 100 -1024
22 0 100 -1024
23 512 100 -1024
24 1024 100 -1024

Now, I’ve assumed that East is the positive X axis and North is the positive Z axis. This isn’t necessarily correct, although if it is, the vertex 0 is the North West (top left) corner of the tile.

Now, back to tluxor.3, the first set of polygon descriptors is:

002E00000003001700470000005F00000047002F0003000600000009
002E000000030000005F001700470017005F002F0003000000060001
0047003E000400300060005F0060005F008F0030008F008E00040009000600010000

From the ends of these lines, the vertices 0,1,6 & 9 are involved.

9 -1024 100 512
6 -512 100 512
0 -1024 100 1024
1 -512 100 1024

The 0047 line gives the scruff texture, but we can see from the earlier pictures that the top left corner does not contain any scruff, so vertex 0 can’t be there.

So, decoding the 0047 line:
003E=62 adding 1 gives entry 63 in redsea.ini =scrf_ref

Now, the texture coordinates,

U____V____Vertex
0030 0060 9
005F 0060 6
005F 008F 1
0030 008F 0

… or in decimal:

U__V__Vertex
48 96 9
95 96 6
95 143 1
48 143 0

Plotting these on scrf_ref.bmp gives:

This must correspond to the bottom left hand (South West) corner, since this is the only one with any scruff, although it’s hard to see that from my ingame screenshot.

Thus, I’ve been wrong all the time and South is the +ve Z axis. This explains why my rendering needed to be flipped.

Thanks Polak! I’m glad that’s sorted out. 🙂

… although I seem to remember swapping the Z-axis before in this post from 2006.

http://www.simhq.com/forum/ubbthreads.php?ubb=showflat&Number=705519#Post705519

Damn, I still need to think about this. 🙁

Your dilemma here is probable pertaining assuming left hand, or right hand coordinate axis.

I think we have established in the past that it was left, but I might be wrong. Google for explanation of what are the differencies and how to recognise which is which.

Your exploration of the code above is truly breathtaking. Unfortunately I see not much practical application for this discovery unless there is a way to increase the texture size. As you can perhaps see FOUR of scruff textures are projected on ONE terrain tiles. That, means resolution of the graphics for the target backgrounds in comparison to terrain is like 4× higher.

At the moment, it looks like both left hand and right hand systems are used for different things, but maybe in that Dhow example there is a system for mirror imaging the model that we haven’t found yet. Also, the vertex coordinates of the Luxor tile are given at a height of +100, but the list giving the coordinates of all the objects in Luxor.ssd put their origins at height -100 for some reason. So, our understanding of the coordinate system is not yet complete. I would have thought that the terrain coordinate system must be consistent though, and I’m still reasonably happy with the latest developments.

Which texture size do you want to increase? If you mean the terrain, then we can already go to 192×192 for a single texture.
If we break down the tile into 16 textures we could get a resolution of 768×768 where we now have 96×96.
We would need to replace the 002E lines with 0047 in the terrain .3 files to do this which would cause Z-buffering problems with the scruff, but we could make the scruff effect part of the background texture. Anyway, may be worth a try.

EDIT: Polak, if you get bored, you’re welcome to create a 768×768 indexed colour .bmp depicting a suitable background for Luxor airbase with the TAW palette … even better if you can split it up into 16 TAW standard 256×192 textures, although I could do that.
I could then try and apply the above theory to tluxor.3. Of course, any picture would do, but it be much more cool to see the effect with a bitmap designed to fit in with the existing objects, and there’s no better person to do that than you.

mikew

you’re welcome to create a 768×768 indexed colour .bmp depicting a suitable background for Luxor airbase with the TAW palette …

I think I can do that. And even we could create new scrf family of textures, only in higher resolution.

A couple of encouraging things. I modified arablm_1.3 to display 768×768 instead of 96×96 by repeating its single texture over and over. When using 16 different textures on a single tile, we’ll have to use a different approach but it shows that the engine can at least handle the texture resolution.

Any additional textures we create must be listed in the redsea.ini files. I notice that some of the existing files have index numbers greater than 256 which means that we’re not limited by one byte indices. I hope the game leaves it to Windows to decide how much texture memory we can have.

What is useful is that the tiles using different .3 files can have different texture resolutions, so we can modify a tile or two to see what happens.

Whether or not the increased resolution will lead to a better effect I guess depends on the artist. Thankfully, that isn’t me. 🙂

For example, here’s a screenshot of the increased resolution. The close in stuff looks fine, but in the middle distance, it looks a mess due to mip mapping I think.

Anyway, the next stage will be to try and create the 16 texture tile. If that doesn’t work, we’re stuffed.

First, that is very good and encouraging news.

Second, could you send me a file to try on my rig to see what kind of mess you are talking about. I know that in TAW certain ideas with graphics work on paper, but not in practice.

OK, the modified arablm_1.3 is on its way. Just take off from Luxor and have a look around. If you want to see the effect of different types of texture, you could swap tex_2.tm for something else.

My hat off to you for pulling it off. Seeing Hi res TAW terrain is like completely new experience.

Shimmering effect is an issue, but I think it has to do with Nvidia/D3D (antialiasing, anisotroping and all those others who knows what they are for features and settings). Still the clarity of and crispiness the texture gives entirely different feel.

Who knew that so many things could be done with this old game?

Do you think we could introduce new 3terrain files with slightly varied texturing?
That would be really swell.
But I think and I am afraid we are limited to 1024. Already 999 (terrain and targets) is in use.

EDIT: Otherwise and unfortunately indeed, more frequent textures on the same terrain tile will make the perception of repeatibility even more pronounced.

I’m not sure if there is a limit at 1024 SSDs. It did seem like that, but I was trying to do many things at once.
I need to make a tool before trying this again since it was extremely tedious to add objects to the lev folder files manually.

My example picture of showing the repeated texture on the same tile was just to show that the resolution could be achieved. In practice, we would have one 768×768 texture per tile, but it would be split into 16 separate files to work with the game. This will cause a vast increase in the number of textures and is probably impractical.
I would still like to see at least one terrain tile custom made in this fashion just to see if it’s possible, and what it looks like. If it works, we can then find out what the limits are.

How many unique textures/tiles are used for a Strike Fighters theatre? What is the texture resolution there?

Later tonight I ll try to finish the texture. I have to make some changes to TAW palette because the TAWs existing colors is very limiting. Specially for the desert. This is the reason I am bringing the subject of so far iffy converting to 18bit by Palette Maker.

Strike Fighthers were using some 100 plus unique tiles but the limit is much higher. Never really fully explored potential of the game. Res was 256 but 512 was common in mods. 1024 was affecting the performance.

I have created this new scruff larger texture with proper palette as seen on the right.

I do not know how it will present itself in the game, but for the sake of completing this experiment let us try.

As far as palette of colors again – it is Photoshop palette *.act format it needs to be saved and not swatches. I have checked colors on swatches and on *.act. Swatches are buggy and change the colors. *.act is true and all colors are divisive by 4 at each of their componens. That appended Window palette can be deleted so this is not an issue.

Nice.

What I had in mind for tluxor was a single 768×768 texture which would replace both the background arable and scruff textures. If only that higher resolution scruff is applied, won’t it just show up the differences in texture resolution even more?

Anyway, as you say, we need to try it and see what happens.

mikew

won’t it just show up the differences in texture resolution even more?

I see, probable it will. For now though it is rather to have this experiment done. Later if we find that its worthile we can perhaps do and try other approaches.

Well, the theory seems to work. The following terrain tile is made up of 16 separate textures, all called from the same .3 file (arablm_1). These 16 textures consist of 192×192 bitmaps (actually 256×192 when converted to TAW’s format) which are part of one 768×768 picture … the subject of which doesn’t really matter, especially since farm buildings don’t look that big from 10000 feet. 🙂
The names of these extra textures had to be added to the redsea.ini file.

This procedure is a bit extreme, but it shows that there is some flexibility.

Let me understand this: so what you are saying is that any texture could be substituted by the subset of textures constisitng of 16 (4×4) 192×192 textures or when converted to TAW 256×192. No limits how many such a new textures added? Building does need to be so big if you make texture in proper scale – 2000 km / 400 textures = 5 km per texure. But what we are gaining here is that before that 5 km had to be represented by 96 pixels. Now astonishing 4×192=768pixels – thats 8× resolution bump.

Polak

Let me understand this: so what you are saying is that any texture could be substituted by the subset of textures constisitng of 16 (4×4) 192×192 textures or when converted to TAW 256×192

Yes

Polak

No limits how many such a new textures added?

Ah, here’s the problem. Some new textures can be added, but at 16 new textures per tile, we’re probably going to run out of space very quickly. I tried giving the 16 new textures index numbers 1000-1015 in redsea.ini but got an invalid slot error on startup. It worked with index numbers 101-116 though. It’ll require some .exe exploration to improve this.

But, the principle has been shown to work. The question is, can we do anything without changing the exe? We can add some new textures, some new .3 files and some new ssds, I not sure how many of each. This could lead to many new combinations of tile. I don’t know how few extra textures we can get away with so that the terrain doesn’t repeat too often. Maybe we should look at that before going too much further. I guess it depends on how skillfully the edges can be made to go together.

Note that the textures can be reused by rotating and flipping them. Also, if we went 384×384 it would reduce the number of required textures by 4, but still give 4 times the resolution of what we have now.

There is something like 999 objects listed in redsea.asc. There are some other files linked to that too, but I do not remember them all now. Those are all terrain tiles and targets. Their large picture is in redsea.env which is 400×400 map where each tile (terrain and target/ssd) has its label.

Since for each record, I believe, double byte is assigned, so there should be theroretically 65K possible combinations. But 999 maybe is this limit set and marked in some of the places in exe.

Yes, there are currently 999 .ssd objects, 2000 or so .3 files, and a couple of hundred .tm textures. All these 3 types have 2 byte addresses, giving a theoretical 65536 each.
I have seen evidence that the number of ssds is capped at 1024. This could be some arbitrary limit that we could raise if we find it in the exe. There is a chance they have used 10 bit addresses for some reason, giving the maximum as 1023.
I need to go back to my EF2000/TAW hybrid work to see if this 1024 barrier exists, and if so, to try and find out how to breach it.