DrKevDog

Members
  • Content count

    1,207
  • Joined

  • Last visited

Community Reputation

0 Neutral

About DrKevDog

  • Rank
    Colonel
  1. Speaking of .3 headers, IIRC, not until tfx3 did they introduce the upgrade-transition from the class 00 shape files to 83. The 83 files are much easier to work with so I am trying to find an easy conversion process. It seems that the main factors are the presence and number of LOD's, and the presence or absence of a header texture and its length, don't recall if render order is a factor also, but didn't you work this all out at some time in the past?
  2. SPECULATION ALERT! I am speculating that 0028 is a different type of instruction/opcode than we have been studying before, which is perhaps why it is not found in any of the game files. It seems to be a practical opcode for use during the development phase. 0028 can render a wide range of routines and subroutines. It would be useful to the graphics artists who were working on the 3d models. Let’s say, for example, an artist is working on the visuals for the damage states of the Luxor tile, and lets say they are working on the lux_radr.3 model and would like to visualize the various LOD and damage state models in-game. They could use 0028 to simultaneously render the various damage state models, in-game, for inspection and potential modifications. Simply place the 0028, or an array of such, in the lux_radr.3 file and configure it so that the second operand word calls the specific damage model subroutine and the first operand word defines the distances at which the called model will be rendered. The specific model can be further manipulated, for analysis, by placing modification codes, such as 0030 (scale) ahead of the 0028 instruction. 0028002F15EC In this example I have set the distance so that only the undamaged model is visible beyond distance 002F. From distance 0 to 2F I also call the subroutine for damage state 1: 003000020028002F15EC This example is identical to the above, except I scaled the damage model up to unmask it completely.
  3. 1. The C4 objective is only the primary objective for the first 10 hours of the campaign and required damage is only 20%. Attacking EWR stations does blind the enemy and yet, the first priority would be to focus on the primary targets. After the 10 hours expires the target class changes to airforce which means all the "outside" attacks, during the C4 targeting period, should be centered around clearing lanes for Strikes to access enemy airforce targets. 11. TAW does not have a dynamic resource management code of any significance, therefore, if the game gives you F-22s: take-em.
  4. The 0028 opcode is more interesting than at first. It has me rooting around in the executable and wishing there was more known about the structure and format of the executable. format: 0028 <unknown><unknown> Unknown #1 appears to set the distance at which action is initiated Unknown #2 is the offset to the routine in bytes (-2B) The unusual thing about the unknown #2 in the 0028 instruction is that it seems to disregard .3 file headers and footers and treats the executable like a container. It can execute the shadows routine of one .3 file when called from another, simply by adding a proper 0028 line to the recipient file. An array of 0028's can do some interesting things. Below is an image of Hangl_90.3 with its file-coded shadow in the back but also with the shadow contained in the Hangs90.3 file-code in the front. It's like I have now acquired the ability to bend light, bi-directionally
  5. 100 Bitcoins deserves the man who persevered to analyze the timeline all the way back to F29-Retaliator. My hats off to you I'm still working on opcodes 0028 and 0029, hopefully some progress by next post.
  6. I am following your archeological ventures with good interest. One of my concerns with the undocumented opcodes is that, despite reasonable efforts to define their function, without a formal game example / model, the definitions remain unprovable and mere speculation. That similar functions are grouped together is helpful. I'm currently working on undocumented opcodes 0028 and 0029. Like 0026 and 0027, we can assume some similar function. 0027 <threshold> <offset> If the object’s distance from the viewer is above or equals <threshold>, jump <offset> - 2 bytes. Used to fade details, e.g. shadows, with distance. This is what I have discovered for 0028: format: 0028 <unknown><unknown> Many of the values I plugged in caused a program fault but a few caused a division overflow. That led to an assumption that, because a division overflow is not very common, I could work with divisional increments, so I began playing around with some integers and found a pair that resulted in the following: Believe it or not, that shadow is cast from the windsock (awind.3) by simply adding 002800C51770 to the front of the bytecode. It seems 0028 handles horizontal shadow casting while 0029 handles vertical shadows. I still get some instability and the file modified will cast shadows off of any nearby object at times and other times is stable. The values I used for the unknowns were an educated guess and I am still trying to know what those unknowns really are.
  7. Very Interesting.
  8. LOL! I have thought of that at least a hundred times. The idea of it simply being useless code is, IMHO, not only unpleasant but, more disturbing, currently unprovable
  9. The header format looks identical. Eluding to the comment you made about the increasing complexity of the opcodes as TFX evolved, I wonder if the Robocop executable would make for easier work finding where the .3 handling could be located and give some clues on how to find it in the later programs?
  10. And the last thing you want for your costly project is to piss the artists off, lest you risk ending up with art and models and graphics that look like this: Not that there's anything wrong with that...um...well maybe The difficulty I am having with accepting the 2 point version of the triangle jump explanation for this instruction is that the triangle jump uses a 3D-Hyperplane for 3D-models but a 2D-hyperplane can only be used on 2D-models. In TFX/2/3/ the 3D-hyperplanes are used exclusively for obtaining a back-to-front draw order but that is simply not necessary for flat 2D models and that makes the presence of such an instruction, for that purpose: illogical to me. I can think of all sorts of fun ways that I could possibly use that opcode, however, I hope to find the definitive purpose for which they included that instruction
  11. The facts, after additional testing, indicate that the jump executes if the camera position is closer to vertex <position0> than vertex <position1>. Is this related to implementing perspective correct interpolation? It's interesting that using the diagonal on a quad enables the jump with triggers both in the horizontal as well as vertical plane.
  12. Good point ! While it might be possible that an line algorithm could be involved, that is not yet within my grasp of the concepts. It would make sense then to assume your distance theory and I will work to get some better control over the facts
  13. I agree, and I suspect they are undocumented in all of the three TFX file bundles. I am using my new technique on them. - starting with 0011: Visibility test // 0011 <position0> <position1> <offset> If the line of the (transformed) vertices at the given positions faces away from the viewer, jump <offset> - 2 bytes relative to the end of the instruction. TFX3 has no Z-buffer, therefore this instruction could be used to assist with maintaining the back-to-front draw order in the same, or similar way as the 0015 instruction. As I recall TFX uses the 0015 instruction, exclusively, for the hyperplanes created for this purpose. Perhaps there are specific instances in which a tri-poly-hyperplane is not the optimal solution (?).
  14. Do you have any record of the existence in any of the object files, or not, of the following opcodes: 0010, 0011, 0012, 0013 or 0014 ?
  15. Thanks, that is useful I can look in TFX and TFX2 for the 0006 answer. Not sure where that is in the dissembled code.