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

Chocolate Doom

Recommended Posts

I got a french AZERTY.

When using vanilla EXEs, my keyboard works like a QWERTY.

The following keys are swapped :
- A and Q
- Z and W
- M and :/;
- all the caracters have different location

So it gets tedious when typing messages in coop/dm, and even cheat codes.

Share this post


Link to post
Graf Zahl said:

For in-game key handling this doesn't really matter and with the methods at hand it will be hard to fix anyway. DirectInput under Windows doesn't offer any means of keyboard localization and neither does SDL if it is used with DirectInput.
Keyboard mappping only is important when entering text into a console or another editing field (e.g. savegame names)

SDL keyboard events have a "sym" field that denotes the key pressed (this never changes regardless of the keyboard mapping), and a "unicode" field that denotes the character typed.

Anyway, I think I'm going to go with a mixed approach: Chocolate Doom will behave like Vanilla does - my reasoning being that Vanilla users will be used to pressing the wrong keys. However, for actually typing things in (savegame names and multiplayer messages), the proper typed character will be used. People can be used to pressing the wrong keys to drive the menus and enter cheat codes, but it can only ever be annoying when entering text.

Share this post


Link to post
fraggle said:

SDL keyboard events have a "sym" field that denotes the key pressed (this never changes regardless of the keyboard mapping), and a "unicode" field that denotes the character typed.



As long as Windows keyboard events are used this will work correctly. But last time I checked when using DirectInput for the keyboard SDL used a hard coded US mapping because DI bypasses the keyboard mapper. I can't say if there is any chance to control this though. It was some time ago...

Share this post


Link to post

fraggle said:
Anyway, I think I'm going to go with a mixed approach: Chocolate Doom will behave like Vanilla does - my reasoning being that Vanilla users will be used to pressing the wrong keys. However, for actually typing things in (savegame names and multiplayer messages), the proper typed character will be used. People can be used to pressing the wrong keys to drive the menus and enter cheat codes, but it can only ever be annoying when entering text.

I note the difference only when typing text, since I have a Mexican keyboard and usually expect the keys to be taken as under an English layout (the letters and numbers are in the same places, but many of the special characters are not), so I initially type with the "wrong" keys, but I waste time correcting my typing messages during games, as in Chocolate they are not mixed up.

Wouldn't a compatibility in the custom CFG be more helpful? People who want that to work like in Doom could toggle it on (perhaps the default), and those that want it to read their nonEnglish or nonQWERTY keyboard properly could leave it at 0.

This would allow Chocolate to work as Doom without necessarily annoying those who can't stand the messed up layout (especially users who never used Doom with a nonEnglish key layout).

I think a compatibility method makes more sense than a hybrid, in any case.

Share this post


Link to post
Janizdreg said:

Does this mean that PC speaker support could be implemented in Chocolate Doom?

To answer my own question, PC speaker support has been added to Chocolate Doom in the latest unofficial builds. If you want to try it out, you can set the snd_sfxdevice setting in the Doom config file to 1. Though now I'm hoping that fraggle will add an option for choosing the SFX device in Chocolate-setup for easier access to this setting.

I must also comment that I just spent the last hour playing Chocolate Doom with the PC speaker sounds on, which was very nostalgic for me since I first played Doom on a 386 with only PC speaker sounds available. I really appreciate the chance to get to relive those childhood memories, so big thanks to Chocolate Doom and fraggle for that.

Share this post


Link to post
myk said:

I note the difference only when typing text, since I have a Mexican keyboard and usually expect the keys to be taken as under an English layout (the letters and numbers are in the same places, but many of the special characters are not), so I initially type with the "wrong" keys, but I waste time correcting my typing messages during games, as in Chocolate they are not mixed up.

Wouldn't a compatibility in the custom CFG be more helpful? People who want that to work like in Doom could toggle it on (perhaps the default), and those that want it to read their nonEnglish or nonQWERTY keyboard properly could leave it at 0.

This would allow Chocolate to work as Doom without necessarily annoying those who can't stand the messed up layout (especially users who never used Doom with a nonEnglish key layout).

I think a compatibility method makes more sense than a hybrid, in any case.

Yeah, I'm starting to think you may be right. In general I kind of dislike adding in more configuration options, so I try to avoid it if I can.

Janizdreg said:

To answer my own question, PC speaker support has been added to Chocolate Doom in the latest unofficial builds. If you want to try it out, you can set the snd_sfxdevice setting in the Doom config file to 1. Though now I'm hoping that fraggle will add an option for choosing the SFX device in Chocolate-setup for easier access to this setting.

