Re: [Warzone-dev] shapened textures

2007-02-11 Thread The Watermelon

On 2/11/07, Dennis Schridde <[EMAIL PROTECTED]> wrote:


Am Sonntag, 11. Februar 2007 schrieb The Watermelon:
>  yes I know the texture 'quality' makes no difference in memory as long
as
> the total number of bits are changed,it's just weird WZ render lags the
> overall performance in the areas where you least expected:
>
> 1.the matrix multiplications' performance impact is minor(probably 5%
fps
> drop) with 'drawshadow' function disabled(the one actually draws the
> shapes,not the ones doing matrix stuff)
> 2.after some simple 'vertex3f to color3f' tests,it turns out that the
poor
> performance is geometry limited...really odd it could be geometry
limited
> with wz's low polygons...
> 3.cpu usage by renderer is pretty high too,it always gives you
unacceptable
> fps and 100% cpu usage for 1Ghz or lesser,100% cpu and acceptable fps
for
> 1Ghz - 1.5Ghz,80% or so cpu for 2 - 3Ghz or AMD equivalent...consider
the
> old one can run happily on a 500-1000Mhz from what I heard and I dont
think
> changing software/d3d renderer to opengl will up the cpu
> requirements(actually changing software to opengl should reduce cpu
burden
> imo...)...
> 4.changing texture affects performance...
> 5.wondering why there are no inline function in piedraw.c...
1: You disabled what? The matrix calculations or the draw functions?
The problem with the shadows is afaik that it does poping/pushing of
matrices
and that it does that very often. This probably stresses the bus a lot.
2/3: This is very probably caused by immediate-mode drawing. I talked to a
friend a while ago and he told me that he did some benchmarking (in his
own
engine):
In immediate-mode he could reach 80k vertices in 100fps.
Using VBOs he reached the maximum his card supported (4m vertices) with
about
the same fps.
4: I don't have the profiling I did with gDEBugger at hand, but I think
the
texture changing did harm performance a lot. Probably again because it
stresses the bus and CPU.

--Dennis



1.I disabled the drawshadow(the one draws the shadowcasting shapes like
piePolygon function),
'drawshadows' is the one enable/disable stencil buffer and doing all those
matrix multiplications and identify reloads,which is untouched during the
tests.
2/3.I dont think wz even has 80k vertices concurrently on screen...
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev


Re: [Warzone-dev] shapened textures

2007-02-11 Thread Dennis Schridde
Am Sonntag, 11. Februar 2007 schrieb The Watermelon:
>  yes I know the texture 'quality' makes no difference in memory as long as
> the total number of bits are changed,it's just weird WZ render lags the
> overall performance in the areas where you least expected:
>
> 1.the matrix multiplications' performance impact is minor(probably 5% fps
> drop) with 'drawshadow' function disabled(the one actually draws the
> shapes,not the ones doing matrix stuff)
> 2.after some simple 'vertex3f to color3f' tests,it turns out that the poor
> performance is geometry limited...really odd it could be geometry limited
> with wz's low polygons...
> 3.cpu usage by renderer is pretty high too,it always gives you unacceptable
> fps and 100% cpu usage for 1Ghz or lesser,100% cpu and acceptable fps for
> 1Ghz - 1.5Ghz,80% or so cpu for 2 - 3Ghz or AMD equivalent...consider the
> old one can run happily on a 500-1000Mhz from what I heard and I dont think
> changing software/d3d renderer to opengl will up the cpu
> requirements(actually changing software to opengl should reduce cpu burden
> imo...)...
> 4.changing texture affects performance...
> 5.wondering why there are no inline function in piedraw.c...
1: You disabled what? The matrix calculations or the draw functions?
The problem with the shadows is afaik that it does poping/pushing of matrices 
and that it does that very often. This probably stresses the bus a lot.
2/3: This is very probably caused by immediate-mode drawing. I talked to a 
friend a while ago and he told me that he did some benchmarking (in his own 
engine):
In immediate-mode he could reach 80k vertices in 100fps.
Using VBOs he reached the maximum his card supported (4m vertices) with about 
the same fps.
4: I don't have the profiling I did with gDEBugger at hand, but I think the 
texture changing did harm performance a lot. Probably again because it 
stresses the bus and CPU.

