Re: [Warzone-dev] [Warzone 2100 Trac] #569: Drag-build rearm pads
#569: Drag-build rearm pads -+-- Reporter: Per | Owner: Type: enhancement | Status: closed Priority: major | Milestone: 2.3 Component: Engine: other | Version: svn/trunk Resolution: fixed |Keywords: path-finding VTOL rearm Operating_system: All/Non-Specific | Blockedby: Blocking:| -+-- Changes (by sendai): * status: new = closed * resolution: = fixed Comment: (In [7654]) Make it possible to drag a line of rearm pad production similar to how walls and defenses can be built by dragging the production with the mouse. It also removes the obligatory empty tile between rearm pads. Instead, it allows units to drive over rearm pads that are not currently busy rearming. This closes ticket:569 -- Ticket URL: http://developer.wz2100.net/ticket/569#comment:1 Warzone 2100 Trac http://developer.wz2100.net/ The Warzone 2100 Resurrection Project ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] Trunk's GLee hack, revert?
The problem with this hack is, that if we keep this in, then this hack is enabled for *all* people on linux, if they need it or not. AFAIK, we can't detect what drivers people are using, so the below error message is spit out for everyone on linux. If people don't report about the problem to the driver guys, then it don't get fixed. This is bad. I am thinking we should revert the hack altogether. Opinions? Index: lib/ivis_opengl/GLee.c === --- lib/ivis_opengl/GLee.c (revision 7656) +++ lib/ivis_opengl/GLee.c (working copy) @@ -12002,7 +12002,8 @@ // NOTE: this hack causes issues with MAC OS // HACK: work around for drivers that report VBO, but don't have full openGL 1.5 implementation. - #if defined(WZ_OS_UNIX) !defined(WZ_OS_MAC) + #if !defined (_WIN32) || !defined (__APPLE__) || !defined (__APPLE_CC__) + fprintf(stderr, GLee hack is enabled. Work around for video drivers that report VBO, but don't have full openGL 1.5 implementation--please report the issue to the driver maker.); GLeeFuncPtr_glBindBuffer = GLeeFuncPtr_glBindBufferARB; GLeeFuncPtr_glDeleteBuffers = GLeeFuncPtr_glDeleteBuffersARB; GLeeFuncPtr_glGenBuffers = GLeeFuncPtr_glGenBuffersARB; ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [Warzone2100-commits] SF.net SVN: warzone2100:[7655] branches/2.2/src
Am Donnerstag, 4. Juni 2009 19:33:00 schrieb bugina...@users.sourceforge.net: Revision: 7655 http://warzone2100.svn.sourceforge.net/warzone2100/?rev=7655view=rev Author: buginator Date: 2009-06-04 17:32:59 + (Thu, 04 Jun 2009) Log Message: --- Adding crash handler testing code. (to test crash dump reports) enable it by --crash on the command line. Why do you hide a crashing path to display3d.c? A simple *(char*)0=0; inside clparse.c would have worked, wouldn't it? Or if that is for some reason not possible, add a dedicated function (with significant name), which is called from an obvious location in main.c. (I.e. if you need to initialise the game, then make --crash initiate that and place the call after all init functions are passed and before the mainloop is being started.) --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] Trunk's GLee hack, revert?
On Thursday, 4 June 2009 at 15:42, bugs buggy wrote:
The problem with this hack is, that if we keep this in, then this hack
is enabled for *all* people on linux, if they need it or not.
AFAIK, we can't detect what drivers people are using, so the below
error message is spit out for everyone on linux.
If people don't report about the problem to the driver guys, then it
don't get fixed.
Afaik this only affects Mesa, not any other drivers. And the Mesa guys are
currently busy with Gallium, so I don't think they will do full OpenGL 1.5 for
the old Mesa.
This is bad.
I am thinking we should revert the hack altogether.
Opinions?
Actually there is no need to do the hack in GLee.c, so we can move it somewhere
we can check the GL_RENDERER string. See patch.
diff --git a/lib/ivis_opengl/GLee.c b/lib/ivis_opengl/GLee.c
index 499fcbd..9cc4613 100644
--- a/lib/ivis_opengl/GLee.c
+++ b/lib/ivis_opengl/GLee.c
@@ -12000,21 +12000,6 @@ GLuint __GLeeLink_GL_ARB_vertex_buffer_object(void)
if ((GLeeFuncPtr_glGetBufferParameterivARB = (GLEEPFNGLGETBUFFERPARAMETERIVARBPROC) __GLeeGetProcAddress(glGetBufferParameterivARB))!=0) nLinked++;
if ((GLeeFuncPtr_glGetBufferPointervARB = (GLEEPFNGLGETBUFFERPOINTERVARBPROC) __GLeeGetProcAddress(glGetBufferPointervARB))!=0) nLinked++;
- // NOTE: this hack causes issues with MAC OS
- // HACK: work around for drivers that report VBO, but don't have full openGL 1.5 implementation.
- #if defined(WZ_OS_UNIX) !defined(WZ_OS_MAC)
- GLeeFuncPtr_glBindBuffer = GLeeFuncPtr_glBindBufferARB;
- GLeeFuncPtr_glDeleteBuffers = GLeeFuncPtr_glDeleteBuffersARB;
- GLeeFuncPtr_glGenBuffers = GLeeFuncPtr_glGenBuffersARB;
- GLeeFuncPtr_glIsBuffer = GLeeFuncPtr_glIsBufferARB;
- GLeeFuncPtr_glBufferData = GLeeFuncPtr_glBufferDataARB;
- GLeeFuncPtr_glBufferSubData = GLeeFuncPtr_glBufferSubDataARB;
- GLeeFuncPtr_glGetBufferSubData = GLeeFuncPtr_glGetBufferSubDataARB;
- GLeeFuncPtr_glMapBuffer = GLeeFuncPtr_glMapBufferARB;
- GLeeFuncPtr_glUnmapBuffer = GLeeFuncPtr_glUnmapBufferARB;
- GLeeFuncPtr_glGetBufferParameteriv = GLeeFuncPtr_glGetBufferParameterivARB;
- GLeeFuncPtr_glGetBufferPointerv = GLeeFuncPtr_glGetBufferPointervARB;
- #endif
#endif
if (nLinked==11) return GLEE_LINK_COMPLETE;
if (nLinked==0) return GLEE_LINK_FAIL;
diff --git a/lib/ivis_opengl/screen.c b/lib/ivis_opengl/screen.c
index 05b6f88..031e7dd 100644
--- a/lib/ivis_opengl/screen.c
+++ b/lib/ivis_opengl/screen.c
@@ -171,7 +171,6 @@ BOOL screenInitialise(
{
debug( LOG_ERROR, OpenGL initialization did not give double buffering! );
}
- // Note that no initialisation of GLee is required, since this is handled automatically.
/* Dump information about OpenGL implementation to the console */
debug(LOG_3D, OpenGL Vendor : %s, glGetString(GL_VENDOR));
@@ -193,6 +192,27 @@ BOOL screenInitialise(
debug(LOG_3D, * Rectangular texture %s supported., GLEE_ARB_texture_rectangle ? is : is NOT);
debug(LOG_3D, * FrameBuffer Object (FBO) %s supported., GLEE_EXT_framebuffer_object ? is : is NOT);
+ // Some drivers, namely Mesa, don't support VBOs, but not full OpenGL
+ // 1.5, so work around that.
+ if (!strncmp((const char *)glGetString(GL_RENDERER), Mesa, 4))
+ {
+ debug(LOG_ERROR, Using Mesa hack);
+ // Usually GLee is initialized automatically when needed, but
+ // for this hack to work it has to be done here.
+ GLeeInit();
+ GLeeFuncPtr_glBindBuffer = GLeeFuncPtr_glBindBufferARB;
+ GLeeFuncPtr_glDeleteBuffers = GLeeFuncPtr_glDeleteBuffersARB;
+ GLeeFuncPtr_glGenBuffers = GLeeFuncPtr_glGenBuffersARB;
+ GLeeFuncPtr_glIsBuffer = GLeeFuncPtr_glIsBufferARB;
+ GLeeFuncPtr_glBufferData = GLeeFuncPtr_glBufferDataARB;
+ GLeeFuncPtr_glBufferSubData = GLeeFuncPtr_glBufferSubDataARB;
+ GLeeFuncPtr_glGetBufferSubData = GLeeFuncPtr_glGetBufferSubDataARB;
+ GLeeFuncPtr_glMapBuffer = GLeeFuncPtr_glMapBufferARB;
+ GLeeFuncPtr_glUnmapBuffer = GLeeFuncPtr_glUnmapBufferARB;
+ GLeeFuncPtr_glGetBufferParameteriv = GLeeFuncPtr_glGetBufferParameterivARB;
+ GLeeFuncPtr_glGetBufferPointerv = GLeeFuncPtr_glGetBufferPointervARB;
+ }
+
glViewport(0, 0, width, height);
glMatrixMode(GL_PROJECTION);
glPushMatrix();
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [Warzone2100-commits] SF.net SVN: warzone2100:[7660] trunk
Am Donnerstag, 4. Juni 2009 19:57:03 schrieb bugina...@users.sourceforge.net: Revision: 7660 http://warzone2100.svn.sourceforge.net/warzone2100/?rev=7660view=rev Author: buginator Date: 2009-06-04 17:56:56 + (Thu, 04 Jun 2009) Log Message: --- Slight cleanup of glOrtho parameters that should be double floats. glOrtho wants doubles for all parameters, not just for 2 and 3. This means that 1,4,5,6 should not be floats. --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] Trunk's GLee hack, revert?
Am Freitag, 5. Juni 2009 00:21:24 schrieb Christian Ohm: This is bad. I am thinking we should revert the hack altogether. Opinions? Actually there is no need to do the hack in GLee.c, so we can move it somewhere we can check the GL_RENDERER string. See patch. I think checking for specific drivers and applying hacks in that case is a bad behaviour. Can we not run a behavioural check instead? I.e. supports VBOs, but not GL 1.5 - likely to be broken? If you think that could cause havok on the wrong drivers, you could still check for renderer=mesa as a precondition to that, if it really need be. --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] Trunk's GLee hack, revert?
On Friday, 5 June 2009 at 0:47, Dennis Schridde wrote: I think checking for specific drivers and applying hacks in that case is a bad behaviour. Can we not run a behavioural check instead? I.e. supports VBOs, but not GL 1.5 - likely to be broken? If you think that could cause havok on the wrong drivers, you could still check for renderer=mesa as a precondition to that, if it really need be. Mesa supports VBOs as extensions, in OpenGL 1.5 they are in the core. Mesa needs the xxxARB function names, while Warzone uses the core names without ARB. All this hack does is to make it possible to use the core names even if VBOs are just extensions. I don't think there is any brokenness involved (despite this somewhat unlucky hack label). ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [Warzone2100-commits] SF.net SVN: warzone2100:[7655] branches/2.2/src
On 6/4/09, Dennis Schridde devuran...@gmx.net wrote: Am Donnerstag, 4. Juni 2009 19:33:00 schrieb bugina...@users.sourceforge.net: Revision: 7655 http://warzone2100.svn.sourceforge.net/warzone2100/?rev=7655view=rev Author: buginator Date: 2009-06-04 17:32:59 + (Thu, 04 Jun 2009) Log Message: --- Adding crash handler testing code. (to test crash dump reports) enable it by --crash on the command line. Why do you hide a crashing path to display3d.c? A simple *(char*)0=0; inside clparse.c would have worked, wouldn't it? Or if that is for some reason not possible, add a dedicated function (with significant name), which is called from an obvious location in main.c. (I.e. if you need to initialise the game, then make --crash initiate that and place the call after all init functions are passed and before the mainloop is being started.) Actually, that is by design, the 'bad ' crash report dumps are limited to one or two lines (if at all) of the call stack, instead of having a more deep call stack. If we would crash right away, then it hasn't hit the main game loop or anything of that nature. So, no, I am not hiding it. I just want it in a area, that is deep enough in the codebase, so we can have several layers of the call stack being shown. This whole thing came about since we currently having no way to easily verify which mingw setups work correctly, and which ones don't. This was the issue of a release we had in the past, where the crash dump was worthless. Some of the trunk nightly builds also have the worthless crash dumps. This is a attempt for the packager to verify they can produce builds that have proper crash dump support in them. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [Warzone2100-commits] SF.net SVN: warzone2100:[7660] trunk
On 6/4/09, Dennis Schridde devuran...@gmx.net wrote: Am Donnerstag, 4. Juni 2009 19:57:03 schrieb bugina...@users.sourceforge.net: Revision: 7660 http://warzone2100.svn.sourceforge.net/warzone2100/?rev=7660view=rev Author: buginator Date: 2009-06-04 17:56:56 + (Thu, 04 Jun 2009) Log Message: --- Slight cleanup of glOrtho parameters that should be double floats. glOrtho wants doubles for all parameters, not just for 2 and 3. This means that 1,4,5,6 should not be floats. Erm, I meant, before we only used double casts for 2 or 3 parameters, instead of using doubles for all parameters... void glOrtho( GLdoubleleft, GLdoubleright, GLdoublebottom, GLdoubletop, GLdoublenearVal, GLdoublefarVal); ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
