Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
drfrag

New port (sort of) and crash [fixed]

Recommended Posts

 I've made another fork of Chocolate Doom, it's meant to be a short-lived project to create a strong limit removing port but without fixing most bugs in the engine. I just want to prevent the crashes while minimizing code changes. It's based on choco 2.3 and i've been cherry-picking stuff from Crispy Doom.

I haven't even changed the name for now, i've restored the startup console at least for Code::Blocks and fixed the projects. That was easy so may be i'm missing something.

 I get a crash with planisf2.wad i guess due to the numeric overflow crash in tall areas. As soon as i turn left coming out of the lift and face the tall towers. Sometimes i get a R_MapPlane error where y>200 so it's trying to draw below the bottom of the screen.

 I think the wiggle fix would prevent the crash but i only want to fix the crash it that's even possible. I've read the threads about that matter but this is complex stuff and i guess i'm not very clever. Also i don't know the engine well.

 So i hope any of the experts here will help. Thanks.

 The source is at https://github.com/drfrag666/chocolate-doom/tree/cdoom2nl

 And this is the crash log:

>>>>>>cb_gdb:#0  0x0042f289 in R_DrawMaskedColumn (column=0x369a002) at C:\DEV\chocolate-doom\src\doom\r_things.c:372
#1  0x0042d824 in R_RenderMaskedSegRange (ds=0x53a3f50, x1=55, x2=55) at C:\DEV\chocolate-doom\src\doom\r_segs.c:199
#2  0x0042ff4c in R_DrawSprite (spr=0x36d327c) at C:\DEV\chocolate-doom\src\doom\r_things.c:915
#3  0x00430161 in R_DrawMasked () at C:\DEV\chocolate-doom\src\doom\r_things.c:996
#4  0x0042cae2 in R_RenderPlayerView (player=0x52c5a0 <players>) at C:\DEV\chocolate-doom\src\doom\r_main.c:887
#5  0x0040692f in D_Display () at C:\DEV\chocolate-doom\src\doom\d_main.c:244
#6  0x00406e99 in D_DoomLoop () at C:\DEV\chocolate-doom\src\doom\d_main.c:476
#7  0x00408930 in D_DoomMain () at C:\DEV\chocolate-doom\src\doom\d_main.c:1903
#8  0x00437904 in SDL_main (argc=3, argv=0x972ba0) at C:\DEV\chocolate-doom\src\i_main.c:48
#9  0x0045f4e9 in console_main (argc=3, argv=0x972ba0) at ./src/main/win32/SDL_win32_main.c:315
#10 0x0045f5ab in WinMain@16 (hInst=0x400000, hPrev=0x0, szCmdLine=0x2a2513 "-file tmp.wad", sw=10) at ./src/main/win32/SDL_win32_main.c:398
#11 0x0046599b in main ()
>>>>>>cb_gdb:#0  0x0042f289 in R_DrawMaskedColumn (column=0x369a002) at C:\DEV\chocolate-doom\src\doom\r_things.c:372
C:\DEV\chocolate-doom\src\doom\r_things.c:372:8281:beg:0x42f289
>>>>>>cb_gdb:topscreen = 5243858
bottomscreen = 5243858
basetexturemid = -12744852
>>>>>>cb_gdb:column = 0x369a002
>>>>>>cb_gdb:#0  0x0042f289 in R_DrawMaskedColumn (column=0x369a002) at C:\DEV\chocolate-doom\src\doom\r_things.c:372
#1  0x0042d824 in R_RenderMaskedSegRange (ds=0x53a3f50, x1=55, x2=55) at C:\DEV\chocolate-doom\src\doom\r_segs.c:199
#2  0x0042ff4c in R_DrawSprite (spr=0x36d327c) at C:\DEV\chocolate-doom\src\doom\r_things.c:915
#3  0x00430161 in R_DrawMasked () at C:\DEV\chocolate-doom\src\doom\r_things.c:996
#4  0x0042cae2 in R_RenderPlayerView (player=0x52c5a0 <players>) at C:\DEV\chocolate-doom\src\doom\r_main.c:887
#5  0x0040692f in D_Display () at C:\DEV\chocolate-doom\src\doom\d_main.c:244
#6  0x00406e99 in D_DoomLoop () at C:\DEV\chocolate-doom\src\doom\d_main.c:476
#7  0x00408930 in D_DoomMain () at C:\DEV\chocolate-doom\src\doom\d_main.c:1903
#8  0x00437904 in SDL_main (argc=3, argv=0x972ba0) at C:\DEV\chocolate-doom\src\i_main.c:48
#9  0x0045f4e9 in console_main (argc=3, argv=0x972ba0) at ./src/main/win32/SDL_win32_main.c:315
#10 0x0045f5ab in WinMain@16 (hInst=0x400000, hPrev=0x0, szCmdLine=0x2a2513 "-file tmp.wad", sw=10) at ./src/main/win32/SDL_win32_main.c:398
#11 0x0046599b in main ()
>>>>>>cb_gdb:#1  0x0042d824 in R_RenderMaskedSegRange (ds=0x53a3f50, x1=55, x2=55) at C:\DEV\chocolate-doom\src\doom\r_segs.c:199
C:\DEV\chocolate-doom\src\doom\r_segs.c:199:4926:beg:0x42d824
>>>>>>cb_gdb:index = 0
col = 0x32aa279
lightnum = 13
texnum = 136
>>>>>>cb_gdb:ds = 0x53a3f50
x1 = 55
x2 = 55
>>>>>>cb_gdb:#0  0x0042f289 in R_DrawMaskedColumn (column=0x369a002) at C:\DEV\chocolate-doom\src\doom\r_things.c:372
#1  0x0042d824 in R_RenderMaskedSegRange (ds=0x53a3f50, x1=55, x2=55) at C:\DEV\chocolate-doom\src\doom\r_segs.c:199
#2  0x0042ff4c in R_DrawSprite (spr=0x36d327c) at C:\DEV\chocolate-doom\src\doom\r_things.c:915
#3  0x00430161 in R_DrawMasked () at C:\DEV\chocolate-doom\src\doom\r_things.c:996
#4  0x0042cae2 in R_RenderPlayerView (player=0x52c5a0 <players>) at C:\DEV\chocolate-doom\src\doom\r_main.c:887
#5  0x0040692f in D_Display () at C:\DEV\chocolate-doom\src\doom\d_main.c:244
#6  0x00406e99 in D_DoomLoop () at C:\DEV\chocolate-doom\src\doom\d_main.c:476
#7  0x00408930 in D_DoomMain () at C:\DEV\chocolate-doom\src\doom\d_main.c:1903
#8  0x00437904 in SDL_main (argc=3, argv=0x972ba0) at C:\DEV\chocolate-doom\src\i_main.c:48
#9  0x0045f4e9 in console_main (argc=3, argv=0x972ba0) at ./src/main/win32/SDL_win32_main.c:315
#10 0x0045f5ab in WinMain@16 (hInst=0x400000, hPrev=0x0, szCmdLine=0x2a2513 "-file tmp.wad", sw=10) at ./src/main/win32/SDL_win32_main.c:398
#11 0x0046599b in main ()
>>>>>>cb_gdb:#2  0x0042ff4c in R_DrawSprite (spr=0x36d327c) at C:\DEV\chocolate-doom\src\doom\r_things.c:915
C:\DEV\chocolate-doom\src\doom\r_things.c:915:20497:beg:0x42ff4c
>>>>>>cb_gdb:ds = 0x53a3f50
clipbot = {-21854, 572, -1848, -1, -26844, 66, 20059, -32768, -1276, -3786, -16128, 715, 26184, 84, 2749, 0, 2821, -1, 0, 0, -16128, 715, 28258, 2588, -21854, 572, -1800, 35, -26844, 66, -24518, 30642, 25469, 30016, 232, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, 811, 4096, -1, -1, 0, 0, 0, -1, 78, -2, -2, 4096, 0, 108, 0, 26184, 78, 78, 0, 0, -1, -1, 0, -1796, -1, -1, -1, -1, -1, -21056, 30016, -1, -29710, -2, -1, -1, 35, 6767, 30064, 232, -1, -1, 811, 4096, 0, -1676, 35, 0, -1, 3, 0, -1, -1, -1, 0, -1, -1, -1, -1, 108, 0, 0, 0, -1, -1, 6212, 811, 3, -1, 4096, 0, 0, 0, -1652, 35, -10361, 30062, 2144, 151, -1584, -1, 7081, 30064, 3, 0, 7034, 30064, -1, -349, -25496, 30073, 0, 0, 4096, 0, -1, -1, -1, 0, -1, -1, -1636, 35, -10361, 30062, -1476, 35, 29216, -1, -1, -1, -1, -1, 7034, 30064, 17594, 30065, 3, 0, 6212, -1, 4096, -1, 0, 0, -25496, 30073, 4096, 0, -25496, -1, -1, 875, -1532, 35, -17947, 30062, 11384, -1, -1, 35, -198, 30062, 19, 0, -1460, 35, 10329, 30064, -25496, 30073, 10287, 30064, -11016, -349...}
cliptop = {0, 0, 2184, 143, 11648, 1338, 26581, 70, -824, 35, -2472, 35, -16384, 0, 11640, 1338, 0, 143, 98, 16384, 0, 0, 21748, 646, 2184, 0, 337, 0, 0, 0, 26581, 70, -30656, 1338, -2408, 143, 143, 143, 143, 143, 143, 143, 143, 143, 143, 0, 1072, 143, 143, 0, 144, 0, 143, 143, -2, -2, -824, 35, -2376, 35, 14260, 143, 143, -10512, 0, 144, 144, -6624, 0, 144, 144, 144, 144, 144, 336, 0, 144, 0, 26581, 70, 144, 35, -2328, 35, 14260, 144, 144, -6624, 143, 0, 24437, 28153, 0, 144, 11648, 1338, 144, 144, 144, 0, 144, 144, 144, 144, -28544, 1338, -2280, 35, 144, 69, -6656, 371, 8, 143, 2652, 74, 418, 0, 9218, 85, 72, 0, -84, 874, -6656, 143, 26581, 70, 337, 0, -2232, 35, 143, 66, 2335, 0, 8, 0, 12429, 27971, 143, 143, 143, 85, 143, 143, 1996, 0, -72, -1, 1, 0, -824, 143, 143, 143, 143, 66, 53, 0, 13, 0, 9863, 27992, 0, 143, 2109, 143, 72, 0, 144, 0, 653, 0, 61, 143, 143, 0, 144, 0, 0, 0, 1, 143, 143, 4, -2104, 35, -6020, 66, 25784, 1331, 56, 0, 57, 0, 251, 0, 144, 0...}
x = 56
r1 = 55
r2 = 55
scale = 2701
lowscale = 2701
silhouette = 3
>>>>>>cb_gdb:spr = 0x36d327c
>>>>>>cb_gdb:#0  0x0042f289 in R_DrawMaskedColumn (column=0x369a002) at C:\DEV\chocolate-doom\src\doom\r_things.c:372
#1  0x0042d824 in R_RenderMaskedSegRange (ds=0x53a3f50, x1=55, x2=55) at C:\DEV\chocolate-doom\src\doom\r_segs.c:199
#2  0x0042ff4c in R_DrawSprite (spr=0x36d327c) at C:\DEV\chocolate-doom\src\doom\r_things.c:915
#3  0x00430161 in R_DrawMasked () at C:\DEV\chocolate-doom\src\doom\r_things.c:996
#4  0x0042cae2 in R_RenderPlayerView (player=0x52c5a0 <players>) at C:\DEV\chocolate-doom\src\doom\r_main.c:887
#5  0x0040692f in D_Display () at C:\DEV\chocolate-doom\src\doom\d_main.c:244
#6  0x00406e99 in D_DoomLoop () at C:\DEV\chocolate-doom\src\doom\d_main.c:476
#7  0x00408930 in D_DoomMain () at C:\DEV\chocolate-doom\src\doom\d_main.c:1903
#8  0x00437904 in SDL_main (argc=3, argv=0x972ba0) at C:\DEV\chocolate-doom\src\i_main.c:48
#9  0x0045f4e9 in console_main (argc=3, argv=0x972ba0) at ./src/main/win32/SDL_win32_main.c:315
#10 0x0045f5ab in WinMain@16 (hInst=0x400000, hPrev=0x0, szCmdLine=0x2a2513 "-file tmp.wad", sw=10) at ./src/main/win32/SDL_win32_main.c:398
#11 0x0046599b in main ()
>>>>>>cb_gdb:

 

