Chocolate Doom - Doomworld Forums

Doomworld Forums : Powered by vBulletin version 2.2.5

Doomworld Forums > Classic Doom > Source Ports > Chocolate Doom

Pages (52): « First ... « 5 6 7 [8] 9 10 11 » ... Last »

Author

All times are GMT. The time now is 00:14.

fraggle
Super Moderator

Posts: 6568
Registered: 07-00

athanatos said:
I have downloaded the 0.1.4 release of chocolate-doom and I still had to change the following lines in m_swap.h in order to compile:
code:short   SwapSHORT(short);
int     SwapLONG(int);

Oops. Sorry about that. I thought I had added in all those fixes, but apparently I missed this one.

This is the output of ps while chocolate-doom was running:
code:  PID  TT  STAT      TIME COMMAND
13474  p2  S+     0:10.52 ./chocolate-doom -iwad DOOM2.WAD
0:10:52 is not much, even the mac terminal uses more cpu time.

This is interesting. If the program was encountering a bottleneck (and hence not running at full speed), I would expect it to max out the CPU. Instead, it seems like the opposite. The status is 'S', which is "interruptible sleep" (waiting for an event to complete).

Can you try editing i_system.c and commenting out the SDL_Delay call in the I_Sleep function?

before I forget: how can I find out the fps?

greetings :)

Run with '-timedemo', eg. chocolate-doom -timedemo demo2

03-08-06 19:05 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

athanatos
Warming Up

Posts: 14
Registered: 01-06

Hi!

I have made 2 videos with my webcam to give you an Idea of what it looks like when I start chocolate-doom. While the quality is not that good, you can see some of the things I mentioned.

First video: ./chocolate-doom -iwad DOOM2.WAD

http://rapidshare.de/files/15109722...MacOSX.mov.html

The input doesn't work, so you can't see me playing. I just started chocolate-doom and waited for the demo replay to start. You can see that not the full chocolate-doom screen is visible. When the player moves quickly, you sometimes see through walls and players, it looks like they are getting doubled. Sometimes the mouse is displayed in the middle of the screen.

Second video: ./chocolate-doom -timedemo demo2

http://rapidshare.de/files/15111626...medemo.mov.html

I realized that the new version of chocolate-doom crashes every time I try to play a demo (-timedemo works). The previous version doesn't crash and plays the demo, but sometimes crashes in the demo itself. You can see that the game gets slower when killing the 3rd Imp.

The output of timedemo is:

code:
Error: timed 2001 gametics in 1298 realtics (53.956085 fps)

Last edited by athanatos on 03-09-06 at 22:15

03-09-06 21:57 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

fraggle
Super Moderator

Posts: 6568
Registered: 07-00

Thanks for the videos. It helps a lot to see exactly what is going on.

I have a couple of things I'd like you to try out, as they may fix some of the problems you're having. Obviously, I'm totally guessing here as I don't have a Mac myself :-)

Re: The fullscreen "cut off" status bar, try making this change:

In i_video.c, in the function I_InitGraphics, change this line:

code:    windowheight = SCREENHEIGHT * screenmultiply;

to this:

code:    windowheight = 240 * screenmultiply;

Re: Keyboard input not working. You say that it works in Doom Legacy. I checked, and one thing Legacy does differently is call SDL_PumpEvents (although the documentation says this is not needed). So try this:

In I_GetEvent (also i_video.c), change this bit of code:

code:
void I_GetEvent(void)
{
    SDL_Event sdlevent;
    event_t event;

    // put event-grabbing stuff in here

    while (SDL_PollEvent(&sdlevent))

And add in a call to SDL_PumpEvents, so it looks like this:

code:
void I_GetEvent(void)
{
    SDL_Event sdlevent;
    event_t event;

    SDL_PumpEvents();

    // put event-grabbing stuff in here

    while (SDL_PollEvent(&sdlevent))

Please let me know if any of this helps at all :-)

03-10-06 01:47 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

athanatos
Warming Up

Posts: 14
Registered: 01-06

Good news!

That:

code:
windowheight = 240 * screenmultiply;

fixes the problem with the cut off status bar :-)

The input, however, doesn't work even after adding SDL_PumpEvents(); to i_video.c.

