Emulator

This causes tons of other deficiencies in every other stage too. Flickering on load, backgrounds cutting in and out, flashes of black screen near the start of rounds. Certain camera angles will cut off stage effects like water.

revision 8e9bbdeb2fa59a8496e91cae751a49097e5d52c8 .

And have fun finding the fixes when they are buried inside an indentation change...

I don't really care, it's a D3D9 issue. If someone wants to fix it, it would be nice, but I won't push for it to be done before 4.0.

The issue is in DX9::Renderer::SetLineWidth().

working on it

can you post screenshots from the other backends in the same area?

You can just use the fifo log to look at it yourself ;)

i'm looking at it and the issue looks diferent on my pc, so i want to evaluate how it behave on the diferent backends in the original machine that has the issue

no problem, found the issue, the particle system used there is generating the dots that are not properly rendered in dx9 backend, working on a fix

please can you test the new branch dx9-PointLine-Renderfix

I veto this change unless you can get both Neobrain and degasus to approve of it. The last thing we want 9 days before a release is invasive changes to VideoCommon (both shadergen and vertex loading) for a deprecated backend.

Is not in the main branch and I'm not pushing to merge it, is just a solution for known problems in the backend, is just a concept implementatiopn to update the code.
hey i'm really starting to feel that there is someting personal against dx9 backend, I'm just trying to help fix things as always.

When the crap that is required to emulate Flipper properly in D3D9 (but not required with OGL/D3D11) starts leaking to common parts of the code + D3D11/OGL code (your D3D9 change shouldn't introduce performance regressions in D3D11 like it currently does), it should be easy to understand why people don't want it in.

Basically, D3D11/OGL backends are the way of the future, the D3D9 backend isn't. Especially if it starts requiring hacks like this.

I guess this is yet another example of "D3D9 is faster because it's less accurate".

This is forcing support for a feature on an API that doesn't support it.
This also breaks Intel Ironlake support in Linux.

@ rodolfoosvaldobogado: There's nothing personal about your D3D9 changes, it's just that we agreed on IRC to drop D3D9 some months ago so we don't quite see your motivation to fix things there in the first place instead of improving the common gfx code (which doesn't need to happen via code but could also be just outlining some TODOs publicly - I know you got enough crazy ideas to work on :D). Anyway it doesn't really matter since apparently neither you nor us are trying to get this change to master, so I'll just leave it at this.

Also, you probably have realized that we (= delroth and me) are quite "direct" with criticism these days. You shouldn't feel offended by that, it's just that we figured this is more productive than blindly +1'ing every change and assuming it's bug-free.

First, don't worry, you didn't break ironlake support as glsl120 also support integers, but neither bit operations nor integer attributes ...

But I don't see why you forced enable posmtx. At least I haven't found any more usage on it in the vertex shader.

It's awful to review your VertexManager changes as there are many imo unrelated changes in this file. I guess you just copy the vertices some times and set different offsets? Should be done in geometry shader, but who cares ...

And I don't know how this should change D3D11 or OGL performance. Maybe because of the forced posmtx, but nobody will notice such a performance hit.

So, in the end, non of this is the reason to drop D3D9. Have you looked at the tev_fixes branch? It fixes lots of games, but the more accurate emulation is about 50% slower. Strangly this isn't because of more logic, it's just to accurately emulate integers. So we decided to not merge it but to reimplement this "emulation" with integer itself, which isn't possible on glsl120 nor D3D9 iirc.

NeoBrainX: my decision to continue my work in the dx9 backend is just to take it to the maximum potential before the support is dropped. I'm a professional developer and is not necessary to be a genius to see that dx9 is not powerful enough to fully implement a correct emulation of our target hardware, but I just opted to keep supporting it until is dropped just to test how much I can implement in my free time (is like a personal test, I only have 15 min a day to spend on dolphin), and make it the best it can be. And the question about why I’m not committing to the common code is simple, because modifying what is the common code right now is just useless. The performance problems and the limitations of the implementations in the backbends are attached to architecture decision that where made when technologies like dx11 or ogl3 were not available. For me the only solution to that are changes starting from the bases of state management, data streaming and pipeline emulation, oriented to the new paradigms available right now. To all the other developers my apologies if caused troubles. After dx9 support is dropped I will try to help with the changes in the common code to improve things in the remaining backends.

wickmarkus86: the use of blend indices in my implementation is just to do a indexed offset in the vertices needed to emulate point and line rendering. About the vertex manager changes they all are simplification eliminated the old vertex array path and clean the code to allow an improved quality on the new code. As you point the method is simple just generating the extra vertices and change index to point to the correct offset. About geometry shaders : not available in dx9 so sticking to cpu, I event think in a little trick to use tessellation but the support for that on dx9 is horrible and the implementation is to hacky and complicated to do in my free time.
About the tevfixes, yes look at them, I make something similar some time ago but I discard it because the performance lost was terrible.

going back to the original issue can someone test if this fixed the problem with the particles. I hate the programer that use more than 24000 points to emulate stars :).

Can we just revert 8e9bbdeb2fa59a8496e91cae751a49097e5d52c8 for now, and land a fix which also does not change the indentation and ten other things to be incorrect?

that version is a correction, in the old code we were writing the line size to the point size, this way we where hiding the true problem. please can you test the new branch that should fix the ORIGINAL issue. the remaining problems about indentation and everything else are already fixed.

ironlake already broken on linux.. since much ago u_u

anyone has an oportunity to test if the branch fixes the point issue? for mi it does but i like to see if is the same for every hardware

Branch Fixes it for me on all of my nVidia cards.

now that we are not in stable mode can i merge this branch so i left dx9 plugin in a better state before removal

@ rodolfo: I was actually about to merge my d3d9 removal branch in...

please wait until this branch. tev-fixes performance and efb peek cahe is merged the you can drop dx9

@ Rodolfo: No sorry, but there's absolutely no point in adding more d3d9 work after 4.0 just to have it removed at some point lateron. That's just confusing git history. Also, just because we're not in "stable" mode anymore doesn't mean we'll start merging any unreviewed stuff.

If you want to have a fork (and that's really what you're doing right now is) with D3D9 you're free to do that in a branch. delroth's build bot will happily build it and place builds at https://dl.dolphin-emu.org/builds/ .

ok. please give me a few hours to get the lastest main and create the branch

@Rodolfo: Please delete your redundant branches, the list is getting quite confusing and no one but you knows if any of them are still required to be there.