Edited by drfrag

Share this post


Link to post

WiggleFix will allow sector heights up to 32767, but I seem to remember there also being some other limits to overcome for planisf2 (blockmap, maybe?) When you get it working, do you mind posting a log of what you had to do to get planisf2 rendering properly? Thanks in advance.

Share this post


Link to post

 Actually i think you're the expert and the one who can help me. :)

 There's some old code from crispy to re-create the blockmap, sure there was an overflow, the changelog is the commit history.

 But i don't want to apply that wiggle fix becouse no wiggle no fun you know. :D I don't want to fix the rendering errors only fatal errors to avoid crashes.

 I need a simplified version of the fix or a hack to prevent the crash even with massive rendering errors on that map as soon as is half playable.

 Else it would be just a crispy clone and i want to keep this as close as vanilla as possible.

 I tried to use 32 bit math and to extend the srttop fix but that didn't help. May be those are not needed to get the map running properly.

 Which maps could i try? I've tried a bit nova, nova 2 and deus vult (map 05) but not much. Planisphere is somewhat extreme i know.

 I also need to fix the lack of indenting in a few files but i can't right now to prevent conflicts, sure there were some serious ones but it should be okay.

 Thanks.

 

Share this post


Link to post

The original renderer had a clamp added by Carmack, that prevented the wall texture calculations from overflowing when the view angle became too steep, or the sector height became too large. Instead of using the proper denominator, the code swaps in a small, nonsense number just to prevent crash. The wiggle occurs because of this nonsense number being used.

 

