   Antialiasing hacking
  Halo is a game that implements multiple render targets.  But no antialiasing is supported for multiple render targets for some reason.  I wrote a program to find all IDirect3DDevice9 function calls, and I now know where each SetRenderTarget, GetRenderTarget, and CreateOffscreenPlainSurface is called.  I was wondering if I could divert it to draw it all on one buffer and allow for antialiasing.  Does this seem practical?   
  No, to be honest it doesn't seem practical [smile]Unless you're using a technique like this one then I guess you've just done some sort of reverse-engineering? A simple symbol-substitution is as likely to break things as improve them. If they're using MRT's it's probably for a particular reason - reflection/post-processing etc...Also, I forget the details, but AA'd MRT's isn't universally supported - you'll need some pretty recent hardware to handle it.hthJack   ;  I forgot to mention, I'm doing a lot of low level reverse-engineering.  I did the directx overlay stuff, but this is something else.  I'm not doing simple symbol substitution, I'm altering the assembly of the game.Before the game was ever released (roughly 2 years ago), they teased us with AA'd screenshots.  Then they release it without any form of AA support.  That's why I'm giving this a try.  There is a lot of post-processing going on with Camoflauge and Scope-blurring, but I was hoping there was a way to render AA'd frames to the same buffer.   ;  Can you render to the default target with anti-aliasing, copy to a different render target, render your main scene and then render with your copied render target? You have an extra two texture surface copies, but I wouldn't imagine that's too much of a hit...   ;Quote:Original post by bitterbananaBefore the game was ever released (roughly 2 years ago), they teased us with AA'd screenshots.  Then they release it without any form of AA support.From what I remember they showed Halo for the PC with a number of graphical goodies that mysteriously disappeared as soon as Microsoft bought them for an XBox launch title. Forget the details, but there was something about shadowing as well. I also remember reading an interview stating that as soon as they had guaranteed funding and a publishing deal that they could relax a little and fine-tune everything for XBox.Quote:I'm not doing simple symbol substitution, I'm altering the assembly of the game.Okay, but I meant more that replacing fragments of something (e.g. a particular symbol you've searched for) might not be the way to go about it.Also, a word of warning - reverse engineering software can be against the terms and conditions. More specifically, in some regions it can be illegal. People on these forums are peaceful, law-abiding folks - they don't take kindly to such things. I'd double check you're on safe ground before continuing.However, back on topic, I think your best bet is to consider the algorithms - why are they using render-to-texture?If the result is rendered to a texture and hence not AA'd (hardware doesn't support it), doing anything else with that texture will be pointless as it is by definition not-AA'd. So, instead, you redirect it to the screen and attempt to AA it. You'll then have to grab the front-buffer in order to get an AA'd copy of the final image - which will require the presentation to have happened (AA'd backbuffer isn't accessible).In short, unless you can somehow eliminate the RTT stuff I don't think you can do it for full AA'd glory [smile]hthJack   ;  Again, it's not symbols, they're actual function calls.For example, this in c++:g_pDevice->SetRenderState(D3DRS_MULTISAMPLEANTIALIAS, true);would look like this in assembly:mov eax,[device pointer pointer]mov edx,[eax]  ; derefence pointerpush 0x1  ; truepush 0xA1 ; D3DRS_MULTISAMPLEANTIALIAScall dword ptr[edx+0xE4]  ; call SetRenderState (its interface offset is 0xE4)I wrote some code to look for every d3d function call (all 1,575 of them) and 7 came up as SetRenderTarget. So I can change where each frame is drawn.  I imagine that will be the best way to do it, assuming there is a way.But I think you're right.  Eliminating some of the post-processed stuff might be a worthy sacrifice.  I think that'll be my best bet.  It'll be an interesting project to see if it works.  I hope you better understand what I'm doing now. Do see any more promise in it?  I appreciate your ideas.   ;  Well, I'm not entirely sure if you're doing this as a learning experiance or whatnot, but there's infinitely easier means of enabling anti-aliasing. Most video cards now a days comes with drivers that allow you to force AA support, and totally ignore what the program is telling in in those reguards.   ;  I've already tried that and the game ignores it.   ;  If you read into how AA techniques actually work (Beyond3D is a good source), you'll find that there are a number of implementation details that don't lend themselves to render-to-texture effects. It's a fairly involved process and therefore tends to get implemented in the primary swap chain.You're fighting a hardware (not software) limitation.I'm pretty sure some of the later hardware supports the technique - but again, it's down to the actual hardware.If you want to somehow emulate/force this via software you're going to have to do a lot more than just replace various fragments of code - you'll almost certainly have to step back from that and work out how the actual program (not just it's API calling patterns) work.Jack   ;  Thanks for the resource, I'll definitely start doing some reading.  I'm sad to hear that it's a hardware limitation, not much I can do about that.  I'll try to determine how engine is drawing the frames and I'll go from there.  Thanks for your help Jack.   