Re: [Warzone-dev] shapened textures
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
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
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
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
-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
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 stdio.h
#include string.h
#include SDL/SDL.h
-#ifdef _MSC_VER
-#include windows.h //needed for gl.h! --Qamly
-#endif
-#include SDL/SDL_opengl.h
#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
+
/***/
/*
Re: [Warzone-dev] shapened textures
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
[Warzone-dev] Weired things in current trunk.
I got compiling wz2100 under win/mingw32 working again and tested the new trunk and i saw a few weired things. - Shadows don't work. - Weired image switches, if i hover a button in the menu. See image 1: http://img.rootzilla.de/img/3e065ef90e474b80b240161b09c49ec03c274ebc.jpg And image 2: http://img.rootzilla.de/img/032124237f729801f2b1747c731aa242e83efc14.jpg Look clother to the Blue dust and the build date. This happens with a small delay, if i hover a button in the menu. A bit weired, or? :) - Kamaze ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Weired things in current trunk.
On 2/11/07, Kamaze [EMAIL PROTECTED] wrote: I got compiling wz2100 under win/mingw32 working again and tested the new trunk and i saw a few weired things. - Shadows don't work. - Weired image switches, if i hover a button in the menu. See image 1: http://img.rootzilla.de/img/3e065ef90e474b80b240161b09c49ec03c274ebc.jpg And image 2: http://img.rootzilla.de/img/032124237f729801f2b1747c731aa242e83efc14.jpg Look clother to the Blue dust and the build date. This happens with a small delay, if i hover a button in the menu. A bit weired, or? :) - Kamaze I have the 'onmouseover mosaic' for build date too...though shadows work fine for me ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Weired things in current trunk.
Shadow works fine now. I did mess up my configfile. The Watermelon schrieb: On 2/11/07, Kamaze [EMAIL PROTECTED] wrote: I got compiling wz2100 under win/mingw32 working again and tested the new trunk and i saw a few weired things. - Shadows don't work. - Weired image switches, if i hover a button in the menu. See image 1: http://img.rootzilla.de/img/3e065ef90e474b80b240161b09c49ec03c274ebc.jpg And image 2: http://img.rootzilla.de/img/032124237f729801f2b1747c731aa242e83efc14.jpg Look clother to the Blue dust and the build date. This happens with a small delay, if i hover a button in the menu. A bit weired, or? :) - Kamaze I have the 'onmouseover mosaic' for build date too...though shadows work fine for me ___ 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] shapened textures
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
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] Weired things in current trunk.
Am Sonntag, 11. Februar 2007 schrieb Kamaze: Shadow works fine now. I did mess up my configfile. The Watermelon schrieb: On 2/11/07, Kamaze [EMAIL PROTECTED] wrote: I got compiling wz2100 under win/mingw32 working again and tested the new trunk and i saw a few weired things. - Shadows don't work. - Weired image switches, if i hover a button in the menu. See image 1: http://img.rootzilla.de/img/3e065ef90e474b80b240161b09c49ec03c274ebc.jpg And image 2: http://img.rootzilla.de/img/032124237f729801f2b1747c731aa242e83efc14.jpg Look clother to the Blue dust and the build date. This happens with a small delay, if i hover a button in the menu. A bit weired, or? :) Yes, this is not how it should be... Especially that the backdrop texture seems to loose the alpha channel is weird... pgpmfSI43NoDo.pgp Description: PGP signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] shapened textures
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] Current problems
On 2/11/07, Troman [EMAIL PROTECTED] wrote: Back to this loading topic. I wasn't reading all mailinglist messages lately, but from reading old messages looks like this is still not resolved. Anyhow, I fixed the crash in saving the game. Loading the game resulted in a different crash, which I also fixed, but then there was another one: 7. The following error occurs when loading a saved game, at least in campaign mode: error: eventSetContextVar: Variable type mismatch (1/0) error: Assert in Warzone: event.c:779 : eventSetContextVar (FALSE), last script event: 'none' event.c:779: failed assertion `(0)' I'm really clueless why this happens. I wouldn't deal with the loading/saving code, if it worked fine for you at some point, since AFAIK loading/saving code wasn't changed after the 64bit-patch (r495). Do you know if loading worked after this patch? There were also modifications to the savegame format, maybe something wasn't endianized? Another thind you can do is to try to find the commit that broke savegame loading on mac. I'm attaching a savegame. Chances are good that there are endian issues so it won't load for others, but if you can give me some hints about where it crashes trying to load this, it might help fix it on my end, too. Thanks! Can't load it, that's what I get as debug output: never: levLoadData: loading script system state error: resGetDataFromHash: Unknown ID: error: Assert in Warzone: c:\wz\source\lib\framework\frameresource.c:544 : resGetDataFromHash (FALSE), last script event: 'none' call stack: Warzone.exe!resGetDataFromHash(const char * pType=0x005cba0c, unsigned int HashedID=1065441038) Line 544 + 0x5b bytes C Warzone.exe!eventLoadContextHashed(int version=50331648, char * pBuffer=0x038a0088, unsigned int * pSize=0x0012f540) Line 370 + 0xe bytes C Warzone.exe!eventLoadState(char * pBuffer=0x038a0080, unsigned int fileSize=2204, int bHashed=1) Line 764 + 0x11 bytes C Warzone.exe!loadScriptState(char * pFileName=0x00d39480) Line 11669 + 0x11 bytes C Warzone.exe!levLoadData(char * pName=0x00d63000, char * pSaveName=0x00d39480, int saveType=4) Line 1131 + 0x9 bytes C Warzone.exe!gameLoadV(char * pFileData=0x038a0088, unsigned int filesize=4572, unsigned int version=34) Line 4161 + 0x15 bytes C Warzone.exe!gameLoad(char * pFileData=0x038a0088, unsigned int filesize=4572) Line 3283 + 0x14 bytes C Warzone.exe!loadGameInit(char * pGameToLoad=0x00d39480) Line 1385 + 0xd bytes C Warzone.exe!SDL_main(int argc=12, char * * argv=0x0012fd38) Line 562 + 0xa bytes C Warzone.exe!_main() + 0xd1 bytes C I have attached savegame from campaign 1, mission 1 in case you still need it. That savegame definitely crashes on the Mac. I'm pretty sure it's the endian issue. The problem seems to stem from the script state being saved without any endianizing. To my knowledge, saving and loading games worked fine until that change occurred, which I think was post-r495. A test of r495 just now actually crashes when attempting to save the game, with the crash coming from code that is commented out in the latest source. However, this is entirely separate from the crashes I get now. What we need to do is go through the evntsave.c and scriptobj.c code to endianize all the things that get saved out to the file. I don't know the file formats so I can't go through them accurately myself. As for the scrCBNewUnit() problem, did r690 fix it? I haven't had it occur since then, so it appears that that problem is fixed. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Patch: Severe pointer abuse in design.c (Finally a x86_64 bug! )
The Watermelon wrote: On 2/10/07, *Gerard Krol* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi all, As some of you may know, power required and hit points of droid parts are stored in central arrays. Individual body types are an index into this array and are used like this: (asBodyStats + psTemplate-asParts[COMP_BODY])-buildPower The code in intSetTemplatePowerShadowStats and intSetTemplateBodyShadowStats did store a pointer in this index by using the difference with the asBodyStats address, so that after this addition the correct address would magically reappear. Guilty code looks like this: compTempl.asParts[COMP_BODY] = (BODY_STATS *)psStats - asBodyStats; Funny thing is: on 64bit: sizeof(SDWORD) sizeof(void*) In the attached patch, the calls to calcTemplatePower and calcTemplateBody were removed, and the (simple) formula's used for calculation were directly included in the two modified functions. - Gerard I think that kind of stuff is everywhere in the source,at least I saw multiple instances of 'weapId = psStats - asWeaponStats' or 'psStats = asWeaponStats + weaponId'. In most of the case psStats points to an member of the array asWeaponStats. In that case weaponId is a small integer (0 to about a max of 40) and the code is correct. The bug is by the way exposed if you design a new droid, put a system on it (sensor for example) and then hover your mouse over another system (like the construction unit). The game then segfaults. - Gerard ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Current problems
- Original Message - From: Ari Johnson [EMAIL PROTECTED] To: Development list warzone-dev@gna.org Sent: Sunday, February 11, 2007 8:17 PM Subject: Re: [Warzone-dev] Current problems On 2/11/07, Troman [EMAIL PROTECTED] wrote: Back to this loading topic. I wasn't reading all mailinglist messages lately, but from reading old messages looks like this is still not resolved. Anyhow, I fixed the crash in saving the game. Loading the game resulted in a different crash, which I also fixed, but then there was another one: 7. The following error occurs when loading a saved game, at least in campaign mode: error: eventSetContextVar: Variable type mismatch (1/0) error: Assert in Warzone: event.c:779 : eventSetContextVar (FALSE), last script event: 'none' event.c:779: failed assertion `(0)' I'm really clueless why this happens. I wouldn't deal with the loading/saving code, if it worked fine for you at some point, since AFAIK loading/saving code wasn't changed after the 64bit-patch (r495). Do you know if loading worked after this patch? There were also modifications to the savegame format, maybe something wasn't endianized? Another thind you can do is to try to find the commit that broke savegame loading on mac. I'm attaching a savegame. Chances are good that there are endian issues so it won't load for others, but if you can give me some hints about where it crashes trying to load this, it might help fix it on my end, too. Thanks! Can't load it, that's what I get as debug output: never: levLoadData: loading script system state error: resGetDataFromHash: Unknown ID: error: Assert in Warzone: c:\wz\source\lib\framework\frameresource.c:544 : resGetDataFromHash (FALSE), last script event: 'none' call stack: Warzone.exe!resGetDataFromHash(const char * pType=0x005cba0c, unsigned int HashedID=1065441038) Line 544 + 0x5b bytes C Warzone.exe!eventLoadContextHashed(int version=50331648, char * pBuffer=0x038a0088, unsigned int * pSize=0x0012f540) Line 370 + 0xe bytes C Warzone.exe!eventLoadState(char * pBuffer=0x038a0080, unsigned int fileSize=2204, int bHashed=1) Line 764 + 0x11 bytes C Warzone.exe!loadScriptState(char * pFileName=0x00d39480) Line 11669 + 0x11 bytes C Warzone.exe!levLoadData(char * pName=0x00d63000, char * pSaveName=0x00d39480, int saveType=4) Line 1131 + 0x9 bytes C Warzone.exe!gameLoadV(char * pFileData=0x038a0088, unsigned int filesize=4572, unsigned int version=34) Line 4161 + 0x15 bytes C Warzone.exe!gameLoad(char * pFileData=0x038a0088, unsigned int filesize=4572) Line 3283 + 0x14 bytes C Warzone.exe!loadGameInit(char * pGameToLoad=0x00d39480) Line 1385 + 0xd bytes C Warzone.exe!SDL_main(int argc=12, char * * argv=0x0012fd38) Line 562 + 0xa bytes C Warzone.exe!_main() + 0xd1 bytes C I have attached savegame from campaign 1, mission 1 in case you still need it. That savegame definitely crashes on the Mac. I'm pretty sure it's the endian issue. The problem seems to stem from the script state being saved without any endianizing. To my knowledge, saving and loading games worked fine until that change occurred, which I think was post-r495. A test of r495 just now actually crashes when attempting to save the game, with the crash coming from code that is commented out in the latest source. However, this is entirely separate from the crashes I get now. What we need to do is go through the evntsave.c and scriptobj.c code to endianize all the things that get saved out to the file. I don't know the file formats so I can't go through them accurately myself. Unfortunately I'm not familiar with saving/loading routines or save game formats myself, I don't remember anyone really worked with it before. I think starting to blindly fix the code isn't a good idea. The best approach seems to be to track down the revision that introduced that bug, otherwise it looks pretty hopeless, since non-mac users can't even recreate the bug. If it will turn out to be r496 and loading worked fine on mac before r496 (and hence I assume that it was properly endianized) and saving/loading routines were only modified in r496 dealing with scriptobj.c and other parts of the saving/loading routines that were not modified doesn't make much sense imho. All that has to be checked are the modifications to the saving/loading routines or save game format made after loading stopped working on mac. Troman As for the scrCBNewUnit() problem, did r690 fix it? I haven't had it occur since then, so it appears that that problem is fixed. ___ 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] Current problems
- Original Message - From: Ari Johnson [EMAIL PROTECTED] To: Development list warzone-dev@gna.org Sent: Sunday, February 11, 2007 10:12 PM Subject: Re: [Warzone-dev] Current problems On 2/11/07, Troman [EMAIL PROTECTED] wrote: - Original Message - From: Ari Johnson [EMAIL PROTECTED] To: Development list warzone-dev@gna.org Sent: Sunday, February 11, 2007 8:17 PM Subject: Re: [Warzone-dev] Current problems On 2/11/07, Troman [EMAIL PROTECTED] wrote: Back to this loading topic. I wasn't reading all mailinglist messages lately, but from reading old messages looks like this is still not resolved. Anyhow, I fixed the crash in saving the game. Loading the game resulted in a different crash, which I also fixed, but then there was another one: 7. The following error occurs when loading a saved game, at least in campaign mode: error: eventSetContextVar: Variable type mismatch (1/0) error: Assert in Warzone: event.c:779 : eventSetContextVar (FALSE), last script event: 'none' event.c:779: failed assertion `(0)' I'm really clueless why this happens. I wouldn't deal with the loading/saving code, if it worked fine for you at some point, since AFAIK loading/saving code wasn't changed after the 64bit-patch (r495). Do you know if loading worked after this patch? There were also modifications to the savegame format, maybe something wasn't endianized? Another thind you can do is to try to find the commit that broke savegame loading on mac. I'm attaching a savegame. Chances are good that there are endian issues so it won't load for others, but if you can give me some hints about where it crashes trying to load this, it might help fix it on my end, too. Thanks! Can't load it, that's what I get as debug output: never: levLoadData: loading script system state error: resGetDataFromHash: Unknown ID: error: Assert in Warzone: c:\wz\source\lib\framework\frameresource.c:544 : resGetDataFromHash (FALSE), last script event: 'none' call stack: Warzone.exe!resGetDataFromHash(const char * pType=0x005cba0c, unsigned int HashedID=1065441038) Line 544 + 0x5b bytes C Warzone.exe!eventLoadContextHashed(int version=50331648, char * pBuffer=0x038a0088, unsigned int * pSize=0x0012f540) Line 370 + 0xe bytes C Warzone.exe!eventLoadState(char * pBuffer=0x038a0080, unsigned int fileSize=2204, int bHashed=1) Line 764 + 0x11 bytes C Warzone.exe!loadScriptState(char * pFileName=0x00d39480) Line 11669 + 0x11 bytes C Warzone.exe!levLoadData(char * pName=0x00d63000, char * pSaveName=0x00d39480, int saveType=4) Line 1131 + 0x9 bytes C Warzone.exe!gameLoadV(char * pFileData=0x038a0088, unsigned int filesize=4572, unsigned int version=34) Line 4161 + 0x15 bytes C Warzone.exe!gameLoad(char * pFileData=0x038a0088, unsigned int filesize=4572) Line 3283 + 0x14 bytes C Warzone.exe!loadGameInit(char * pGameToLoad=0x00d39480) Line 1385 + 0xd bytes C Warzone.exe!SDL_main(int argc=12, char * * argv=0x0012fd38) Line 562 + 0xa bytes C Warzone.exe!_main() + 0xd1 bytes C I have attached savegame from campaign 1, mission 1 in case you still need it. That savegame definitely crashes on the Mac. I'm pretty sure it's the endian issue. The problem seems to stem from the script state being saved without any endianizing. To my knowledge, saving and loading games worked fine until that change occurred, which I think was post-r495. A test of r495 just now actually crashes when attempting to save the game, with the crash coming from code that is commented out in the latest source. However, this is entirely separate from the crashes I get now. What we need to do is go through the evntsave.c and scriptobj.c code to endianize all the things that get saved out to the file. I don't know the file formats so I can't go through them accurately myself. Unfortunately I'm not familiar with saving/loading routines or save game formats myself, I don't remember anyone really worked with it before. I think starting to blindly fix the code isn't a good idea. The best approach seems to be to track down the revision that introduced that bug, otherwise it looks pretty hopeless, since non-mac users can't even recreate the bug. If it will turn out to be r496 and loading worked fine on mac before r496 (and hence I assume that it was properly endianized) and saving/loading routines were only modified in r496 dealing with scriptobj.c and other parts of the saving/loading routines that were not modified doesn't make much sense imho. All that has to be checked are the modifications to the saving/loading routines or save game format made after loading stopped working on mac. That's the problem. When I endianized the data loading and saving processes early on in my involvement with the project, I had the struct definitions to go from to determine what parts needed to be endianized and
Re: [Warzone-dev] Current problems
On 2/11/07, Troman [EMAIL PROTECTED] wrote: - Original Message - From: Ari Johnson [EMAIL PROTECTED] To: Development list warzone-dev@gna.org Sent: Sunday, February 11, 2007 10:12 PM Subject: Re: [Warzone-dev] Current problems On 2/11/07, Troman [EMAIL PROTECTED] wrote: - Original Message - From: Ari Johnson [EMAIL PROTECTED] To: Development list warzone-dev@gna.org Sent: Sunday, February 11, 2007 8:17 PM Subject: Re: [Warzone-dev] Current problems On 2/11/07, Troman [EMAIL PROTECTED] wrote: Back to this loading topic. I wasn't reading all mailinglist messages lately, but from reading old messages looks like this is still not resolved. Anyhow, I fixed the crash in saving the game. Loading the game resulted in a different crash, which I also fixed, but then there was another one: 7. The following error occurs when loading a saved game, at least in campaign mode: error: eventSetContextVar: Variable type mismatch (1/0) error: Assert in Warzone: event.c:779 : eventSetContextVar (FALSE), last script event: 'none' event.c:779: failed assertion `(0)' I'm really clueless why this happens. I wouldn't deal with the loading/saving code, if it worked fine for you at some point, since AFAIK loading/saving code wasn't changed after the 64bit-patch (r495). Do you know if loading worked after this patch? There were also modifications to the savegame format, maybe something wasn't endianized? Another thind you can do is to try to find the commit that broke savegame loading on mac. I'm attaching a savegame. Chances are good that there are endian issues so it won't load for others, but if you can give me some hints about where it crashes trying to load this, it might help fix it on my end, too. Thanks! Can't load it, that's what I get as debug output: never: levLoadData: loading script system state error: resGetDataFromHash: Unknown ID: error: Assert in Warzone: c:\wz\source\lib\framework\frameresource.c:544 : resGetDataFromHash (FALSE), last script event: 'none' call stack: Warzone.exe!resGetDataFromHash(const char * pType=0x005cba0c, unsigned int HashedID=1065441038) Line 544 + 0x5b bytes C Warzone.exe!eventLoadContextHashed(int version=50331648, char * pBuffer=0x038a0088, unsigned int * pSize=0x0012f540) Line 370 + 0xe bytes C Warzone.exe!eventLoadState(char * pBuffer=0x038a0080, unsigned int fileSize=2204, int bHashed=1) Line 764 + 0x11 bytes C Warzone.exe!loadScriptState(char * pFileName=0x00d39480) Line 11669 + 0x11 bytes C Warzone.exe!levLoadData(char * pName=0x00d63000, char * pSaveName=0x00d39480, int saveType=4) Line 1131 + 0x9 bytes C Warzone.exe!gameLoadV(char * pFileData=0x038a0088, unsigned int filesize=4572, unsigned int version=34) Line 4161 + 0x15 bytes C Warzone.exe!gameLoad(char * pFileData=0x038a0088, unsigned int filesize=4572) Line 3283 + 0x14 bytes C Warzone.exe!loadGameInit(char * pGameToLoad=0x00d39480) Line 1385 + 0xd bytes C Warzone.exe!SDL_main(int argc=12, char * * argv=0x0012fd38) Line 562 + 0xa bytes C Warzone.exe!_main() + 0xd1 bytes C I have attached savegame from campaign 1, mission 1 in case you still need it. That savegame definitely crashes on the Mac. I'm pretty sure it's the endian issue. The problem seems to stem from the script state being saved without any endianizing. To my knowledge, saving and loading games worked fine until that change occurred, which I think was post-r495. A test of r495 just now actually crashes when attempting to save the game, with the crash coming from code that is commented out in the latest source. However, this is entirely separate from the crashes I get now. What we need to do is go through the evntsave.c and scriptobj.c code to endianize all the things that get saved out to the file. I don't know the file formats so I can't go through them accurately myself. Unfortunately I'm not familiar with saving/loading routines or save game formats myself, I don't remember anyone really worked with it before. I think starting to blindly fix the code isn't a good idea. The best approach seems to be to track down the revision that introduced that bug, otherwise it looks pretty hopeless, since non-mac users can't even recreate the bug. If it will turn out to be r496 and loading worked fine on mac before r496 (and hence I assume that it was properly endianized) and saving/loading routines were only modified in r496 dealing with scriptobj.c and other parts of the saving/loading routines that were not modified doesn't make much sense imho. All that has to be checked are the modifications to the saving/loading routines or save game format made after loading stopped working on mac. That's the problem. When I endianized the data loading and saving processes
Re: [Warzone-dev] Lua-WRF
Am Samstag, 27. Januar 2007 schrieb Dennis Schridde: Am Donnerstag, 28. Dezember 2006 schrieb Dennis Schridde: Hello everyone! I can't find the last thread on this topic anymore, so I started a new one... I am currently into replacing the resource system with a Lua driven one. Works well so far. (Am only in the very early stages.) The concerns some of you had, that Lua could be too slow for that task, are very very probably wrong. I just tried to parse 20k modules. (Each mod had only 2 resources, but when I look at the current code: 20k mods with only 2 resources is very probably worse than 1k mods with 20 resources each. And even having 1k mods is highly unrealistic.) It seems like the place where it needs the most time is the dependency creation part, which currently only consists of some nested for loops walking the whole mod and resource list to find the deps. If I exchange the string compares against some hashing and use a tree instead of a list, I guess it will be fast enough. Here comes some early preview of the parser. Just reads the testscript.lua, creates the according module/resource structure in memory, incl. dependencies etc. and then prints it. Should give an idea of the syntax and structure. Be aware, this is by no means polished. Some intro on the deps system (which this approach is all about): findResource( foo, myModule ): When referencing a resource like foo, it will search the resource of this name the given myModule and all of its parents. Should be a bit faster since not all modules have to be looked at. findResource( foo:bar, NULL ): When referencing a resource as foo:bar, it will search the resource of name bar in the module named foo. Walks through all modules to find it, so it will be a bit slower than the short reference. (You don't have to supply NULL, of course. The supplied module will be ignored in case you give a full reference.) For the next time I'll work on loading of resources and their deps. Loading of resources now works in theory. Dependencies are automatically loaded when a resource is loaded and unloaded when the resource is unloaded and no one else uses it. You will find the API in resource_manager.h and an example is to be found in main.c Call WRF_load(filename) for all wrf files you need. Then call WRF_init(), which will setup the internal depencencies. It will fail if called twice, so after you called it once, you cannot add additional wrf files... Now you can call WRF_loadResource to explicitly request a resource to be loaded. This will ensure that it is not unloaded when not requested. You can also call WRF_getData directly, which will load the resource if it was not before. This function will return the data associated with the resource, which was loaded by the loader implementation. WRF_exit() will unload all resources and destroy them. All functions are provided in a ByName and a ByHandle version for convenience. Both are equal besides that ByName does a name lookup (and thus is slower), which ByHandle doesn't need. I will probably remove the ByName version and instead export the findResource function and require everybody to search for themselves if needed. --Dennis lua_wrf.7z Description: application/7z pgpAavgn26qRm.pgp Description: PGP signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
