Something is not allowing me to hear music. I've got a Soundblaster Live and an onboard sound card which is disabled; my main MIDI device is the Live's actual (non-software) synth. "Use default devices only" hasn't done anything. PrBoom exhibits the same behavior, whereas other SDL apps such as old versions of a certain Rise of the Triad port do not.

Share this post


Link to post

I've been playing around with this wad recently and I've noticed that in both vanilla and Chocolate Doom the archvile's attack crashes the game on map01, but AFAICT it doesn't happen on other maps. The wad features a pretty heavy deh patch which is probably the cause of the crash, but why does it happen only on map01?

Share this post


Link to post
athanatos said:

what doesn't work:
smooth gameplay

I forgot to ask: when the game is running, how much CPU time is the program using? The 'ps' program should be able to tell you. What results (fps) do you get when running with -timedemo demo2?

Share this post


Link to post
Iori Branford said:

Something is not allowing me to hear music. I've got a Soundblaster Live and an onboard sound card which is disabled; my main MIDI device is the Live's actual (non-software) synth. "Use default devices only" hasn't done anything. PrBoom exhibits the same behavior, whereas other SDL apps such as old versions of a certain Rise of the Triad port do not.

Does the ROTT port you mentioned use SDL_mixer as well? If so, try copying its version of SDL_mixer into your Doom directory and seeing if that helps.

Share this post


Link to post
Belial said:

I've been playing around with this wad recently and I've noticed that in both vanilla and Chocolate Doom the archvile's attack crashes the game on map01, but AFAICT it doesn't happen on other maps. The wad features a pretty heavy deh patch which is probably the cause of the crash, but why does it happen only on map01?

If it happens the same in vanilla and chocolate doom I would say mission accomplished.

Share this post


Link to post
fraggle said:

Jon Dowland is working on one for debian.halfcoded.net. There doesn't seem to be anything there yet, though.


OK, I can help him if needed.

Share this post


Link to post
fraggle said:

Does the ROTT port you mentioned use SDL_mixer as well? If so, try copying its version of SDL_mixer into your Doom directory and seeing if that helps.

Version 1.2.4. It required smpeg.dll, so I copied that over too. No dice.

Share this post


Link to post
Belial said:

The wad features a pretty heavy deh patch which is probably the cause of the crash, but why does it happen only on map01?


Where is said DeHackEd patch?

Share this post


Link to post

Check the map to see if it has a zero-size blockmap. If so, it could be causing the crashes. DOOM doesn't allocate 0-size blockmaps properly (a fact which was causing bugs in all BOOM-based ports until as of late).

BTW, I believe 100% demo compatibility for such maps is impossible, since DOOM's behavior would be, in effect, totally random.

Share this post


Link to post

2 fraggle
What variable is located at the following memory address in Chocolate Doom: playeringame[-1] ?
I have been compelled to use a following code for emulation of this overflow

boolean SpawnPlayerOverrun(mapthing_t* mthing)
{
  if (mthing->type==0)
  {
    if (players[4].didsecret)
    {
      fprintf(stderr, "P_SpawnPlayer:"
        "can't spawn: there is no necessary start in the level\n"
        "Error: unable to emulate an overrun "
        "(mthing->type==0 && players[4].didsecret!=0)\n");
      I_SafeExit(-1);
    }
    return true;
  }
  return false;
}