I have tried both now, my self-compiled sdl and the sdl from doomlegacy (using the --with-sdl-prefix and --with-sdl-exec-prefix configure options). I needed to create a bin folder in the legacy sdl dir and to copy the file sdl-config in it, using the sdl-config from the self-compiled sdl, because chocolate-doom does not compile without it and doomlegacy's sld-framework does not include sdl-config.

03-10-06 03:12 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

fraggle
Super Moderator

Posts: 6568
Registered: 07-00

athanatos said:
Good news!

That:
code:
windowheight = 240 * screenmultiply;
fixes the problem with the cut off status bar :-)

Excellent! I think that when a program tries to run in 640x400 mode, SDL actually puts it in 640x480 mode, but when updating the screen, it still updates the top 640x400 area (it is confused about what mode it is running in). I noticed this when I took a screenshot, enlarged the canvas to 640x480, then cropped the top 640x400 area - it was cut off in exactly the same place that it appeared in the videos.

I've added a "letterbox mode" to the version of Chocolate Doom in SVN, so it will run in a 640x480, but with black borders at the top and bottom. Not ideal, but at least it gets around the problem. Some people on Windows cant run in 320x200/640x400, so this solves their problem as well.

What happens when you run in 320x200 mode now (screenmultiply=1)?

The input, however, doesn't work even after adding SDL_PumpEvents(); to i_video.c.

I have tried both now, my self-compiled sdl and the sdl from doomlegacy (using the --with-sdl-prefix and --with-sdl-exec-prefix configure options). I needed to create a bin folder in the legacy sdl dir and to copy the file sdl-config in it, using the sdl-config from the self-compiled sdl, because chocolate-doom does not compile without it and doomlegacy's sld-framework does not include sdl-config.

Which version of Doom Legacy are you using? I ask because I noticed that there are actually three separate trees in Legacy's CVS repository.

Also, have you had any luck getting any other SDL apps running, like I suggested?

03-10-06 13:57 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

fraggle
Super Moderator

Posts: 6568
Registered: 07-00

Ok, here's a guess, try this:

Change the function UpdateFocus(), from this:

code:
static void UpdateFocus(void)
{
    Uint8 state;

    state = SDL_GetAppState();

    // We should have input (keyboard) focus and be visible
    // (not minimised)

    window_focused = (state & SDL_APPINPUTFOCUS) && (state & SDL_APPACTIVE);

    // Should the screen be grabbed?

    screenvisible = (state & SDL_APPACTIVE) != 0;
}

and add this line:

code:
static void UpdateFocus(void)
{
    Uint8 state;

    state = SDL_GetAppState();

    // We should have input (keyboard) focus and be visible
    // (not minimised)

    window_focused = (state & SDL_APPINPUTFOCUS) && (state & SDL_APPACTIVE);
    window_focused = true;

    // Should the screen be grabbed?

    screenvisible = (state & SDL_APPACTIVE) != 0;
}

03-10-06 14:03 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

maximi munkitus
Loser

Posts: 17
Registered: 03-06

compet-n not accepting chocolate doom? i mean, it's just a straight port from DOS to Windoze
whatever if the purists fanatics etc. dont want more demos ^^
they dont get my super duper MAP32 demos then :P

03-10-06 15:10 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

myk

Posts: 14807
Registered: 04-02

fraggle, we tested MultiPlayer and the connectivity seems pretty good; no lag spikes or disconnection issues. But, why's it that the server won't accept PWADs yet? How will that be implemented? Please avoid PrBoom's server to client path transfer (where everyone is forced to put wads in the engine's home directory, or under the same exact path.) Recording doesn't seem to work yet, either.

One other thing, I could run the server, but [W4GH4X] coudn't... for some reason I could not connect, even though he had shut down everything but mIRC and Chocolate Doom. We did wonder whether it was possible that (unless we missed something else) his connection was somehow blocking the port used by Chocolate Doom... though we forgot to try the -port parameter (we'll have to test that later.)

03-13-06 05:34 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

fraggle
Super Moderator

Posts: 6568
Registered: 07-00

Thanks for the feedback!

myk said:
fraggle, we tested MultiPlayer and the connectivity seems pretty good; no lag spikes or disconnection issues. But, why's it that the server won't accept PWADs yet? How will that be implemented? Please avoid PrBoom's server to client path transfer (where everyone is forced to put wads in the engine's home directory, or under the same exact path.)

Not sure how to approach this yet. For the time being, PWADs should work fine as long as everyone specifies -file?

Recording doesn't seem to work yet, either.

