On Thu 21. March 2002 19:09, you wrote:
> Martin Dressler writes:
> > > I think that we should pass on this patch for now -- I have no clear
> > > explanation of how it might help the framerate, and I cannot imagine
> > > that skipping a single glViewport call could make any difference. It
>
Martin Dressler writes:
> > I think that we should pass on this patch for now -- I have no clear
> > explanation of how it might help the framerate, and I cannot imagine
> > that skipping a single glViewport call could make any difference. It
> > also removes some existing functionality (suc
On Thu 21. March 2002 13:38, you wrote:
> D Luff writes:
> > With Norman's main, maximising the window and then returning it to
> > 800x600 leaves the external view of the plane (and probably the
> > scenery but its hard to tell) all scrunched up.
>
> I think that we should pass on this patch f
On Wed 20. March 2002 18:54, you wrote:
> Erik Hofman wrote:
> > While I don't see a direct improvement in framerate I notice a real
> > effect on the screen update. The old behaviour had a small bump in the
> > update every second or so, while the new code elliminates that.
>
> This doesn't ma
D Luff writes:
> With Norman's main, maximising the window and then returning it to
> 800x600 leaves the external view of the plane (and probably the
> scenery but its hard to tell) all scrunched up.
I think that we should pass on this patch for now -- I have no clear
explanation of how it mi
Julian Foad wrote:
> Norman Vine wrote:
> >
> > Removed fgReshape() call from main loop
>
> That's undoubtedly a good thing. Never mind who can see a speed benefit and who
>can't. I can only imagine it was put there to work around some bug. If so, let's
>see if the bug shows up again, and
Norman Vine wrote:
>
> Removed fgReshape() call from main loop
That's undoubtedly a good thing. Never mind who can see a speed benefit and who
can't. I can only imagine it was put there to work around some bug. If so, let's see
if the bug shows up again, and fix it properly if it does.
> R
Norman Vine writes:
> >This is rapidly getting on towards voodoo coding, and I think perhaps
> >we should step back a bit. What, exactly, are the changes in this
> >patch that make it worthwhile? What does it eliminate? What is the
> >evidence for speedup?
>
> gprof is your friend
gpro
Andy Ross writes:
>
>This is rapidly getting on towards voodoo coding, and I think perhaps
>we should step back a bit. What, exactly, are the changes in this
>patch that make it worthwhile? What does it eliminate? What is the
>evidence for speedup?
gprof is your friend
Cheers
NOrman
___
David Megginson writes:
> Andy Ross writes:
>
> > Oooh, which reminds me: has the default logging level changed? I was
> > noticing last night that lots of stuff that used to be printed isn't
> > anymore, including the YASim solution report which I'd like to
> > preserve. I looked briefly f
Andy Ross writes:
> Oooh, which reminds me: has the default logging level changed? I was
> noticing last night that lots of stuff that used to be printed isn't
> anymore, including the YASim solution report which I'd like to
> preserve. I looked briefly for something that might have changed
> I don't know, cpu cycles are cpu cycles...they're good for anything aren't
> they? If you reduce per-frame-code-load then that frees time up for other tasks
> like disk io. Or am I confused about this?
You are confused about that.
Most modern processors are memory bandwidth limited. That's
Andy Ross <[EMAIL PROTECTED]> said:
> Erik Hofman wrote:
> > While I don't see a direct improvement in framerate I notice a real
> > effect on the screen update. The old behaviour had a small bump in the
> > update every second or so, while the new code elliminates that.
>
> This doesn't make
Andy Ross wrote:
> Erik Hofman wrote:
> > While I don't see a direct improvement in framerate I notice a real
> > effect on the screen update. The old behaviour had a small bump in the
> > update every second or so, while the new code elliminates that.
>
> This doesn't make much sense. All of
David Megginson writes:
> That is possible. We're on different OS's with different windowing
> systems and drivers -- you may have identified a performance bug that
> affects only Windows systems. I posted your main.cxx to a temporary
> URL (http://www.megginson.com/flightsim/main.cxx), and I'
David Megginson wrote:
> Norman Vine writes:
> > >Current CVS with Norm's main.cxx patch added
> > >
> > > From 4,000 ft: 49 fps
> > > From 8,000 ft: 35 fps
> >
> > Hmm...
> >
> > My guess is that this has something todo with your running in
>
Norman Vine writes:
> David Megginson writes:
> >
> >Norman Vine writes:
> >>
> >Old binary (about 2 days old, pre-property changes)
> >---
> > From 4,000 ft: 45-46 fps
> > From 8,000 ft: 29-30 fps
> >
> >Current CVS
> >---
> > Fr
David Megginson writes:
>
>Norman Vine writes:
>>
>Old binary (about 2 days old, pre-property changes)
>---
> From 4,000 ft: 45-46 fps
> From 8,000 ft: 29-30 fps
>
>Current CVS
>---
> From 4,000 ft: 49-50 fps
> From 8,000 ft: 35-36 fps
This
David Megginson writes:
>
>Norman Vine writes:
>
> > True -- but then again I have sped the program up ~15% even more if
> > you consider the model view, within the last month. Heck I
> > replaced five matrix multiplies with one for every moving part in
> > the model display code alone :-))
>
>No
David Megginson writes:
>Norman Vine writes:
>
> > Updated test code @
> >
> > http://www.vso.cape.com/~nhv/files/fgfs/nhv_obvious.tgz
> >
> > This is against CVS files as of ~18:00 GMT today
>
>I tried it sitting still on the runway with the panel hidden and the
>ground filling more than half
Norman Vine writes:
> Updated test code @
>
> http://www.vso.cape.com/~nhv/files/fgfs/nhv_obvious.tgz
>
> This is against CVS files as of ~18:00 GMT today
I tried it sitting still on the runway with the panel hidden and the
ground filling more than half the screen. Before Norm's patch, I
Norman Vine writes:
> True -- but then again I have sped the program up ~15% even more if
> you consider the model view, within the last month. Heck I
> replaced five matrix multiplies with one for every moving part in
> the model display code alone :-))
Norm -- I am very grateful for your
Norman Vine writes:
> Consider this scenario
> I want my normal view down 20% slightly to the left
> I can set these with the keys or whatever
> I can now use the mouse to spin about do what ever in mouse mode
> when I leave mouse mode I am back at my normal position
I want my normal view 2
Norman Vine wrote:
> Why -- all you need to do is document it
>
> Consider this scenario
> I want my normal view down 20% slightly to the left
> I can set these with the keys or whatever
> I can now use the mouse to spin about do what ever in mouse mode
> when I leave mouse mode I am back a
Norman Vine wrote:
>
>>FWIW
>I notice about a 10% decrease in fps after applying the new
>simgear code from this morning
>
>What happened ?
My bad I had a orphaned background process running
FWIW
According to my records at normal startup hud no panel frozen
my records show that I was getting
David Megginson writes:
>
> > http://www.vso.cape.com/~nhv/files/fgfs/nhv_obvious.tgz
>
>Are the main.cxx changes atomic? I'd like to apply just them, for
>now.
If by that you mean can you just try the new main.cxx
YES
FWIW
I notice about a 10% decrease in fps after applying the new
simgear co
David Megginson writes:
>
>Norman Vine writes:
>
> > I am not so sure that we don't want both an pulsed 'euler' angle
> > setter 'keypoard and hat' AND a separate mouse controller.
> >
> > I mean after all you don't have to go into Mouse View mode and this
> > way I can use the keyboard to set th
On Tue, 19 Mar 2002 15:17:20 -0600 (CST)
"Curtis L. Olson" <[EMAIL PROTECTED]> wrote:
>Oh well, I've only been flamed by RMS (but that should at
>least count for something, right?)
Are you kidding? If not, you can't get away with stopping
there. What's the story?
Jon
__
Curtis L. Olson writes:
> Oh well, I've only been flamed by RMS (but that should at least count
> for something, right?)
You get one point for every 12 flames.
All the best,
David
--
David Megginson
[EMAIL PROTECTED]
___
Flightgear-devel mail
David Megginson writes:
> Curtis L. Olson writes:
>
> > You definitely can't be ranked as an emacs power user until you are
> > intimate with all the .elc's. :-)
>
> No, you're not an Emacs power user until RMS has forced you to have
> your boss sign one of those disclaimers before he puts you
Norman Vine writes:
> http://www.vso.cape.com/~nhv/files/fgfs/nhv_obvious.tgz
Are the main.cxx changes atomic? I'd like to apply just them, for
now.
Thanks,
David
--
David Megginson
[EMAIL PROTECTED]
___
Flightgear-devel mailing list
[EMAIL P
Norman Vine writes:
> I am not so sure that we don't want both an pulsed 'euler' angle
> setter 'keypoard and hat' AND a separate mouse controller.
>
> I mean after all you don't have to go into Mouse View mode and this
> way I can use the keyboard to set the default viewin offsets and I
>
Jim Wilson writes:
> Can we hold off on this? I'm totally reorganizing the viewer code
> and really don't need to deal with these kind of changes. It'll
> functionally be the same so there shouldn't be any problem making
> this change later.
I agree that we need to hold off on any viewer c
Curtis L. Olson writes:
> You definitely can't be ranked as an emacs power user until you are
> intimate with all the .elc's. :-)
No, you're not an Emacs power user until RMS has forced you to have
your boss sign one of those disclaimers before he puts your code in
the main elisp distribution.
Updated test code @
http://www.vso.cape.com/~nhv/files/fgfs/nhv_obvious.tgz
This is against CVS files as of ~18:00 GMT today
Norman
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
"Curtis L. Olson" <[EMAIL PROTECTED]> writes:
> You definitely can't be ranked as an emacs power user until you are
> intimate with all the .elc's. :-)
Heh. Well, in days passed, I was able to write PDP-11 code with:
cat > a.out
(back in college when I had nothing better to spend my time pl
Andy Ross writes:
>
>Norman Vine wrote:
> > FWIW for vertical virtual panel
> > added 3 lines to Panel.cxx to get and multiply panel matrix by
> > gui_quat_ matrix
> > added 5 lines to viewer.cxx < add gui_quat_matrix and a
>get function >
> > removed line from viewer_rph.cxx and viewer_l
Norman Vine <[EMAIL PROTECTED]> said:
> FWIW for vertical virtual panel
> added 3 lines to Panel.cxx to get and multiply panel matrix by
> gui_quat_ matrix
> added 5 lines to viewer.cxx < add gui_quat_matrix and a get function >
> removed line from viewer_rph.cxx and viewer_lookat.cxx t
[EMAIL PROTECTED] writes:
> Hey, XEmacs is my universe -- after having first been a "guru" level 'vi' user
> for many years, so I'm allowed to have a strong opinion: The difference
> between "vi" and "emacs" is similar to the difference between sleeping in a
> tent and sleeping in your bed at home
Andy Ross <[EMAIL PROTECTED]> writes:
> Derrell Lipman wrote:
> > `ediff-ignore-similar-regions' is a variable declared in Lisp.
> > -- loaded from "/usr/local/lib/xemacs/xemacs-packages/lisp/ediff/ediff-diff.elc"
>
> You, sir, have clearly been spending *far* too much time in info mode.
> Th
Norman Vine wrote:
> FWIW for vertical virtual panel
> added 3 lines to Panel.cxx to get and multiply panel matrix by
> gui_quat_ matrix
> added 5 lines to viewer.cxx < add gui_quat_matrix and a get function >
> removed line from viewer_rph.cxx and viewer_lookat.cxx that
> de
Derrell Lipman wrote:
> `ediff-ignore-similar-regions' is a variable declared in Lisp.
> -- loaded from "/usr/local/lib/xemacs/xemacs-packages/lisp/ediff/ediff-diff.elc"
You, sir, have clearly been spending *far* too much time in info mode.
This has to stop. I fear for your health.
Andy
--
Melchior FRANZ writes:
>
>* David Megginson -- Tuesday 19 March 2002 19:16:
>> Would it be possible either put out a version without the spurious
>> whitespace changes, or to post a message showing only what you
>> actually changed?
Removed fgReshape() call from main loop
Removed fgIdle from t
"Curtis L. Olson" <[EMAIL PROTECTED]> writes:
> diff -w ignores white space, but that doesn't necessarily help if you
> are using emacs ediff to compare the files and merge the changes.
`ediff-ignore-similar-regions' is a variable declared in Lisp.
-- loaded from "/usr/local/lib/xemacs/xemacs-
Curtis L. Olson writes:
> diff -w ignores white space, but that doesn't necessarily help if you
> are using emacs ediff to compare the files and merge the changes.
It could, perhaps, if you do something like this:
diff -w main.cxx /tmp/new-main.cxx > main.patch
patch main.cxx < /tmp/main.
Melchior FRANZ writes:
> * David Megginson -- Tuesday 19 March 2002 19:16:
> > Would it be possible either put out a version without the spurious
> > whitespace changes, or to post a message showing only what you
> > actually changed?
>
> You could also patch a copy, make your own patch
46 matches
Mail list logo