--Dennis


pgpdiYEXS4n5F.pgp
Description: PGP signature
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev


Re: [Warzone-dev] shapened textures

2007-02-11 Thread Dennis Schridde
Am Sonntag, 11. Februar 2007 schrieb Linas Žvirblis:
> The Watermelon wrote:
> > yes I know the texture 'quality' makes no difference in memory as long as
> > the total number of bits are changed,it's just weird WZ render lags the
> > overall performance in the areas where you least expected:
>
> Maybe this has something to do with the increased number of individual
> colors in the texture? Although it should not matter much if the bit
> depth remains the same, so just a wild guess...
>
> Are you sure you save the textures in the same bit-depth? (I could not
> check that, because the file storage site told me to wait an hour before
> downloading) You could try replacing textures with solid color blocks,
> and again with gradients, and compare the performance.
They are allways loaded as 32bit RGBA... If the file would have a different 
bit depth, you would see that immediately, as it would look "funny".


pgpDBqOrmytIi.pgp
Description: PGP signature
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev


Re: [Warzone-dev] shapened textures

2007-02-11 Thread The Watermelon

On 2/11/07, Linas Žvirblis <[EMAIL PROTECTED]> wrote:


Maybe this has something to do with the increased number of individual
colors in the texture? Although it should not matter much if the bit
depth remains the same, so just a wild guess...

Are you sure you save the textures in the same bit-depth? (I could not
check that, because the file storage site told me to wait an hour before
downloading) You could try replacing textures with solid color blocks,
and again with gradients, and compare the performance.

Disclaimer: I am not that well familiar with how things work in WZ.


sry for uploading to that weird site,but other sites just failed due to my
borked internet(corrupted file/got rejected after finishing uploading)

the depth is converted to 32bit according to the png read function,so I dont
think the depth is the problem


On 2/11/07, Per Inge Mathisen <[EMAIL PROTECTED]> wrote:


The only thing I can think of would be that sharpened images are less
amenable to texture compression (I do not know if that is true - it is
just a conjecture), and the textures take more space in the GPU cache
or need to be swapped out. How much GPU RAM do you have?

We do not currently request texture compression, but I guess cards may
do a little bit compression anyway. I heard they do really strange
things to textures in GPU memory.

Anyway, this got me inspired to port over some code I wrote for
another project that adds OpenGL texture compression, if available.
This gave me *much* slower loading times, around 20x slower, and FPS
was about 40% slower as well. So as I suspected earlier, texture
compression does not give us anything useful at the moment (although
granted, the patch is a hack and not optimal in any way). It is
attached if you want to play with it (but note that backdrops do not
work, maybe because I added alpha channel to them?).

- Per


I have 64mb video mem,maybe that is not sufficient to store all texture
png's(12MB compressed),though I think most games' texture will always exceed
the limits of vram,they just store all textures in system memory(unlike
wz,loads all textures into vram) and fetch the needed ones from system
memory when rendering scene.
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev


Re: [Warzone-dev] shapened textures

2007-02-11 Thread Per Inge Mathisen

The only thing I can think of would be that sharpened images are less
amenable to texture compression (I do not know if that is true - it is
just a conjecture), and the textures take more space in the GPU cache
or need to be swapped out. How much GPU RAM do you have?

We do not currently request texture compression, but I guess cards may
do a little bit compression anyway. I heard they do really strange
things to textures in GPU memory.

Anyway, this got me inspired to port over some code I wrote for
another project that adds OpenGL texture compression, if available.
This gave me *much* slower loading times, around 20x slower, and FPS
was about 40% slower as well. So as I suspected earlier, texture
compression does not give us anything useful at the moment (although
granted, the patch is a hack and not optimal in any way). It is
attached if you want to play with it (but note that backdrops do not
work, maybe because I added alpha channel to them?).

 - Per