Unfortunately for your goals, the wiggle is directly tied to the sector height crashes - they are two sides of the same coin. Wigglefix dynamically adjusts the texture calculations, to allow for the best possible precision, without crash, yet it also goes the other direction, and allows for maximum height sectors (with much worse precision). In other words, the more "wiggle protection" you have, the shorter the sectors can be, before a crash will occur. You can't have one without the other.

 

Your other option is to use floating point for the variables that Wigglefix adjusts, which will also serve to reduce wiggle, probably better than Wigglefix would. But, then, you're using floating point math A LOT, which may or may not slow down rendering.

 

Instead of using floating point, I chose to build Wigglefix, for speed, and for the possibly misguided notion of keeping the renderer as close to vanilla as possible. Personally, as much of a "vanilla purist" as I am, I have no desire to emulate wiggle. Wiggle is also affected by resolution, and, in 320x200 mode, it is hardly noticeable. So, one could argue that using a higher resolution is just as non-purist as fixing wiggle. One could also argue that, since the effect is almost non-existent in 320x200, removing wiggle for higher resolutions IS emulating vanilla!

 

Now, you could always implement WiggleFix, and then reintroduce the clamp on top of it, thereby eliminating crashes due to tall sectors/high resolutions, while emulating the original wiggle. But, again, I see no benefit, and feel no nostalgia for that horrible looking wiggle, that makes walking down tiny rails nearly impossible.

 

