> You may be right that I did not pick the exactly right person for every
> line of code.
> But I also did not get the completely wrong one as you never cared for
> the state of the art even if being pointed to.
Quoting myself:
"You did no such thing, Mathias. You gave a completely incomprehe
On Monday, January 28, 2013 09:27:53 Renk Thorsten wrote:
> Ah, now I understand what Mathias is after:
> > That would be ok if this would be optional in the sense that it does not
> > impact what is there performance wise. But since this is all runtime
> > configured
> > by an uebershader with a l
On 28 Jan 2013, at 22:52, Curtis Olson wrote:
> On Mon, Jan 28, 2013 at 4:42 PM, James Turner wrote:
> Yes of course, that's probably wise.
>
> This does mean that the default behavior is still broke for the people we are
> trying to help with this, but it at least offers a fix for anyone who
> On 28 Jan 2013, at 19:09, Torsten Dreyer wrote:
>
> > Any chance to wrap this into something like
> >
> > if( true == getprop("/sim/use-ati-hack") ) {
> > addTheEmptyPrerenderCamera();
> > } else {
> > doNothing();
> > }
>
On Mon, Jan 28, 2013 at 4:42 PM, James Turner wrote:
> Yes of course
On 28 Jan 2013, at 19:09, Torsten Dreyer wrote:
> Any chance to wrap this into something like
>
> if( true == getprop("/sim/use-ati-hack") ) {
> addTheEmptyPrerenderCamera();
> } else {
> doNothing();
> }
Yes of course, that's probably wise.
James
---
Any chance to wrap this into something like
if( true == getprop("/sim/use-ati-hack") ) {
addTheEmptyPrerenderCamera();
} else {
doNothing();
}
Am 28.01.2013 18:56, schrieb James Turner:
> http://code.google.com/p/flightgear-bugs/issues/detail?id=385
>
> Is about a problem with the viewport
http://code.google.com/p/flightgear-bugs/issues/detail?id=385
Is about a problem with the viewport behaving very oddly, in certain Ati
catalyst drivers.
A kind person has worked out a hack, which fixes the issue, or at least avoids
it. It add an empty, pre-render camera to the scene, which I as
Agreed, though I think the GUI is Gijs' work rather than mine.
-Stuart
--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with L
> After some discussion / observation, I am going to change the default
> shader level for 2.10 (and probably next) to '1' instead of '3'
(...)
> Comments / objections?
Complete agreement, after looking at the Intel and Mac problems in the forum, I
was about to suggest the same thing.
* Thorst
Heads up:
After some discussion / observation, I am going to change the default shader
level for 2.10 (and probably next) to '1' instead of '3'
'3' is causing folks with underpowered hardware to die, and not realise there's
a setting they can tweak. I'd rather we make the default setting pessim
On 28 Jan 2013, at 10:41, Emilian Huminiuc wrote:
> Just to set things straight, models don't need to be modified. The "local"
> effect inheriting from model-combined*.eff needs to have those, and this is a
> workaround to Flightgear not handling graciously untextured models fed to the
> bino
On Monday, January 28, 2013 09:27:53 Renk Thorsten wrote:
> Ah, now I understand what Mathias is after:
> > That would be ok if this would be optional in the sense that it does not
> > impact what is there performance wise. But since this is all runtime
> > configured
> > by an uebershader with a l
Ah, now I understand what Mathias is after:
> That would be ok if this would be optional in the sense that it does not
> impact what is there performance wise. But since this is all runtime
> configured
> by an uebershader with a lot of uniforms this is not the case. Any
> additional
> featur
On Monday 28 January 2013 08:46:02 Renk Thorsten wrote:
> Well, yes, that I know - this is why the performance/quality steps in the
> framework utilize mostly different shaders rather than one shader with
> if-statements.
>
> But we were talking about *optional* usage of the framework making thin
> No, I think what he meant is that (without me ever even seeing shader
> code)
> something like:
> if (enable_light_scattering) {
> a = b + c;
> }
> compromises performance, even if light_scattering is disabled because the
> compiler would assign registers to this code (the a = b + c), even
On Monday 28 January 2013 08:02:14 Renk Thorsten wrote:
> > Any
> > additional uniform takes time to be set up in the driver. Any code that
> > is in the shader and that cannot be optimized away at *link* time of the
> > shader may
> > take registers which affects the partitioning and the amoun
Dear Mathias,
> But what I saw lately - especially from this finish guy - is noting close
> there.
I continue to have a name (which is Thorsten), that name doesn't actually sound
very Finnish, and that would be because I am actually German (I do live in
Finland). There's no need to pretend you
17 matches
Mail list logo
