Sounds great! It would be nice if we could add more frames to make smoother animations for exampe.


But Jeff, if you could somehow find a way to reduce the speed of the wave cycling and bobbing in the tower view, and remove the wave bobbing entirely from periscope view, you would be my HERO. The boat should roll slower and smoother with the swells. The waves cycle far to fast compared to their big height, and it does not look good since the wave animation/rolling of the texture only extends a very short range out from the boat.

As We figure out the file formats that MAY be possible! Only testing will show.
Say We have 5 different frames that control that. What if we add 5 more?
Now you've cut the roll down by half.
I'm seeing that the files themselves control actions. Not uncommon for early Games from the 90's.
I've also seen extended files that have no relation to the EXE's so that's a GOOD sign!

One needs to look at the files from the original release, then look at the files from any patch or updates!
You'll see them!

Understand what you mean. That would work for textures yes. But the textures for the sea and their cycling is only part of it. It is 7 frames of them and 16 frames for the foam patches in SEA.BMP. My testing shows that of the 7 first frames, number 1 is a complete ocean view from the boat to the horizon. Number 2-7 are copies of different parts of number 1 (top to bottom), that build their way inward to the boat. 7 is closest to the boat. Of these, the inner 3/4(?) textures are also part of the rolling mesh.

It is the cycling / speed of this wave mesh animation I hope that we can take some control of. :hmmm:

As We learn more of the files? That may be possible to change.
As you say, it's almost an animation based on frames.
One thing I'm VERY good at? Animations! No matter the format!
SH3, SH4, SH5? I am the Guy you talk to.
AOD, a Game from the 90's? I started hacking Games back then!
Probably forgot more then most people will ever learn!

Jens, regarding the waves. You probably already know but the cycles can be reduced in dosbox.
Also, I seem to recall that the few seconds of fast cycles that occurs sometimes when you say, go on the bridge, is tc meant to simulate the time traveling to there.

@John, I know but that is a very primitive solution, which also reduces the game speed overall, making other actions take forever. My DOSbox is configured at fixed 9000, as type 486. This setting I find optimal for AOTD, and many other games of the era. In Topbench this setting equals about an Intel DX2/50. I see no point in running AOTD on anything slower than that. Below 8000/7000 cycles the wave animation becomes very choppy, even though the waves roll with a more natural speed.

There must be a way to gain control of the mesh cycle intervals without reducing CPU speed. So we can have an alternative to this "I am attacking with my rubber duck boat" feeling.


https://j.gifs.com/LZ9YlX.gif

Well, that is the huge storm/waves/no fog graphics of AOD but mine isn't that bouncy anyway. :hmmm: Strange.
I remember at the time, the wave action was a huge WOW factor for people in the game. :)

Might have been the first game with them, close if not.

Reading through the source code is providing good information
that may help to decompress other files.
Also found some old Code from around 1990 that may help.
It's Turbo C which is Borland. I'll have to see if my versions of Borland will compile it.
:hmmm:

Update to the BMP/VGA file structure.
-----------------------------------------

4 bytes = BMP:
4 bytes read as an int = file size to read.
4 bytes = INF:
4 bytes = the amount of data to read. This contains frames and sizes of each frame in pixels.
This section is variable but you read each as a byte with a 00 seperator.
4 bytes = BIN:
4 bytes read as an int = data to read until we hit the next chunk.
1 byte = Compression type used (01 = RLE -- 02 = LZW)
4 bytes read as an int = data in this chunk after it's decompressed.

4 bytes = VGA:
4 bytes read as an int = data to read until we hit the next chunk.
1 byte = Compression type used (01 = RLE -- 02 = LZW)
4 bytes read as an int = data in this chunk after it's decompressed.


It's IMPORTANT to have your Editor of choice set to Little Endian!

Now I may have a clue as to how to encode the SCN/OFF format.
I'm working on Tower1.bmp
What I am going to do is CUT out a section from the SCN chunk.
OFF is Off Sets to data I'm pretty sure.
So if I cut from the last off set position and remove the last off set information,
then change file size references? It should open and be missing 1 frame.
As far as I can tell at this point? The SCN: information does not contain the size of the file decompressed.
:hmmm:

Also noticed Engie misreports number of frames by 1.
Frame 0 to Frame 22 = 23 frames. NOT 22.
That's bad coding. Makes me wonder what else is sloppy coding.
Going to see if I can Compile the Source Code and if I can? Will track down the error and correct it.
The License says "DO WTF you want".
:)

Again I'l say this...........
ADD frames to the last 16 frames. Say double each frame so you end up with 32 frames.
Unless you try it? You will never know what happens! Just thinking that won't work and even thinking it will proves NOTHING!
A Theory is only ever a Theory until you prove it one way or the other!

OK. Pretty sure I have the SCN/OFF format figured out!
Not only that but I'm pretty sure HOW we can adjust it at our whim!
You better get comfortable with Hex Editing but it is fairly simple.

So. As you asked Andreas86
You CAN change the Tower stuff! I'm still documenting the steps needed but it can be done!
Engie will do everything except build the final file to be in Game. That is where working in HEX comes in.
Me? I'll write a script for 010 to build the file.Unless people buy 010? It's all by hand!

@Jeff, I am following your progress with excitement! It is fantastic that you are closing in on the SCN format, and that it can be changed. And thank you for posting your progress as you go, it is very interesting to read. Good work! :salute: Look forward to documentation, and hopefully making some tower graphics.

About the wave stuff, I believe you regarding the doubling of textures. But we might be talking about different things. Just to be clear, I did not mean changing the cycling speed of the textures, but rather the speed of the sine wave mesh animation:


https://tinyimg.io/i/pILktRY.gif

By the way, here is a quote from the interview with Mike Jones of Dynamix, from the interview found here on subsim.com:


"Jones: The waves were conceived fairly early, before a development team was assembled. I needed to put together a demo/proof of concept and had the opportunity to work with Tim Gift [Tim is the director of Tribes, a soon-to-be released Dynamix product] on that. He put together a quick demo of the rolling waves by introducing sine wave motion to a grid and texturing it. It looked good, but needed to be speeded up. After the project got underway, another programmer, Peter Lukaszuk, took the concept and developed the waves as you see them in the game. And they hardly take any processor time. The funny thing is that I never asked Peter how he did the waves; I mean the exact method. People would come up to me at shows and asked how we did the waves, and I could honestly reply, "I don’t know"."

Looking for that wave motion but haven't found a solid lead at this time.

I am a bit confused about a file and trying to track it's history now.
Shapes.vol
File size in a DOS version is 279,558 bytes
File size in a CAOD version is 727,656 bytes
I suspect the first may be a compressed version or lower details on Models?

I checked the 2 patches available here at SubSim and none contain that change. Yes I opened the Resources.xxx files.

AOD Dos is running on my system but the CAOD is not at this time.

In the Subsim.exe, those shapes are listed with a .bmd extension.
BMD usually means Binary Model Data and there are bmd files in the Game folders.