I must also comment that I just spent the last hour playing Chocolate Doom with the PC speaker sounds on, which was very nostalgic for me since I first played Doom on a 386 with only PC speaker sounds available. I really appreciate the chance to get to relive those childhood memories, so big thanks to Chocolate Doom and fraggle for that.

I'm glad you like it :-) I posted this in the other thread already, but I put a video of this on youtube, here for anyone that hasn't seen.

Graf Zahl said:

As long as Windows keyboard events are used this will work correctly. But last time I checked when using DirectInput for the keyboard SDL used a hard coded US mapping because DI bypasses the keyboard mapper. I can't say if there is any chance to control this though. It was some time ago...

I just tried running Chocolate Doom in Windows with a german keyboard mapping and it seems to work fine (mapping is done correctly). Perhaps it's been fixed in SDL?

Share this post


Link to post
fraggle said:

I just tried running Chocolate Doom in Windows with a german keyboard mapping and it seems to work fine (mapping is done correctly). Perhaps it's been fixed in SDL?



It may be. Did you run fullscreen or in a window? If I remember correctly that makes a difference for SDL.

Share this post


Link to post
Graf Zahl said:

It may be. Did you run fullscreen or in a window? If I remember correctly that makes a difference for SDL.

I'm pretty sure it was running in a Window, as keyboard mapping is (for some reason) done on an application-by-application basis in Windows, and I needed to switch to the DE mapping after the program started.

Share this post


Link to post

I have found an incompatibility between doom2.exe and chocolate\prboom. Check this test level as example. The sector will rise differently in doom2.exe and chocolate-doom.exe. It happens, because all original EXE's don't check for overflow of heightlist[MAX_ADJOINING_SECTORS] array in P_FindNextHighestFloor() as distinct from linuxdoom and all derived ports (dosdoom, tasdoom, chocolate)

You should rewrite this function as follows:

// 20 adjoining sectors max!
//#define MAX_ADJOINING_SECTORS    	20

fixed_t
P_FindNextHighestFloor
( sector_t*	sec,
  int		currentheight )
{
    int			i;
    int			h;
    int			min;
    line_t*		check;
    sector_t*		other;
    fixed_t		height = currentheight;
    fixed_t		*heightlist;

    static int MAX_ADJOINING_SECTORS = 0;

    if (MAX_ADJOINING_SECTORS == 0)
        MAX_ADJOINING_SECTORS = M_CheckParm("-doom95") ? 500 : 20;

    heightlist = malloc(sec->linecount * sizeof(heightlist[0]));

    for (i=0, h=0 ;i < sec->linecount ; i++)
    {
	check = sec->lines[i];
	other = getNextSector(check,sec);

	if (!other)
	    continue;
	
	if (other->floorheight > height)
	{
	    // Emulation of memory (stack) overflow
	    if (h == MAX_ADJOINING_SECTORS + 0)
	        ; //do nothing
	    if (h == MAX_ADJOINING_SECTORS + 1)
	        height = other->floorheight;

	    // Check for fatal overflow. Exit.
	    if ( h == MAX_ADJOINING_SECTORS + 2 )
	        I_Error("Sector with more than 20+2 adjoining sectors. "
                        "Vanilla will crash here");

	    heightlist[h++] = other->floorheight;
	}
    }
    
    // Find lowest height in list
    if (!h)
    {
	free(heightlist);
	return currentheight;
    }
		
    min = heightlist[0];
    
    // Range checking? 
    for (i = 1;i < h;i++)
	if (heightlist[i] < min)
	    min = heightlist[i];
			
    free(heightlist);
    return min;
}
Or simply delete the check for overflow.

Share this post


Link to post

Are there plans for 1.2 compatibility?
There are several changes keeping maps designed for 1.2 from working as intended.

All collectible stuff has the standard pickup sound.

Sectors can be 32768 units high without crashing the game (though you encounter visual glitches when they are taller than 512 units).
For testing this issue, check out FORGEX.WAD which has a lift going down really deep. The game often crashes when walking near the shaft. V1.2 never crashes there.

Lost Souls count for kills.

Stairbuilders have no clunk sounds (only the crusher sound is there)

Max. health is 199 and armor is unlimited.