There were a couple of demo-related bugs that I've now squashed. The next alpha should have that fixed.

I've been careful to make the demo recording smart: in Vanilla, if one player is recording a demo, all players must record demos (because recording demos reduces the turning resolution). Chocolate Doom detects if any player is recording a demo and makes everyone play in low res mode automatically. This doesn't happen when recording a "longtics" (v1.91) demo.

One other thing, I could run the server, but [W4GH4X] coudn't... for some reason I could not connect, even though he had shut down everything but mIRC and Chocolate Doom. We did wonder whether it was possible that (unless we missed something else) his connection was somehow blocking the port used by Chocolate Doom... though we forgot to try the -port parameter (we'll have to test that later.)

If you are behind a NAT connection or a firewall, you may not be able to accept incoming connections, so you will be unable to run as a server. Outgoing connections will still work, so you will be able to connect to other peoples' servers, though.

03-13-06 09:46 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

fraggle
Super Moderator

Posts: 6568
Registered: 07-00

athanatos, good news!

I've managed to get Chocolate Doom running on OS X. The main change you need to do is add the following line to i_main.c:

code:
#include

I feel really stupid because I've had this exact same problem with a previous SDL game I was writing, but I somehow missed it again.

Thanks go to Insomniak for giving me an account on his mac to debug this with. I really appreciate all the help he's given me.

03-18-06 21:52 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

myk

Posts: 14807
Registered: 04-02

We tried some more Chocolate Doom MultiPlayer the other day and had three errors; two of them were Error: FixedDiv: divide by zero in the command prompt. One of these affected the client in a Coop game, the other the server during a DeathMatch game (and the client read "disconnected from server.") Both were using PWADs (one was Dwango5 Map01 and the other AV Map01.) The other error terminated the server on AV Coop in Map08:

http://www.doom2.net/~mykdoom/misc/choco-error-1.png

Also, do you recall the discussion about Map08 and ExM8 sound sound playback? AV's Map08 was jarringly unplayable with the raw code from the source... you had a ton of noisy monsters all screaming in your head at full volume; something is needed to emulate the DOS version's sound depth for those maps (or else just ignore that code like they did with Boom... though that would change things a little bit.)

03-19-06 02:24 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

fraggle
Super Moderator

Posts: 6568
Registered: 07-00

myk said:
We tried some more Chocolate Doom MultiPlayer the other day and had three errors; two of them were Error: FixedDiv: divide by zero in the command prompt. One of these affected the client in a Coop game, the other the server during a DeathMatch game (and the client read "disconnected from server.") Both were using PWADs (one was Dwango5 Map01 and the other AV Map01.) The other error terminated the server on AV Coop in Map08:

I haven't really tested either of those WADs in Chocolate Doom yet. I'll give them a go and see if I can reproduce the crashes.

consistency failure

Consistency errors are a bit worrying. Stupid question, but did you make sure that both sides loaded the dehacked patch (-deh av.deh)? I don't know exactly what is in the av deh patch but this could cause a desync.

Also, do you recall the discussion about Map08 and ExM8 sound sound playback? AV's Map08 was jarringly unplayable with the raw code from the source... you had a ton of noisy monsters all screaming in your head at full volume; something is needed to emulate the DOS version's sound depth for those maps (or else just ignore that code like they did with Boom... though that would change things a little bit.)

I'll see if I can look into this. There is a definite difference between Vanilla/Chocolate here. How does changing your sfx volume setting affect the problem?

03-20-06 15:35 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

myk

Posts: 14807
Registered: 04-02

fraggle said:
I haven't really tested either of those WADs in Chocolate Doom yet. I'll give them a go and see if I can reproduce the crashes.

Wouldn't demos of such events help? If you could release a fourth alpha with demo support (if not anyithng else) that would be very useful to us and would provide you more input.

Consistency errors are a bit worrying. Stupid question, but did you make sure that both sides loaded the dehacked patch (-deh av.deh)? I don't know exactly what is in the av deh patch but this could cause a desync.

It wasn't a LAN so I can't be 100% sure but I gave the parameters and the DEH to my partner, so it was more than likely applied by both of us. The patch changes the start-up heading, the PWAD notice, all the automap level names, and the episode (and secret map) intermission texts, but nothing else.

I'll see if I can look into this. There is a definite difference between Vanilla/Chocolate here. How does changing your sfx volume setting affect the problem?

