HODE warpos

Cowcat · 15 April 2020, 20:19

Heart Of Darkness Engine.

Give it a try: I have it working with WinUAE warpos, but could not work as supposed to be for other environments (wrong colors, etc).

Needs all *_hod. files and hod.paf from original game or demo files inside a DATA dir.

Of course thanks to "Modern Vintage Gamer" for the release of the XBOX SDL1 source.

Upgrade beta6:

grelbfarlk · 16 April 2020, 01:33

Works pretty well! Played in a window on 16bpp LE Workbench with a joystick for a while on Ragnarok/Voodoo3 system. Did get a crash at exit, sonnetlib complaining PPC Memory List Corruption Detected and it threw an exception.

Pyromania · 16 April 2020, 01:46

Cool news, I’ll try it.

grelbfarlk · 16 April 2020, 02:33

One issue I've noticed is that regardless of the scaler setting it seems to want a window or a screen at 800x600 the extra space is just black. Would be nice if XBR mode did not require 32bpp but that seems what is set in the original source, don't know if that would be easy to fix.

Cowcat · 16 April 2020, 09:38

@grelbfarlk Good that it works for 98% systems out there.

What I know:
- It crashes on exit.
- The extra black spaces.
- Hardcoded to 800x600 and 16 bpp.
- Path directory is hardcoded to DATA (no config file is re-created): Use provided hode.ini to change fullscreen or other settings.
- Thought XBR mode worked, but it turned out only on earlier versions: Needed to cheat the code with a 16bit screen AND 32 bit surface with 16 bit masking. 32/32 was too slow for normal systems. 16/16 gives a mangled display, so what the hell.....

Hedeon · 17 April 2020, 23:24

Seems to work nicely and fast on my Ragnarok with Radeon 9200.

grelbfarlk · 20 April 2020, 00:49

Quote:

Originally Posted by Hedeon

Seems to work nicely and fast on my Ragnarok with Radeon 9200.

Do you or anyone else get the crash on exit or is that just me?

Hedeon · 20 April 2020, 09:04

It crashes on exit, yes.

funK · 20 April 2020, 15:54

Quote:

Originally Posted by Hedeon

It crashes on exit, yes.

This is the exception thrown on my machine:

Quote:

Code:

PowerPC Data access exception (load operation)
Page fault - Access to FAFF4000
The excepting instruction is located at 70CAC30C
Task name: 'hode_wos_PPC1'  Task address: 70F974F0  Task ID: 105

SRR0: 70CAC30C    SRR1:  0000F070     MSR:   00003040    HID0: 0040C000
PVR:  00070201    DAR:   FAFF4000     DSISR: 40000000    SDR1: 7140003F
DEC:  00013DDA    TBU:   00000000     TBL:   38925798    XER:  00000000
CR:   88000444    FPSCR: 82004000     LR:    70CA76FC    CTR:  00000000

R0-R3:   70CA76FC 71A53854 70F979A8 71B5A018   IBAT0: 00001FFF 00000022
R4-R7:   71B5A018 FAFF4000 FAFF4000 71B5A138   IBAT1: 00000000 00000000
R8-R11:  00000040 70DB0000 75D90000 00000000   IBAT2: 00000000 00000000
R12-R15: 00000008 71A539AC 70CA8310 70CAC72C   IBAT3: 00000000 00000000
R16-R19: 71A53DC0 0000004C 00000000 00000000   DBAT0: 00001FFF 0000002A
R20-R23: 00000000 00000000 0B0C2A10 132B1114   DBAT1: 00000000 00000000
R24-R27: 27111422 0C0F1805 07130002 70CA768C   DBAT2: 00000000 00000000
R28-R31: 71B5A020 71B5A020 70E67200 70E67200   DBAT3: 00000000 00000000

F0-F3:     0              QNAN             1.0000 E 0      3.0643 E-313
F4-F7:     4.2439 E-314    9.3546 E-315    8.1912 E 235    4.3120 E 235
F8-F11:    4.3120 E 235    0               0               4.5035 E 15
F12-F15:   0               0               0               0
F16-F19:   0               0               0               0
F20-F23:   0               0               0               0
F24-F27:   0               0               0               0
F28-F31:   0               0               0               0

Warp-OS                                              2001 by Sam Jordan

And here I have a lot of Enforcer hits on startup, too:

Quote:

Code:

