D3D9 only supports 8 texcoords. But we need a new one for ppl, so we just store it in the first 4 texcoords in the free 4th component.
This isn't needed for both d3d11 and ogl3, so just remove it.
This isn't needed in VertexShaderManager as it's still in the old dirty flag way.
But it's very importend for PixelShaderManager as some float4s aren't initialized as 0.0f
The old way was to use a dirty flag per setter. Now we just update the const buffer per setter directly.
The old optimization isn't needed any more as the setters don't call the backend any more.
The follow parts are rewritten:
Alpha
ZTextureType
zbias
FogParam
FogColor
Color
TexDim
IndMatrix
MaterialColor
FogRangeAdjust
Lights
The upload in the backend isn't done, it's just pushed by the mostly removed SetMulti*SConstant4fv.
Also no optimizations was done on VideoCommon side, but I can start now :-)
Sorry for the hacky way, but I think this is a nice (working) snapshot for a much bigger change.
Turns out Android devs decided to opt for one of the most retarded ways of handling assets. Assets with some specific extensions are not compressed (png, jpeg, etc), and anything else is compressed. The AssetManager is so revolutionary, that you actually can't retrieve valid FileChannel descriptors from these compressed files! To add to this revolutionary system, they actually didn't give you a straightforward way of disabling this compression. Now using FileChannels are not possible, and thus we must use the much slower way of copying everything over. Thank you Android devs. Godforbid someone would like to use a non-array based way of copying things that's actually efficient, considering DMA access is possible with FileChannels.
This reverts commit 0dd32986b8.
(Read_Opcode_JIT and Write_Opcode_JIT read/write from unrelated memory
areas.* Rename the latter and refactor.)
*except at the one specific exception handler where it doesn't. I
have no idea what this is supposed to do, but it probably doesn't do
it correctly. For now, remove the exception.
(1) The alternative doesn't compile.
(2) Despite "unlimited" sounding like a hack, it's actually
significantly more correct then the alternative, which is no
emulated icache.
(3) Easier to wrap my head around.
This implements a partial JITIL based off of the JIT64IL. It's enough to run most games, albiet at a slow speed.
Implementing instructions for this IL is really simple since it basically is just enabling based on what is already in JIT64IL, and then enabling each individual IL instruction.
Tillmann Karras