It's actually sector height difference that matters. The original clamp, at the original resolution allows for, I think, a difference of 8192 units max. I don't know what the biggest difference is in Planisf2.wad. But if you allow higher resolutions, you'll need some solution, whether it's WiggleFix, 64-bit fixed-point (also slow, maybe), floating-point, wiggle-inducing clamps, etc. Sure, you can also range check, but what do you do with that information? HOM?

 

Hope this makes sense. Please let me know.

Share this post


Link to post

 Thanks, that makes a lot of sense but unfortunately it still crashes and it's pretty much the same crash.

 I've applied the patches i mentioned and it's not a bad merge.

 Initially i got an error message in r_draw.c:

R_Drawcolumn: 26 to 25172 at 6
#ifdef RANGECHECK 
    if ((unsigned)dc_x >= SCREENWIDTH
	|| dc_yl < 0
	|| dc_yh >= SCREENHEIGHT) 
	I_Error ("R_DrawColumn: %i to %i at %i", dc_yl, dc_yh, dc_x); 
#endif

 Then the crash:

>>>>>>cb_gdb:#0  0x0042f6e2 in R_DrawMaskedColumn (column=0x3664fff) at C:\DEV\chocolate-doom\src\doom\r_things.c:377
#1  0x0042daa3 in R_RenderMaskedSegRange (ds=0x525cc28, x1=4, x2=4) at C:\DEV\chocolate-doom\src\doom\r_segs.c:293
#2  0x00430709 in R_DrawMasked () at C:\DEV\chocolate-doom\src\doom\r_things.c:1003
#3  0x0042cc9b in R_RenderPlayerView (player=0x52c5c0 <players>) at C:\DEV\chocolate-doom\src\doom\r_main.c:891
#4  0x0040693b in D_Display () at C:\DEV\chocolate-doom\src\doom\d_main.c:244
#5  0x00406ea5 in D_DoomLoop () at C:\DEV\chocolate-doom\src\doom\d_main.c:476
#6  0x0040897c in D_DoomMain () at C:\DEV\chocolate-doom\src\doom\d_main.c:1906
#7  0x00437e78 in SDL_main (argc=3, argv=0x3e2ba0) at C:\DEV\chocolate-doom\src\i_main.c:48
#8  0x0045fa09 in console_main (argc=3, argv=0x3e2ba0) at ./src/main/win32/SDL_win32_main.c:315
#9  0x0045facb in WinMain@16 (hInst=0x400000, hPrev=0x0, szCmdLine=0x962523 "-file planisf2.wad", sw=10) at ./src/main/win32/SDL_win32_main.c:398
#10 0x00465ebb in main ()
>>>>>>cb_gdb:#4  0x0040693b in D_Display () at C:\DEV\chocolate-doom\src\doom\d_main.c:244
C:\DEV\chocolate-doom\src\doom\d_main.c:244:5704:beg:0x40693b
>>>>>>cb_gdb:viewactivestate = true
menuactivestate = false
inhelpscreensstate = false
fullscreen = false
oldgamestate = GS_LEVEL
borderdrawcount = 0
nowtime = 64
tics = 143
wipestart = 8
y = 31921800
done = (unknown: 4893184)
wipe = false
redrawsbar = false
>>>>>>cb_gdb:No arguments.
>>>>>>cb_gdb:#0  0x0042f6e2 in R_DrawMaskedColumn (column=0x3664fff) at C:\DEV\chocolate-doom\src\doom\r_things.c:377
#1  0x0042daa3 in R_RenderMaskedSegRange (ds=0x525cc28, x1=4, x2=4) at C:\DEV\chocolate-doom\src\doom\r_segs.c:293
#2  0x00430709 in R_DrawMasked () at C:\DEV\chocolate-doom\src\doom\r_things.c:1003
#3  0x0042cc9b in R_RenderPlayerView (player=0x52c5c0 <players>) at C:\DEV\chocolate-doom\src\doom\r_main.c:891
#4  0x0040693b in D_Display () at C:\DEV\chocolate-doom\src\doom\d_main.c:244
#5  0x00406ea5 in D_DoomLoop () at C:\DEV\chocolate-doom\src\doom\d_main.c:476
#6  0x0040897c in D_DoomMain () at C:\DEV\chocolate-doom\src\doom\d_main.c:1906
#7  0x00437e78 in SDL_main (argc=3, argv=0x3e2ba0) at C:\DEV\chocolate-doom\src\i_main.c:48
#8  0x0045fa09 in console_main (argc=3, argv=0x3e2ba0) at ./src/main/win32/SDL_win32_main.c:315
#9  0x0045facb in WinMain@16 (hInst=0x400000, hPrev=0x0, szCmdLine=0x962523 "-file planisf2.wad", sw=10) at ./src/main/win32/SDL_win32_main.c:398
#10 0x00465ebb in main ()
>>>>>>cb_gdb:#1  0x0042daa3 in R_RenderMaskedSegRange (ds=0x525cc28, x1=4, x2=4) at C:\DEV\chocolate-doom\src\doom\r_segs.c:293
C:\DEV\chocolate-doom\src\doom\r_segs.c:293:8498:beg:0x42daa3
>>>>>>cb_gdb:index = 0
col = 0x30db80d
lightnum = 10
texnum = 262
>>>>>>cb_gdb:ds = 0x525cc28
x1 = 4
x2 = 4
>>>>>>cb_gdb:#0  0x0042f6e2 in R_DrawMaskedColumn (column=0x3664fff) at C:\DEV\chocolate-doom\src\doom\r_things.c:377
#1  0x0042daa3 in R_RenderMaskedSegRange (ds=0x525cc28, x1=4, x2=4) at C:\DEV\chocolate-doom\src\doom\r_segs.c:293
#2  0x00430709 in R_DrawMasked () at C:\DEV\chocolate-doom\src\doom\r_things.c:1003
#3  0x0042cc9b in R_RenderPlayerView (player=0x52c5c0 <players>) at C:\DEV\chocolate-doom\src\doom\r_main.c:891
#4  0x0040693b in D_Display () at C:\DEV\chocolate-doom\src\doom\d_main.c:244
#5  0x00406ea5 in D_DoomLoop () at C:\DEV\chocolate-doom\src\doom\d_main.c:476
#6  0x0040897c in D_DoomMain () at C:\DEV\chocolate-doom\src\doom\d_main.c:1906
#7  0x00437e78 in SDL_main (argc=3, argv=0x3e2ba0) at C:\DEV\chocolate-doom\src\i_main.c:48
#8  0x0045fa09 in console_main (argc=3, argv=0x3e2ba0) at ./src/main/win32/SDL_win32_main.c:315
#9  0x0045facb in WinMain@16 (hInst=0x400000, hPrev=0x0, szCmdLine=0x962523 "-file planisf2.wad", sw=10) at ./src/main/win32/SDL_win32_main.c:398
#10 0x00465ebb in main ()
>>>>>>cb_gdb:#0  0x0042f6e2 in R_DrawMaskedColumn (column=0x3664fff) at C:\DEV\chocolate-doom\src\doom\r_things.c:377
C:\DEV\chocolate-doom\src\doom\r_things.c:377:8640:beg:0x42f6e2
>>>>>>cb_gdb:topscreen = 5458922
bottomscreen = 5458922
basetexturemid = 6774236
>>>>>>cb_gdb:column = 0x3664fff
>>>>>>cb_gdb:#0  0x0042f6e2 in R_DrawMaskedColumn (column=0x3664fff) at C:\DEV\chocolate-doom\src\doom\r_things.c:377
#1  0x0042daa3 in R_RenderMaskedSegRange (ds=0x525cc28, x1=4, x2=4) at C:\DEV\chocolate-doom\src\doom\r_segs.c:293
#2  0x00430709 in R_DrawMasked () at C:\DEV\chocolate-doom\src\doom\r_things.c:1003
#3  0x0042cc9b in R_RenderPlayerView (player=0x52c5c0 <players>) at C:\DEV\chocolate-doom\src\doom\r_main.c:891
#4  0x0040693b in D_Display () at C:\DEV\chocolate-doom\src\doom\d_main.c:244
#5  0x00406ea5 in D_DoomLoop () at C:\DEV\chocolate-doom\src\doom\d_main.c:476
#6  0x0040897c in D_DoomMain () at C:\DEV\chocolate-doom\src\doom\d_main.c:1906
#7  0x00437e78 in SDL_main (argc=3, argv=0x3e2ba0) at C:\DEV\chocolate-doom\src\i_main.c:48
#8  0x0045fa09 in console_main (argc=3, argv=0x3e2ba0) at ./src/main/win32/SDL_win32_main.c:315
#9  0x0045facb in WinMain@16 (hInst=0x400000, hPrev=0x0, szCmdLine=0x962523 "-file planisf2.wad", sw=10) at ./src/main/win32/SDL_win32_main.c:398
#10 0x00465ebb in main ()
>>>>>>cb_gdb:

 Note that topscreen and bottomscreen seem to contain a crazy value (5458922).

 Does the backtrace says something meaningful to you?

 It's pretty much the same, any ideas? Thanks.

 I've updated https://github.com/drfrag666/chocolate-doom/commits/cdoom2nl

 

