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

Chocolate Strife Beta 1 now available

Recommended Posts

Excellent news! Though, am I correct in saying that there is no other method of changing key bindings outside of the .cfg atm?


Big thanks to both yourself and Kaiser and any other contributors, your work is very much appreciated. :)

Share this post


Link to post
Khorus said:

Excellent news! Though, am I correct in saying that there is no other method of changing key bindings outside of the .cfg atm?


Big thanks to both yourself and Kaiser, your work is very much appreciated. :)

Right. I do not know if the Chocolate Setup program has been updated for strife-branch at all, nor am I currently equipped to compile it.

Share this post


Link to post

Finally! I'll play it in the morning and post my thoughts. Kudos to Quasar, fraggle, and whoever else worked on this project. Keep up the hard work, guys!

Share this post


Link to post

Two bugs spotted:
I get palette issues when running it. White or close to white colors come out garbled. But there are also glitches between pixels in textures at places. I tried to make a print screen of it, but all it caught was the glitches, everything else was black.
http://www.doglike.org/temp/chocostrife.png

Demo desyncs.

Share this post


Link to post
kristus said:

Two bugs spotted:
I get palette issues when running it. White or close to white colors come out garbled. But there are also glitches between pixels in textures at places. I tried to make a print screen of it, but all it caught was the glitches, everything else was black.
http://www.doglike.org/temp/chocostrife.png

Demo desyncs.

1. Have you ever had this palette issue with any version of Chocolate Doom? Strife does not modify any of the low-level ChocoDoom code, so I cannot imagine what caused that.

2. You didn't read the readme did you? ;) Demo sync is not quite there yet. -nomonsters demos sync, but one or more functions being called by monsters or NPCs on Tarnhill have at least one line of code wrong amongst them which will have to be found. I've already gone through thousands of lines of code looking for the discrepancy and so far, no luck.

Share this post


Link to post
Quasar said:

Here is the very first beta release of Chocolate Strife. The provided binaries are Win32-only, XP or higher.


Isn't there some kind of switch in subversion that will monkey with line endings for you? autogen.sh and configure.in in that zipfile archive both have DOS line endings, which breaks things badly when you try to run them.

Also, some of the files need to be marked executable, as zipfiles won't don't save file modes, and the Makefile tries (and fails) to execute those files.

Quickie compile instructions on *NIX:

# unzip source file, fix line endings as documented above, then...
chmod 755 man/docgen
chmod 755 data/convert-icon
sh autogen.sh
./configure --prefix=/path/to/where/you/want/to/install/choco-strife
make
sudo make install
FWIW, once you replace the DOS line endings with UNIX ones and fix the file mode bits, it compiles fine on Debian Lenny.

The text output in the console says "Chocolate Doom 1.4.0". Was that intentional?

teh stupid...

(compiled on my linux box, then forwarded through X back to my Mac, so I didn't test sound nor play it that much;
click on the thumbnails below for larger images)




Share this post


Link to post
Quasar said:

1. Have you ever had this palette issue with any version of Chocolate Doom? Strife does not modify any of the low-level ChocoDoom code, so I cannot imagine what caused that.

I tested Chocolate Doom and it was even worse there. I'm guessing that this is because I got Win7 x64 now since I haven't had this issue before with this computer.

Quasar said:

2. You didn't read the readme did you? ;) Demo sync is not quite there yet. -nomonsters demos sync, but one or more functions being called by monsters or NPCs on Tarnhill have at least one line of code wrong amongst them which will have to be found. I've already gone through thousands of lines of code looking for the discrepancy and so far, no luck.

Heh, yeah I was being a bit facetious there. :p Hope to see you get it working though. But I realize it can't be easy.

Share this post


Link to post
spicyjack said:

Isn't there some kind of switch in subversion that will monkey with line endings for you? autogen.sh and configure.in in that zipfile archive both have DOS line endings, which breaks things badly when you try to run them.

I'm surprised these Unix tools still can't cope with DOS (or Mac) line endings.

Share this post


Link to post
spicyjack said:

Isn't there some kind of switch in subversion that will monkey with line endings for you? autogen.sh and configure.in in that zipfile archive both have DOS line endings, which breaks things badly when you try to run them.

Yes, you set the versioned property 'svn:eol-style' to 'native' on every file that needs translation. Ideally that would be all text files in your repository :-)

