1394 replies to this topic

[bodydump]

Same problem as JP.  I was using a bunch of overlapping ramps at the same height for gi.  Worked great in 780, now have graphical glitches galore.

[toxie]

We have some fundamental problem there with these damn alpha ramps:

If we allow the 'old' behavior (with 'normal 3D stereo off') there are problems for users that can't use some 'standard' RU/RO setting (as this thread showed).

If we only allow the 'normal 3D stereo off' if stereo 3D is actually running (new behavior) then these problems go away.

 

Now one trick that might work for these overlapping ramps: Use drawing order and slightly offset the height, so that lower ramps get drawn first, etc.

Please try if that is okay for you guys, otherwise we have to figure out something else.

[koadic]

I know that works for some of the issues I have had messing with CV, I ended up adding or removing 0.1 to the height of some ramps that I was having issues getting to draw correctly.

[toxie]

And does it complicate the table design significantly, or is it okayish to work with it like that?

[koadic]

For what I had, it wasn't that big of a deal... for the ramps a had issues with all at the same height, I just looked at the drawing order and adjusted the heights according to that

[jpsalas]

Yes, I guess we can live with that

[fuzzel]

But what about already released tables? Does the changed behavior have an impact on them?

[koadic]

I guess it might if it has a lot a closely placed and overlapping alpha ramps used for lighting...

Does this mainly just effect the alpha blended ramps?

[fuzzel]

Yep, I think it's not a good idea to screw tables with alpha flashers just to help some people who have problems because of their hardware. I know it would be a nice option to just change a setting and everything works again but if the majority of users have glitches because of that I would remove it.

[TedB]

Yep, I think it's not a good idea to screw tables with alpha flashers just to help some people who have problems because of their hardware.

 

I agree, and I am one of the persons having the problem. Are you sure it is a hardware issue? Can you tell me what is wrong in below setup? I wouldn't mind buying some new hardware to solve issues.

 

AMD Athlon II X2 Dual Core 3.0GHz

4GB RAM
GeForce GTX 550 Ti 1024MB (separate Geforce card for my backglass)
Gigabyte 870 A-UD3 Mainboard

[fuzzel]

Your system should be fast enough but it's hard to tell because we all don't know how different versions of the graphic card drivers handle old DX support. Actually the real problem is if the drawing order is not 100% correct. If you use transparency and/or additive blending you have to make sure that the order is correct. Older VP versions didn't support a proper drawing order handling so maybe tables showing this issue must be updated.

[toxie]

The thing is that actually only very very few tables abused the "3D stereo" setting in the ramp options for this kind of stuff, most people left the "3D stereo" setting at default (so same behaviour as it is now anyhow)..

And i also tested a lot of tables where i added the "3D stereo" setting myself for various reasons.. And the fails are very very low from my experience (as overlapping was rarely used when additive blending was introduced, just recently it became hip with faking GI and "overdoing" the flasher sizes )..

I guess it might if it has a lot a closely placed and overlapping alpha ramps used for lighting...

Does this mainly just effect the alpha blended ramps?

 

as said, only if these old tables actually used this new setting (3D stereo).. otherwise it is still the same behaviour.. so only tables that have overlapping AND use alpha ramps AND abused the 3D stereo flag will be affected (to my knowledge that is basically JP with his two test tables and the new CV, i think also the newest Hurricane (not sure), and -maybe- some other 2 or 3 recent tables (teppotees night mods come to mind))

 

 

@TedB: Could you please state which tables have some problem for you? And if you use RU/RO on/off?

 

 

it's a mixed bag.. i would prefer to make this cut now while we are still in beta, so that the final has this clean behavior, no matter if you have RU/RO on or off, otherwise people will be heavily confused when to turn this on/off or will complain if a table comes pre-shipped with RU/RO on/off, as it will affect their performance..

And actually this damn flag (sorry ) was never intended to be abused like that, it was really just meant to fix rendering issues in -3D-, not for normal "2D"..