I was just messing around in E4M8; lowering the sound volume to 3 the effect is pretty much what the current code dictates, which makes you hear far away fights as if they occurred in your location, quite loudly, while nearby fights are very faint. This effect is also evident to a degree in the DOS version, where it's harder to tell the distance from sound at lower sound volumes, at lower volumes it seems rather even (but all sounds are pretty low, unlike in Chocolate Doom, where the difference is more pronounced and some sounds are really loud.) I think that the sound code in the DOS version is attempting to give the impression you're trapped; you always hear the monsters, but sound distance is preserved (although it seems to work better at median or high sound volumes.)

On another note, is there a particular reason why Chocolate Doom selects DOOM before DOOM II? It's otherwise in Doom. What I would suggest is the standard selection sequence (except maybe putting the Final DOOM wads last), and then an entry in chocolate-doom.cfg where you specify the IWAD to load if nothing is specified.

03-20-06 17:34 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

fraggle
Super Moderator

Posts: 6568
Registered: 07-00

Hi,

myk said:
Wouldn't demos of such events help? If you could release a fourth alpha with demo support (if not anyithng else) that would be very useful to us and would provide you more input.

I just have :-)

http://www.soulsphere.org/netalpha4.zip

It wasn't a LAN so I can't be 100% sure but I gave the parameters and the DEH to my partner, so it was more than likely applied by both of us. The patch changes the start-up heading, the PWAD notice, all the automap level names, and the episode (and secret map) intermission texts, but nothing else.

Ok, that's almost certainly not it, then.

On another note, is there a particular reason why Chocolate Doom selects DOOM before DOOM II? It's otherwise in Doom. What I would suggest is the standard selection sequence (except maybe putting the Final DOOM wads last), and then an entry in chocolate-doom.cfg where you specify the IWAD to load if nothing is specified.

I rewrote the IWAD detection code and didn't pay attention to the ordering. That's fixed, now. I can certainly see about adding an entry in chocolate-doom.cfg as well.

03-20-06 18:33 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

athanatos
Warming Up

Posts: 14
Registered: 01-06

Hi!

Well thats really good news :-)

I've tested it and I can confirm that the controls work now. (You said adding #include <SDL.h> is the main change, is it also the only change you did?)

One thing: Does chocolate-doom work perfectly (gameplay performance just like under windows or linux) on your mac? If so, then there's a problem with my sdl i suppose (there are still the same problems about the game getting slower for some seconds when entering a big room with many monsters). Also, I have seen that you have added a 'Building on MacOS' section on your website with links to the official MacOS distribution of SDL. These distributions don't include sdl-config so I can't use them when I compile using the mac terminal, maybe it works with xcode? I am not used to xcode-compiling so I don't know. Also the new 0.1.4 release still crashes when trying to play a demo (I have tried out some compet-n demos), the 0.1.3 release doesn't.

Anyway, to have the controls working sure is a big step forward :-)

greetings,
athanatos

03-22-06 20:58 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

fraggle
Super Moderator

Posts: 6568
Registered: 07-00

athanatos said:
Hi!

Well thats really good news :-)

I've tested it and I can confirm that the controls work now. (You said adding #include is the main change, is it also the only change you did?)

Good to hear it's working for you now! That is pretty much the only change I made.

One thing: Does chocolate-doom work perfectly (gameplay performance just like under windows or linux) on your mac? If so, then there's a problem with my sdl i suppose (there are still the same problems about the game getting slower for some seconds when entering a big room with many monsters). Also, I have seen that you have added a 'Building on MacOS' section on your website with links to the official MacOS distribution of SDL. These distributions don't include sdl-config so I can't use them when I compile using the mac terminal, maybe it works with xcode? I am not used to xcode-compiling so I don't know. Also the new 0.1.4 release still crashes when trying to play a demo (I have tried out some compet-n demos), the 0.1.3 release doesn't.

Anyway, to have the controls working sure is a big step forward :-)

I don't actually have a Mac myself. Insomniak gave me ssh access to his Mac, which I used to compile the SDL libraries and Chocolate Doom. I was then able to hack the code directly, while he tested it for me.

I'm sorry to hear that it still isn't running smoothly, though. One thing you may want to try is disabling the call to I_Sleep in d_net.c. Let me know if that improves performance and if it does, I'll disable the call in Mac builds in the future.

03-23-06 18:12 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

fraggle
Super Moderator

