michael-fadely / d3d8to11 Goto Github PK

This will make long-term dependent project compatibility less of a pain.

i.e.

1. Remove all the std:: collections from the header, make this a real interface again
2. Add methods that return things like the Direct3D 11...
   • Device
   • Context
   • Parameters
3. Avoid changing them

Hi, do you offer a binary or compile instructions?

In Direct3D 8 and 9, a pointer to a contiguous buffer is provided when a level is locked. This contiguous buffer is encompassing of all the mipmap levels including the level asked for, and all the levels to follow.

Some games, such as Phantasy Star Online: Blue Burst exploit this to populate all mipmap levels simultaneously.

There is a branch called lock-rect-all-mips which is experimenting with a fix.

(cuz the SADX version says it's missing some module, and you archived it...)

This will require some refactoring. Current implementation doesn't allow for creation of individual Direct3DSurface8 instances without a parent Direct3DTexture8.

May be a somewhat stupid question but how do i see it did work?

I am using it on an mmorpg, where i have the source code from and can compile the entire game. The game sadly is so old it is a 32 bit game with DX8.1

I Put your files after compiling to my games Bin folder where an original d3d8.dll file was located and replaced all with your files, but ingame i see no difference and my ingame console still says directx8

This is my current game folder structure with your files:

And this is the open public source code link if that helps understanding:
https://github.com/openlastchaos/lastchaos-source-client/blob/master/Engine/Graphics/Gfx_Direct3D.cpp

Because why wouldn't you want a 4294967295x4294967295 32-bit ARGB texture?

Thought it might be the implementation of Direct3DDevice8::GetDeviceCaps, but it doesn't even call this function.

At startup there's an error message:

Cannot create 3D device:
Adapter 0 () Fullscreen
Resolution 1920x1080, format A8R8G8B8/D24S8, refresh 60 Hz.
Error D3DERR_INVALIDCALL

Once press OK the application is closed.

The screen will typically just go blank.

When you die, the screen starts to blur and become purple.

It's evident that the blur effect is working:

However, the purple effect seems to be getting occluded or incorrectly blended:

Current shader implementations use a combination of runtime branching and preprocessor magic to compile the desired shader permutation required for rendering.

Typical uses of runtime branching are:

• Fog mode - still not sure why I made this runtime
• Alpha blending modes - for optimizing opaque data out of OIT buffer
• Alpha rejection toggle, comparison mode
• Texture stages et al.
• Light enabled state, type (point, spot, directional)

To greatly reduce runtime branching, shader source code generation could be employed to generate task-optimized shaders that already understand these conditions.

These shaders need to be uniquely and reliably identifiable at runtime. This is currently handled with a huge 64-bit bitfield. By taking runtime checks and making them shader permutations, we exhaust the number of reasonable bits we can use in that bitfield. An optimized multiple-key lookup mechanism might be a good idea (conceptually, std::unordered_map<bitfield_a, std::unordered_map<bitfield_b, shader>>).

I'd like this done in such a way that snippets of shader code--which would be used to produce full shaders--can be modified and re-loaded at runtime for rapid iteration.