[Warzone-dev] [patch #1103] Cleanup of buildStructure

[Per I. Mathisen]

URL:
  

 Summary: Cleanup of buildStructure
 Project: Warzone Resurrection Project
Submitted by: per
Submitted on: Sunday 09/07/2008 at 10:02
Category: None
Priority: 5 - Normal
  Status: Works For Me
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: None

___

Details:

Cosmetic only.



___

File Attachments:


---
Date: Sunday 09/07/2008 at 10:02  Name: buildStructure.diff  Size: 5kB   By:
per



___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


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

Re: [Warzone-dev] Barrier Intel GMA

[Dennis Schridde]

On Sunday 07 September 2008 13:28:45 Kamaze wrote:
> Looks like a stuck situation, at least for the renderer. Does someone
> already have some ideas for the future? Different rendering parts to
> stay GMA compatible or breaking GMA support some day?
Can you get a bit more specific please?
What exactly is broken about rendering on Intel chips?

--Devurandom


signature.asc
Description: This is a digitally signed message part.
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

[Warzone-dev] Barrier Intel GMA

[Kamaze]

Looks like a stuck situation, at least for the renderer. Does someone
already have some ideas for the future? Different rendering parts to
stay GMA compatible or breaking GMA support some day?

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

Re: [Warzone-dev] Barrier Intel GMA

[Kamaze]

Whops, i git lost while writing. I talked with EvilGuru in IRC about
using VBO and such things for Warzone. Well, these feature for example
was introduces with OpenGL 1.5 while most GMA Chips only support OpenGL
1.4.

If I remember right, Per has a GMA 950, so if there would be some
serious use of VBO (for example) he would be locked out, as well as
other player.

So, my question is how to "solve" this "issue". Stucking forever for
OpenGL 1.4 sounds somehow bad :(

Dennis Schridde schrieb:
> On Sunday 07 September 2008 13:28:45 Kamaze wrote:
> Can you get a bit more specific please?
> What exactly is broken about rendering on Intel chips?
> 
> --Devurandom
> 
> 
> 
> 
> ___
> Warzone-dev mailing list
> Warzone-dev@gna.org
> https://mail.gna.org/listinfo/warzone-dev

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

Re: [Warzone-dev] Barrier Intel GMA

[Kamaze]

Please forgive me for the poor spelling...
Some people annoy me currently at home >:(

--
Kamaze

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

Re: [Warzone-dev] Barrier Intel GMA

[Giel van Schijndel]

Kamaze schreef:
> Dennis Schridde schrieb:
>> On Sunday 07 September 2008 13:28:45 Kamaze wrote:
>> Can you get a bit more specific please?
>> What exactly is broken about rendering on Intel chips?
> 
> Whops, i git lost while writing. I talked with EvilGuru in IRC about
> using VBO and such things for Warzone. Well, these feature for example
> was introduces with OpenGL 1.5 while most GMA Chips only support OpenGL
> 1.4.
> 
> If I remember right, Per has a GMA 950, so if there would be some
> serious use of VBO (for example) he would be locked out, as well as
> other player.

Instead of VBOs we can use VAs if VBOs aren't available. Drawing with
VAs is (codewise) nearly the same as using VBOs and VAs are available in
OpenGL 1.1.

> So, my question is how to "solve" this "issue". Stucking forever for
> OpenGL 1.4 sounds somehow bad :(

There is no issue...

PS Please don't top-post.

-- 
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] Barrier Intel GMA

[Freddie Witherden]

Hi Dennis,

On 7 Sep 2008, at 13:17, Dennis Schridde wrote:
> On Sunday 07 September 2008 13:28:45 Kamaze wrote:
>> Looks like a stuck situation, at least for the renderer. Does someone
>> already have some ideas for the future? Different rendering parts to
>> stay GMA compatible or breaking GMA support some day?
> Can you get a bit more specific please?
> What exactly is broken about rendering on Intel chips?

More the drivers; modern Intel chips are quite capable (the X3100 in  
my Macbook, and by extension the X3000 have reasonable support for  
modern OpenGL extensions). (Although performance is another issue.)

The main issue is with their poor driver support on Linux and Windows.  
They claim to support framebuffer objects (but don't actually) —  
resulting in us having to workaround it ourself. No VBO support is  
another issue, even through it could be emulated should the card  
provide no real support for it. Most do not support fragment or vertex  
shaders.

On the Windows side of things some of their chips have been shipping  
without support for age-old extensions such as  
GL_ARB_texture_rectangle, again things that are easy to emulate should  
there be no hardware support (just pad the texture with transparent  
pixels until it is power-of-two).

The lack of FBO and VBO support is the main issue — down to nothing  
more than poor drivers. It is very hard to design a chip that does not  
support them [1] yet there is no driver support. This is poor,  
considering render-to-text has been part of DirectX (SetRenderTarget)  
since its inception and therefore has near perfect hardware support.  
VBOs, as I have already mentioned can be emulated if need be.

The lack of FBO support is something of a thorn in betawidgets side —  
having buttons with things such as rotating models becomes quite  
difficult.

Regards, Freddie.

[1] http://lists.freedesktop.org/archives/xorg/2008-May/034844.html
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Re: [Warzone-dev] Barrier Intel GMA

[Per Inge Mathisen]

Attached is a patch to remove the need for GL_ARB_texture_rectangle
for the radar code. I suppose a similar approach could be used for
betawidget. The complexity of manipulating texture coordinates can be
hidden by an abstraction layer.

  - Per
Index: lib/ivis_opengl/pieblitfunc.c
===
--- lib/ivis_opengl/pieblitfunc.c	(revision 5946)
+++ lib/ivis_opengl/pieblitfunc.c	(working copy)
@@ -55,6 +55,7 @@
 
 static GLuint radarTexture;
 static GLuint radarSizeX, radarSizeY;
+static GLfloat radarTexX, radarTexY;
 
 /***/
 /*
@@ -302,54 +303,45 @@
 	return true;
 }
 
+/** Store radar texture with given width and height. */
 void pie_DownLoadRadar(UDWORD *buffer, int width, int height)
 {
-	if (!GLEE_ARB_texture_rectangle)
-	{
-		return;
-	}
+	int w = 1, h = 1;
+
+	/* Find power of two size */
+	while (width > (w *= 2));
+	while (height > (h *= 2));
+
 	pie_SetTexturePage(radarTexture);
-	glDisable(GL_TEXTURE_2D);
-	glEnable(GL_TEXTURE_RECTANGLE_ARB);
-	glBindTexture(GL_TEXTURE_RECTANGLE_ARB, _TEX_PAGE[radarTexture].id);
-	glTexImage2D(GL_TEXTURE_RECTANGLE_ARB, 0, wz_texture_compression, width, height, 0,
-		 GL_RGBA, GL_UNSIGNED_BYTE, buffer);
+	glBindTexture(GL_TEXTURE_2D, _TEX_PAGE[radarTexture].id);
+	glTexImage2D(GL_TEXTURE_2D, 0, wz_texture_compression, w, h, 0, GL_RGBA, GL_UNSIGNED_BYTE, NULL);
+	glTexSubImage2D(GL_TEXTURE_2D, 0, 0, 0, width, height, GL_RGBA, GL_UNSIGNED_BYTE, buffer);
 	glTexEnvf(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_MODULATE);
-	glTexParameteri(GL_TEXTURE_RECTANGLE_ARB, GL_TEXTURE_MIN_FILTER, GL_LINEAR);
-	glTexParameteri(GL_TEXTURE_RECTANGLE_ARB, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
-	glTexParameteri(GL_TEXTURE_RECTANGLE_ARB, GL_TEXTURE_WRAP_S, GL_CLAMP);
-	glTexParameteri(GL_TEXTURE_RECTANGLE_ARB, GL_TEXTURE_WRAP_T, GL_CLAMP);
+	glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);
+	glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
+	glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP);
+	glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP);
 	radarSizeX = width;
 	radarSizeY = height;
-	glDisable(GL_TEXTURE_RECTANGLE_ARB);
-	glEnable(GL_TEXTURE_2D);
+	radarTexX = ((GLfloat)width / (GLfloat)w) * 256.0;
+	radarTexY = ((GLfloat)height / (GLfloat)h) * 256.0;
 }
 
+/** Display radar texture using the given height and width, depending on zoom level. */
 void pie_RenderRadar(int x, int y, int width, int height)
 {
-	const int tw = radarSizeX * 256;
-	const int th = radarSizeY * 256;
-
-	if (!GLEE_ARB_texture_rectangle)
-	{
-		return;
-	}
 	pie_SetTexturePage(radarTexture);
-	glDisable(GL_TEXTURE_2D);
-	glEnable(GL_TEXTURE_RECTANGLE_ARB);
-	glBindTexture(GL_TEXTURE_RECTANGLE_ARB, _TEX_PAGE[radarTexture].id);
+	glBindTexture(GL_TEXTURE_2D, _TEX_PAGE[radarTexture].id);
 	pie_SetRendMode(REND_GOURAUD_TEX);
 	glEnable(GL_BLEND);
 	glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);
 	glColor4ubv(WZCOL_WHITE.vector);
 	glBegin(GL_TRIANGLE_STRIP);
-		glTexCoord2f(0, 0);	glVertex2f(x, y);
-		glTexCoord2f(tw, 0);	glVertex2f(x + width, y);
-		glTexCoord2f(0, th);	glVertex2f(x, y + height);
-		glTexCoord2f(tw, th);	glVertex2f(x + width, y + height);
+		glTexCoord2f(0, 0);			glVertex2f(x, y);
+		glTexCoord2f(radarTexX, 0);		glVertex2f(x + width, y);
+		glTexCoord2f(0, radarTexY);		glVertex2f(x, y + height);
+		glTexCoord2f(radarTexX, radarTexY);	glVertex2f(x + width, y + height);
 	glEnd();
-	glDisable(GL_TEXTURE_RECTANGLE_ARB);
-	glEnable(GL_TEXTURE_2D);
 }
 
 void pie_LoadBackDrop(SCREENTYPE screenType)
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Re: [Warzone-dev] Barrier Intel GMA

[Dennis Schridde]

On Sunday 07 September 2008 15:08:32 Giel van Schijndel wrote:
> Kamaze schreef:
> > Dennis Schridde schrieb:
> >> On Sunday 07 September 2008 13:28:45 Kamaze wrote:
> >> Can you get a bit more specific please?
> >> What exactly is broken about rendering on Intel chips?
> >
> > Whops, i git lost while writing. I talked with EvilGuru in IRC about
> > using VBO and such things for Warzone. Well, these feature for example
> > was introduces with OpenGL 1.5 while most GMA Chips only support OpenGL
> > 1.4.
> >
> > If I remember right, Per has a GMA 950, so if there would be some
> > serious use of VBO (for example) he would be locked out, as well as
> > other player.
>
> Instead of VBOs we can use VAs if VBOs aren't available. Drawing with
> VAs is (codewise) nearly the same as using VBOs and VAs are available in
> OpenGL 1.1.
Afaik modern drivers also fall back automatically to VAs if VBOs are not 
available.

--Devu


signature.asc
Description: This is a digitally signed message part.
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Re: [Warzone-dev] Barrier Intel GMA

[Dennis Schridde]

On Sunday 07 September 2008 18:27:46 Per Inge Mathisen wrote:
> Attached is a patch to remove the need for GL_ARB_texture_rectangle
> for the radar code. I suppose a similar approach could be used for
> betawidget. The complexity of manipulating texture coordinates can be
> hidden by an abstraction layer.
The code afterwards even seems to be simpler...
And (didnt benchmark myself, relying on others peoples numbers) non-square-pot 
textures render slower, too...

--Devu


signature.asc
Description: This is a digitally signed message part.
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

[Warzone-dev] Fixing directories

[bugs buggy]

 Ok, the issue is, that we open the music file. (in base/music).
 Then we want to remove base, since we are going to play a MP game.
 But we can't since we still have a open file handle.
This leaves it in the physfs search path, and causes us issues.


 fix 1) move music out of base, and stick it in its own directory.  fix 2)