Posts: 6568
Registered: 07-00

myk said:
I was just messing around in E4M8; lowering the sound volume to 3 the effect is pretty much what the current code dictates, which makes you hear far away fights as if they occurred in your location, quite loudly, while nearby fights are very faint. This effect is also evident to a degree in the DOS version, where it's harder to tell the distance from sound at lower sound volumes, at lower volumes it seems rather even (but all sounds are pretty low, unlike in Chocolate Doom, where the difference is more pronounced and some sounds are really loud.) I think that the sound code in the DOS version is attempting to give the impression you're trapped; you always hear the monsters, but sound distance is preserved (although it seems to work better at median or high sound volumes.)

Ok, I figured this out at last after several days of disassembling Doom 95 and the Sun Doom port (of all things!). It turns out that this was actually happening because the sound code was changed before the source release. Check out the updated page on the Doom wiki.

The fix for this is currently in Subversion, and should be in the next release (netgame alpha).

03-23-06 18:14 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

exp(x)

Posts: 2457
Registered: 04-04

I can't get chocolate doom to run when I compile it for x86_64. Everything compiles fine, and the game loads, but when I select an episode, it crashes with "Error: Z_Free: freed a pointer without ZONEID". It will crash while browsing the menu, too, with "Error: Aborting due to signal 11". I also get "Error loading midi" twice unless I disable sound or music even though I have timidity installed and working.

Previously, I had chocolate doom installed in my 32-bit chroot, and I didn't have any of the above problems. I don't like using my chroot, though, because it's slow as hell, and the game is choppy.

EDIT: I'm using the 0.1.4 tarball.

EDIT2: The above errors occured with doom.wad. When I use doom2.wad, I get a completely different error while browsing the menu or selecting an episode: "Fatal signal: Bus Error (SDL Parachute Deployed)"

03-23-06 20:57 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

fraggle
Super Moderator

Posts: 6568
Registered: 07-00

exp(x) said:
I can't get chocolate doom to run when I compile it for x86_64. Everything compiles fine, and the game loads, but when I select an episode, it crashes with "Error: Z_Free: freed a pointer without ZONEID". It will crash while browsing the menu, too, with "Error: Aborting due to signal 11". I also get "Error loading midi" twice unless I disable sound or music even though I have timidity installed and working.

Previously, I had chocolate doom installed in my 32-bit chroot, and I didn't have any of the above problems. I don't like using my chroot, though, because it's slow as hell, and the game is choppy.

EDIT: I'm using the 0.1.4 tarball.

EDIT2: The above errors occured with doom.wad. When I use doom2.wad, I get a completely different error while browsing the menu or selecting an episode: "Fatal signal: Bus Error (SDL Parachute Deployed)"

It currently doesn't work when compiled for 64-bit. I haven't tracked down all the problems yet. Sorry.

03-23-06 21:53 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

exp(x)

Posts: 2457
Registered: 04-04

fraggle said:
It currently doesn't work when compiled for 64-bit. I haven't tracked down all the problems yet. Sorry.

If you want, I can give you an ssh account on my computer if you don't have a 64-bit machine to test on. I managed to get rid of the music error; apparently I had timidity only installed in my chroot.

03-23-06 22:01 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

Quasar
Moderator

Posts: 5150
Registered: 08-00

Porting DOOM to 64-bit is going to be a freaking nightmare >_<

03-24-06 02:17 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

fraggle
Super Moderator

Posts: 6568
Registered: 07-00

exp(x) said:

If you want, I can give you an ssh account on my computer if you don't have a 64-bit machine to test on. I managed to get rid of the music error; apparently I had timidity only installed in my chroot.

That's ok, I actually have an Athlon 64, I just run it with the 32-bit version of Ubuntu most of the time.

Anyway, I seem to have found the cause of your problem. In p_setup.c, change this line:

code:
linebuffer = Z_Malloc (total*4, PU_LEVEL, 0);

to this:

code:
linebuffer = Z_Malloc (total*sizeof(line_t *), PU_LEVEL, 0);

I only had a quick play through, but everything seem to work fine as far as I can tell.

Quasar said:
Porting DOOM to 64-bit is going to be a freaking nightmare >_<