Lower floor to lowest neighbor and copy type and texture got the target type and texture from the least numbered neighbor, regardless of its height. (since 1.666, it's the least numbered neighbor which matches the target height)
Some mapping errors (including the original E3M9 prior 1.9) producing an invalid sector type, because the tagged sector is lower than its neighbors.

Share this post


Link to post

Older version compatibility seems more a thing PrBoom could go for, but there are other more obscure issues to deal with, such as a weird movement glitch when recording demos, and the buggy line type used in the second level of Return to Phobos, that is hard to emulate.

LogicDeLuxe said:
For testing this issue, check out FORGEX.WAD which has a lift going down really deep. The game often crashes when walking near the shaft. V1.2 never crashes there.

Where? In the red room with the two end level shafts? I couldn't get it to crash there. I know of a crash when you fall great distances, though, and you are right that it doesn't affect v1.2 (where you get HOMs, or something, instead).

A good wad for seeing that falling limit is Daniel Hornbaker's The Apocalypse Project; in E1M9 you jump down an abyss where the error can occur (to avoid it in v1.9, let the player fall straight instead of running forward). Here is a demo (recorded with PrBoom+) that triggers the error. Curiously, Doom says it's an R_MapPlane error, while Chocolate Doom calls it an R_DrawColumn error.

Share this post


Link to post

Ah, I see, the deep lift. It's curious how it is caused when there is both vertical and horizontal movement, but not when there's little or no horizontal movement. I guess scrolling the texture very fast isn't a problem, but suddenly having to load extra textures to scroll is.

PS: You got me going with "crash" as well but it's not a really crash, but a only terminal error.

Share this post


Link to post

fraggle, can you add one optional fix for control?
I'm always use WASD keyset but i'm not use W for move forward. Instead it i use left mouse button. And in that case doom have one issue. By default mouse button used for move forward behaves as open/use in double-click and this can't be disabled. This is a big inconvenient. entryway fix it in prboom-plus at my request by adding that option in game settings. Please do same with your chocolate!

Share this post


Link to post

c.imp said:
Please do same with your chocolate!

That sounds like something completely against the spirit of the engine; which is to work like the original as much as possible, and to be an interchangeable port with it (using either should be the same as far as possible). When inconvenients are "bugs" the DOS engine shares, they are things Chocolate Doom isn't really meant to fix, but to either emulate or support.

I had that issue too for some time, as moving forward would sometimes make me close doors I was attempting to open. What I did is change my setup. I use a key for key_up, and I replaced key_strafe with mouseb_strafe, in case I need sr50 movement.

Share this post


Link to post

This one not related to comatibility broke. Previously recorded demos (if some exist) with this behavior don't goes out of sync. And this fix can be optional like in prboom+

Share this post


Link to post

c.imp said:
And this fix can be optional like in prboom+

Chocolate Doom is not just about demo compatibility. You could also fix every other bug in the engine that way (like, screen resolution would definitely not alter demo compatibility either), but what's the point? In any case, if this is fixed, how does it fix the problem in Doom, which is supposed to be the same as Chocolate Doom as far as functionality? You're making the engines different, which means that a Chocolate Doom user (that uses this option you request) will have a problem using Doom.

Another option is to use an advanced mouse driver, like Microsoft's Intellipoint (which can be downloaded for free from Microsoft or other places) to swap mouse functions when you play Doom or Chocolate Doom. With this you'd be able to keep your unusual setup by temporarily changing the function of your mouse button (to the effect of a keyboard key).

Share this post


Link to post
myk said:

Chocolate Doom is not just about demo compatibility. You could also fix every other bug in the engine that way (like, screen resolution would definitely not alter demo compatibility either), but what's the point? In any case, if this is fixed, how does it fix the problem in Doom, which is supposed to be the same as Chocolate Doom as far as functionality? You're making the engines different, which means that a Chocolate Doom user (that uses this option you request) will have a problem using Doom.

Another option is to use an advanced mouse driver, like Microsoft's Intellipoint (which can be downloaded for free from Microsoft or other places) to swap mouse functions when you play Doom or Chocolate Doom. With this you'd be able to keep your unusual setup by temporarily changing the function of your mouse button (to the effect of a keyboard key).

To be honest, considering that it is possible to work around these things with driver settings, I'm tempted to just support it directly.

When it comes to input, you're dependent on the OS to provide you with input. Considering that you could theoretically simulate any kind of input you wanted, the notion of staying pure to Vanilla Doom becomes irrelevant.

As another example: there's no way to bind a joystick/joypad button to strafe left or right (did I mention I just added joystick support in the past week?). But programs exist that intercept the joystick input and simulate keypresses, so it's already possible to create a setup where a joystick button strafes left or right. In this situation, I might as well just add the ability to bind a joystick button to strafe left or right. Otherwise, all I'm doing is being deliberately obstructive and annoying.

Share this post


Link to post

If you want... but in regard to Doom (and already also to Chocolate Doom) those means are external to the program, and those settings aren't really normally part of the "vanilla" game.

If you think you're being "obstructive" then you might also want to add Doom+ support, since that is quite possible for Doom, and certainly in a more immediate way than external key binding tweaks are. Especially if you already added DeHackEd and longtics.

Share this post


Link to post
myk said:

If you want... but in regard to Doom (and already also to Chocolate Doom) those means are external to the program, and those settings aren't really normally part of the "vanilla" game.

If you think you're being "obstructive" then you might also want to add Doom+ support, since that is quite possible for Doom, and certainly in a more immediate way than external key binding tweaks are. Especially if you already added DeHackEd and longtics.

I don't really see Doom+ support as being in the same category here. Entryway has done some impressive work with Doom+ in removing the limits, but I don't want to add support for it because it's a moving target. Longtics was a one-off feature I could add, whereas with Doom+, I would have to track the project, adding new features in as they appear in Doom+. I don't want to do that. And besides, prboom[-plus] already does a good job of being a classic port with limits removed.

I admit that when it comes to the edge here the line gets a bit blurry, and I have to use my best judgement about what I feel "belongs" in Chocolate Doom. With the input though, it seems pretty clear. Whether I add support for extra inputs or not, it's possible, and there's no way around that. People want it, and it can already be done anyway, so by saying "no, because it's not in Vanilla", all I'm doing is forcing people to resort to more complicated and annoying methods to do it. I can't prevent it, so I might as well add it in as a proper feature and make using Chocolate Doom a more pleasant experience :-)

