Per Inge Mathisen schreef: > On 1/1/07, Giel van Schijndel <[EMAIL PROTECTED]> wrote: >>>> When looking at the code I'm guessing that all you've changed is the >>>> removal of all direct calls to the blockheap system throughout all >>>> src/ >>>> files? > All memory allocations now take place using ordinary malloc/free, > instead of inside fixed size block heaps, yes. >>>> A huge difference I'm noticing is that now my FPS actually comes above >>>> 25 on my laptop. Before using your patch I'd only have an FPS between >>>> 18-25 (yes the FPS limit was set on 60 as well then), now it runs >>>> on 60 >>>> while 60 currently is my set limit. > Interesting. > >>>> For every time when I now encounter enemy units approaching me over a >>>> hill (or some other terrain that requires height checking for >>>> visibility) an assert gets fired from src/visibility.c:164 (in >>>> function: >>>> SDWORD visObjHeight(BASE_OBJECT *psObject)). It seems like the memory >>>> which contains psObject now somehow gets corrupted which causes >>>> psObject->type to be overwritten. I'm guessing this is now being >>>> exposed >>>> because the previous malloc allocated 32 bytes extra before and after >>>> the requested memspace as a safety zone. >>> PS It only seems to occur when I pass the --cheat parameter to WZ >> Uploaded a savegame and my own compilation (only diff to r591 is your >> mempatch) that cause the assert-loop here: http://wz-debug.mortis.eu/ > I cannot reproduce it with the savegame. I see some odd artefacts, > though - the ocean tiles do not tile well, and some "error: ... > warning ..." messages, but no asserts. > > I do not have time to test this in any depth. If you can get me a > backtrace, I could look at that. The next step is probably to look at > the valgrind report and check those invalid reads and conditional > jumps. Those need to be fixed (I think most of them are present in > current svn also? perhaps a good idea would be to fix them in svn > current first, then see if we get any _new_ ones after applying the > patch). As requested a backtrace: > (gdb) run > Starting program: C:\Program Files\Warzone 2100/warzone2100.exe > --cheat --datadi > r "C:/Program Files/Warzone 2100" --savegame "Little Egypt crash on > visibility H > eight.gam" > > Program received signal SIGTRAP, Trace/breakpoint trap. > 0x77c05b62 in OpenAL32_dll_iname () > (gdb) bt > #0 0x77c05b62 in OpenAL32_dll_iname () > #1 0x00000001 in ?? () > #2 0x004d4b8e in _Z12visObjHeightP12_base_object (psObject=0x4a1d010) > at visibility.c:164 > #3 0x004d59c3 in _Z13visibleObjectP12_base_objectS0_ (psViewer=0x4a15208, > psTarget=0x4a1d010) at visibility.c:646 > #4 0x004086dd in _Z17actionUpdateDroidP6_droid (psDroid=0x4a15208) > at action.c:1430 > #5 0x00427ce3 in _Z11droidUpdateP6_droid (psDroid=0x4a15208) at > droid.c:1331 > #6 0x0046b64e in _Z8gameLoopv () at loop.c:320 > #7 0x005038ad in SDL_main (argc=6, argv=0x22fce0) at main.c:683 > #8 0x005dc2eb in console_main (argc=6, argv=0x22fce0) > at ./src/main/win32/SDL_win32_main.c:217 > #9 0x005dc4a2 in [EMAIL PROTECTED] (hInst=0x400000, hPrev=0x0, > szCmdLine=0x241f10 "--cheat --datadir \"C:/Program Files/Warzone > 2100\" --savegame \"Little Egypt crash on visibility Height.gam\"", sw=10) > at ./src/main/win32/SDL_win32_main.c:353 > #10 0x0057fbaa in main () > (gdb) PS it seems also only to occur when I order the units in group 1 to move leftwards (up that tiny hill).
-- Giel
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
