Quasar Posted February 12, 2011 Here is the very first beta release of Chocolate Strife. The provided binaries are Win32-only, XP or higher.Read Me! Binaries Source Code Some development files 0 Share this post Link to post
Khorus Posted February 12, 2011 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. :) 0 Share this post Link to post
Quasar Posted February 12, 2011 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. 0 Share this post Link to post
E_O Posted February 12, 2011 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! 0 Share this post Link to post
kristus Posted February 12, 2011 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. 0 Share this post Link to post
Quasar Posted February 12, 2011 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. 0 Share this post Link to post
spicyjack Posted February 12, 2011 Quasar said:Here is the very first beta release of Chocolate Strife. The provided binaries are Win32-only, XP or higher.Source Code 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) 0 Share this post Link to post
kristus Posted February 12, 2011 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. 0 Share this post Link to post
Gez Posted February 12, 2011 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. 0 Share this post Link to post
kristus Posted February 12, 2011 Probably some pretentious reason for that. 0 Share this post Link to post
RjY Posted February 12, 2011 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 likesvn 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. 0 Share this post Link to post
Aliotroph? Posted February 12, 2011 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 0 Share this post Link to post
kristus Posted February 12, 2011 cant be the drivers then cause I got Nvidia. 0 Share this post Link to post
fraggle Posted February 12, 2011 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... 0 Share this post Link to post
E_O Posted February 12, 2011 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 0 Share this post Link to post
fraggle Posted February 12, 2011 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? 0 Share this post Link to post
Quasar Posted February 12, 2011 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 ;) 0 Share this post Link to post
spicyjack Posted February 12, 2011 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] 0 Share this post Link to post
fraggle Posted February 12, 2011 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... 0 Share this post Link to post
Gez Posted February 12, 2011 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. 0 Share this post Link to post
Quasar Posted February 12, 2011 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. 0 Share this post Link to post
kristus Posted February 13, 2011 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. :) 0 Share this post Link to post
Graf Zahl Posted February 13, 2011 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? 0 Share this post Link to post
fraggle Posted February 13, 2011 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. 0 Share this post Link to post
LexiMax Posted February 13, 2011 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? 0 Share this post Link to post
Graf Zahl Posted February 13, 2011 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? 0 Share this post Link to post
kb1 Posted February 14, 2011 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! 0 Share this post Link to post
Quasar Posted February 15, 2011 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. 0 Share this post Link to post
Graf Zahl Posted February 15, 2011 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. 0 Share this post Link to post