Edit: again which demanding maps should i try?

Edited by drfrag

Share this post


Link to post

It should not be able to crash due to height, if WiggleFix is applied. Did you also grow the shorts to ints? I should really update that thread, because when I wrote it, I wasn't sure if the move from shorts to ints was necessary, but it was verified that this was required.

 

My best advice is to use the Crispy Doom source and compare the arrays and vars used for texturing and column spans in particular. They need to become 32-bit. I wish I could give you a list, but right now I cannot. That may feel like it's out-of-scope for what your goals are, but, without this, you're going to continually have these types of issue, especially with the modern largeish maps. There is also a division that needs to be 64-bit. From memory, look for sprtopscreen in Crispy source.

 

And, yes, with some adjustments, you might get WiggleFix to work without moving to 32-bit vars, but I don't recommend it. You might also consider Linguica's long wall fix.

 

When I developed WiggleFix, I started from a point where I had already grown some arrays to 32-bit, so when it came time to write the thread, I wasn't sure how far my source deviated from vanilla. Sorry about that. The error above suggests an overflow situation - trying to draw far below the screen. To exactly trace the cause, you have to set up a scene, from start, or from save game load, and then you have to backtrack to find the calculations that lead to that large y value.

 

Alternately, you could add a clamp instead of the Range error, preventing the crash, but it's not going to display properly.

 