The command is something like

svn propset svn:eol-style native <pathnames...>
See 'svn help propset' and the SVN book on setting properties and eol-style

By the way setting _versioned_ properties does not need special privileges (unversioned properties might, it depends how the repository was set up.) I mention this because at least one person believed otherwise the last time this came up.

Share this post


Link to post

I can confirm the same palette glitch on my machine running Windows 7 x64. Graphics driver information follows:

Driver Packaging Version	8.812-110104a-111988C-ATI	
Catalyst Version		10.11	
Provider			ATI Technologies Inc.	
2D Driver Version		8.01.01.1114	
2D Driver File Path		/REGISTRY/MACHINE/SYSTEM/ControlSet001/Control/CLASS/{4D36E968-E325-11CE-BFC1-08002BE10318}/0001	
Direct3D Version		7.14.10.0806	
OpenGL Version			6.14.10.10428	
Catalyst Control Center Version	2011.0104.2155.39304	

Share this post


Link to post

I can confirm that this works on Linux for me! This is great to see!

The only problem I've encountered is the zone memory problem related to the long sound effects. I really need to come up with a proper solution to this...

Share this post


Link to post
kristus said:

I tested Chocolate Doom and it was even worse there. I'm guessing that this is because I got Win7 x64 now since I haven't had this issue before with this computer.

Odd. Chocolate Doom has no graphical problems running on my Win7 x64 machine (with a NVidia card), but Chocolate Strife does.


EDIT: clarified

Share this post


Link to post

Recent versions of Windows have some problems with 8-bit palettized surfaces. The latest version of Chocolate Doom supports running in true-colour screen modes (24/32-bit) to work around this, and defaults to 32-bit color mode on Vista/7. However, strife-branch as it appears in this beta did not have this feature as it had not had the latest changes merged on for a while. I've merged the latest changes now so hopefully the next beta might work better?

Share this post


Link to post

Yeah, it's important to remember in this process that Choco Strife lags behind Choco Doom trunk, because merging is a time-expensive process. Changes must be merged from trunk to raven-branch, and then from raven-branch to strife-branch (and if necessary, changes could be merged from strife-branch/src/doom to strife-branch/src/strife, but that's highly unlikely).

Every time there is a merger, I have to spend a lot of time fixing problems with Visual Studio. For instance last time I had to remove GNU Cisms in the OPL library which involved several dozen variables being declared in C++ style, intermixed with expression statements ;)

Share this post


Link to post
Gez said:

I'm surprised these Unix tools still can't cope with DOS (or Mac) line endings.


Macs for all intents and purposes are Unix machines now, so they're plumb happy with linefeed - \n.

Not like I've used a Microsoft compiler in, oh, about 15 years, but what would happen if I fed it a file I edited in vim with ':set filetype=unix' (i.e. linefeed - \n instead of \r - carriage return). Would it run or barf?

[edit - vim command now has proper syntax]

Share this post


Link to post
Quasar said:

Every time there is a merger, I have to spend a lot of time fixing problems with Visual Studio. For instance last time I had to remove GNU Cisms in the OPL library which involved several dozen variables being declared in C++ style, intermixed with expression statements ;)

The DBOPL emulator was converted from C++, so that's why. Hope this latest merge doesn't cause you so many problems...

Share this post


Link to post
spicyjack said:

Not like I've used a Microsoft compiler in, oh, about 15 years, but what would happen if I fed it a file I edited in vim with ':set filetype=unix' (i.e. linefeed - \n instead of \r - carriage return). Would it run or barf?

Run, if Visual Studio 2005 is any indication. CR, LF, CRLF, LFCR, who cares, it's all whitespace anyway. When opening the files to edit them in the IDE, it'll tell you the line endings aren't native, and ask you if you want to convert them, to which you can tell it "no" and it'll still work and be displayed correctly anyway.

Share this post


Link to post
fraggle said:

The DBOPL emulator was converted from C++, so that's why. Hope this latest merge doesn't cause you so many problems...

No trouble at all with this one, I'm happy to say. I did find one obvious warning that should probably be fixed in trunk though, which is, m_argv.c needs to include m_argv.h for forward declaration of M_CheckParm.

