trunk. Branch Rambetter-math-fix-experiments can be deleted now.
git-svn-id: svn://svn.icculus.org/gtkradiant/GtkRadiant/trunk@417 8a3a26a2-13c4-0310-b231-cf6edde360e5
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.
git-svn-id: svn://svn.icculus.org/gtkradiant/GtkRadiant/trunk@416 8a3a26a2-13c4-0310-b231-cf6edde360e5
C:\MinGW, make sure there is no space in the path".
git-svn-id: svn://svn.icculus.org/gtkradiant/GtkRadiant/trunk@412 8a3a26a2-13c4-0310-b231-cf6edde360e5
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.
git-svn-id: svn://svn.icculus.org/gtkradiant/GtkRadiant/trunk@390 8a3a26a2-13c4-0310-b231-cf6edde360e5
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.
git-svn-id: svn://svn.icculus.org/gtkradiant/GtkRadiant/trunk@379 8a3a26a2-13c4-0310-b231-cf6edde360e5
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.
git-svn-id: svn://svn.icculus.org/gtkradiant/GtkRadiant/trunk@378 8a3a26a2-13c4-0310-b231-cf6edde360e5
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().
git-svn-id: svn://svn.icculus.org/gtkradiant/GtkRadiant/trunk@377 8a3a26a2-13c4-0310-b231-cf6edde360e5
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).
git-svn-id: svn://svn.icculus.org/gtkradiant/GtkRadiant/trunk@375 8a3a26a2-13c4-0310-b231-cf6edde360e5
poking around at the numbers from disappearing_sliver2.
git-svn-id: svn://svn.icculus.org/gtkradiant/GtkRadiant/trunk@374 8a3a26a2-13c4-0310-b231-cf6edde360e5
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.
git-svn-id: svn://svn.icculus.org/gtkradiant/GtkRadiant/trunk@371 8a3a26a2-13c4-0310-b231-cf6edde360e5
A regression test is included.
This is a bug in q3map2. Please read
regression_tests/q3map2/disappearing_sliver/README.txt for more info.
git-svn-id: svn://svn.icculus.org/gtkradiant/GtkRadiant/trunk@363 8a3a26a2-13c4-0310-b231-cf6edde360e5
Just some code maintenence. Like removing unused local vars.
PLS MERGE TO TRUNK.
git-svn-id: svn://svn.icculus.org/gtkradiant/GtkRadiant/branches/Rambetter-temp-fixes@356 8a3a26a2-13c4-0310-b231-cf6edde360e5
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.
THIS SHOULD BE MERGED INTO TRUNK.
git-svn-id: svn://svn.icculus.org/gtkradiant/GtkRadiant/branches/Rambetter-temp-fixes@355 8a3a26a2-13c4-0310-b231-cf6edde360e5
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.
PLEASE MERGE THIS TO TRUNK.
git-svn-id: svn://svn.icculus.org/gtkradiant/GtkRadiant/branches/Rambetter-temp-fixes@354 8a3a26a2-13c4-0310-b231-cf6edde360e5
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.
THIS PATCH SHOULD BE MERGED INTO TRUNK.
git-svn-id: svn://svn.icculus.org/gtkradiant/GtkRadiant/branches/Rambetter-temp-fixes@353 8a3a26a2-13c4-0310-b231-cf6edde360e5
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!!!
git-svn-id: svn://svn.icculus.org/gtkradiant/GtkRadiant/branches/Rambetter-temp-fixes@352 8a3a26a2-13c4-0310-b231-cf6edde360e5
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!!!
git-svn-id: svn://svn.icculus.org/gtkradiant/GtkRadiant/branches/Rambetter-temp-fixes@351 8a3a26a2-13c4-0310-b231-cf6edde360e5
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.
git-svn-id: svn://svn.icculus.org/gtkradiant/GtkRadiant/branches/Rambetter-temp-fixes@350 8a3a26a2-13c4-0310-b231-cf6edde360e5
So, this branch is now r344 with patch r346.
DO NOT MERGE THIS CHANGE INTO TRUNK!!!!
git-svn-id: svn://svn.icculus.org/gtkradiant/GtkRadiant/branches/Rambetter-temp-fixes@349 8a3a26a2-13c4-0310-b231-cf6edde360e5
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.
git-svn-id: svn://svn.icculus.org/gtkradiant/GtkRadiant/branches/Rambetter-temp-fixes@348 8a3a26a2-13c4-0310-b231-cf6edde360e5
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.
git-svn-id: svn://svn.icculus.org/gtkradiant/GtkRadiant/trunk@346 8a3a26a2-13c4-0310-b231-cf6edde360e5
fixed/optimized a number of VC9 project settings
fixed sprintf being hijacked by intl.dll stuff
git-svn-id: svn://svn.icculus.org/gtkradiant/GtkRadiant/trunk@345 8a3a26a2-13c4-0310-b231-cf6edde360e5
pango memory buffer directly to OpenGL. This simplifies the code. Performance
did not seem to be better, but it certainly looks faster in theory.
git-svn-id: svn://svn.icculus.org/gtkradiant/GtkRadiant/trunk@336 8a3a26a2-13c4-0310-b231-cf6edde360e5
- 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.
git-svn-id: svn://svn.icculus.org/gtkradiant/GtkRadiant/trunk@335 8a3a26a2-13c4-0310-b231-cf6edde360e5
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".
git-svn-id: svn://svn.icculus.org/gtkradiant/GtkRadiant/trunk@334 8a3a26a2-13c4-0310-b231-cf6edde360e5