Hope this helps. Unfortunately I don't have time to take a detailed look at your source right now, so try to find and grow the vars and arrays, and add that 64-bit calc, by checking your source against Crispy, which also strives for minimal source changes. That should fix this overflow. If not, let me know, and I'll try to take a quick look.

Share this post


Link to post

Please name your port, so I can name my folders accordingly!

 

Ok, I do see your changelog, and it looks like you are on the right track. You should be able to test WiggleFix easily on Doom II MAP 01, by jumping down to the diagonal steps where the first pistolguys are, and lining up the player to look directly parallel to a step. Then sidestep a bit. Especially if you are in a higher resolution, you'd see some ugly wiggling and tearing. This should have disappeared since WiggleFix.

 

On the other end of the spectrum, open up Doom's E1M1 in a map editor. Edit the outdoor nukage pit, by setting the floor of that sector to -20000 or something. This should make a very deep pit. Save the map and run it in your port. NoClip, and walk along the edges of the pit. If it crashes, or if you see full height flashing "color bars", or strange diagonal streaks covering the screen, something's still missing in your WiggleFix implementation. Basically, this setup should render without color bars, streaks, or crashes. The only legitimate possible issue is that on the walls inside the pit, the texture might wiggle a bit - this is the other half of the tradeoff for allowing huge sector height differences.

 

