-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jeff Breidenbach a écrit :
>> 1) test the patch at home, to check it works
>
>
> The patch is preliminary and does NOT work well enough to commit. The
> hex tiling artifacts are unacceptable and I'd love to get an insight as
> to what might be causin
On Tue, Dec 13, 2005 at 05:15:16PM +0100, David Philippi wrote:
> Am Dienstag, den 13.12.2005, 17:08 +0100 schrieb Nils Kneuper:
> > It is mainly need on big screens and most users that
> > use big screens also do have rather fast machines. (>500MHz)
>
> Why not make it even simpler - only active
Am Dienstag, den 13.12.2005, 18:56 +0100 schrieb Isaac Clerencia:
> > Why not make it even simpler - only active it for a defined resolution
> > and above? I think everything beyond 1024x786 or even 800x600 may use
> > bilinear as it is unlikely that the user is running a very slow machine.
> It ma
On Tuesday, 13 December 2005 17:15, David Philippi wrote:
> Am Dienstag, den 13.12.2005, 17:08 +0100 schrieb Nils Kneuper:
> > It is mainly need on big screens and most users that
> > use big screens also do have rather fast machines. (>500MHz)
>
> Why not make it even simpler - only active it for
1) test the patch at home, to check it works
The patch is preliminary and does NOT work well enough to commit. The
hex tiling artifacts are unacceptable and I'd love to get an insight as
to what might be causing it.
--Jeff
I think this plan is fine with the caveat that since this might significantly
effect performance on low end machines, when you commit, make sure to email the
dev-list. It does point to the question of do we have any dedicated low-end
testers who can complain quickly if there is a performance hit?
> Hmm, maybe it would be possible to implement this via an option in the
> graphics menu? This way we would have no problem if it really is a
> little slower. It is mainly need on big screens and most users that
> use big screens also do have rather fast machines. (>500MHz)
> When we make it an opt
Am Dienstag, den 13.12.2005, 17:08 +0100 schrieb Nils Kneuper:
> It is mainly need on big screens and most users that
> use big screens also do have rather fast machines. (>500MHz)
Why not make it even simpler - only active it for a defined resolution
and above? I think everything beyond 1024x786
Hmm, maybe it would be possible to implement this via an option in the
graphics menu? This way we would have no problem if it really is a
little slower. It is mainly need on big screens and most users that
use big screens also do have rather fast machines. (>500MHz)
When we make it an option the us
On Tue, 13 Dec 2005 2:08 am, [EMAIL PROTECTED] wrote:
1) please patch against trunk, such a change will not go in the stable
branch
Ok
2) what is the performence hit of the patch ?
Unmeasured. My wimpy 1Ghz VIA CPU runs it ok even with compiler
optimization turned off.
3) please submit
>
> Here's a shorter implementation. I'm still confused
> as to what is causing the artifact on the hex tiles.
> Patch is against wesnoth 1.0.2.
>
I can't test the patch right now, just a couple of things
1) please patch against trunk, such a change will not go in the stable branch
2) what is the
Here's a shorter implementation. I'm still confused
as to what is causing the artifact on the hex tiles.
Patch is against wesnoth 1.0.2.
-Jeff
diff -u /ramdisk/home/knoppix/bar/wesnoth-1.0.2/src/sdl_utils.cpp.orig
/ramdisk/home/knoppix/bar/wesnoth-1.0.2/src/sdl_utils.cpp
--- /ramdisk/home/kno
12 matches
Mail list logo