So before we introduce new legacy that might be hard to fix afterwards, i vote for having this new behavior as the standard..

Edited by toxie, 11 December 2013 - 02:49 PM.

[unclewilly]

I use this also so I can utilize nvidia aa.
Have to turn off ro and ru so the work around is necessary for me.
I also seem to get better fps with those turned off

[TedB]

@TedB: Could you please state which tables have some problem for you? And if you use RU/RO on/off?

 

Not sure what you mean, the latest adjustment >782 solved my graphics issues.

Example of a table I had to adjust the alpha ramps using an older version was AFM night mod. After adjusting I used RU on / RO off for best performance.

 

I can do some checks with some newly downloaded tables - I might have messed up a couple of them on my cab trying to fix the paintball effect. Just let me know what revision and setting you want me to test.

[DJRobX]

I figured out a fix to the code editor text search cursor issue if anyone's interested.  The problem is that the code tries to reposition the cursor without window focus.    If you try to focus at the time the found text is selected, it works, but then the find window loses focus, which isn't desirable either.    So my workaround was to re-select the selected text when you close the find window.  It seems to work very well for me.

 

Near line 1623 of CodeView.cpp, in CodeViewWndProc

 if (pfr->Flags & FR_DIALOGTERM)
      {
         pcv->m_hwndFind = NULL;
         const DWORD selstart = SendMessage(pcv->m_hwndScintilla, SCI_GETSELECTIONSTART, 0, 0);
         const DWORD selend = SendMessage(pcv->m_hwndScintilla, SCI_GETSELECTIONEND, 0, 0);
         ::SetFocus(pcv->m_hwndScintilla);
         SendMessage(pcv->m_hwndScintilla, SCI_SETSEL, selstart, selend);
         return 0;
      }

 

[toxie]

Not sure what you mean, the latest adjustment >782 solved my graphics issues.

Example of a table I had to adjust the alpha ramps using an older version was AFM night mod. After adjusting I used RU on / RO off for best performance.

 

I can do some checks with some newly downloaded tables - I might have messed up a couple of them on my cab trying to fix the paintball effect. Just let me know what revision and setting you want me to test.

 

 

 

Okay, so everybody is happy then with the new behavior.. Even better..

 

So we are even closer to final release of 9.2.0 then?   *push*

[bodydump]

By new behavior do you mean like in 783?  If so no, I'm not happy...now I have to try to fix 2 new tables I was about to release.

[fuzzel]

I figured out a fix to the code editor text search cursor issue if anyone's interested.  The problem is that the code tries to reposition the cursor without window focus.    If you try to focus at the time the found text is selected, it works, but then the find window loses focus, which isn't desirable either.    So my workaround was to re-select the selected text when you close the find window.  It seems to work very well for me.

 

Near line 1623 of CodeView.cpp, in CodeViewWndProc

 if (pfr->Flags & FR_DIALOGTERM)
      {
         pcv->m_hwndFind = NULL;
         const DWORD selstart = SendMessage(pcv->m_hwndScintilla, SCI_GETSELECTIONSTART, 0, 0);
         const DWORD selend = SendMessage(pcv->m_hwndScintilla, SCI_GETSELECTIONEND, 0, 0);
         ::SetFocus(pcv->m_hwndScintilla);
         SendMessage(pcv->m_hwndScintilla, SCI_SETSEL, selstart, selend);
         return 0;
      }

great find...added this to rev784

[bent98]

I think we need to find a solution an alternative solution as 783 breaks new techniques used on tables that are being worked on.

[toxie]

I would totally agree if this wouldn't be based on exploiting a 'bug', so that it doesn't work properly on some setups..

And as it seems to be fair enough to work around that with the new rev, i think it's okay (i didn't say fun ) to use it like that..

 

Sorry.. But this is better than having it to fix after 9.2.0 is officially out and confusion/re-releases happening all over the place..