17-Apr-20  09:55:08
LONG WRITE to  000000C8        data=000000C0   PC: 00FE814C
USP : 71A0ADE0 SR: 0000  (U0)(-)(-)  TCB: 70FC2000
Data: 000C061A 02000001 000C061A 00000000 0000021C 71A53B90 71991880 70E7C668
Addr: 000000C0 71A53BB0 00000000 00000000 718F67CC 70C95394 7004B974 70002654
Stck: 00FDDD60 000000C0 70DB0000 70E7C668 7198B74C 00FCF360 00000000 000C061A
Stck: 70C953AC 00000100 71A0AE14 70E76560 70CAC72C 2E7A0008 4EF970C9 81C871A0
PC-8: 48E70022 2C6E0570 4CEF0700 000C4EAE FF284CDF 44004E75 206F0004 42A80004
PC *: 21480008 58882108 4E750000 00000000 01020404 02040402 80000020 18168001
00fe813c :  ff28 4cdf                  usave $4cdf(a0) ;extended opcode
00fe8140 :  4400                       neg.b d0
00fe8142 :  4e75                       rts
00fe8144 :  206f 0004                  movea.l $4(a7),a0
00fe8148 :  42a8 0004                  clr.l $4(a0)
00fe814c : *2148 0008                  move.l a0,$8(a0)
00fe8150 :  5888                       addq.l #$4,a0
00fe8152 :  2108                       move.l a0,-(a0)
00fe8154 :  4e75                       rts
00fe8156 :  0000 0000                  ori.b #$0,d0
00fe815a :  0000 0102                  ori.b #$2,d0
Name: "Background CLI"  CLI: "hode_wos"


17-Apr-20  09:55:08
LONG WRITE to  000000C0        data=000000C4   PC: 00FE8152
USP : 71A0ADE0 SR: 0000  (U0)(-)(-)  TCB: 70FC2000
Data: 000C061A 02000001 000C061A 00000000 0000021C 71A53B90 71991880 70E7C668
Addr: 000000C4 71A53BB0 00000000 00000000 718F67CC 70C95394 7004B974 70002654
Stck: 00FDDD60 000000C0 70DB0000 70E7C668 7198B74C 00FCF360 00000000 000C061A
Stck: 70C953AC 00000100 71A0AE14 70E76560 70CAC72C 2E7A0008 4EF970C9 81C871A0
PC-8: 05704CEF 0700000C 4EAEFF28 4CDF4400 4E75206F 000442A8 00042148 00085888
PC *: 21084E75 00000000 00000102 04040204 04028000 00201816 80011817 E0011818
00fe8142 :  4e75                       rts
00fe8144 :  206f 0004                  movea.l $4(a7),a0
00fe8148 :  42a8 0004                  clr.l $4(a0)
00fe814c :  2148 0008                  move.l a0,$8(a0)
00fe8150 :  5888                       addq.l #$4,a0
00fe8152 : *2108                       move.l a0,-(a0)
00fe8154 :  4e75                       rts
00fe8156 :  0000 0000                  ori.b #$0,d0
00fe815a :  0000 0102                  ori.b #$2,d0
00fe815e :  0404 0204                  subi.b #$4,d4
Name: "Background CLI"  CLI: "hode_wos"


17-Apr-20  09:55:08
LONG WRITE to  0000005A        data=000000AC   PC: 00FDDD64
USP : 71A0ADE4 SR: 0000  (U0)(-)(-)  TCB: 70FC2000
Data: 000C061A 02000001 000C061A 00000000 0000021C 71A53B90 71991880 70E7C668
Addr: 000000AC 71A53BB0 00000000 00000000 718F67CC 70C95394 7004B974 70002654
Stck: 000000C0 70DB0000 70E7C668 7198B74C 00FCF360 00000000 000C061A 70C953AC
Stck: 00000100 71A0AE14 70E76560 70CAC72C 2E7A0008 4EF970C9 81C871A0 AE0C0D8C
PC-8: 76004A82 67404AAA 005A661C 157C0002 00BA486A 00C04EB9 00FE8144 41EA00AC
PC *: 2548005A 7601588F 4AAA0056 66184EB9 00FE7644 25400056 660C4A83 670442AA
00fddd52 :  0002 00ba                  ori.b #-$46,d2
00fddd56 :  486a 00c0                  pea.l $c0(a2)
00fddd5a :  4eb9 00fe 8144             jsr $fe8144
00fddd60 :  41ea 00ac                  lea.l $ac(a2),a0
00fddd64 : *2548 005a                  move.l a0,$5a(a2)
00fddd68 :  7601                       moveq.l #$1,d3
00fddd6a :  588f                       addq.l #$4,a7
00fddd6c :  4aaa 0056                  tst.l $56(a2)
00fddd70 :  6618                       bne.s $fddd8a
00fddd72 :  4eb9 00fe 7644             jsr $fe7644
Name: "Background CLI"  CLI: "hode_wos"