Index: lib/ivis_opengl/tex.c
===
--- lib/ivis_opengl/tex.c	(revision 697)
+++ lib/ivis_opengl/tex.c	(working copy)
@@ -41,6 +41,8 @@
 #include "lib/ivis_common/bug.h"
 #include "lib/ivis_common/ivispatch.h"
 
+#include "screen.h"
+
 //*
 
 iTexPage _TEX_PAGE[iV_TEX_MAX];
@@ -120,7 +122,7 @@
 
 	if (   (s->width & (s->width-1)) == 0
 	&& (s->height & (s->height-1)) == 0) {
-		gluBuild2DMipmaps(GL_TEXTURE_2D, GL_RGBA, s->width, s->height,
+		gluBuild2DMipmaps(GL_TEXTURE_2D, wz_texture_compression, s->width, s->height,
 			 GL_RGBA, GL_UNSIGNED_BYTE, s->bmp);
 	} else {
 		debug(LOG_TEXTURE, "pie_AddBMPtoTexPages: non POT texture %s", filename);
Index: lib/ivis_opengl/pieblitfunc.c
===
--- lib/ivis_opengl/pieblitfunc.c	(revision 697)
+++ lib/ivis_opengl/pieblitfunc.c	(working copy)
@@ -478,7 +478,7 @@
 		}
 	}
 	pie_SetTexturePage(radarTexture);
-	glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, 128, 128, 0,
+	glTexImage2D(GL_TEXTURE_2D, 0, wz_texture_compression, 128, 128, 0,
 		 GL_RGBA, GL_UNSIGNED_BYTE, radarBitmap);
 	glTexEnvf(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_MODULATE);
 	glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);
Index: lib/ivis_opengl/screen.c
===
--- lib/ivis_opengl/screen.c	(revision 697)
+++ lib/ivis_opengl/screen.c	(working copy)
@@ -32,10 +32,6 @@
 #include 
 #include 
 #include 
-#ifdef _MSC_VER
-#include   //needed for gl.h!  --Qamly
-#endif
-#include 
 #ifdef __cplusplus
 extern "C" {
 #endif
@@ -63,6 +59,9 @@
 
 SDL_Surface *screen;
 
+/* global used to indicate preferred internal OpenGL format */
+GLint wz_texture_compression;
+
 //backDrop
 #define BACKDROP_WIDTH	640
 #define BACKDROP_HEIGHT	480
@@ -93,7 +92,8 @@
 			)
 {
 	static int video_flags = 0;
-	int bpp = 0;
+	int bpp = 0, value;
+	GLint glval;
 
 	/* Store the screen information */
 	screenWidth = width;
@@ -174,6 +174,12 @@
 		debug( LOG_ERROR, "Error: SDL_SetVideoMode failed (%s).\n", SDL_GetError() );
 		return FALSE;
 	}
+	if (SDL_GL_GetAttribute(SDL_GL_DOUBLEBUFFER, &value) == -1) 
+	{
+		debug(LOG_ERROR, "OpenGL initialization did not give double buffering!\n");
+	}
+	glGetIntegerv(GL_MAX_TEXTURE_SIZE, &glval);
+	debug(LOG_TEXTURE, "Maximum texture size: %dx%d", (int)glval, (int)glval);
 
 	glViewport(0, 0, width, height);
 	glMatrixMode(GL_PROJECTION);
@@ -378,7 +384,7 @@
 
 		pie_SetTexturePage(-1);
 		glBindTexture(GL_TEXTURE_2D, texture);