void P_SpawnPlayer (mapthing_t* mthing)
  {
  player_t* p;
  fixed_t   x;
  fixed_t   y;
  fixed_t   z;
  mobj_t*   mobj;
  int       i;

  if (SpawnPlayerOverrun(mthing)) return;//e6y

  // not playing?

  if (!playeringame[mthing->type-1])
    return;
  ...

Share this post


Link to post
entryway said:

2 fraggle
What variable is located at the following memory address in Chocolate Doom: playeringame[-1] ?

I recently fixed an issue with plutonia.wad MAP12. This level contains a thing of type 0. The game interprets this as a "Player -1 start", and the game was crashing on level start when trying to spawn player -1.

Is this similar to the issue you're describing?

Share this post


Link to post

Why is is that only real DOS can read ENDOOM?

How long till the version with MultiPlayer is out?

Share this post


Link to post
myk said:

Why is is that only real DOS can read ENDOOM?


What do you mean? ENDOOM is read by the doom engine. In doom2.exe the data is just sent to the VGA text memory. In most modern os'es the executables 1. can't send stuff straight to the hardware, and 2. isn't runned with the VGA card set to text mode anyway, so just sending stuff the the VGA text mode memory won't show anything on screen.

I once wrote a function that converted the ENDOOM colour data to standard ANSI terminal control codes, only to discover that the windows console doesn't support those by default. I guess it could be useful for linux ports though.

Share this post


Link to post

Anders said:
ENDOOM is read by the doom engine. In doom2.exe the data is just sent to the VGA text memory. In most modern os'es the executables 1. can't send stuff straight to the hardware, and 2. isn't runned with the VGA card set to text mode anyway, so just sending stuff the the VGA text mode memory won't show anything on screen.

I see. Engines like PrBoom, Eternity and Chocolate Doom open another window for it, but I was wondering if it wasn't possible to have the command prompt draw (display) that info. I guess that's what you tried in your conversion (which didn't work for Windows.)

Share this post


Link to post

I looked into it again and after some browsing in the MSDN labyrinth I found out how to set the colors in the windows console, tested it by modifying the eternity 3.33.02 source, works like a charm. If anyone wants to use it in their port, just say so and I'll write a version using ANSI control codes for non-windows targets.

#define WIN32_LEAN_AND_MEAN
#include <windows.h>
#include <stdio.h>

// Written by Anders Åstrand 2006-02-11
// Displays the colorful ENDOOM lump on the windows console
// Give it a pointer to the ENDOOM lump, and the length of it.
void TXT_Endoom(char *src, int length) {
	int i;
	char c;
	char *ptr;
	HANDLE console_handle;
	CONSOLE_SCREEN_BUFFER_INFO console_info;

	console_handle = GetStdHandle(STD_OUTPUT_HANDLE);
	GetConsoleScreenBufferInfo(console_handle, &console_info);

	ptr = src;
	i = 0;
	while (ptr < src+length) {
		c = *(ptr++);
		SetConsoleTextAttribute(console_handle, *(ptr++));
		putc(c, stdout);

		// Make sure to add linebreaks every 80th char if the console is wider then that
		if ((console_info.dwSize.X > 80) && ((++i)%80 == 0))
			putc('\n', stdout);		
	}
}
EDIT: Oh, and if you feel this is a really time critical part of your port you could ofcourse modify it to only set the attribute when it actually changes.

EDIT2: And sorry for the thread hi-jacking fraggle, i didn't realise this was the chocolate doom thread when i posted. Perhaps someone can split it out as this isn't targeted towards chocolate doom in any way.

EDIT3: I just realised this isn't fraggle's thread. /me hides.

Share this post


Link to post

Don't worry, it's ok :-) The latest versions of Eternity actually use the Chocolate Doom code to display the ENDOOM screen, so it is kind of related. The code I've written uses SDL, though, so is more portable. At the moment I basically emulate the DOS text mode display, so everything is drawn properly across all OSes.

myk said:

How long till the version with MultiPlayer is out?

When it's done :-)

Here's a not-so-exciting screenshot I took a while ago. I'm going for the "retro" look.

http://www.chocolate-doom.org/wiki/index.php/Image:New-waiting-screen.png

Share this post


Link to post

I've released v0.1.4 at long last.

  • NWT-style merging command line options (allows Mordeth to be played)
  • Unix manpage (thanks Jon Dowland)
  • Dehacked improvements/fixes:
    * Allow changing the names of graphic lumps used in menu, status bar intermission screen, etc.
    * Allow changing skies, animated flats + textures
    * Allow changing more startup strings.
    * Allow text replacements on music + sfx lump names
  • Fix for plutonia map12 crash.
  • Fix bug with playing long sfx at odd sample rates.
  • Big Endian fixes (for MacOS X). Thanks to athanatos for helping find some of these.
  • Install into /usr/games, rather than /usr/bin (thanks Jon Dowland)

Share this post


Link to post

I'm seriously considering making Anders's code an option on the Win32 platform. If it's possible to so easily display the ENDOOM in the existing console window, I may as well give the user the option of doing it that way. Personally, I prefer fraggle's code not just because it is portable but because it is 100% authentic (looks EXACTLY like it did in DOS on my 486), unlike the Windows console, the appearance of which may drastically vary depending on the user's settings.

Share this post


Link to post

Quasar said:
unlike the Windows console, the appearance of which may drastically vary depending on the user's settings.

PrBoom has options for the user to configure how ENDOOM will be displayed called "endoom_mode" (in my case the default looked wrong and I had to change it) but I've no idea what the issues on the Windows (or whatever) console could be, and if those modes cover them in any way (I guess not much, or else PrBoom would be displaying it in the console.)

Share this post


Link to post

I just contributed a slightly controversial patch (although not that exciting). Andrew Apted reported problems saving large levels due to the savegame buffer limit which Vanilla Doom has. I've now added the ability to disable the savegame buffer limit.

By default, Chocolate Doom will still have the same savegame buffer limit as Vanilla Doom has. However, I've added a configuration file option ("vanilla_savegame_limit") which allows the limit to be turned off.

The way I see it, the savegame limits are more of a "player-centric" option rather than a "level-designer-centric" option. Players may find it useful to be able to turn the limit off. Also, the Vanilla limit only applies when saving games: there is no limit when loading savegames. It may be useful to be able to create large Vanilla-compatible savegames to load with Vanilla Doom. Finally, the limit is on by default, so out of the box it still behaves the same way as Vanilla Doom.

Share this post


Link to post

Hi again!

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:

short   SwapSHORT(short);
int     SwapLONG(int);
to
extern unsigned short   SwapSHORT(unsigned short);
extern unsigned int     SwapLONG(unsigned int);
This is the output of ps while chocolate-doom was running:
  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.

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

greetings :)