NOTE: Don't go further than 32767, in Abs(PitCeiling-PitFloor), or for adjacent sectors, or it WILL crash. A single adjustment of WiggleFix would allow for changes >= 32768, but other Doom physics fail in these situations, so I didn't bother.

 

Please let me know when you get, at least those tests working. I would like to check out your port when I get a chance.

Share this post


Link to post

 Thanks very much, the wiggle fix is working fine. No wiggle and no crash on the maps you suggested.

 The range error was after the initial wiggle fix commit, then the same crash as before.

 Seems like the fix was not needed after all and it's something different. If i apply the long wall fix inmediate crash on every map, more changes would be needed before. But that's not the problem.

 The towers are definitely screwed but they are only 3000 units tall. I managed to take some screenshots but if i look to the right it crashes. Do you now what's going on?

 Let's name this thing Doom++ for now. Regards.

https://imgur.com/a/R2H2gMZ

 

 Edit: i've added more screenshots, i've managed to walk a lot around without crashing. Seems that when something happens it won't crash even at the start area. The map is really screwed, depending on where you look at. With big walls in the sky in wrong places and dissapearing sprites. Does this remember you something?

 Values for those screen variables were normal, even basetexturemid can be negative.

Edit2: i've managed to avoid the crash starting a new game and then loading a savegame facing a wall in a different area. If i load the savegame directly it crashes.

Edited by drfrag

Share this post


Link to post

 Now i think is an overflow in rw_distance in R_StoreWallRange in r_segs.c. Of course i'm not sure, the rw_distance value is 1247936511. May be in crispy the overflow was less severe and only caused rendering errors. The fix there is built on the wall wobble fix but that wobble fix is not applicable here since it causes an inmediate crash on all maps dunno why. It's the 'Fix rendering error casued by overflow of the rw_distance variable' in crispy but GitHub search doesn't work in forks. Do you know how to fix the overflow? I don't. Thanks.

Edited by drfrag

Share this post


Link to post
51 minutes ago, drfrag said:

the rw_distance value is 1247936511.

 

This sounds bad.

 

Remember that the code has stuff like:

    hyp = R_PointToDist (curline->v1->x, curline->v1->y);
    rw_distance = FixedMul (hyp, sineval);

Where FixedMul() is a fixed-point multiplication function. If you're gonna have distances wildly outside the normal Doom map range, you need to make sure everywhere in the rendering pipeline where there's stuff like this is accounted for.

Share this post


Link to post

 Thanks for confirming the overflow, there's only a long wall about 17000 units long and i was not facing that direction so i guess it's just the map is too big? Also doing that new game/load game trick there's no crash. The problem is i don't know how to keep the overflow at bay without the wooble fix, something is missing since with that fix all maps crash.

Share this post