-		glTexImage2D(GL_TEXTURE_2D, 0, GL_RGB,
+		glTexImage2D(GL_TEXTURE_2D, 0, wz_texture_compression,
 			 image.width, image.height,
 			 0, GL_RGB, GL_UNSIGNED_BYTE, image.data);
 		glTexEnvf(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_MODULATE);
@@ -408,7 +414,7 @@
 
 		pie_SetTexturePage(-1);
 		glBindTexture(GL_TEXTURE_2D, backDropTexture);
-		glTexImage2D(GL_TEXTURE_2D, 0, GL_RGB,
+		glTexImage2D(GL_TEXTURE_2D, 0, wz_texture_compression,
 			 image.width, image.height,
 			 0, GL_RGB, GL_UNSIGNED_BYTE, image.data);
 		glTexEnvf(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_MODULATE);
@@ -446,7 +452,7 @@
 	glGenTextures(1, &backDropTexture);
 	pie_SetTexturePage(-1);
 	glBindTexture(GL_TEXTURE_2D, backDropTexture);
-	glTexImage2D(GL_TEXTURE_2D, 0, GL_RGB,
+	glTexImage2D(GL_TEXTURE_2D, 0, wz_texture_compression,
 		   512,512,//backDropWidth, backDropHeight,
 			0, GL_RGB, GL_UNSIGNED_BYTE, newBackDropBmp);
 
Index: lib/ivis_opengl/piemode.c
===
--- lib/ivis_opengl/piemode.c	(revision 697)
+++ lib/ivis_opengl/piemode.c	(working copy)
@@ -49,6 +49,7 @@
  */
 /***/
 #define DIVIDE_TABLE_SIZE		1024
+
 /***/
 /*
  *	Local Variables

Re: [Warzone-dev] shapened textures

2007-02-11 Thread Linas Žvirblis
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

The Watermelon wrote:

> yes I know the texture 'quality' makes no difference in memory as long as
> the total number of bits are changed,it's just weird WZ render lags the
> overall performance in the areas where you least expected:

Maybe this has something to do with the increased number of individual
colors in the texture? Although it should not matter much if the bit
depth remains the same, so just a wild guess...

Are you sure you save the textures in the same bit-depth? (I could not
check that, because the file storage site told me to wait an hour before
downloading) You could try replacing textures with solid color blocks,
and again with gradients, and compare the performance.

Disclaimer: I am not that well familiar with how things work in WZ.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFFzx5dztOe9mov/y4RAqS/AJ49ic5LuneJZYvYjgGR0MrKvyfDZQCfW8yk
1Qc1xIosXE+BX7Gy/KYJbYk=
=vCqm
-END PGP SIGNATURE-

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev


Re: [Warzone-dev] shapened textures

2007-02-11 Thread The Watermelon

yes I know the texture 'quality' makes no difference in memory as long as
the total number of bits are changed,it's just weird WZ render lags the
overall performance in the areas where you least expected:

1.the matrix multiplications' performance impact is minor(probably 5% fps
drop) with 'drawshadow' function disabled(the one actually draws the
shapes,not the ones doing matrix stuff)
2.after some simple 'vertex3f to color3f' tests,it turns out that the poor
performance is geometry limited...really odd it could be geometry limited
with wz's low polygons...
3.cpu usage by renderer is pretty high too,it always gives you unacceptable
fps and 100% cpu usage for 1Ghz or lesser,100% cpu and acceptable fps for
1Ghz - 1.5Ghz,80% or so cpu for 2 - 3Ghz or AMD equivalent...consider the
old one can run happily on a 500-1000Mhz from what I heard and I dont think
changing software/d3d renderer to opengl will up the cpu
requirements(actually changing software to opengl should reduce cpu burden
imo...)...
4.changing texture affects performance...
5.wondering why there are no inline function in piedraw.c...

sorry for the slow reply,was uploading the changed png's at 12KB/s...

http://rapidshare.com/files/16002859/tex.zip.html
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev


Re: [Warzone-dev] shapened textures

2007-02-11 Thread Giel van Schijndel
Dennis Schridde schreef:
> Am Sonntag, 11. Februar 2007 schrieb The Watermelon:
>   
>> On 2/10/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>> 
>>> On Sat, 10 Feb 2007 15:51:59 -0500 The Watermelon
>>>
>>> <[EMAIL PROTECTED]> wrote:
>>>   
 I noticed the textures in wz are abit 'blur',so I tried to sharpen
 texture
 png's with gimp's sharpen filter,it does look a bit better but it
 also runs
 significantly slower on my pc =(
 
>>> Why would run slower?  You can change different texture file, and
>>> still same speed, since nothing really change?
>>> Or you mean you doing sharpen in wz code?
>>>   
>> no I meant shapened png's using gimp,dont know why it became slower with
>> bigger(the png filesize increased 10% or so after applying gimp's sharpen
>> filter) png files,maybe the problem has something to do with wz's frequent
>> texture changing and 'slicing'(separate tileset texture page into several
>> pieces etc)
>> 
> Currently I also think like "this can't be"...
> Because the underlying bitmap is still the same size, no matter what you do 
> with the pixels in it. And OpenGL only has the bitmap, it never sees the png 
> data... AFAIK WZ only decompresses the png once and then passes it to GL. I 
> don't think it reloads the textures during the game.
> Maybe you can find out what made it slower..
Even if WZ where to decompress the PNGs multiple times that wouldn't
explain a 10% FPS drop (or more) for a 10% filesize increase. This since
libpng's operation is not linear to compressed data size. I.e. it isn't
O(n) and most certainly not O(n*n), it instead is O( log n ) which means
that it could barely have a noticeable impact on speed. So if the
resolution of the image hasn't changed I must say I find this to be very
strange indeed.

-- 
Giel



signature.asc
Description: OpenPGP digital signature
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev


Re: [Warzone-dev] shapened textures

2007-02-11 Thread Dennis Schridde
Am Sonntag, 11. Februar 2007 schrieb The Watermelon:
> On 2/10/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > On Sat, 10 Feb 2007 15:51:59 -0500 The Watermelon
> >
> > <[EMAIL PROTECTED]> wrote:
> > >I noticed the textures in wz are abit 'blur',so I tried to sharpen
> > >texture
> > >png's with gimp's sharpen filter,it does look a bit better but it
> > >also runs
> > >significantly slower on my pc =(
> >
> > Why would run slower?  You can change different texture file, and
> > still same speed, since nothing really change?
> > Or you mean you doing sharpen in wz code?
>
> no I meant shapened png's using gimp,dont know why it became slower with
> bigger(the png filesize increased 10% or so after applying gimp's sharpen
> filter) png files,maybe the problem has something to do with wz's frequent
> texture changing and 'slicing'(separate tileset texture page into several
> pieces etc)
Currently I also think like "this can't be"...
Because the underlying bitmap is still the same size, no matter what you do 
with the pixels in it. And OpenGL only has the bitmap, it never sees the png 
data... AFAIK WZ only decompresses the png once and then passes it to GL. I 
don't think it reloads the textures during the game.
Maybe you can find out what made it slower...

--Dennis


pgpgfL8ZOcYdX.pgp
Description: PGP signature
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev


Re: [Warzone-dev] shapened textures

2007-02-11 Thread The Watermelon

On 2/10/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:


On Sat, 10 Feb 2007 15:51:59 -0500 The Watermelon
<[EMAIL PROTECTED]> wrote:
>I noticed the textures in wz are abit 'blur',so I tried to sharpen
>texture
>png's with gimp's sharpen filter,it does look a bit better but it
>also runs
>significantly slower on my pc =(
>
Why would run slower?  You can change different texture file, and
still same speed, since nothing really change?
Or you mean you doing sharpen in wz code?



no I meant shapened png's using gimp,dont know why it became slower with
bigger(the png filesize increased 10% or so after applying gimp's sharpen
filter) png files,maybe the problem has something to do with wz's frequent
texture changing and 'slicing'(separate tileset texture page into several
pieces etc)
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev


Re: [Warzone-dev] shapened textures

2007-02-10 Thread vs2k5
On Sat, 10 Feb 2007 15:51:59 -0500 The Watermelon 
<[EMAIL PROTECTED]> wrote:
>I noticed the textures in wz are abit 'blur',so I tried to sharpen 
>texture
>png's with gimp's sharpen filter,it does look a bit better but it 
>also runs
>significantly slower on my pc =(
>
Why would run slower?  You can change different texture file, and 
still same speed, since nothing really change?
Or you mean you doing sharpen in wz code?




--
Online Business & MBA Degrees
Find online business degrees from accredited colleges. Browse subjects
http://tagline.hushmail.com/fc/MhtZOXMDk79i6bq8px0FExlbVlYTbRa7rPIJE/


___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev