rambetter [Tue, 11 Jan 2011 02:23:58 +0000 (02:23 +0000)]
Finishing up the degenerate_winding2 and degenerate_winding3 regression tests.
Sure enough, they expose the "problem". I just created these based on my
understanding of the code and seeing a potential problem.
rambetter [Mon, 10 Jan 2011 06:15:47 +0000 (06:15 +0000)]
Importing code changes for q3map2 from Rambetter-math-fix-experiments branch
into trunk. Right now all the new code that fixes problems is turned off.
There are three new #defines in q3map2.h:
EXPERIMENTAL_HIGH_PRECISION_MATH_Q3MAP2_FIXES, EXPERIMENTAL_SNAP_NORMAL_FIX,
and EXPERIMENTAL_SNAP_PLANE_FIX. All of these are currently set to 0, which
means don't enable that new code. You can easily edit these to be 1 in order
to enable the new code.
There are very very minor changes to the code even with these three #defines
disabled. They are as follows.
- In PlaneEqual() in map.c, now considering deltas equal to given epsilon
values as "far enough to be different". Previously, the '<=' operation was
used, now '<' is being used.
- In FindFloatPlane() in map.c, considering delta equal to distanceEpsilon
(for plane distance) to be sufficiently far away. Before, delta had to be
strictly greater than distanceEpsilon.
- VectorNormalize() in mathlib.c is more accurate now. This change itself
causes at least one regression test to succeed. The previous implementation
of VectorNormalize() caused excessive errors to be introduced due to sloppy
arithmetic.
Note, the epsilon changes account for the possibility that the epsilons
are set to 0.0 on the command-line.
rambetter [Fri, 31 Dec 2010 03:03:13 +0000 (03:03 +0000)]
Undoing commits r363 and r371 as it pertains to polylib.c, mathlib.c,
and mathlib.h (the regression tests have not been removed).
Trunk is now restored to a state that it was in before I started
trying to fix the math accuracy errors in q3map2. Commits r363 and
r371 were "correct" and did improve math accuracy significantly, but
unfortunately the underlying cause of math accuracy issues is something
else, which is being addressed in branch Rambetter-math-fix-experiments
currently. I'm taking the BSD approach here, which is "we not going to
partially fix the problem. it's all or nothing". Otherwise it's just
too risky in my opinion. I don't like playing Whack-A-Mole.
Someday, we might merge Rambetter-math-fix-experiments branch to trunk.
Sorry about all these needless commits to trunk.
rambetter [Wed, 29 Dec 2010 09:00:47 +0000 (09:00 +0000)]
Undoing revision 377 (reverting just those files modified by that
commit). I have disovered the fundamental problem to the math error problems,
and although this commit (r377) is "correct", it fails to address the
fundamental problem. Therefore, I'd rather leave the code in a state that
has the exact same behavior as before until I get a chance to address the
fundamental issue.
rambetter [Wed, 29 Dec 2010 05:20:32 +0000 (05:20 +0000)]
Updating notes on regression tests. They are "mostly sort of fixed". Won't
be fixed for good until I look at the last bit of code that has not been
examined yet, which is the plane intersection code. I want the errors to be
much less than they are now, even though the disappearing_sliver* tests are
now working.
rambetter [Wed, 29 Dec 2010 04:32:35 +0000 (04:32 +0000)]
Continuing work on BaseWindingForPlane() in polylib.c. In fact I'm pursuing
the approach that was committed in r375 (but was then backed out). I can't
believe my eyes, but I seem to be getting 0.000000% error in some of my
regression tests. The trick is to scale by a power of 2 and never do a
VectorNormalize().
rambetter [Tue, 28 Dec 2010 19:26:52 +0000 (19:26 +0000)]
Following up on r371; found another optimization for math rounding errors
in BaseWindingForPlane(). This allows me to get rid of an extra call to
VectorSetLength() which contain floating point multiplications. Behavior
of BaseWindingForPlane() has been verified against base_winding regression
test (comparing output w/ logging patch).
rambetter [Tue, 28 Dec 2010 10:02:11 +0000 (10:02 +0000)]
Rewriting BaseWindingForPlane() in polylib.c from the ground up. The behavior
is totally unchanged, and I verified this by running extensive tests. The
only difference is that the math precision is much much better now.
Performance should be better as well (but that is not tested).
This is a major milestone because it fixes two regression tests:
disappearing_sliver2 and sparkly_seam.
Improvements to math precision is ongoing and more improvements can probably
be made even after this patch.
I will update the README.txt files in the regression tests in a separate
commit. This commit only includes the actual fixed code.
rambetter [Mon, 27 Dec 2010 08:08:00 +0000 (08:08 +0000)]
Fixing "disappearing_sliver" bug.
A regression test is included.
This is a bug in q3map2. Please read
regression_tests/q3map2/disappearing_sliver/README.txt for more info.
rambetter [Sun, 19 Dec 2010 03:44:26 +0000 (03:44 +0000)]
This is a big big GTK file dialog change in Rambetter-temp-fixes branch.
Thank you to Markus Fischer who provided some example code on how to
use the "new" method of GTK file dialogs. I then did a lot of research into
how to shape his code into exactly what I wanted.
This is an incomplete change in that I have not cleaned up the code such
as removing unused local variables and unused functions yet. However, I
wanted to commit this now because it really works beautifully (the GTK file
dialog that is).
- In CFileType, m_pstrGTKMasks now contains string like
"quake3 maps (*.map)" instead of like "quake3 maps <*.map>". Nobody else
is using this code except in gtkmisc.cpp so it's a safe change.
- Removing all FILEDLG_DBG blocks in gtkmisc.cpp. It really clutters up the
code and since it's completely overhauled, it's OK to remove.
- Instead of the "old" way of gtk_file_selection_new(), now using
gtk_file_chooser_dialog_new() instead. Thx to Markus Fischer for examples.
- Actually adding GTK file dialog filters. It works really nice! :-)
- Now using the same file extension logic on Windows file dialogs and GTK
file dialogs.
- Improved file extension logic. "No file extension specified in file to
be saved. Attempt to save anyways?"
Tested on Win7 and Linux.
More related changes on the way.
rambetter [Sun, 19 Dec 2010 01:31:52 +0000 (01:31 +0000)]
Slight fix to r353 in Rambetter-fixes temp: the file suffix in
save operation is case sensitive now w.r.t. to checking a registered
suffix. The problem was that saving a file foo.MAP does not work.
rambetter [Sun, 19 Dec 2010 01:08:29 +0000 (01:08 +0000)]
Another Windows file dialog change in Rambetter-temp-fixes branch.
Handling file extensions better during save operations. This is more
Windows-compliant. For example, when saving map:
- If ".xmap" filter is selected and user types "foo.map", map will be
saved as "foo.map" (previous behavior was "foo.xmap").
- If an unrecognized file extension is typed, GtkRadiant will now honor that
but issue a warning popup window: "Unknown file extension for this save
operation. Attempt to save anyways?". All known extensions for the type
are checked. Previous behavior was that the extension is always changed
based on selected filter.
I will continue making lots of incremental fixes to Rambetter-temp-fixes.
rambetter [Sat, 18 Dec 2010 03:03:55 +0000 (03:03 +0000)]
Improving native Windows file dialog in Rambetter-temp-fixes branch some
more. This adds new code and improves code committed in revision 351.
- Calling GetOpenFileName() and GetSaveFileName() from a new thread, thus
allowing the main thread to continue refreshing GtkRadiant while the native
Windows file dialog is open. Prevents the ugly "hall of mirrors" effect.
A similar approach is used in the open source Inkscape, so I'm not doing
anything too dangerous here. However, this _is_ hacky in my opinion.
- Using memset() to zero out the memory of the OPENFILENAME structure.
This is safer than selectively setting fields on this structure. We no
longer need to explicity set certain field to NULL now.
- "all files" filter now lowercase to be consistent with other code.
These changes have been tested on Windows XP and Windows 7.
THIS COMMIT SHOULD BE MERGED INTO TRUNK AT SOME POINT!!!
rambetter [Thu, 16 Dec 2010 07:08:00 +0000 (07:08 +0000)]
Fixing the native Windows file dialog in Rametter-temp-fixes branch
of GtkRadiant. The previous code was Plain Old Wrong (TM) in the way that
it handled determining which "Save as type" was selected in the file save
dialog. This change affects the function file_dialog() in gtkmisc.cpp.
Fix has been tested on Windows 7 when the pattern input parameter is something
such as "map" and when it's null. Will test Windows XP shortly and follow
up with another commit if it's not working correctly there.
THIS COMMIT SHOULD BE MERGED INTO TRUNK AT SOME POINT!!!
rambetter [Wed, 15 Dec 2010 09:52:26 +0000 (09:52 +0000)]
Progressing on bringing Radiant 1.6.x to a workable state on Windows.
This commit:
1. Reverts to using GtkR-deps-1.6-3.zip (instead of GtkR-deps-1.6-4.zip).
Some font-related DLLs are therefore no longer used with this patch.
2. Because of the above #1, now using the really old OpenGL font rendering
code on Windows systems. This is controlled via "#ifdef _WIN32" blocks.
Linux still uses the new and improved OpenGL font rendering.
Note that this old font rendering that Windows now uses (err, has used in the
past too) makes use of gdk_gl_font_use_pango_font(), which is really old
and crufty.
So, with this commit Radiant is fully working (modulo bugs) on Linux and
Windows, and OpenGL fonts work too.
I WOULD NOT SUGGEST MERGING THIS CHANGE INTO TRUNK. THE CORRECT APPROACH
IS TO INSTEAD FIX THE DLL LIBRARY DEPENDENCIES IN TRUNK. I AM ONLY COMMITTING
THIS SO THAT I CAN CONTINUE FIXING BUGS IN RADIANT IN THE MEANTIME.
There are still a zillion bugs on Windows. For example, I can't even save
a .map file at this point. That is my next task, to fix saving of .map files.
rambetter [Wed, 15 Dec 2010 06:42:34 +0000 (06:42 +0000)]
Creating a temporary branch for Rambetter to use in order to
fix some outstanding issues while the lib-reassembly is taking place.
This branch is starting out as a copy of r347.
I [Rambetter] am not able to work on trunk at the moment because it
is broken on Windows due to the DLL nightmare that is going on. I would
like to fix some bugs in the meantime. Commits that should be imported back
into trunk will be clearly marked as such.
rambetter [Mon, 13 Dec 2010 04:50:40 +0000 (04:50 +0000)]
ixing a big problem on Windows platforms that has to do with copying over
game packs to the game install directory. Before this patch, users of
Radiant weren't able to start Radiant without doing some manual copying of
game pack files over by hand (and I'm sure nobody figured that out).
The problem is in radiant/missing.cpp. CopyTree() didn't correctly recursively
copy directories because of a problem in FindFiles::FindFiles() on Windows.
rambetter [Tue, 16 Nov 2010 07:07:28 +0000 (07:07 +0000)]
Doing away with the 32 bit per pixel memory buffer. Now passing the returned
pango memory buffer directly to OpenGL. This simplifies the code. Performance
did not seem to be better, but it certainly looks faster in theory.
rambetter [Tue, 16 Nov 2010 03:42:28 +0000 (03:42 +0000)]
DONE:
- Removed usage of gdk_gl_font_use_pango_font() which is no longer in
GtkGLExt Git. Radiant now compiles on Linux From Scratch using current
versions of software.
- As a side effect to the above, font inconsistency issues (like really
large intermittent font in GL views) are gone. Font looks better too.
- Changing algorithm for labeling grid view to be more robust. Uses new
functions gtk_glwidget_font_ascent() and gtk_glwidget_font_descent(), and
uses locally defined "cushion" variables.
- In xywindow.cpp, changing stepx and stepy based on 40 pixels, not 32.
When coordinate numbers are very large the labels get too cluttered.
- Added calls to gtk_gl_init() and gdk_gl_init() in main(). This is
recommended according to the GtkGLExt reference manual.
- Tested all changes on Ubuntu 10.10 and Debian 5.0 (Lenny).
TODO:
- In glDrawPixels(), instead of using a 32 bit pixel with
GL_UNSIGNED_INT_8_8_8_8, see if we can use an 8 bit variant where each
byte defines opacity and the GL current color is used. In other words, try
to use the FT_Bitmap directly without conversion.
- Examine every other use of gtk_glwidget_print_string() and
gtk_glwidget_print_char() to make sure the positions are determined
accurately.
NOT TODO:
- Decided not to use glBitmap() with display lists because it would
disallow pretty antialiased fonts.
rambetter [Sun, 14 Nov 2010 01:40:25 +0000 (01:40 +0000)]
In Radiant main() method, add putenv("LC_NUMERIC=C").
sscanf() and *printf() calls are all over the code, which are
locale-sensitive. gtk_init() sets all locales. So if you're in
Germany, your printf()'s will output e.g. "10,5" for ten and
a half. Reading floating points with sscanf() is also totally broken
in locales such as Germany. So, we can't really get rid of all the
*scanf()'s and the *printf()'s. Instead, set LC_NUMERIC to "C".
* applied patch by StefanV (from mailinglist) that fixes an error in config.py (broke compilation) and some string conversion warnings
* fixes some more string conversions warnings in bobtoolz
* fixed unresolved symbols in bobtoolz and gtkgensurf (due to the above mentioned patch where the prototypes were not updated)
ported over the 1.5 branch version of q3map2 which is newer
made Visual Studio files work in VS2005 Express
fixed a ton of warnings in VS2005 Express
fixed some compile problems on OpenSUSE 11.0
* divVerent's patch for the brush primitives surface dialog (fixed segfault due to NULL pointer)
* Quote http://zerowing.idsoftware.com/pipermail/gtkradiant/2008-July/011094.html : Attached to this message is a patch for a "somewhat working" brush
primitives surface dialog. It is an ugly hack, as it converts between
fake texdef notations and brush primitives whenever values are needed.
Had to fix an accuracy bug: the surface dialog rounded all rotation
values to integer angles, which SEVERELY broke things for me (changed
the Gtk spin object to use 4 digits, which is enough for me).
Also, I changed the fake texdef / brush primitives conversions to use
long double internally, as float's roundoff errors were quite visible to
me when testing.
Hope the remaining roundoff errors from converting back and forth won't
kill me, but it worked for a simple map example.
Also, I had to separate out "Snap to grid" and "Don't clamp" into two
separare options. They now mean:
- Snap to grid: snaps drag/etc. actions to the grid
- Don't clamp: disable brush point snapping during many operations, like
merely shifting brushes, editing texturing parameters, map loading,
etc.
The reason is that I do need the grid, but I don't want to get my
objects messed up by the snapping in my map. As I am using free
rotations, this DOES change quite much.
The config.py change is needed for compilation on Debian stable;
Debian's scons does not use the CFLAGS variable, but just CCFLAGS and
CXXFLAGS. In newer scons versions, CFLAGS is _shared_ flags for C and
C++, so if you want to require these, you don't need to include the
CFLAGS in CXXFLAGS too.
* removed a lot of HACKs for several games by merging the enginepath_win32, enginepath_linux and enginepath_macos from 1.5
to 1.6 (default for everything is quake3)
* removed the hacks for q2.game and heretic2.game (just check whether the game config value quake2 is set - TODO: game
dialog needs update - quake2 option should be given)
mattn [Fri, 27 Jun 2008 15:09:36 +0000 (15:09 +0000)]
* reactivated WXY_Print function to generate screenshots from the xy window
* removed all the references to the old bugzilla links (deadlinks - no longer useful)
mattn [Thu, 26 Jun 2008 11:21:13 +0000 (11:21 +0000)]
* fixed warnings
* removed www dir (dead links, almost none of the posted links are available - correct me when i'm wrong, then we can revert this remove)
projects / xonotic / netradiant.git / log