DrKevDog

Members
  • Content count

    1,203
  • Joined

  • Last visited

Community Reputation

0 Neutral

About DrKevDog

  • Rank
    Colonel
  1. 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.
  2. 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.
  3. Very Interesting.
  4. 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
  5. 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?
  6. 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
  7. 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.
  8. 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
  9. 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 (?).
  10. 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 ?
  11. Thanks, that is useful I can look in TFX and TFX2 for the 0006 answer. Not sure where that is in the dissembled code.
  12. I have never seen a list of opcodes in the .exe. It would be helpful to have if such a list does exist. I am working on opcode # 0006 which I have never seen in any file in TFX2 or 3. Currently it has me stumped. In memory the format suggests the following: 0006 <color> <pos0><pos1><pos2> <double word> Any idea what that double word might be?
  13. The work that was done on TFX3 .3 object models identified most working operation (opcodes) instructions completely as well as many with functions that remain unknown. Not much work has gone into identification and/or analysis of undocumented opcodes. Mikew and Krycztij were able to uncover useful information related to game memory formatting, including Optimizations, memory format, format handling, etc.. That information I have incorporated into a method to analyze undocumented operation / instructions and map out their operand strings. Considering that TFX3 was built upon TFX2 which was built upon TFX, it seemed reasonable to me that there should be some undocumented TFX3 instructions for even further future expansion. One of my personal interests in periodically rooting around in this classic legacy game is the area of color and transparency graphics. TFX3 makes it fun to play with. In TFX3 there was the initial introduction of non-indexed 24 bit color and 32 bit color. The implementation, however, was very limited. I seem to be learning new things about color and transparency from some of my recent discoveries. These are some of the new instructions that I am currently working on: 00A0 00A1 00A4<offset> 00A6<offset> 00A5<offset> 00A9 terminator? 00AD <unknown> <unknown><unknown><unknown><unknown><unknown> 00A0 and 00A1 seem to be involved in shadow casting transparency / Vertex Alpha? 00A4, 00A5, 00A6 and 00A9 seem to effect alpha transparency and blending. Example: 00A4 the addition of 00A4 has an effect on Alpha Blend Mode and/or State, either single or stacked, increases the Alpha Transparency value (increased opacity) approximately 20% per occurrence. This is effective on 32-bpp RGBA textures (with BGRA output images) and RGB using alpha images (00A7). Without 00A4: With 00A4 (4X stacked): Note the Blue / Red and Yellow / Cyan (a) swap due to the BGRA output of the 32 bit images. I suspect this is an TFX3 efficiency optimization which takes advantage of the way images are written in Little Endian memory format.
  14. I created some new files just to slow the TAW rate in order to study the behavior. I used the 01 Diagnostic suite to document the rates. The 01 suite, curiously, combines the virtual cockpit MFD diagnostics with a print out for Rate and FPS. I wonder if the rates assignments suggest rate determined compensations for slow rendering? RATE FPS 1 50 TAW Frame Rate Cap 2 25 3 16 4 12 5 10 6 8 7 7 8 6 9 5 or 6
  15. One of the tools in TAW that may be of assistance in determining what is being rendered when the slowdowns occur is the Polygon tool. When in-game simply press Alt + 0 (zero) and you should see the following: Use a screen capture process to capture the results, both in areas where there are slowdowns (eg:"It happens whenever I get as close as 100 miles from an enemy aircraft group ") and when not slow.