Link to post

 Some progress, i think, now i've applied the wooble fix and the game still works (it was a quick bad merge) but Planisphere 2 crashes as soon as i start a new game. Crispy 3.0 also crashes and probably is the same crash. How do i test the wooble fix?

 Now a get a division by zero calculating rw_distance where curline->length is zero. I've tracked it down to li->length in p_setup.c. What's next? Should i apply the slime trail fix?

 Edit: Now sunder map14 also crashes (didn't before neither in crispy so it was not the same crash). May be this is a regression.

 Edit2: removed the backtrace, this crash is fixed.

Edited by drfrag

Share this post


Link to post

 I don't know what's going on but i've set two breakpoints: one at li->length = (fixed_t)sqrt((double)dx*dx + (double)dy*dy); in p_setup.c and another one at dist = (dy * dx1 - dx * dy1) / curline->length; in r_segs.c.

 For non crashing maps it stops at the first one, for crashing ones at the second. I'm using tdm-gcc 5.1 and Code::Blocks.

Edited by drfrag

Share this post


Link to post

 I've fixed that crash, it happened on maps with zero size or very big SEGS lumps. I had to debug the damn thing for a while. Now back to the starting point but with the wobble fix, but i think now it's even worse.

Now rw_distance is a uint32_t but i think the problem with the crash is not there. Sprites dissapear a lot with the savegame. rw_distance =1563838844, curline->length = 92681.

 Crashes at for ( ; column->topdelta != 0xff ; ) in r_things.c and i'm using the original draw functions.

 Note that x1=x2 in R_RenderMaskedSegRange, could that be a problem? Any ideas? Thanks.

 Edit: fixed the crash.

Edited by drfrag

Share this post


Link to post

 It's fixed, i've applied the medusa fix. However that map is unplayable due to massive rendering errors, mainly HOM i guess. The main problem is sprites dissapearing here and there.

 Some serious conflicts due to not following history but should be fine.

 Now i shoud choose a name, what about chocochewy or doom++? :)

Share this post


Link to post

Here's what happens: A port adds a new rendering ability or limit removal. Then, mappers release maps that depend on those enhancements. Then, another limit is removed, and another map released that depends on both enhancements. Rinse and repeat.

 

So, there's now a situation where there are massive maps that require ALL known enhancements. These maps push everything right up to the limits. So, you have to decide how vanilla your renderer will be vs. which maps do you want to play. In other words, you simply cannot load some maps without the enhancements.

 

As far as the large numbers go, I don't know if this applies or not, but I'll put it out there: The WiggleFix code scales the vars to be as large as possible without crashing, by moving the "fixed decimal point". So, you cannot really expect the texturing numbers to stay in a certain range, without also considering the current scale being used.

 

Have you implemented a HOM detector in your port? (When enabled, the output buffer is pre-filled with red for a few tics, then black for a few tics, alternating between the two.) By pre-filling the buffer with solid colors, any area of the screen that has not been filled by texture or flat will flash, making HOM very obvious.

 

On disappearing sprites: Did you remove the sprite limit (MAXVISSPRITES, I think)? Also, is your port rebuilding the BLOCKMAP? If I remember correctly, this requires a more advanced BLOCKMAP builder than MBF's, due to sheer size.

Share this post


Link to post

 Thanks, it was the SlopeDiv overflow. It's fixed now and the map is playable i think. But i have not fixed HOMs nor slime trails.

Share this post


Link to post
On 6/11/2018 at 1:54 PM, drfrag said:

Now i shoud choose a name, what about chocochewy or doom++? :)

I know this is a very minor thing, but I have a suggestion for a name: Doom# (Doom Sharp).

Mode of thinking goes you initially named it Doom++, which reminds me of C++. Personally, I think the + has been done to death and back, so I thought, "Well, C++ heavily influenced C#, so maybe Doom# would be a nice name, being influenced by Doom++."

Just my opinion on the name.

Share this post


Link to post
3 hours ago, Aquila Chrysaetos said:

Doom++

Please not, I'd consider this way too generic.

Share this post


Link to post

I suggest Choconocrash, it's the mission statement summarized as a single word.

Share this post


Link to post
21 minutes ago, Grain of Salt said:

"Milk Chocolate"

Heh, I like it how there will always be a name suggestion that's food related for a Chocolate Doom fork.

I've got to admit though, that does sound tasty.

Share this post


Link to post

DrDoom, or DrFragDoom.

StableDoom.

SolidDoom.

DoomSolid.

 

Names are difficult!

Share this post


Link to post

 I didn't heard about that Doom+, what about QDDoom (Quick N' Dirty Doom)?

 Just kidding, i've already got a name. It's catchy and fits very well and has nothing to do with food. :)

 I had the name years ago for a port i never did with some crazy features. I'll create a thread later to explain things and i plan to do a release very soon.

 I hope it won't crash (it should be fine) but i'll explain later.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×