don't play music :P  fix 3) ???

Also, *why* is there a base/multiplay directory?
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Re: [Warzone-dev] Fixing directories

[Dennis Schridde]

On Sunday 07 September 2008 23:01:08 bugs buggy wrote:
>  Ok, the issue is, that we open the music file. (in base/music).
>  Then we want to remove base, since we are going to play a MP game.
>  But we can't since we still have a open file handle.
> This leaves it in the physfs search path, and causes us issues.
You mean when we start the game we are in "base" mode?
SearchPath#base
When we then start an MP game we switch to mp mode?
SP#mp
Correct till now?
That causes issues when files from base are still opened when the searchpath 
is removed?
So why dont we just add directories? And before removing any make sure there 
are no open files?
SP#base:mp
The no-open-files part would have to be out of the system itself, I think. 
Checking all open files and refusing to unmount (or closing files on unmount) 
doesnt sound very clever.

--Devu


signature.asc
Description: This is a digitally signed message part.
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

[Warzone-dev] [Warzone 2100 Trac] #57: Should fix the 'playlist' bug + other bugs that have to do with music in trunk.

[Warzone 2100 Trac]

#57: Should fix the 'playlist' bug + other bugs that have to do with music in
trunk.
---+
 Reporter:  Buginator  |  Owner:   
 Type:  defect | Status:  new  
 Priority:  blocker|  Milestone:   
