OK, just finished another major, major spam cleanup on this thread.


Note that this is the ** Decal Update ** thread, not the "let's debate the morals and attitudes of the decal devs" or the "let Decal die" thread.

I think a lot of people misinterpret what is said on the boards without knowing the people who are saying it.


I'm sure a lot of the stuff I say can be taken the wrong way, and come off the wrong way if you don't know who I am, or know anything about me.


_________________________________________________________________________________________________


You got that right..


Thanks for the update and Thanks to all of you working with Decal and making it right. I know it will be active soon enough.


Thanks again


Del

*leaves Gouru a White Russian on table*


*This is sort of an insider joke from what Gouru told us last year at his party at acpl just to kind of give him a chuckel while reading this thread

 

-----signature-----

I am planning development on a plug in that puts a HUD with the information that you find under the green chain (ping time and packet loss) since I believe that is wasted space. Is there any way to add something to hook to those 2 parts, like a filter or something similar?

Just a question out of curiosity, but are you developers having to use the dx9c sdk? It is my understanding that biggest hurdle to overcome is simply getting Decal to draw. I know there's a slim chance or I could be wrong altogether, but since we have a new engine and it partakes of dx9.0c, I thought I'd pass this information along on the slight chance that it may have been an oversight[though I greatly doubt so].


Anyways, best of luck to you guys and if you need any testers, I am at your disposal.

 

-----signature-----

Since all i know is perl, i'm probably no help


but don't hesitate to hollar if ya'll need something,... I have lots of free time over the next week

 

-----signature-----

Drawing onto the screen is easy. Incredibly easy.


The problem is converting a rendering system based on DX6-DirectDraw to D3D, where many of the features are not directly compatible.


For example, Decal uses many GetDC() calls which is NOT compatible with A8R8G8B8 surfaces - because "GDI does not have a well defined behavior on the alpha channel." Of course, to use color keyed alphsa "blending" (transparency), you need A8R8G8B8 surfaces instead of X8R8G8B8 surfaces which work fine with GetDC(). This of course means we have to either convert our surfaces between two formats (which is incredibly expensive in terms of time) or redo the way Decal works behind the scenes (which takes a lot of code!).


This is in addition to the fact that we lost every single memloc, basically. The only part of AC that didn't change is the core networking layer - though the protocol numbers changed, the protocol is basically the same absent a new message type (packed DWORD).

 

-----signature-----

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/gdi/bitmaps_6ig4.asp


I worked a lot on GDI and DirectX stuff and could have eventually helped on that part, but I would need a prototype of source code as I don't feel like getting an aged sourceforge version and having to adapt it first.

 

-----signature-----

Would it be more practical to say 'screw it' to alpha blending and go with opaque drawing? I understand that HUD plugins will look uglier that way, but if BS/2 works(example), then thats enough to release, IMO. Worry about alpha later if its holding you up AND you could have it working faster if you ignore it for now and work on it as time allows.


Buffing plugins and robochef-like plugins don't care about alpha.

 

-----signature-----

It's all moot anyway, since memlocs aren't done. If the rendering was the only thing holding back a release, I would probably put out something that's ugly as sin so people can get their buffing plugins back.


Edit: The SF version is for all intents and purposes, exactly the same as current Decal code for everything but ACHooks. The only changes that have been made to Decal since we split have been mirrored to SF for the most part (and DLLs built from SF will work if you use our Decal.dll for ACHooks). Though SF doesn't have any TOD related code.


I don't think people realized how much back end work was needed; Checksum and I had to figure out the new DAT file stuff, then figure out what the new formats were. There are a lot of changes to the actual image formats. This is stuff that needed to be done before we could even work on Decal. Just like kgober had to find all the packet changes before we can incorporate them into Decal... there is research involved, not just coding.


This is basically converting Decal to a *new* game. We have to redo all the old research on AC for TOD because so much changed... we are just lucky that there is shared code between AC2/MEO/TOD that we could use which aided this.

 

-----signature-----