Share this post


Link to post

fraggle said:
I don't really see Doom+ support as being in the same category here.

Not the same category, but closer to the game itself; the hack is directly intended for the engine, as opposed to key and mouse tweaks, which are part of the operating system running the game.

I don't want to add support for it because it's a moving target.

I guess it's not entirely impossible that something could be added, but there doesn't seem to be anything more that can be extended without breaking demo compatibility, which is what Doom+ avoids. As far as can be determined, it's a completed hack. If you can think of anything to add to it I'm quite interested in learning about it, regardless of whether a "plus" option were to be added to Chocolate Doom.

Share this post


Link to post

Hey all, I patched Chocolate Doom to support 5x scaling. It'd be 1600x1000 for regular scaling, and 1600x1200 for 4:3 aspect ratio correction. The main advantage comes from the latter; there is no blending required at this resolution (1200 is a multiple of 200; the lower modes are not, so special blending is done to make it look okay), so the game should look identical at 1600x1200 as it would on 320x200 (of which newer hardware often lacks support). It should go without saying that such a high resolution also requires a fairly fast computer :P

I talked to fraggle on IRC about it, it seemed he had planned for a mode in the past, though I'm not sure if he will incorporate this patch; it's the first time I've really done anything in C, so I'm not sure if the code is up to standards. As a result of my experience with C, this code should be treated as highly experimental and untested (it works for me, but that doesn't mean for everybody).

(edit: removed source code patch as it has been incorporated into Chocolate Doom, so the thread page size stays shorter. If you want to see the patch, just type "svn diff -r 918:919" in a checkout'd tree)

Share this post


Link to post
LogicDeLuxe said:

I recorded a demo of forgex.wad
http://rapidshare.com/files/37512013/forgecra.lmp.html
It crashes with Error: R_MapPlane: 316, 316 at 244 in Chocolate Doom.

Also seen is an imp trapped in the floor due to a blockmap bug from the really old bps builder. You can fall in there as well when walking slow on that spot.


I looked into this. This is actually consistent with Vanilla Doom, but it's a crash in the renderer. It depends on your screen size. If you run totally fullscreen (no status bar) you won't get the crash, where as if you run with the status bar you get the crash.

Share this post


Link to post

When mouse sensitivity is set very high, you can not use the options menu in game. Will that be fixed?
Sure, your goal is to preserve the bugs of vanilla, though you really should make an exception with this one.

Share this post


Link to post
LogicDeLuxe said:

When mouse sensitivity is set very high, you can not use the options menu in game. Will that be fixed?

You use your mouse to navigate the menu? What is your sensitivity set to anyway? Mine's 30 with 1.85 acceleration, and I have no problems.

Share this post


Link to post

exp(x) said:
You use your mouse to navigate the menu?

Nah, it's just that with enough sensitivity the lever sprite will go off the screen and the game will close with an error message, complaining about that. It's one of Doom's nifty features (I use sens 75 so I always avoid the mouse sensitivity menu screen).

Share this post


Link to post

fraggle, thanks very much for dblclick disabling function! :)

Vanilla also have support for Logitech Cyberman - mouse/joystick hybrid with vibration when enemies hit player. Maybe add support for vibration itself for all manipulators that have it? This is pure original feature.

Share this post


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