Component:  other  |Version:  svn/trunk
 Keywords: |   Operating_system:  All  
---+
 Issue was that we had (in this case) a open file handle to the music track
 (menu.ogg).
 We then tried to remove the directory 'base' from the search path.
 This was '''NOT''' possible, since we had the above open file handle.

 This resulted in us using the '''wrong''' search path order, and cause all
 these strange crashes.

 It should fix bug https://gna.org/bugs/?12280 &
 https://gna.org/bugs/?11847 and maybe others.

 The patch now assumes the following:

 {{{
 Warzone/data
 Warzone/data/base
 Warzone/data/mods
 Warzone/data/mp
 Warzone/data/music
 Warzone/data/music/music*
 }}}
 *since the source has 'music' hardcoded (static const char UserMusicPath[]
 = "music";), rather than changing allot of things around, I did it the
 simplest way to prove this is the problem.

-- 
Ticket URL: 
Warzone 2100 Trac 
The Warzone 2100 Resurrection Project
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Re: [Warzone-dev] Fixing directories

[bugs buggy]

On 9/7/08, Dennis Schridde <[EMAIL PROTECTED]> wrote:
>
> On Sunday 07 September 2008 23:01:08 bugs buggy wrote:
> >  Ok, the issue is, that we open the music file. (in base/music).
> >  Then we want to remove base, since we are going to play a MP game.
> >  But we can't since we still have a open file handle.
> > This leaves it in the physfs search path, and causes us issues.
>
> You mean when we start the game we are in "base" mode?
> SearchPath#base
> When we then start an MP game we switch to mp mode?
> SP#mp
> Correct till now?
> That causes issues when files from base are still opened when the
> searchpath
> is removed?
> So why dont we just add directories? And before removing any make sure
> there
> are no open files?
> SP#base:mp
> The no-open-files part would have to be out of the system itself, I think.
> Checking all open files and refusing to unmount (or closing files on
> unmount)
> doesnt sound very clever.
>
> --Devu
>

Huh?
How are you supposed to tell which file is open?  All we know is that at
least one file handle is open,  (in this case, it happens to be the music
one) and physfs won't allow it to be removed from the search path (which is
correct behavior IMO) so it fails.  I am unaware of a way to check just
which file(s) we have open unless you keep them in a list.

If you want to add all the files/directories in base, one by one, then
remove them one by one, checking no file handle is open, that seems to be a
overly complex way to handle this.


I was thinking of something along the lines of:
Warzone
Warzone/data
Warzone/data/base
Warzone/data/mods
Warzone/data/mp
Warzone/data/music
Warzone/data/music/music*

There is also a configdir/music  directory (which overrides the other music
folder) which needs to be removed, unless, we will allow sharing of music
tracks between people?  AFAIK, this is left over behaviour from before, and
not really needed.

The above is what my patch does, and I did test it, and it works.
It should also fix bug https://gna.org/bugs/?12280 &
https://gna.org/bugs/?11847

patch here: http://developer.wz2100.net/ticket/57


*since the source has 'music' hardcoded (static const char UserMusicPath[] =
"music";), rather than changing allot of things around, I did it the
simplest way to prove this is the problem.
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev