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

Chocolate Doom

Recommended Posts

Grazza said:

From your deh_text.txt file:

7020-7067 Iwad names

Could be useful, as it allows an iwad (e.g. the Freedoom iwad) to be specified via a dehacked patch to be specified via a dehacked patch, rather than the user needing to choose the appropriate -iwad in the command line.

[only works in vanilla?]



10852-10875 skies

[only works in vanilla?]

18028-18203 / 18236-18247 Status bar

There are some things you can do here that can't be achieved just by replacing the graphics, as you can, to some degree, modify the logic that is used to display the face graphics (making them either vary, or not vary, depending on the amount of health and direction that an attack came from).

[only works in vanilla?]
20044-20267 Stats screen

[only works in vanilla?]

It's possible, to some degree, to change the logic of what is displayed, and where. But maybe not immensely useful.

20540-21075 Music

[works in Prboom+, but not in Chocolate-Doom]

21076-21931 Sounds

[works in Prboom+, but not in Chocolate-Doom]



6956-7007 Order and choice of images and demos for pre-game cycle and background for post-game rollcall

[only works in vanilla?]

11508-12031 menu graphics et al.

[does some of this - in particular the graphics - only work in vanilla?]

I'm not sure what is to be gained by using dehacked rather than replacing the graphics, but I notice that M_DOOM was changed in Hyena.wad

I've added support for all of these.

22044-23147 Sprites

[works in most exes, but in Boom-based ports the logic is wrong/different, meaning that you can't make a pure swap of two sprite names without using a dummy name - a method that is rejected by dehacked.exe, doesn't work in other exes, and can cause a crash in Chocolate-Doom]

Chocolate Doom's dehacked code works differently to Boom, so this should work in the same way as Dehacked.

The effect of changing the following is not clear to me:

6880-6887 [default: map01]

10728-10736 [default: map31]

Possibly something to do with secret exits?

Uber geek mode on.

Doom checks for the existence of a lump named "map01". If the player is playing Doom II and that lump isn't present, it assumes that the special "store demo" version of the game is playing, so any inputs (keyboard, mouse etc) are ignored.

The "map31" is used to disable the Doom 2 secret exit when playing the German version with no wolfenstein levels.

Share this post


Link to post

Hi! First of all, great work, thanks a lot! I am enjoying chocolatedoom like no other source port at the moment :-)

Do you think that chocolatedoom will compile on a ppc mac, or is the code to much x86 specific?

Share this post


Link to post
athanatos said:

Hi! First of all, great work, thanks a lot! I am enjoying chocolatedoom like no other source port at the moment :-)

Do you think that chocolatedoom will compile on a ppc mac, or is the code to much x86 specific?

It should do, infact I'm eager to see if it will work properly on PowerPC!

Share this post


Link to post

Hi!

I was able to compile chocodoom on an mac, but I had to additionally compile sdl-mixer (I installed version 1.2.6) and sdl-net (installed 1.2.5). I got a single executable 'chocolate-doom'. I don't know why, but it's still not working. When I try to play doomII i get the following error message:

chello084114148142:~/Desktop/tmp/chocolate-doom-0.1.3/tmp/usr/local/bin Littledexter$ ./chocolate-doom
                         Chocolate Doom 0.1.3
V_Init: allocate screens.
M_LoadDefaults: Load system defaults.
saving config in /Users/Littledexter/.chocolate-doom/default.cfg
Z_Init: Init zone memory allocation daemon. 
zone memory: 0x2008000, 600000 allocated for zone
DEH_Init: Init Dehacked support.
W_Init: Init WADfiles.
 adding ./doom2.wad
Error: Z_Malloc: failed on allocation of 1890582552 bytes
when trying to play doom I get the message:
chello084114148142:~/Desktop/tmp/chocolate-doom-0.1.3/tmp/usr/local/bin Littledexter$ ./chocolate-doom
                         Chocolate Doom 0.1.3
V_Init: allocate screens.
M_LoadDefaults: Load system defaults.
saving config in /Users/Littledexter/.chocolate-doom/default.cfg
Z_Init: Init zone memory allocation daemon. 
zone memory: 0x2008000, 600000 allocated for zone
DEH_Init: Init Dehacked support.
W_Init: Init WADfiles.
 adding ./doom.wad
Error: Z_Malloc: failed on allocation of 545259544 bytes
and ultimate doom:
chello084114148142:~/Desktop/tmp/chocolate-doom-0.1.3/tmp/usr/local/bin Littledexter$ ./chocolate-doom -iwad DOOMU.WAD
                         Chocolate Doom 0.1.3
V_Init: allocate screens.
M_LoadDefaults: Load system defaults.
saving config in /Users/Littledexter/.chocolate-doom/default.cfg
Z_Init: Init zone memory allocation daemon. 
zone memory: 0x2008000, 600000 allocated for zone
DEH_Init: Init Dehacked support.
W_Init: Init WADfiles.
 adding DOOMU.WAD
Error: Z_Malloc: failed on allocation of 546308120 bytes
compiling was done using the regular ./configure && make && make install DESTDIR=./tmp procedure.

Share this post


Link to post

Can you look in the "config.h" file and tell me if WORDS_BIGENDIAN is defined? ie. you should see something like

#define WORDS_BIGENDIAN 1
If you see something like this:
/* #undef WORDS_BIGENDIAN */
Then try changing that line to the above version, recompile and see if that fixes it.

Share this post


Link to post

BIGENDIAN is defined in config.h

#define WORDS_BIGENDIAN 1
I tried running chocolatedoom using the xserver for mac (xdarwin, kde). I thougt it may compiled with support for x because it may found it, but no luck.. same error messages

Share this post


Link to post
athanatos said:

BIGENDIAN is defined in config.h

#define WORDS_BIGENDIAN 1
I tried running chocolatedoom using the xserver for mac (xdarwin, kde). I thougt it may compiled with support for x because it may found it, but no luck.. same error messages

Can you compile this small program and paste me the output? It may help me work out what is going on.

It sounds like you probably know how to do this, but just in case, here are the commands :-)

gcc wadtest.c -o wadtest
./wadtest
By the way, I am assuming that you are using the "normal" (PC) IWADs and not the files for the Mac version.

Also, are you using the version 1.9 IWADs?

Share this post


Link to post

the output of wadtest:

sizeof(wadinfo_t): 12 bytes
sizeof(lumpinfo_t): 24 bytes
sizeof(int): 4 bytes
sizeof(void *): 4 bytes
identification: 0
numlumps: 4
infotableofs: 8
endianness test: 554e4958

fraggle said:

By the way, I am assuming that you are using the "normal" (PC) IWADs and not the files for the Mac version.

Also, are you using the version 1.9 IWADs?


Yes I am using the PC IWADS. According to LichSoft IWAD Verifier the version of my doom2.wad is 1.9.

Share this post


Link to post
fraggle said:

  • Imported the spechit overrun mulation code from prboom-plus. Thanks to Andrey Budko for this.

I think we should reduce emulated restriction up to 14 lines.

Share this post


Link to post
athanatos said:

the output of wadtest:

sizeof(wadinfo_t): 12 bytes
sizeof(lumpinfo_t): 24 bytes
sizeof(int): 4 bytes
sizeof(void *): 4 bytes
identification: 0
numlumps: 4
infotableofs: 8
endianness test: 554e4958


Yes I am using the PC IWADS. According to LichSoft IWAD Verifier the version of my doom2.wad is 1.9.

Ok, I'm stupid. Add this to m_swap.h, just after the line reading "#define __M_SWAP_H__":

#include "config.h"
Tell me if that fixes it. If it does, I'll release a new version containing the fix and the new dehacked stuff.

If it works, can you provide a screenshot for the website? :-)

Share this post


Link to post
entryway said:

I think we should reduce emulated restriction up to 14 lines.

I see what you mean. However, Chocolate Doom is supposed to be bug compatible with Vanilla Doom. Presumably an overflow of 14 lines will crash Vanilla Doom, so it should crash Chocolate Doom as well?

By the way, your work on the demo compatibility has been really impressive. What tools have you been using to reverse engineer the DOS EXE? Also, have you seen my Vanilla savegame work?

Share this post


Link to post
fraggle said:

What tools have you been using to reverse engineer the DOS EXE?

I've reverse engineered the Doom95.exe by means of IdaPro 4.7 Practically all functions and variables have the real names in my doom95.idb. It is very useful for search and correction of desyncs in PrBoom. I used the built in debugger and breakpoints with conditions like:

fprintf(fopen("d:\\aa.txt", "a+"),"%.10d: %.10d - %s\n",
  Dword(gametic),EAX,GetFunctionName(Dword(ESP)))