athanatos

Share this post


Link to post

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

Like in Doom, use -devparm in the command line. On the lower left of the screen you will get a series of dots. If divide 70 by the number of dots you get +1, you have the frame rate (you won't see less than 1 dot because the game is limited to 35 FPS.)

Share this post


Link to post

I don't know what happened good sirs, but the problem with the right shift key has been resolved in this new version. I can play now. :D

Share this post


Link to post
myk said:

Like in Doom, use -devparm in the command line. On the lower left of the screen you will get a series of dots. If divide 70 by the number of dots you get +1, you have the frame rate (you won't see less than 1 dot because the game is limited to 35 FPS.)

A more accurate way is to run chocolate-doom -timedemo demo2 :-)

EarthQuake said:

I don't know what happened good sirs, but the problem with the right shift key has been resolved in this new version. I can play now. :D

Good to hear! I don't remember changing anything, but maybe it was an SDL problem.

By the way, in case anyone is interested: I've been testing the new network code over the past few days. It seems to run quite smoothly, there are just a few more bugs I need to iron out. I'm in irc.oftc.net #zdoom and #chocolate-doom for anyone who wants to help me test it out.

Share this post


Link to post

Hi,

Following on from my last post, I've added an entry to the Wiki here describing how to play with the new multiplayer code.

Share this post


Link to post

Yay Choco-Doom has multi.

You can also find willing players in #DMClub (OFTC). In fact, I think we ought to try choco-doom multi out...

Share this post


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