mikew

Thank you! Hmmn, now I have a problem in that my did.dat from the 3dFX install is of a different format to that from SEF2000, ADF, TAW etc.

Yes, I'd like to see your CLUMP_SS.TXT list as well. This doesn't help with your original problem, which I still think is caused by some mismatch between your did.dat files, but this exercise has been very interesting for me.

OK thanks. That's strange, putting the list in 'code' tags should produce a window with scroll bars...hmmn Yes, those files should be in the Dosbox folder......but your EF2000 files really shouldn't. At the end of my dosbox config file, I have the following: .. # Lines in this section will be run at startup. # You can put your MOUNT lines here. mount g c:\pc2009\ef3dfx g: Here, I mount the 'G' drive to point to my EF2000 files which on my PC are in 'C:\pc2009\ef3dfx' I believe there can be confusion with dosbox if you use 'C:' as the mounted drive. EDIT: ...and I'm staggered with that list. With 'paul', that's 3209 entries.

In the toolbar immediately above where you type in a reply, there'a <> symbol and it should say 'Insert code snippet' if you hover the mouse over it. If you click on this, a 'code' '/code' pair should appear. Just put the list in the middle of them. Anyway, this is intriguing. Apart from the malformed clump file in my SEF2000 install, I don't see it my DOS installs. EF2000 is a bit different to TAW in that it will read in all the model files whether they are used or not.

Thanks for the list! I wouldn't mind seeing the top half as well since it's different to mine. Maybe best put inside 'code' tags so it's easier to read the thread. You could try deleting 'paulpaul' and any subsequent failure...but it's a long way to 'z'.

OK, well my theory is that somehow that the wrong 'did.dat' file is being accessed. You may have a few since you have the original game, then tactcom, then the 3dFX patch... You could also make a copy of CLUMP_3.TXT for backup, then delete the 'paul' line to see what happens. This would show whether the clump file is being used or not.

Ah, OK. That's again interesting. I have a malformed file called 'gCLUMP_3.txt' in my install of SEF2000, but not my 3dFX version. This contains the .3 filenames up to 'pmoskit' in alphabetical order, then becomes corrupt. Anyway, does your 'CLUMP_3.TXT' file contain an entry called 'paul'?

In a way, this is good! It shows up some interesting behaviour (at least from my point of view. ) If I try to run the game from the Config menu, I also get the CDROM error. Just typing 'ef2000' at the command prompt causes the game to start normally. Note that my 3dFX version is from the V2.0 disk which is just one install.... The file 'paul.3' is a 3D model file that should get extracted from the did.dat archive. I haven't seen this file mentioned before. Do you have a file called 'gCLUMP3_3.txt' anywhere in your EF2000 directories?

意味をなさないこと。

Yes.

Changing the memsize parameter in the DosBox config file should fix that: memsize=48

If you're happy enough with SEF2000, then you're probably better off sticking to that until you update. Running the 3dFX version in DosBox seems stable, but I haven't actually played the game very much.

Yes, check out this thread, particularly page 10 and onwards: http://vogons.zetafleet.com/viewtopic.php?t=25606 If you're having problems with FPS with the non-3dFX version of EF2000 in DosBox, there's probably not much point in trying it since the 3dFX emulation is done in software. There is an experimental build using OpenGL which speeds things up dramatically, but this still has some problems to overcome.

Interesting... I like the 'distant object culling' theory, although I don't think that replacing 0054 with 0000 is the right thing to do since 0000 is itself a terminator. It might be better to remove the 0054 and then adjust the offset values in the header if needed. Also, it might be interesting to replace a runway section with 0054 with one without it, and then fly a long distance away and look for some visible effect. This I don't understand.... This implies that something in the .3 file affects the behaviour of the game. Could it be that the 0054 is a tag that helps the AI in some way? Your picture is interesting in another way. That distant horizon looks a bit like a problem I get with the OpenGL version of EF2000.....

Nice!

Totally agree. One day, we will get around to working on EF2000....

Ah, the 'T-Zone'. At least it's more plausible than the 'G-Spot'. So, in which year did JFK shag Marlene?

Why not try Glide mode now? With dgVoodoo you can select a resolution of 1024x768. It may run too slowly, but there's only one way to find out....

Not much I can say about that except that 0x8f8f8f8f is an unlikely value for the program counter. If it CTDs a lot, it might be worth running in software rendered mode for a while to see if it's more stable.

TAW does occasionally CTD I'm afraid. All we can ask you to do is post the contents of your f22.$$$ file which you'll find on your top level drive (normally C: ). This file can be opened with Notepad.

Regarding small monitors for MFDs, aren't you better off taking the USB route? eg: http://www.thinkgeek.com/computing/usb-gadgets/c609/

Yes, TAW/ADF and EF2000 are still great for those of us that are too lazy to learn all the Falcon 4 button pushing. A pity DID (and GTT) are not still around. Things seemed to get done a lot faster in those days. Anyway, TAWBC is something to be proud of. Birkemose (Lars?), do you still do any flight sim stuff?

That's interesting. I'll have a look when I get home. Unfortunately, a bit of disassembler browsing is all I'll have time for today.

Nice day, we've had the highest temperatures ever recorded in october for this part of the world, 86F. I love cheese, so I guess Green Bay is my team as well.

In TAW, redsea.env contains a 2 byte index for each of the 160000 tiles. In EF2000, these two bytes are split into two files called something like norway.4ev and norway.4ev2. It's almost as though the original engine had a capacity for 256 different terrain tiles, but for EF2000 this wasn't enough so they had to tack something on.