-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Am 2015-09-23 um 10:27 schrieb Riccardo Bortolato:
> - HRESULT (__cdecl *volume_created)(struct wined3d_device_parent
> *device_parent, void *container_parent, - struct
> wined3d_volume *volume, void **parent, const struct
> wined3d_parent_ops **parent_ops); + HRESULT (__cdecl
> *volume_created)(struct wined3d_device_parent *device_parent, +
> struct wined3d_texture *texture, unsigned int sub_resource_idx, +
> void **parent, const struct wined3d_parent_ops **parent_ops);
Is there a reason why you're passing the wined3d_texture container
instead of the container parent? It doesn't matter too much because
you can either do wined3d_resource_get_parent or
d3d*_texture->wined3d_texture, but I think it is a needless change.
It seems the patch is bigger than it needs to be. You could just add
unsigned int sub_resource_idx and keep the rest in place. Through
struct d3d8_texture *texture inside struct d3d8_volume you already
have access to the wined3d texture. With the addition of the sub
resource idx you can migrate the volume methods one by one, and in the
last patch that removes access to wined3d_volume drop struct
wined3d_volume *volume from the callback.
For surfaces in d3d8 and d3d9 you have to make sure you're always
creating a d3d8/9_texture struct for plain surfaces, but this is
something you can change internally in d3d8/9.
It doesn't matter too much for this patch because the volume API is
pretty simple, but the next patch is pretty complicated because it
changes all the stuff at once. It'll be terrible to bisect / fix if
there are regressions.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBCAAGBQJWAmguAAoJEN0/YqbEcdMwpecP/RqlgzxhIzYQikgOQHhMBuLr
1jOtBW2aAj8qRCPebkM5JAGK+93Y+r9jrkFbJn01ZHKR1fQCfWQteCoMRUIDJ6Iz
TUf5IeuKsUMucU6XJ70kh/d8MQCauOKJizvROCg6F1qILF+W6higdGHC/6FjSqqb
GiXmYAtqGgOP3BGAjM4W4r8+A7yoqssLhLYmJggn8PlX6yFfdIwl/rpOdRfSC+9T
ADrncsPVPpyYFRnQI+atdQuMN5M/GvioqxFS24Fuq65tUqNaXC6D8BsGy0tk6bN2
nZAWkSkrx1bSi24U7RzHbq936Z+qnUp5UH/ZkView8dp5dXiqjmOLucWd4WJ/+0I
rMjIduEPuLgDraKnE4vKtn5WpPmV/ITX6If5zI9fTuFBLwyIrC06lIeaGd5VOHiO
2/U00pyIQuS9F6Ir73J0hl5CJITYhmSdT9xsz2sIBbQheZu7OYLqqfIHM0d3DGBk
tC3H9X4bJQh9nDzLy4IGVr2W2vqQgKIVGxyVcYFyvA448kP7/W2Z1i+ak9CevFGg
fVBrwoPtTzPIoucC9cQ1vnskTITgzSNCuy3t+HBKsbm+0+7VsDnq8CL7wrGbs8uN
hSXwpCA4qLsPyK+6XCuITB8rmkGVX3/2j6Ratf2lSgdZVexQfsK/+hWQYIwXzjki
otAB34aWZl2+f/socndA
=6ndo
-----END PGP SIGNATURE-----
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
https://testbot.winehq.org/JobDetails.pl?Key=16924
Your paranoid android.
=== w2000pro (32 bit msvcp120) ===
The test timed out
Hello,
I'm writing here for asking a suggestion about a patch that I have sent one month ago.
The fix attached in this email:
https://www.winehq.org/pipermail/wine-patches/2015-August/141811.html
is required because, when compiling opengl32 on Windows (CYGWIN or MINGW), the compiler complains that the exported functions are redeclared without dllimport attribute, while they should be declared with dllexport from beginning.
This error can be fixed by adding the definition of _GDI32_ so that WINGDIAPI macro is declared correctly.
This fix already exists for example in /dlls/gdi32/Makefile.in as you can see here:
http://source.winehq.org/git/wine.git/blob/HEAD:/dlls/gdi32/Makefile.in
I hope that it could be committed because perhaps it does not make difference on platforms without dllexport/dllimport attribute support, but it does on real Windows.
Thank you.
Sincerely,
Carlo
Hi all, I know it may sound idiot as I have zero knowledge on 3d
graphics but is it possible to make wined3d to not add textures to
things resulting in a sort of wireframe renderer?
The long and uninteresting background:
I used to play a game called X-moto in 300Mhz Celeron Linux computer,
in its standard rendering mode it was impossible to play the game due
to low fps, but it had an awesome wireframe mode that played smoothly.
So if this could be achieved globally by wined3d we could play new
games on old computers (my overly noob conclusion about all this).
Thanks in advance for any reply,
Bruno