It's not so bad. Doom is pretty portable already, although it does make a few 32-bit assumptions (like the change I listed above). Probably the worst thing it does is assume int=32 bits, short=16 bits, etc. In 64-bit Linux, only long changes (32->64), so that isn't much of a problem. Also, the level loading code makes some assumptions regarding structure packing - ie. it assumes the structures in doomdata.h are tightly packed like they are on disk. They haven't tripped me up yet so I haven't bothered to change them.

I just booted up from a Ubuntu livecd into 64-bit Linux to track this bug down. I actually already applied some 64-bit fixes ages ago to try to get it up and running - before those, it never even reached the title screen.

03-24-06 17:01 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Quasar
Moderator

Posts: 5150
Registered: 08-00

Structure packing isn't generally a problem as long as the target compilers all support packing pragmas or directives of some sort (and since GNU C does, that covers almost everything immediately). But the data type issues are dangerous, especially since they can sometimes be hidden.

For example, if angle_t became an unsigned 64-bit integer instead of 32-bit, adding 1 degree to 359 to get zero would no longer work, because the BAM logic depends on an assumption which is not actually supported by the C standard - that 0xffffffff + 1 = 0.

03-24-06 19:24 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

exp(x)

Posts: 2457
Registered: 04-04

fraggle said:
In p_setup.c, change this line:
code:
linebuffer = Z_Malloc (total*4, PU_LEVEL, 0);
to this:

code:
linebuffer = Z_Malloc (total*sizeof(line_t *), PU_LEVEL, 0);

Thanks! Midi doesn't want to work for some reason, though. I don't even get any error messages. It works fine in the 32-bit chroot.

03-24-06 21:53 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

athanatos
Warming Up

Posts: 14
Registered: 01-06

Here's a screenshot for your website:

http://img366.imageshack.us/img366/1083/bild36yi.png

Last edited by athanatos on 03-27-06 at 03:51

03-26-06 22:15 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

fraggle
Super Moderator

Posts: 6568
Registered: 07-00

athanatos said:
Here's a screenshot for your website:

http://img101.imageshack.us/img101/3830/bild22nt.png

Thanks! I've added it to the screenshots page.

03-27-06 00:04 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

ultdoomer
Junior Member

Posts: 234
Registered: 06-04

When playing Andrey's 1427uv01.lmp, I keep getting this error a little bit after Doom 2, Level 3 starts playing:

C:\Doom Files\Chocolate Doom>chocolate-doom -IWAD DOOM2.WAD -playdemo 1427uv01
Chocolate Doom 0.1.4
Z_Init: Init zone memory allocation daemon.
zone memory: 00B70020, 600000 allocated for zone
DEH_Init: Init Dehacked support.
V_Init: allocate screens.
M_LoadDefaults: Load system defaults.
saving config in default.cfg
W_Init: Init WADfiles.
adding DOOM2.WAD
adding 1427uv01.lmp
Playing demo 1427uv01.lmp.
===========================================================================

DOOM 2: Hell on Earth
===========================================================================

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.
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.
Error: FixedDiv: divide by zero

How can I fix this?

03-27-06 17:54 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

xit-vono
Member

Posts: 547
Registered: 06-01

May I suggest an option where you can play this in coop without the extra weapons or monsters?

03-27-06 19:22 #

Profile || Blog || Email || Search || Add Buddy

IP || Edit/Delete || Quote

fraggle
Super Moderator

Posts: 6568
Registered: 07-00

ultdoomer said:
When playing Andrey's 1427uv01.lmp, I keep getting this error a little bit after Doom 2, Level 3 starts playing:

How can I fix this?

Thanks for the bug report, I've found the cause. The next version should be fixed.

03-27-06 22:57 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

fraggle
Super Moderator

Posts: 6568
Registered: 07-00

I've released a new multiplayer alpha. This also fixes the above demo bug.

Dedicated server mode (start with chocolate-doom -dedicated or run chocolate-server.exe)
Fix crash when playing 1427uv01.lmp
Don't blink the menu skull's eyes too fast.
Now runs on MacOS X and AMD64 Linux!
Fix bug with sounds on MAP08.

03-31-06 16:37 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

All times are GMT. The time now is 00:14.

Pages (52): « First ... « 5 6 7 [8] 9 10 11 » ... Last »

Doomworld Forums > Classic Doom > Source Ports > Chocolate Doom

Show Printable Version |

Email this Page |

Subscribe to this Thread

Forum Rules:

You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

HTML code is OFF
vB code is ON
Smilies are OFF
[IMG] code is ON

< Contact Us - Doomworld >