17-Apr-20  09:55:08
LONG READ from 00000056                        PC: 00FDDD6C
USP : 71A0ADE8 SR: 0000  (U0)(-)(-)  TCB: 70FC2000
Data: 000C061A 02000001 000C061A 00000001 0000021C 71A53B90 71991880 70E7C668
Addr: 000000AC 71A53BB0 00000000 00000000 718F67CC 70C95394 7004B974 70002650
Stck: 70DB0000 70E7C668 7198B74C 00FCF360 00000000 000C061A 70C953AC 00000100
Stck: 71A0AE14 70E76560 70CAC72C 2E7A0008 4EF970C9 81C871A0 AE0C0D8C 71A0AED0
PC-8: 005A661C 157C0002 00BA486A 00C04EB9 00FE8144 41EA00AC 2548005A 7601588F
PC *: 4AAA0056 66184EB9 00FE7644 25400056 660C4A83 670442AA 005A7000 60302F02
00fddd5a :  4eb9 00fe 8144             jsr $fe8144
00fddd60 :  41ea 00ac                  lea.l $ac(a2),a0
00fddd64 :  2548 005a                  move.l a0,$5a(a2)
00fddd68 :  7601                       moveq.l #$1,d3
00fddd6a :  588f                       addq.l #$4,a7
00fddd6c : *4aaa 0056                  tst.l $56(a2)
00fddd70 :  6618                       bne.s $fddd8a
00fddd72 :  4eb9 00fe 7644             jsr $fe7644
00fddd78 :  2540 0056                  move.l d0,$56(a2)
Name: "Background CLI"  CLI: "hode_wos"


17-Apr-20  09:55:08
LONG WRITE to  00000056        data=70E67240   PC: 00FDDD78
USP : 71A0ADE8 SR: 0000  (U0)(-)(-)  TCB: 70FC2000
Data: 70E67240 BFFFFFFF 000C061A 00000001 0000021C 71A53B90 71991880 70E7C668
Addr: 70E67240 70E67254 00000000 00000000 718F67CC 70C95394 7004B974 70002654
Stck: 70DB0000 70E7C668 7198B74C 00FCF360 00000000 000C061A 70C953AC 00000100
Stck: 71A0AE14 70E76560 70CAC72C 2E7A0008 4EF970C9 81C871A0 AE0C0D8C 71A0AED0
PC-8: 00C04EB9 00FE8144 41EA00AC 2548005A 7601588F 4AAA0056 66184EB9 00FE7644
PC *: 25400056 660C4A83 670442AA 005A7000 60302F02 2F0A4878 001B4EB9 00FD5D64
00fddd68 :  7601                       moveq.l #$1,d3
00fddd6a :  588f                       addq.l #$4,a7
00fddd6c :  4aaa 0056                  tst.l $56(a2)
00fddd70 :  6618                       bne.s $fddd8a
00fddd72 :  4eb9 00fe 7644             jsr $fe7644
00fddd78 : *2540 0056                  move.l d0,$56(a2)
00fddd7c :  660c                       bne.s $fddd8a
00fddd7e :  4a83                       tst.l d3
00fddd80 :  6704                       beq.s $fddd86
00fddd82 :  42aa 005a                  clr.l $5a(a2)
00fddd86 :  7000                       moveq.l #$0,d0
Name: "Background CLI"  CLI: "hode_wos"


