Poll: Is it time to upgrade your GPU !
You do not have permission to vote in this poll.
I already own a GL4/DX11 GPU Smile
93.18%
82 93.18%
GL3/DX10 GPU/SandyBridge with no plan to upgrade
5.68%
5 5.68%
GL3/DX10 GPU/Sandybridge but will upgrade soon
1.14%
1 1.14%
Total 88 vote(s) 100%
* You voted for this item. [Show Results]

OpenGL 4 dilemma
#41
(08-26-2015, 08:16 PM)willkuer Wrote: I would just put a new renderer ogl => ogl 3.3 and add ogl 4.0. If you are on xp you can not use dx10/11. The same is valid for gpu supporting dx10/11. I think adding a new renderer but keeping the old one is the current policy of pcsx2.

I will likely do that. On windows you can still uses dx9/dx10. In the end it is the same. Either you have an old gsdx version or an unmaintained renderer in the middle of the code.
Reply

Sponsored links

#42
By the way most of the recent improvement (the part that makes gl better than dx) requires gl4 extensions.

On the future, I think it is possible to do an adaptative MSAA/SSAA (aka upscaling). Better trade off between quality/perf/glitches
Reply
#43
what makes PCSX2 so different than modern applications and games.

DROP THE HAMMER Tongue
Reply
#44
For the sake of PCSX2's future, dump OGL3 and DX10.
MyAnimeList: http://www.myanimelist.net/profile/tyestor
Last.fm: http://www.last.fm/user/tyestor
Current PCSX2 version: v1.7.2460-windows-64bit-SSE4

The plural of anime is anime.
Reply
#45
Why not wait till after 1.4.0 to drop it?

When dropping support for something it's nice to give a heads up. In the release notes for 1.4.0 it could be added that the 1.4 series will be the last to support for OGL < 4, DX[9/10/etc], and Windows XP/Vista and maybe 7 since it also hit EOL recently and by the time a 1.6.0 gets released it will be almost unsupported.

If a user wants to use an old OS and Hardware then they should not mind having to use a old stable version of PCSX2 and staying with the 1.4 branch. Any updates to the old code path could be added in the 1.4 git branch and released as 1.4.1/1.4.2/etc but from what I have seen stable releases rarely get a point release.

This should cleanup the code since old paths could be removed and avoids polluting the repository with another plugin GSdx-ogl3 which will rarely get updated at all. Updating it in the 1.4 branch it's just cleaner and it's equivalent to forking it as GSdx-ogl3.

I think it's better for the project to reasonably drop support for legacy stuff as needed provided they give a head ups in the previous stable release. This is just my opinion and also 1st post.
Reply
#46
I agree micove, we should have a definite cutoff point where users with the old hardware can get the latest fixes they can as development builds will drop off at some point and then they will need to get an even older one with more bugs
[Image: ref-sig-anim.gif]

Reply
#47
Same opinion here. Let's ship 1.4 still supporting older hardware (also WinXP) and then after that drop legacy stuff as is convenient.
Reply
#48
But why do you want to drop dx9, ogl 3 and possibly even dx10/11 if it is cheap to keep it? You already have the environment to support different api's.

WinXP one probably needs to drop if future vs don't support it.
Reply
#49
We don't want to drop DX9 yet, that is completely separate from DX10/11 and OpenGL. It might happen in the future, but not now.. Right now we're talking about dropping support for older cards in OpenGL where they aren't compatible with the newer API
[Image: ref-sig-anim.gif]

Reply
#50
Also, at the GSdx context, if we eventually decide to drop older APIs, I think it could be useful to still maintain some legacy backend for SW rendering (which technically doesn't require any advanced HW capabilities), if only as a fallback when trying on new systems, or when porting etc, or when testing PCSX2 in a (Linux) VM, etc.

We already maintain SW rendering anyway, but not being able to render it to screen because GSdx "requires" OpenGL 4 is a bit of a shame IMO. We should support SW rendering IMO with really minimal HW/driver requirements.

(We did have SDL, which was also a portable backend, I actually liked it as a fallback SW backend, but it got removed...)
Reply




Users browsing this thread: 1 Guest(s)