Krycztij

The maximal visible map is 200×200 tiles, i.e. 3200×3200 pixels, which is also 10 MB of palettized texture data (40 MB in true color), so this is no option either. (VRAM was 2 MB on average at the time of TAW's release, wasn't it?) I strongly suspect they modified their software renderer to resolve the tile indices on-the-fly into rotated and scaled pixels.

I've got some questions here: One can generate seaworld's .map file from .4ev and .4e2. Is that also true for redse_.map? In this case, I'd throw away my .map handler and just always generate the maps from scratch, so I've got common code for Red Sea as well as Seaworld. What is noname605’s actual name? I've lost track of the "noname" table, sorry Your upper snapshot in the top-left shows tiles different from sea tiles, but in my version, I can only spot sea tiles. Was that a modification of yours, an error in the image, or do I have wrong game files?

Seconding that. Are redsea.lbm / arcade.lbm legacy from the EF2000 system (with only one 400×400 bitmap for the whole scenario)? Why these colors? I just implemented the moving map in TFXplorer, and it's taking an incredible amount of resources. Maximal sensor range is 200 NM, the top-left of the display is 280 NM from the F-22. Tile sidelength is 2.7 NM. That's a display size of up to 200×200 tiles, i.e. ~80,000 triangles and ~10 MB of vertex data! I have no idea how they got that thing render efficiently in 2 MB of VRAM. It probably was a highly optimized software renderer. Maybe that's the reason they couldn't fix the moving map in D3D. I could make it blazing fast with a specialized shader, but that would be a portability nightmare and a hassle for all API users.

My take on the ILBMs: arcade.lbm & clds2000.lbm redse_.lbm & redsea.lbm Does that match your results? Especially regarding the strange colors?

… just doing a little uphill race with my F-22 and my Shilka. Ordinary routine, you know …

It's a tool to inspect the scenario without starting the game. Starting it and looking up coordinates of an airfield for a mission is far easier than launching TAW and flying to the place. And it allows modders to test their modifications without having to start the actual game. But yes, the in-game mode will be extended and better physics are work in progress. TAW doesn't use arbitrary image files for textures. There's a fixed set of a handful data layouts, mainly paletted, and probably native to the ancient 3dfx Glide API. Nothing else can be used. There also is a hard-coded limit on the total number of textures for all terrain, planes, vehicles, sky and clouds in the game. The meshes are not just triangle lists with UV on it, but much more complicated. Last but not least, texture coordinates are not normalized UV but pixels indices. All of that makes each and every texture change very painful But again, DrKevDog is the one to know best. You'll have to ask him yourself Mikew's main objective is data analysis of TAW formats; DrKevDog is excellent at actual modding; Home Fries coordinates the TAW 2.0 project; and so on. Help is always appreciated, but we all have lives and jobs and while sometimes we're working 24-7 to move things forward, sometimes for months we don't do anything at all. (I'm having such a low since a few weeks; too many other things to do.)

Like that: http://community.combatsim.com/topic/25920-taw-terrain-format/?p=5172164 ? Textures don't improve by themselves, you need artists and programmers. High-resolution textures are subject to research for at least a decade now, and DrKevDog is our authority on that. More detailed terrain is possible (with some limitations), and higher resolution textures are also possible- But we just don't have the time or manpower to rework over TAW's entire content (or even a handful of tiles). ("we" not including me here, since I'm not directly improving TAW, but investing all my time into TFXplorer.)

I made it. Landed just after 20:11. With stronger enemies, I need to evade more often. Pulling left and right hard is typically enough. I had to turn 180° three times. One time I was hit by a missile. The A.I. is really good at crashing into the ground Once you land, the mission stops. You can't select to play on (like in most missions). Looks like you can land at any airbase in egypt, maybe at others, too. Could be interesting to find out. IL-78 gives most points, followed by hanger.