17-Apr-20  09:55:08
LONG WRITE to  00000052        data=000C061A   PC: 00FDDDCA
USP : 71A0AD30 SR: 0000  (U0)(-)(-)  TCB: 70FC2000
Data: 000C061A 00000024 71A0ADCE 000C061A 70DB0000 71A53B90 71991880 70E7C668
Addr: 71A0AD98 7004B974 00000000 7004B974 718F67CC 71A0ADD4 7004B974 70002654
Stck: 00000000 00FD7316 00000000 000C061A 00FD6314 00000000 000C061A 7004B974
Stck: 00FD704C 718F67CC 00FD7982 0000001B 00000000 71A0AD98 7004B974 00FD5FD8
PC-8: 2F004EB9 00FE7654 588F42AA 005A7001 4CDF040C 4E752F0A 246F0008 202F000C
PC *: 25400052 4A80662A 4AAA0056 671C600A 2F004EB9 00FE7798 588F2F2A 00564EB9
00fdddba :  4cdf 040c                  movem.l (a7)+,d2-d3/a2
00fdddbe :  4e75                       rts
00fdddc0 :  2f0a                       move.l a2,-(a7)
00fdddc2 :  246f 0008                  movea.l $8(a7),a2
00fdddc6 :  202f 000c                  move.l $c(a7),d0
00fdddca : *2540 0052                  move.l d0,$52(a2)
00fdddce :  4a80                       tst.l d0
00fdddd0 :  662a                       bne.s $fdddfc
00fdddd2 :  4aaa 0056                  tst.l $56(a2)
00fdddd6 :  671c                       beq.s $fdddf4
00fdddd8 :  600a                       bra.s $fddde4
Name: "Background CLI"  CLI: "hode_wos"

Also, a much smaller resolution than 800x600 would be really nice for us BlizzPPC owners, otherwise we're going to be stuck with displaying only a slideshow instead of a game.

Cowcat · 20 April 2020, 18:14

@funK

Try to downgrade scale_factor on hode.ini (just to test what happens, even with large black space) and of course fullscreen.

800x600 is what it is in source. Not sure about other resolutions or if game data is set internally to work with other dimensions. I tested it a little with it but not a firm sucess. Also another hack to set 8 bit depth could be interesting if I find how to do it.

The end crashes and enforcer hits I don't know: They don't happen running in morphos emulation so I don't know what to look for.

Edit:

Actually setting game to 512x384 (in source) and scale factor of 2 gives a screen with no black borders. Game base resolution is 256x192 so multiply for 2 and you have an feasible amiga screen. It explains why 800x600 or other resolutions have black borders because no rescaling is done for screen dimensions by the engine or SDL1 .... So....

Cowcat · 20 April 2020, 23:02

New beta above with added "width" value in .ini file.

For low systems set it to "512" if you got 512x384 screenmode (game fits perfectly to full display too). Other width's could be possible but depends of scale_factor.

xbr algorithm working now.

grelbfarlk · 21 April 2020, 22:01

Did a quick test on beta 2. With scaler set to 2 and 512 width, XBR works fine on in a window on 16bpp Workbench. Fullscreen works correct as well. Still crash on exiteverything I've been trying to build lately is doing this too so, let me know how you fix it..

funK · 22 April 2020, 09:37

Quote:

Originally Posted by grelbfarlk

Did a quick test on beta 2. With scaler set to 2 and 512 width, XBR works fine on in a window on 16bpp Workbench. Fullscreen works correct as well. Still crash on exiteverything I've been trying to build lately is doing this too so, let me know how you fix it..

Did a quick test on my system, too, and strangely enough fullscreen is not working here. Which is a shame because with 256x192 as resolution and scale_factor = 1 game seems to be fully playable on my BlizzPPC, if only it weren't stuck in that tiny little window on my Workbench.

Enforcer hits are still there on startup and game still crashes on exit, and I also noticed there's following warning thrown many times with different values, especially during the intro but sometimes also in-game:

Quote:

Code:

WARNING: PafPlayer::mix() soundQueue underrun 3782!
WARNING: PafPlayer::mix() soundQueue underrun 8192!

Cowcat · 22 April 2020, 10:10

@funK

Technically a 320x240 fullscreen should suffice (with black surroundings). About 512x384 fullscreen, that's something I had years ago for Blitzquake with a BlizzardVision: Can't check it with WinUAE warpos emu as Picasso drivers don't have this resolution but 640 is the closest.