BTW did you ever catch the buffer overflow fix in an earlier revision? If not I can drag that back up for you. IIRC it was in the configuration variable binding code.

Share this post


Link to post
Quasar said:

Every time there is a merger, I have to spend a lot of time fixing problems with Visual Studio. For instance last time I had to remove GNU Cisms in the OPL library which involved several dozen variables being declared in C++ style, intermixed with expression statements ;)

Sorry to hear that, but I hope you know that your efforts are well appreciated. :)

Share this post


Link to post
Gez said:

When opening the files to edit them in the IDE, it'll tell you the line endings aren't native, and ask you if you want to convert them, to which you can tell it "no" and it'll still work and be displayed correctly anyway.



Actually, I only get complaints when the line endings aren't consistent in one file.

Most Windows editors can deal with all text formats, btw.

fraggle said:

The DBOPL emulator was converted from C++, so that's why. Hope this latest merge doesn't cause you so many problems...


I know it's possibly a dumb question - but wouldn't it have been better to leave it C++ and write a C-compatible interface only?

Share this post


Link to post

All the Chocolate Doom source code is in plain C. I could have done as you describe but I liked the idea of keeping it that way.

Share this post


Link to post
fraggle said:

Recent versions of Windows have some problems with 8-bit palettized surfaces. The latest version of Chocolate Doom supports running in true-colour screen modes (24/32-bit) to work around this, and defaults to 32-bit color mode on Vista/7. However, strife-branch as it appears in this beta did not have this feature as it had not had the latest changes merged on for a while. I've merged the latest changes now so hopefully the next beta might work better?


At least when ported to Odamex, I have found that using "8to32" at high resolutions gives unacceptable frame-rates, while somehow ZDoom manages to stay silky smooth at similar resolutions. Any idea why?

Share this post


Link to post

ZDoom uses 3D hardware acceleration to draw the 8 bit surface. Unless you disable that in the console, that is.

Have you tried ZDoom with 'vid_forceddraw' set to 1?

Share this post


Link to post
Quasar said:

2. You didn't read the readme did you? ;) Demo sync is not quite there yet. -nomonsters demos sync, but one or more functions being called by monsters or NPCs on Tarnhill have at least one line of code wrong amongst them which will have to be found. I've already gone through thousands of lines of code looking for the discrepancy and so far, no luck.


I've got an idea how to find the desyncs, but it requires hacking the original exe (which you're a pro at now...)

1. Modify the P_Random function in the original exe (by jumping to a currently-unused area where your new code resides) to pop the return address off the stack, and write it to a file, along with the current game tic.
2. Make a list of ALL the return addresses and to which function they correspond to.
3. In your new source code, Modify P_Random(void) to be P_Random(int), and, each time it is called, include the corresponding address into the P_Random() statement, like P_Random(2240318).
4. Modify the P_Random (in the new source code) function itself, to make it write a file just like above.

Now, run both the hacked original, and the new game. If both games are in sync, these files should be identical. If not, they will almost invariably be different, and the difference should point you very close to the source of the desync.

It sounds like B.S., but it definitely works. The stub code might look something like this:

asm
{
P_Random:

  ; (this overwrites the original P_Random code)
  JP DesyncCheck

TempStorage:
  DW 0000
  DW 0000

  ...
}

asm
{
DeSyncCheck:
  ; place this into an unused portion of the exe

  POP EAX   ; get return address
  PUSH EAX  ; put it back
  MOV (TempStorage), EAX  ; store it
}

{
  f = fopen("sync.txt", "w")
  fprintf(f, "tic %i, addr %i\n", gametic, *TempStorage);
  fclose(f);
}

  ' insert the original P_Random code here
  ...

  return;
By the way, excellent work, guys! This is truly awesome!

Share this post


Link to post

One difficulty with adding code to DOS programs is the relocation table - there must be an entry in it for every absolute address in the code. xttl came up with a way to overcome this for the Prebeta EXE when we were hacking on it (and I'd still love to release something based on that effort as well...) but I do not know if the same approach would work on Strife or not - probably so, actually.

Share this post


Link to post
Quasar said:

One difficulty with adding code to DOS programs is the relocation table - there must be an entry in it for every absolute address in the code.



Even for DOS-extended 32bit programs? I always thought that the DOS extender was taking care of this by properly mapping the memory.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×