fprintf(fopen("d:\\aa.txt", "a+"),"---R_InitData_End---\n")

Share this post


Link to post
Grazza said:

  • ouchetc.deh: a commented dehacked patch using a variety of "text" features, for illustrative and testing purposes. [The file-name is based on the changes it makes to the status bar. :o ]

  • By the way, I forgot to mention: this is the most hilarious, bizarre dehacked patch I've ever seen. Better dehacked compatibility should be a goal of all ports just so they can play this patch.

    Share this post


    Link to post
    entryway said:

    I've reverse engineered Doom95.exe by means of IdaPro 4.7 Practically all functions and variables have the real names in my doom95.idb. It is very useful for detection of desyncs. I used the built in debugger and breakpoints with conditions like these:

    fprintf(fopen("d:\\aa.txt", "a+"),"%.10d: %.10d - %s\n",Dword(gametic),EAX,GetFunctionName(Dword(ESP)))
    fprintf(fopen("d:\\aa.txt", "a+"),"---R_InitData_End---\n")

    Ok, that's interesting. The spechits overrun code includes the value 0x01C09C98: is this from Doom 95, then?

    Share this post


    Link to post

    I added #include "config.h" to m_swap.h, I now get the following error message during the 'make' process:

    /usr/bin/ld: Undefined symbols:
    _SwapLONG
    _SwapSHORT
    collect2: ld returned 1 exit status
    make[2]: *** [chocolate-doom] Error 1
    make[1]: *** [all-recursive] Error 1
    make: *** [all] Error 2

    Share this post


    Link to post
    fraggle said:

    Ok, that's interesting. The spechits overrun code includes the value 0x01C09C98: is this from Doom 95, then?

    Yes. It is the address of an array of lines (p_setup.c\P_LoadLineDefs\lines = Z_Calloc(...)).
    Exact value depends on a level and many other parameters.
    I do not know how the tmbbox[] works in Doom.
    But the approximate value works in all known cases of overflow.

    Share this post


    Link to post
    athanatos said:

    I added #include "config.h" to m_swap.h, I now get the following error message during the 'make' process:

    /usr/bin/ld: Undefined symbols:
    _SwapLONG
    _SwapSHORT
    collect2: ld returned 1 exit status
    make[2]: *** [chocolate-doom] Error 1
    make[1]: *** [all-recursive] Error 1
    make: *** [all] Error 2

    Change this line in m_swap.c:

    #ifndef WORDS_BIGENDIAN
    to
    #ifdef WORDS_BIGENDIAN

    Share this post


    Link to post

    Hi again!

    Now I get another error message:

    .
    .
    .
    if gcc -DHAVE_CONFIG_H -I. -I. -I..    -I../textscreen -I/sw/include/SDL -D_THREAD_SAFE   -Wall -O3  -MT mmus2mid.o -MD -MP -MF ".deps/mmus2mid.Tpo" -c -o mmus2mid.o mmus2mid.c; \
    then mv -f ".deps/mmus2mid.Tpo" ".deps/mmus2mid.Po"; else rm -f ".deps/mmus2mid.Tpo"; exit 1; fi
    if gcc -DHAVE_CONFIG_H -I. -I. -I..    -I../textscreen -I/sw/include/SDL -D_THREAD_SAFE   -Wall -O3  -MT m_random.o -MD -MP -MF ".deps/m_random.Tpo" -c -o m_random.o m_random.c; \
    then mv -f ".deps/m_random.Tpo" ".deps/m_random.Po"; else rm -f ".deps/m_random.Tpo"; exit 1; fi
    if gcc -DHAVE_CONFIG_H -I. -I. -I..    -I../textscreen -I/sw/include/SDL -D_THREAD_SAFE   -Wall -O3  -MT m_swap.o -MD -MP -MF ".deps/m_swap.Tpo" -c -o m_swap.o m_swap.c; \
    then mv -f ".deps/m_swap.Tpo" ".deps/m_swap.Po"; else rm -f ".deps/m_swap.Tpo"; exit 1; fi
    m_swap.c:55: error: conflicting types for 'SwapSHORT'
    m_swap.h:39: error: previous declaration of 'SwapSHORT' was here
    m_swap.c:62: error: conflicting types for 'SwapLONG'
    m_swap.h:40: error: previous declaration of 'SwapLONG' was here
    make[2]: *** [m_swap.o] Error 1
    make[1]: *** [all-recursive] Error 1
    make: *** [all] Error 2

    Share this post


    Link to post

    Looks like fraggle didn't put include guards in all of his header files.

    Shame on you fraggle.

    Share this post


    Link to post

    It's actually Id's fault :-) The header declares the function one way, but the function itself is declared differently. It's been like that since the source release.

    Change these lines in m_swap.h:

    short	SwapSHORT(short);
    long	SwapLONG(long);
    to these:
    extern unsigned short	SwapSHORT(unsigned short);
    extern unsigned long	SwapLONG(unsigned long);

    Share this post


    Link to post
    fraggle said:

    By the way, I forgot to mention: this is the most hilarious, bizarre dehacked patch I've ever seen. Better dehacked compatibility should be a goal of all ports just so they can play this patch.

    Thanks. :) I did try not to go too apeshit with this stuff, but also to choose things that would be fairly obvious. In terms of bizarre dehacked patches, I think blessed and sadhusct are pretty hard to beat. And of serious ones, hyena does some fairly odd things.

    I've noticed that the use of demon sprites for the imp is dangerous, as the lack of gib frames can lead to crashes in Doom2.exe and Chocolate Doom. I've therefore commented that out. I've also added explanations of the map01 and map31 entries, and reuploaded.

    Share this post


    Link to post

    Good News!

    After I had done these 3 changes I got no error messages during the compilation. However there are still some strange things appearing. My first impression was that there was no executable build. After the 'make' process the file chocolate-doom in ./src was not executable, I had to manually do this with chmod +x. I started the game and the screen was switching to black, I heard the doom sound (and the music :-) and I saw just a tiny square of the screen in the uppon left corner of the doom play screen.

    It worked when I used the -2 option, but the screen is cut off in the bottom so that I cannot see anything more down of the blue key.

    The input doesn't work and there where no configuration files created when running the game the first time despite it says 'saving config in /Users/Littledexter/.chocolate-doom/default.cfg', I had to use the win version of chocolate-doom on virtualpc/winxp to create configuration files. I put them into ~/.chocolate-doom. The changes iin the chocolate-doom.cfg affect the game but I still cannot use my mouse or keyboard.

    Another thing is that when I add the -nofullscreen option, I get the following error message:

    .
    .
    .
    S_Init: Setting up sound.
    S_Init: default sfx volume 8
    HU_Init: Setting up heads up display.
    ST_Init: Init status bar.
    2006-01-24 17:03:49.445 chocolate-doom[1500] *** _NSAutoreleaseNoPool(): Object 0x153a210 of class NSMutableParagraphStyle autoreleased with no pool in place - just leaking
    2006-01-24 17:03:49.445 chocolate-doom[1500] *** _NSAutoreleaseNoPool(): Object 0x153a450 of class NSCFDictionary autoreleased with no pool in place - just leaking
    2006-01-24 17:03:49.448 chocolate-doom[1500] *** _NSAutoreleaseNoPool(): Object 0x153c3e0 of class NSCFNumber autoreleased with no pool in place - just leaking
    2006-01-24 17:03:49.448 chocolate-doom[1500] *** _NSAutoreleaseNoPool(): Object 0x153c8e0 of class NSCFNumber autoreleased with no pool in place - just leaking
    2006-01-24 17:03:49.448 chocolate-doom[1500] *** _NSAutoreleaseNoPool(): Object 0x153c8f0 of class NSCFNumber autoreleased with no pool in place - just leaking
    2006-01-24 17:03:49.448 chocolate-doom[1500] *** _NSAutoreleaseNoPool(): Object 0x153c9a0 of class NSCFDictionary autoreleased with no pool in place - just leaking
    2006-01-24 17:03:49.448 chocolate-doom[1500] *** _NSAutoreleaseNoPool(): Object 0x153c970 of class NSIdEnumerator autoreleased with no pool in place - just leaking
    2006-01-24 17:03:49.448 chocolate-doom[1500] *** _NSAutoreleaseNoPool(): Object 0xaed36ca4 of class NSCFString autoreleased with no pool in place - just leaking
    2006-01-24 17:03:49.448 chocolate-doom[1500] *** _NSAutoreleaseNoPool(): Object 0x153cb50 of class NSCFArray autoreleased with no pool in place - just leaking
    2006-01-24 17:03:49.450 chocolate-doom[1500] *** _NSAutoreleaseNoPool(): Object 0x150d890 of class NSCFString autoreleased with no pool in place - just leaking
    2006-01-24 17:03:49.450 chocolate-doom[1500] *** _NSAutoreleaseNoPool(): Object 0x150d8d0 of class NSCFString autoreleased with no pool in place - just leaking
    2006-01-24 17:03:49.450 chocolate-doom[1500] *** _NSAutoreleaseNoPool(): Object 0x150cb10 of class NSCFString autoreleased with no pool in place - just leaking
    2006-01-24 17:03:49.450 chocolate-doom[1500] *** _NSAutoreleaseNoPool(): Object 0x150d830 of class NSCFString autoreleased with no pool in place - just leaking
    2006-01-24 17:03:49.450 chocolate-doom[1500] *** _NSAutoreleaseNoPool(): Object 0x150d8e0 of class NSCFString autoreleased with no pool in place - just leaking
    2006-01-24 17:03:49.450 chocolate-doom[1500] *** _NSAutoreleaseNoPool(): Object 0x150d8c0 of class NSCFString autoreleased with no pool in place - just leaking
    2006-01-24 17:03:49.450 chocolate-doom[1500] *** _NSAutoreleaseNoPool(): Object 0xaed36c34 of class NSCFString autoreleased with no pool in place - just leaking
    2006-01-24 17:03:49.450 chocolate-doom[1500] *** _NSAutoreleaseNoPool(): Object 0x150d8c0 of class NSCFString autoreleased with no pool in place - just leaking
    2006-01-24 17:03:49.450 chocolate-doom[1500] *** _NSAutoreleaseNoPool(): Object 0x150d8e0 of class NSCFString autoreleased with no pool in place - just leaking
    2006-01-24 17:03:49.451 chocolate-doom[1500] *** _NSAutoreleaseNoPool(): Object 0xaed36c34 of class NSCFString autoreleased with no pool in place - just leaking
    2006-01-24 17:03:49.451 chocolate-doom[1500] *** _NSAutoreleaseNoPool(): Object 0x150d8e0 of class NSCFString autoreleased with no pool in place - just leaking
    2006-01-24 17:03:49.451 chocolate-doom[1500] *** _NSAutoreleaseNoPool(): Object 0xaed36c34 of class NSCFString autoreleased with no pool in place - just leaking
    2006-01-24 17:03:49.451 chocolate-doom[1500] *** _NSAutoreleaseNoPool(): Object 0x150d8e0 of class NSCFString autoreleased with no pool in place - just leaking
    2006-01-24 17:03:49.451 chocolate-doom[1500] *** _NSAutoreleaseNoPool(): Object 0x150d8e0 of class NSCFString autoreleased with no pool in place - just leaking
    2006-01-24 17:03:49.451 chocolate-doom[1500] *** _NSAutoreleaseNoPool(): Object 0x150d8e0 of class NSCFString autoreleased with no pool in place - just leaking
    2006-01-24 17:03:49.451 chocolate-doom[1500] *** _NSAutoreleaseNoPool(): Object 0x150d900 of class NSCFNumber autoreleased with no pool in place - just leaking
    2006-01-24 17:03:49.451 chocolate-doom[1500] *** _NSAutoreleaseNoPool(): Object 0x1537bd0 of class NSCFArray autoreleased with no pool in place - just leaking
    2006-01-24 17:03:49.466 chocolate-doom[1500] *** _NSAutoreleaseNoPool(): Object 0x1537120 of class __NSFontTypefaceInfo autoreleased with no pool in place - just leaking
    2006-01-24 17:03:49.466 chocolate-doom[1500] *** _NSAutoreleaseNoPool(): Object 0x15660e0 of class NSAffineTransform autoreleased with no pool in place - just leaking
    2006-01-24 17:03:49.466 chocolate-doom[1500] *** _NSAutoreleaseNoPool(): Object 0x1566260 of class NSFont autoreleased with no pool in place - just leaking
    2006-01-24 17:03:49.466 chocolate-doom[1500] *** _NSAutoreleaseNoPool(): Object 0x15662e0 of class NSFont autoreleased with no pool in place - just leaking
    2006-01-24 17:03:49.467 chocolate-doom[1500] *** _NSAutoreleaseNoPool(): Object 0xaed3282c of class NSCFString autoreleased with no pool in place - just leaking
    2006-01-24 17:03:49.468 chocolate-doom[1500] *** _NSAutoreleaseNoPool(): Object 0x1566bf0 of class _NSCachedBitmapImageRep autoreleased with no pool in place - just leaking
    2006-01-24 17:03:49.469 chocolate-doom[1500] *** _NSAutoreleaseNoPool(): Object 0x1567490 of class NSImage autoreleased with no pool in place - just leaking
    2006-01-24 17:03:49.469 chocolate-doom[1500] *** _NSAutoreleaseNoPool(): Object 0x1567bc0 of class _NSCachedBitmapImageRep autoreleased with no pool in place - just leaking
    2006-01-24 17:03:49.469 chocolate-doom[1500] *** _NSAutoreleaseNoPool(): Object 0x1567a80 of class NSImage autoreleased with no pool in place - just leaking
    2006-01-24 17:03:49.470 chocolate-doom[1500] *** _NSAutoreleaseNoPool(): Object 0x153b470 of class _NSThemeCloseWidget autoreleased with no pool in place - just leaking
    2006-01-24 17:03:49.471 chocolate-doom[1500] *** _NSAutoreleaseNoPool(): Object 0x15662e0 of class NSFont autoreleased with no pool in place - just leaking
    2006-01-24 17:03:49.471 chocolate-doom[1500] *** _NSAutoreleaseNoPool(): Object 0xaed3282c of class NSCFString autoreleased with no pool in place - just leaking
    2006-01-24 17:03:49.471 chocolate-doom[1500] *** _NSAutoreleaseNoPool(): Object 0x1568330 of class _NSCachedBitmapImageRep autoreleased with no pool in place - just leaking
    2006-01-24 17:03:49.471 chocolate-doom[1500] *** _NSAutoreleaseNoPool(): Object 0x15681a0 of class NSImage autoreleased with no pool in place - just leaking
    2006-01-24 17:03:49.471 chocolate-doom[1500] *** _NSAutoreleaseNoPool(): Object 0x15684b0 of class _NSCachedBitmapImageRep autoreleased with no pool in place - just leaking
    2006-01-24 17:03:49.471 chocolate-doom[1500] *** _NSAutoreleaseNoPool(): Object 0x1568200 of class NSImage autoreleased with no pool in place - just leaking
    2006-01-24 17:03:49.472 chocolate-doom[1500] *** _NSAutoreleaseNoPool(): Object 0x1567ec0 of class _NSThemeWidget autoreleased with no pool in place - just leaking
    2006-01-24 17:03:49.472 chocolate-doom[1500] *** _NSAutoreleaseNoPool(): Object 0x15662e0 of class NSFont autoreleased with no pool in place - just leaking
    2006-01-24 17:03:49.472 chocolate-doom[1500] *** _NSAutoreleaseNoPool(): Object 0xaed3282c of class NSCFString autoreleased with no pool in place - just leaking
    2006-01-24 17:03:49.473 chocolate-doom[1500] *** _NSAutoreleaseNoPool(): Object 0x1566a30 of class _NSCachedBitmapImageRep autoreleased with no pool in place - just leaking
    2006-01-24 17:03:49.473 chocolate-doom[1500] *** _NSAutoreleaseNoPool(): Object 0x1533100 of class NSImage autoreleased with no pool in place - just leaking
    2006-01-24 17:03:49.473 chocolate-doom[1500] *** _NSAutoreleaseNoPool(): Object 0x15682e0 of class _NSCachedBitmapImageRep autoreleased with no pool in place - just leaking
    2006-01-24 17:03:49.473 chocolate-doom[1500] *** _NSAutoreleaseNoPool(): Object 0x15688a0 of class NSImage autoreleased with no pool in place - just leaking
    2006-01-24 17:03:49.473 chocolate-doom[1500] *** _NSAutoreleaseNoPool(): Object 0x15687e0 of class _NSThemeWidget autoreleased with no pool in place - just leaking
    2006-01-24 17:03:49.474 chocolate-doom[1500] *** _NSAutoreleaseNoPool(): Object 0x1567b90 of class NSCFString autoreleased with no pool in place - just leaking
    2006-01-24 17:03:49.475 chocolate-doom[1500] *** _NSAutoreleaseNoPool(): Object 0x153a4e0 of class NSException autoreleased with no pool in place - just leaking
    2006-01-24 17:03:49.475 chocolate-doom[1500] *** Uncaught exception: <NSInternalInconsistencyException> Error (1002) creating CGSWindow
    Trace/BPT trap
    Good thing is that I was able to play demos :-), I really dont't know a source port that runs on mac that can play vanilla doom demos. However the quality is bad. When entring a room with a lot of monsters the game is stuck for a second and running slow for a short time. Also the screen is most of the time slower than the game.

    ok lets point this down:

    what works:

    Screen with -2 option
    music and sounds
    demos (playable, but bad performance)

    what doesn't work:
    smooth gameplay
    controls, no mouse and keyboard (I have to kill the process everytime I want to exit)

    Anyway, being able to watch all those great vanilla doom demos on the mac is great news for me. I think its close, some ideas about the lack of controls and gameplay performance?

    Just to let you know I am compiling on a Powermac G5 with 2x2.5 Ghz and lots of RAM.

    greetings,
    athanatos

    Share this post


    Link to post

    I wouldn't doubt more than a few of those are SDL mac problems. I understand the Mac version of the library is not nearly as developed or stable as the versions for other platforms.

    Share this post


    Link to post
    athanatos said:

    Good News!

    After I had done these 3 changes I got no error messages during the compilation. However there are still some strange things appearing. My first impression was that there was no executable build. After the 'make' process the file chocolate-doom in ./src was not executable, I had to manually do this with chmod +x. I started the game and the screen was switching to black, I heard the doom sound (and the music :-) and I saw just a tiny square of the screen in the uppon left corner of the doom play screen.

    I'm really pleased that you've had some success! By tiny square do you mean that the whole screen was black, except for a square at the top right which was visible?


    It worked when I used the -2 option, but the screen is cut off in the bottom so that I cannot see anything more down of the blue key.

    Is this like the same effect as above, except a different area?

    The input doesn't work


    In i_video.c, can you change the start of I_GetEvent to look like this:

    void I_GetEvent(void)
    {
        SDL_Event sdlevent;
        event_t event;
    
        printf("I_GetEvent called\n");
    
        // put event-grabbing stuff in here
    
        while (SDL_PollEvent(&sdlevent))
        {
            printf("Got an event: %i\n", sdlevent.type);
            if (!window_focused
             && (sdlevent.type == SDL_MOUSEMOTION
              || sdlevent.type == SDL_MOUSEBUTTONDOWN
              || sdlevent.type == SDL_MOUSEBUTTONUP))
            {
                continue;
            }
    
            // process event
    
            printf("process event\n");
    
    
    (Just adding some printfs). Can you tell me which, if any, of the messages get displayed?

    Also, do any other SDL games work?

    and there where no configuration files created when running the game the first time despite it says 'saving config in /Users/Littledexter/.chocolate-doom/default.cfg', I had to use the win version of chocolate-doom on virtualpc/winxp to create configuration files. I put them into ~/.chocolate-doom. The changes iin the chocolate-doom.cfg affect the game but I still cannot use my mouse or keyboard.

    This actually makes sense. Configuration files are created when you quit the game, so if you can't quit the game, they are never going to be created.

    Good luck!

    Share this post


    Link to post

    Bug (sort of): Chocolate-Doom 0.1.3 crashes upon picking up a health potion when Max Health = -1 is used in a deh patch.

    While Doom2.exe's behaviour is pretty weird in this case, it doesn't actually crash. (Nor does Prboom-plus, but it displays different garbage in the status bar.)

    Edit: The crash in Chocolate Doom only occurs if the status bar is displayed.

    Share this post


    Link to post
    fraggle said:

    By tiny square do you mean that the whole screen was black, except for a square at the top right which was visible?


    Exactly, I can see about that much of the screen when I start chocolate-doom with the -1 option:



    With the -2 option it looks like this:



    Screenshots made with DooMLegacy and edited after because I don't know how to make a screenshot when in fullscreen.

    fraggle said:

    (Just adding some printfs). Can you tell me which, if any, of the messages get displayed?


    Here is the output when I start chocolate-doom:

                             Chocolate Doom 0.1.3
    V_Init: allocate screens.
    M_LoadDefaults: Load system defaults.
    saving config in /Users/Littledexter/.chocolate-doom/default.cfg
    Z_Init: Init zone memory allocation daemon. 
    zone memory: 0x2008000, 600000 allocated for zone
    DEH_Init: Init Dehacked support.
    W_Init: Init WADfiles.
     adding DOOM.WAD
    ===========================================================================
                                DOOM Registered
    ===========================================================================
     Chocolate Doom is free software, covered by the GNU General Public
     License.  There is NO warranty; not even for MERCHANTABILITY or FITNESS
     FOR A PARTICULAR PURPOSE. You are welcome to change and distribute
     copies under certain conditions. See the source for more information.
    ===========================================================================
    M_Init: Init miscellaneous info.
    R_Init: Init DOOM refresh daemon - [                          ]..........................
    P_Init: Init Playloop state.
    I_Init: Setting up machine state.
    2006-01-25 21:52:15.308 chocolate-doom[3596] CFLog (21): Error loading /Library/QuickTime/DivX 5.component/Contents/MacOS/DivX 5:  error code 4, error number 0 (Library not loaded: /Library/Application Support/DivXNetworks/liblame3.92.dylib
      Referenced from: /Library/QuickTime/DivX 5.component/Contents/MacOS/DivX 5
      Reason: image not found)
    2006-01-25 21:52:15.310 chocolate-doom[3596] CFLog (21): Error loading /Library/QuickTime/DivX 5.component/Contents/MacOS/DivX 5:  error code 4, error number 0 (Library not loaded: /Library/Application Support/DivXNetworks/liblame3.92.dylib
      Referenced from: /Library/QuickTime/DivX 5.component/Contents/MacOS/DivX 5
      Reason: image not found)
    2006-01-25 21:52:15.320 chocolate-doom[3596] CFLog (21): Error loading /Library/QuickTime/DivX 5.component/Contents/MacOS/DivX 5:  error code 4, error number 0 (Library not loaded: /Library/Application Support/DivXNetworks/liblame3.92.dylib
      Referenced from: /Library/QuickTime/DivX 5.component/Contents/MacOS/DivX 5
      Reason: image not found)
    2006-01-25 21:52:15.326 chocolate-doom[3596] CFLog (21): Error loading /Library/QuickTime/DivX 5.component/Contents/MacOS/DivX 5:  error code 4, error number 0 (Library not loaded: /Library/Application Support/DivXNetworks/liblame3.92.dylib
      Referenced from: /Library/QuickTime/DivX 5.component/Contents/MacOS/DivX 5
      Reason: image not found)
    D_CheckNetGame: Checking network game status.
    startskill 2  deathmatch: 0  startmap: 1  startepisode: 1
    player 1 of 1 (1 nodes)
    Emulating the behaviour of the 'Doom 1.9' executable.
    S_Init: Setting up sound.
    S_Init: default sfx volume 8
    HU_Init: Setting up heads up display.
    ST_Init: Init status bar.
    I_GetEvent called
    I_GetEvent called
    I_GetEvent called
    I_GetEvent called
    I_GetEvent called
    I_GetEvent called
    I_GetEvent called
    I_GetEvent called
    I_GetEvent called
    .
    .
    .
    "I_GetEvent called" is getting printed numerous times (exactly 784).

    fraggle said:

    Also, do any other SDL games work?


    DooMLegacy works, but it uses its own copy of sdl and not the one I compiled. What games can I try out to check this?

    Share this post


    Link to post
    athanatos said:

    Exactly, I can see about that much of the screen when I start chocolate-doom with the -1 option:



    With the -2 option it looks like this:



    Screenshots made with DooMLegacy and edited after because I don't know how to make a screenshot when in fullscreen.


    This may be an issue with screen resolutions. Chocolate Doom doesn't check what screen resolutions are available: it just tries to set 320x200 or 640x400.



    Here is the output when I start chocolate-doom:

    "I_GetEvent called" is getting printed
    numerous times (exactly 784).


    I assume this includes when you press keys, move the mouse, etc. You don't see any "got an event" messages?

    If so, it looks like this is an issue with SDL itself. Chocolate Doom is asking SDL for events, and SDL is not returning any.


    DooMLegacy works, but it uses its own copy of sdl and not the one I compiled. What games can I try out to check this?

    SDL Sopwith is one of my other projects. I know my ex-housemate got it working on his Powerbook. You might want also to try using the version of SDL from Doom Legacy to see if that works.

    Hope this helps!

    Share this post


    Link to post
    Guest
    This topic is now closed to further replies.
    ×