BTW 512x384 has scale factor fixed to 2 (can't be changed).

And well, a 2.5 scale_factor (256x192) sets 640x480, but the engine uses integer values, so is not possible now.

The buffer underruns also happens for whatever system used (debian for example). There's a value to test: max_active_sounds.

Now news for hits/end crash....

Cowcat · 10 May 2020, 21:13

Updated to 0.2.9.

Beware of old setup.cfg (where game is saved) as the filesystem behaviour is changed: Now resides on root game dir, not on DATA dir. Better to backup it and put it in new place as only one should exist.

grelbfarlk · 11 May 2020, 03:30

Beta3 works, has the same crash on exit, which seems to throw the same exception at SRR0 as an application I just built. HOD and my app crash and set SRR0 at the same address, dumping the memory 0x1000+- have the exact same output via VDAPPC. So whatever it is it's common between our two programs.
Attached vdappc output from SRR0: +-1000.

Code:

Task name: 'fbasdlppcx_PPC'  Task address: 69DE91A0
Exception: Program

SRR0: 68485B5C    SRR1:  0008F030     MSR:   00003030    HID0: 0000C0A4
PVR:  70000203    DAR:   08E13D40     DSISR: 40000000    SDR1: 17E0001F
DEC:  00079FC7    TBU:   00000000     TBL:   2D2D8452    XER:  20000000
CR:   44000484    FPSCR: 82002000     LR:    68485C38    CTR:  00000000

R0-R3:   454D454D 69EA8E40 6000FFFF 7FDFFA88   IBAT0: 0000003E 00000002
R4-R7:   69C81300 00000000 00000060 0000007F   IBAT1: 620003FF C2000002
R8-R11:  69C00000 69940000 69C00000 69940000   IBAT2: 6820003F 00200002
R12-R15: 68DB9A90 69EA8F44 00000000 00000000   IBAT3: 00000000 00000000
R16-R19: 00000000 00000000 00000000 00000000   DBAT0: 0000003E 00000002
R20-R23: 00000000 00000000 F8007FFF 00007FFF   DBAT1: 620003FF C2000042
R24-R27: FFFFFFFF F8007FFF 68E2E8A0 69C89420   DBAT2: 6820003F 00200022
R28-R31: 69C88FC0 69C81300 69C89420 00000058   DBAT3: 00000000 00000000

Cowcat · 11 May 2020, 09:19

@grelbfark Yep, I know. Kinda of what it happens with Devilutionx too and others. I suspect that crashes happen using certain posix functions not being freed at exit.

Hedeon · 11 May 2020, 11:29

Nothing has changed in both libraries for more than two years now. Other SDL compiled stuff do not seem to be affected. I recommend not using atexit().

You didn't show the requester that popped up stating this is a memory error. It is either memory corruption detected during freeing memory or memory freed twice.

Cowcat · 11 May 2020, 13:25

@hedeon AFAIK there's no atexit problem, because there's none in the program. SDL is another case to check: Sometimes game can be closed but get system unstable.

Hedeon · 11 May 2020, 14:29

If that was checked on either MOS or UAE then it does not count.

16 April 2020, 02:33	#4
grelbfarlk Registered User Join Date: Dec 2015 Location: USA Posts: 2,902	One issue I've noticed is that regardless of the scaler setting it seems to want a window or a screen at 800x600 the extra space is just black. Would be nice if XBR mode did not require 32bpp but that seems what is set in the original source, don't know if that would be easy to fix. Last edited by grelbfarlk; 16 April 2020 at 03:33.

16 April 2020, 09:38	#5
Cowcat Registered User Join Date: Apr 2013 Location: Mallorca Posts: 758	@grelbfarlk Good that it works for 98% systems out there. What I know: - It crashes on exit. - The extra black spaces. - Hardcoded to 800x600 and 16 bpp. - Path directory is hardcoded to DATA (no config file is re-created): Use provided hode.ini to change fullscreen or other settings. - Thought XBR mode worked, but it turned out only on earlier versions: Needed to cheat the code with a 16bit screen AND 32 bit surface with 16 bit masking. 32/32 was too slow for normal systems. 16/16 gives a mangled display, so what the hell..... Last edited by Cowcat; 16 April 2020 at 12:20.

20 April 2020, 18:14	#10
Cowcat Registered User Join Date: Apr 2013 Location: Mallorca Posts: 758	@funK Try to downgrade scale_factor on hode.ini (just to test what happens, even with large black space) and of course fullscreen. 800x600 is what it is in source. Not sure about other resolutions or if game data is set internally to work with other dimensions. I tested it a little with it but not a firm sucess. Also another hack to set 8 bit depth could be interesting if I find how to do it. The end crashes and enforcer hits I don't know: They don't happen running in morphos emulation so I don't know what to look for. Edit: Actually setting game to 512x384 (in source) and scale factor of 2 gives a screen with no black borders. Game base resolution is 256x192 so multiply for 2 and you have an feasible amiga screen. It explains why 800x600 or other resolutions have black borders because no rescaling is done for screen dimensions by the engine or SDL1 .... So.... Last edited by Cowcat; 20 April 2020 at 19:13.

21 April 2020, 22:01	#12
grelbfarlk Registered User Join Date: Dec 2015 Location: USA Posts: 2,902	Did a quick test on beta 2. With scaler set to 2 and 512 width, XBR works fine on in a window on 16bpp Workbench. Fullscreen works correct as well. Still crash on exiteverything I've been trying to build lately is doing this too so, let me know how you fix it.. Last edited by grelbfarlk; 21 April 2020 at 22:38.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
RTCW for Warpos	Cowcat	Coders. Releases	63	23 November 2023 13:28
OWB WarpOS possible ?	drluking	support.Apps	10	29 November 2021 19:54
GLHexen2 Warpos.	Cowcat	Coders. General	84	01 July 2021 22:29
UAE for WarpOS 0.8.12	grelbfarlk	request.Apps	0	23 November 2016 01:14
WarpOS Programming Help?	esc	support.Other	8	21 October 2015 10:37

16 April 2020, 01:33	#2
grelbfarlk Registered User Join Date: Dec 2015 Location: USA Posts: 2,902	Works pretty well! Played in a window on 16bpp LE Workbench with a joystick for a while on Ragnarok/Voodoo3 system. Did get a crash at exit, sonnetlib complaining PPC Memory List Corruption Detected and it threw an exception.

16 April 2020, 01:46	#3
Pyromania Moderator Join Date: Jan 2002 Location: Chicago, IL Posts: 3,375	Cool news, I’ll try it.

17 April 2020, 23:24	#6
Hedeon Semi-Retired Join Date: Mar 2012 Location: Leiden / The Netherlands Posts: 1,994	Seems to work nicely and fast on my Ragnarok with Radeon 9200.

20 April 2020, 09:04	#8
Hedeon Semi-Retired Join Date: Mar 2012 Location: Leiden / The Netherlands Posts: 1,994	It crashes on exit, yes.

20 April 2020, 23:02	#11
Cowcat Registered User Join Date: Apr 2013 Location: Mallorca Posts: 758	New beta above with added "width" value in .ini file. For low systems set it to "512" if you got 512x384 screenmode (game fits perfectly to full display too). Other width's could be possible but depends of scale_factor. xbr algorithm working now.

22 April 2020, 10:10	#14
Cowcat Registered User Join Date: Apr 2013 Location: Mallorca Posts: 758	@funK Technically a 320x240 fullscreen should suffice (with black surroundings). About 512x384 fullscreen, that's something I had years ago for Blitzquake with a BlizzardVision: Can't check it with WinUAE warpos emu as Picasso drivers don't have this resolution but 640 is the closest. BTW 512x384 has scale factor fixed to 2 (can't be changed). And well, a 2.5 scale_factor (256x192) sets 640x480, but the engine uses integer values, so is not possible now. The buffer underruns also happens for whatever system used (debian for example). There's a value to test: max_active_sounds. Now news for hits/end crash....