Fellow players! I know this is mostly about TAW, but from time to time I like to play good ole ADF as the Quick Combat mode is a great opportunity for some instant action. I never reached the end (yet), and since I don't have the time to seriously play over and over, I'm training for a speed run (not fight the enemies, but just fly through the level as fast as you can). This is a bad idea for flight simulations. If you don't fight an enemy, he'll get on your six and shoot you down. But I found some tricks: Shoot all your weapons when the combat starts (don't use the jettison menu!). Shoot all AA weapons and AG weapons until the count is zero. If you do, you can reach 2.1 machs. If you don't, speed is limited to 1.4 machs. (I think the game considers air resistance and weight only for the weapons which are mounted at the time the mission starts, and auto-refill weapons are not counted.) You don't need to kill anything to get extra time, just reach the next waypoint. Don't waste your time on enemies. Best cruising speed is achieved at 34,000–36,000 ft (2.1 machs constantly). Higher is better, though, because missiles fired from normal enemy height generally won't have sufficient kinetic energy to hit you up there. 40,000 ft is the best compromise of speed (2.06 m) and safety. The only other plane in the game sustaining that speed at that altitude is the MiG 31. So, if you see any Foxhound ahead, shoot everything you have at it. If you miss, its missiles are generally no problem because of high speed and chaff/flares, but you've got only 30 minutes left until it's close enough to hit you with the cannon, no matter how fast / high you are. Planes have unlimited fuel. The enemies will stall when trying to get up to your height when you pass above them, and quickly fall behind. But they will follow you forever. After a dozen checkpoints, there will be fifty planes following you. They won't catch up with you if you keep altitude and speed, but at some point a MiG-31 will close in and you need to turn and then it's open season on you. The safest maneuver is: If Foxhounds close in, turn. Fire a load of missiles at the herd of enemies in the distance. You've got one minute until they're all around you. Go down to less than 100 ft altitude as quickly as possible and keep mach 1. The A.I. will typically screw up the decent and most planes will crash into terrain. Most effective with mountains, far away from checkpoints (no SAM), and with no new enemies in sight. Fight the rest with sidewinders. Accelerate and climb when it's safe to do so. I'll keep you informed on my discoveries.

Yes please, that would be incredibly helpful!

Yes, the only problem is the ILBM format. Just gathering the facts here — so I don't have to search again when I come around to implement it

Well neither do I want to distribute 3rd party software with TFXplorer, nor do I want to distribute my own copy of the textures (not compatible to mods and huuuuge overhead for a 270 KB program). So there's only the parser left Yes, DKD posted the texture in the TAW Terrain Format thread. I wonder if they assembled it on the CPU — GPUs at TAW's days probably couldn't handle textures that large …

Thanks — converting to BMP with a 3rd party tool would save most of the effort. But it would also mean the map runs only on my system I'll write a ILBM parser sometime, maybe it comes in handy with some other projects, too

I noticed I always get lost while flying in TFXplorer, so adding the moving map on the center MFD seemed like a good idea to lower confusion bring development forward. Research on the moving map is pretty much scattered, with DKD having done the main work. So before I can even start implementing anything, I'll have to list all resources on the topic. What I found so far: The very first thing anyone ever answered me on this forum TAW Terrain Format, page 1: "The redse_.map file is the index for the moving map" TAW Terrain Format, page 33: How DKD created his own .map for Seaworld TAW Terrain Format, page 38: DKD lists individual tiles in the redse_.lbm file TAW Terrain Format, page 39: More experiments TAW Terrain Format, page 43: redsea.lbm opened in IrfanView Until that point I thought of .lbm as a proprietary DID format, but turns out on Wikipedia it was one of the standard image formats on Atari, and it's 30 years old now (don't know whether I should feel too young or too old) TAW's files seem to be in the BMHD domain of the format. That was the good news. The bad news is it consists of interleaved bit planes … … with run-length encoding. So writing a decoder is not trivial any more and I surely won't do it tonight. Together with tiling and MFD infrastructure, it'll be a week of coding and I'll do it some time later. This thread serves as a collection of resources on the topic, anyone feel free to add. P.S.: Many pictures in the TAW Terrain Format thread are missing due to image hosters being run by idiots. (Was there really a need do delete 10 MB of images? A Wal Mart HDD can store millions of those, would it have been too much efford for you to buy one?) I keep archived copies of the pages, just write me if anyone needs them.

Late answer, but we came around looking at the code. 100 % is implemented in TAW as 100 % fuel rate and 100 % thrust for the turbofan. If you go higher, a second formula for the afterburner is added with much more fuel consumption (10×) and more thrust. The result is multiplied with the current air density. There are no advanced computations like optimal thrust/drag ratio, bleed air, etc in TAW. The formula is also linear (50 % throttle is 0 % thrust — 75 % throttle is 50 % thrust — 100 % throttle is 100 % thrust) which is not accurate either (I think thrust is exponential to RPM) and the spin-up / spin-down time is also just a very simple interpolation formula without scientific background.

Was programming far behind enemy lines; this recon shot made it back: There will be Seaworld in the next TFXplorer release

so … awesome … Is there any known way to slow down the animation?

Awesome!

Oh right, I forgot the delta opcodes … disregard my comment then.

That's a leap forward! Could you produce a version where each Y coordinate is a unique number (e.g. ABC0, ABC1, …)? Then we could import heightmaps and generate tiles automatically by just searching for these numbers and replacing them with the according heightmap values! I know. After almost four years, they're still on my to-do and I just don't want to touch them …

Seconding this. I always wanted to get head tracking into TFXplorer. I had a TrackIR (and it was nice with TAW, although not as great as e.g. ARMA II because only 2 DOF) but sent it back when I noticed the API was sealed. I had wasted too much time with TrackIR, so I didn't get to even test FacetrackNoIR

Yes, that's what I mean. There will be lots of bytecode for the tree when terrain is wrinkled. If you need something to read, flipcode had a good section on BSP types.

The problem is not how to generate more triangles, it's writing the bytecode so the triangles are drawn in the correct order even with mountains in the middle But the high-res mesh is great progress anyway, and it's a very clever way to turn up texture resolution!

Some bad quantization errors in their heightmap at 8:55: Or if it's no real geodata, it's a feedback loop in the erosion algorithm. Great graphics nontheless.

Yes, different engine. Much XML. There was a thread on SimHQ but it's gone; I'll have to search my archives some time … The differences are no surprise, as the no-depth-buffer-painters-algorithm-dynamic-branched-binary-tree stuff from TFX, EF2000, TAW etc. is nowhere near efficient for 2000's graphics hardware and required loads of dedicated infrastructure to maintain.