3D floors ... again (impossible comes true)

[StrikerMan780]

Oh, sorry. So then it _doesn't_ look any different in GL mode?

It renders fine in GL, as it's true color. What he's trying to say is that it is Palette-Mapped in Software Mode.

[Graf Zahl]

FYI, I just added GZDoom's FraggleScript code to this branch so some Legacy WADs like Nimrod and HTH2 are playable.

Before anyone voices any licensing concerns, I asked Fraggle before adding it and the conditions remain precisely the same as for GZDoom, which most notably means that Skulltag cannot use it as long as its source remains closed.

[Graf Zahl]

For a general status update, I wouldn't mind merging it back into the trunk but I get some occasional memory allocation errors when running outside the debugger and so far couldn't track down the cause for them.

[kgsws-CZ]

no idea, i use only M_Malloc and TArray in r_3dfloors.cpp

[Graf Zahl]

After endless testing I finally got an error in the debugger:

Heap block at 07CD31F0 modified at 07CE321C past requested size of 10024

Hope that helps. It looks like you allocate something too small. This could also mean that you write into something that has already been freed.

[Graf Zahl]

I did some debugging and I found 2 problems:

1) The ClipStacks are not released properly. The only place where this is done is when the main view's rendering is started. This should be done after any view has been rendered.

2) The code is leaking visplanes. Since the freelist of visplanes gets released I can only assume that something related to the 3D floors forgets to release them to the freelist.

I also added some asserts to see if the 3D floor code might try to access some old data structures but so far they weren't triggered and I didn't get the crash again.

[Graf Zahl]

Ok, both memory leaks are plugged. But I don't think they have anything to do with the heap corruption.

[Edward-san]

I'm trying to compile this with gcc, but i got the following errors when it tries to link all the .o needed to create the executable:

Code: Select all

CMakeFiles/zdoom.dir/p_setup.o: In function `SpawnMapThing(int, FMapThing*, int)':
/home/edward-san/zdoom/branch/3dfloors2/src/p_setup.cpp:1608: undefined reference to `T_AddSpawnedThing(AActor*)'
CMakeFiles/zdoom.dir/p_setup.o: In function `P_SetupLevel(char*, int)':
/home/edward-san/zdoom/branch/3dfloors2/src/p_setup.cpp:3519: undefined reference to `T_LoadScripts(MapData*)'
/home/edward-san/zdoom/branch/3dfloors2/src/p_setup.cpp:3872: undefined reference to `T_PreprocessScripts()'
collect2: ld returned 1 exit status
make[2]: *** [zdoom] Error 1
make[1]: *** [src/CMakeFiles/zdoom.dir/all] Error 2
make: *** [all] Error 2

[Graf Zahl]

That happens because I never use CMake...

[Karl Murks]

Great work all around. I just played through Nimrod with this and it was mostly looking good, except the sprite clipping issues on 3D floors. I hope someone finds a solution here.

However, what I find a bit disappointing is that of all people Randy hasn't said a word about this submission yet. One could get the feeling that Graf has taken over development completely by reading this thread...

[kgsws-CZ]

1) The ClipStacks are not released properly. The only place where this is done is when the main view's rendering is started. This should be done after any view has been rendered.

Right. Clip stack is actually only needed while rendering BSP nodes. Fixing this is very simple.

3Df004.zip

(666 Bytes) Downloaded 75 times

But i have no idea about memory or heap problems.

[Graf Zahl]

I haven't been able to reproduce the crashes yet after properly NULLing all related pointers when the memory is deleted and plugging the memory leaks. Let's just hope it was some undefined access through one of these stray pointers. I'll do some more tests later today to see if I can get it again.

[kgsws-CZ]

I just noticed that you that you already fixed R_3D_ResetClip. Maybe you can change as in my patch (3Df004), you can free ClipStack after each main R_RenderBSPNode.

[Graf Zahl]

I'd really appreciate if someone else could do some more extensive tests here. I've tried to make it crash yesterday evening but it looks like the current version is stable. I couldn't make it crash even once despite changing levels like crazy, saving, reloading etc.

Regarding the last patch, ok, I understand but since this version does not leak memory and doesn't seem to exhibit any other problems I'd rather keep it as it is. Never change a running system unless you have good reasons to do so.

[koverhbarc]

Anyway, I can't play on versions later than 2.5.0 at all until that renderer error is fixed! It's simply ridiculous that I have the 'choice' between windowed mode, which is far too slow on any serious level, or full-screen mode which flashes weird colors every other tic or whatever - it looks to be palette-related as some colors do not flash. What has changed since 2.5.0 affecting this? I doubt it was anything intentional.

No idea. You seem to be the only one having this problem. What's your graphics card?

I don't know but it shouldn't matter with software rendering! There's something broken in ZDoom or, more likely, in a library it uses. I'd like to determine exactly which version broke it but I can't as it seems SVN doesn't allow obtaining old source versions.

I fixed it, knowing it was a palette issue, by setting vid_displaybits=16, but as that also slowed it down (though much less than running in a window) I don't consider it to be a complete solution.