10 May 2020, 21:13	#15
Cowcat Registered User Join Date: Apr 2013 Location: Mallorca Posts: 758	Updated to 0.2.9. Beware of old setup.cfg (where game is saved) as the filesystem behaviour is changed: Now resides on root game dir, not on DATA dir. Better to backup it and put it in new place as only one should exist.

11 May 2020, 09:19	#17
Cowcat Registered User Join Date: Apr 2013 Location: Mallorca Posts: 758	@grelbfark Yep, I know. Kinda of what it happens with Devilutionx too and others. I suspect that crashes happen using certain posix functions not being freed at exit.

11 May 2020, 11:29	#18
Hedeon Semi-Retired Join Date: Mar 2012 Location: Leiden / The Netherlands Posts: 1,994	Nothing has changed in both libraries for more than two years now. Other SDL compiled stuff do not seem to be affected. I recommend not using atexit(). You didn't show the requester that popped up stating this is a memory error. It is either memory corruption detected during freeing memory or memory freed twice.

11 May 2020, 13:25	#19
Cowcat Registered User Join Date: Apr 2013 Location: Mallorca Posts: 758	@hedeon AFAIK there's no atexit problem, because there's none in the program. SDL is another case to check: Sometimes game can be closed but get system unstable.

11 May 2020, 14:29	#20
Hedeon Semi-Retired Join Date: Mar 2012 Location: Leiden / The Netherlands Posts: 1,994	If that was checked on either MOS or UAE then it does not count.

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)