Ben Noordhuis [Sun, 18 Mar 2012 01:02:48 +0000 (02:02 +0100)]
q3map2: bump MAX_OS_PATH to 4096
Fixes a "buffer overflow detected" abort when compiled with _FORTIFY_SOURCE=1.
The realpath(3) function in glibc checks if the destination buffer is large
enough to hold up to PATH_MAX characters and aborts if that is not the case.
PATH_MAX doesn't have to be defined so assume that it's equal to 4096.
We should really be using pathconf(_PC_PATH_MAX) instead of a hard-coded value
but that means we can no longer use static buffers to hold paths.
rambetter [Tue, 14 Feb 2012 18:31:09 +0000 (18:31 +0000)]
Switching order of picoModuleLWO and picoModuleOBJ as a quick
and dirty workaround to problems in libs/picomodel/pm_obj.c which
passes files that aren't Wavefront ASCII.
Removing optimization GCC flags because q3map2 crashes on Ubuntu 10.10 32 bit,
ever since certain updates in that distribution. This fixes the q3map2 crash,
but no more optimizations.
rambetter [Sun, 6 Mar 2011 19:14:50 +0000 (19:14 +0000)]
Fixing a Sys_Printf() in main() for "q3map2 -convert". The usage message was
copied from "-scale" and was incorrect. Thanks to Ensiform from ioquake3 IRC
room for reporting this bug.
rambetter [Thu, 3 Mar 2011 15:51:44 +0000 (15:51 +0000)]
- Updated Windows build doc, very slight revision. Changed 37 targets to 38.
- Added plugins/imagehl to list of modules built (both Windows and Linux).
Not really sure what this does, but it's the only module (as defined by
stuff in plugins/ or contrib/) that exists and isn't currently part of the
build.
- The code to disable desktop composition in Windows has been moved from start
of main() to an option in Preferences. The pref reads as follows:
"NVIDIA/Aero bug - disable Windows composition". It is enabled by default.
- Color themes controlled by "Misc" -> "Colors" -> "Themes" options are now
saved as soon as you select them. The color theme is no longer clobbered
when opening Preferences.
- The ATI broken driver (bug #802) pref has been reworded since it applies to
Intel cards as well. Before:
"ATI cards with broken drivers - bug #802". After:
"ATI and Intel cards w/ buggy drivers (disappearing polygons)".
rambetter [Thu, 24 Feb 2011 03:53:03 +0000 (03:53 +0000)]
The release config for radiant target was busted on Linux in SCons build.
Problem was that the compile flags were overly aggressive and caused segfaults.
They included: -O3 -Winline -ffast-math -fno-unsafe-math-optimizations
-fno-strict-aliasing
Changed to: -O2 -fno-strict-aliasing
From my experience, -O3 is usually a bad idea.
rambetter [Mon, 21 Feb 2011 14:37:49 +0000 (14:37 +0000)]
This is a major change that updates the 3rd party libs on Windows builds.
A couple of things are broken right now:
- OpenGL font in Windows not appearing (expected to be broken, will fix)
- Linux build broken because it loads some .vcproj files that are removed
- 3rd party libs are downloaded from porky.nerius.com, not id Software
rambetter [Sun, 23 Jan 2011 05:24:30 +0000 (05:24 +0000)]
Adding "Preferences" -> "Other" -> "Brush" tab. This now has
"Default texture scale:". (Preferences are game specific by the way.)
The default value for this preference is specific to a game, but most
of the time it's 0.5. This field allows the user to override that default.
This is a feature that was specifically requrested by someone who wants to
try using ZeroRadiant (he wants to set it to 0.25 for his "premium" maps).
It's already a feature in NetRadiant.
rambetter [Sat, 22 Jan 2011 07:10:03 +0000 (07:10 +0000)]
No longer including JAPack in default Radiant builds. This is in order
to reduce the size of Windows Radiant builds by a factor of 2. JAPack
can still be used, but must either be installed manually after a build
is made, or it must be explicitly downloaded before the build.
rambetter [Sat, 22 Jan 2011 07:03:51 +0000 (07:03 +0000)]
Modifying game_reaction.h (for the game Reaction) to add custom surfaces.
This is more convenient than using custinfoparms.txt. TTI (from the
Reaction team) game these to me.
rambetter [Sat, 22 Jan 2011 03:22:21 +0000 (03:22 +0000)]
Turn off desktop compositing in Windows ("Aero") for Radiant.
Otherwise, "hall of mirrors" effect takes place in the OpenGL viewports.
This fix is a real hack. It's actually borrowed from other Radiants such
as NetRadiant. I'd like to fix the underlying issue someday so that Aero
can be used with Radiant.
rambetter [Wed, 19 Jan 2011 06:41:33 +0000 (06:41 +0000)]
Fixing a 45 degree model clipping problem.
Introducing Q3MAP2_EXPERIMENTAL_MODEL_CLIPPING_FIX to control the new code,
current value is 1 (enable the fix).
This code fixes the q3map2 regression test model_clipping_45_degrees.
rambetter [Wed, 12 Jan 2011 08:33:40 +0000 (08:33 +0000)]
In decal_misalignment regression test for q3map2, accidentally had checked in
the wrong shader file, ramb_common.shader. Replacing with
radiant_regression_tests.shader.
rambetter [Wed, 12 Jan 2011 03:35:57 +0000 (03:35 +0000)]
Adding MATHLIB_VECTOR_NORMALIZE_PRECISION_FIX in mathlib to control which
version of code in VectorNormalize() is used. Yes, I put the old code back
in there, and it's active if MATHLIB_VECTOR_NORMALIZE_PRECISION_FIX is 0.
Right now it's 1, so the fixed code is active. I need this quick way to
test regression tests.
rambetter [Tue, 11 Jan 2011 09:49:45 +0000 (09:49 +0000)]
Increasing the values of 3 constants that control how much space is reserved
for the stack and/or static memory for holding arrays of structures.
MAX_ORIGINAL_EDGES changed from 0x10000 to 0x20000 (x2 increase).
MAX_MAP_BRUSHES changed from 0x8000 to 0x10000 (x2 increase).
MAX_MAP_DRAW_VERTS changed from 0x80000 to 0x100000 (x2 increase).
This is pertaining to q3map2 only.
There is a real-world case where increasing these constants is needed.
That case is when compiling Icy World for Urban Terror.
Besides that, increasing these does not hurt anything (other than requiring
more memory).
rambetter [Tue, 11 Jan 2011 08:25:10 +0000 (08:25 +0000)]
As per TTimo's suggestion, turning all three experimental q3map2 fixes on
in q3map2.h: EXPERIMENTAL_HIGH_PRECISION_MATH_Q3MAP2_FIXES,
EXPERIMENTAL_SNAP_NORMAL_FIX, and EXPERIMENTAL_SNAP_PLANE_FIX. These are all
set to 1 now.
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.
projects / xonotic / netradiant.git / log