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
also
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 make much
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 for now
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
---
From 4,000 ft: 49-50 fps
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
a wIndow and glut
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 much
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 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,
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 for
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
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
gprof will
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.
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 fix it
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 with
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
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
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
declared
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.
This has to
[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... The
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 that
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_lookat.cxx that
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 playing
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 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.
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
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
the
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
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 your code
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
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
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 the default
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 code
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 71
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
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 the screen.
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 :-))
Norm -- I am
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 speedup is
37 matches
Mail list logo
