_bruce_ Posted March 17, 2013 Here's a hack of ChocolateDoom 1.6.0 that has its limits raised according to Doom+. (6x scale of 1920x1200 resolution is included too for those who still have a 16:10 lcd monitor). Archy forwarded the idea that it might be of use for some here... -minimal exe(out of stock since I deleted the project -> changes are included in the more elaborate one below) -source(1.7.0) http://speedy.sh/BrRmx/ChocoLimits.7z -VS2005 -all features are implemented as minimalistic as possible and kept as noninvasive as possible towards the original source(thus some clunky solutions) -I wanted to implement one more feature but due to Fraggle's and Quasar's understandable concerns I had to upload this to prevent any harm done to them -exe(1.7.0)(limits 1.92 and megasave games, OpenGL scaler, disk icon, scanline in software 1920x1200 mode) http://speedy.sh/VdCvw/Choco-Alpha.7z -thx to the mods for making this into a thread -props to those who got the Groom Lake thing -good to see that there some 16:10 aficionados -buses with tinted glasses tend to have top notch air conditioning -new command line parameters ] '-no_disk' disables disk icon graphics ] '-scan1920' write every 3rd line in 1920x1200 mode(software only) ] '-rast1920' write every 3rd line/second pixel in 1920x1200 mode(software only) Changed: -raised data size regarding disk icon activity* *in depth: reading a file of 384 Kbyte would causes the disk to flash for 35 frames -> 1 second. Reading files smaller than ~10Kbyte ( (384*1024) / 35 ) fall through and do not cause the icon to be drawn. !*! .exe will not be updated before a few days have passed because I want to add one feature and the accompanying source has to be up2date. Disk icon behaves as stated by 'Feniks' and can be "tamed" via command line parameter. 0 Share this post Link to post
Archy Posted March 17, 2013 @entryway I would post a link to Chocolate Doom 1.6.0+ in your original post. 0 Share this post Link to post
entryway Posted March 17, 2013 Archy said:@entryway I would post a link to Chocolate Doom 1.6.0+ in your original post. I can't because of «The administrator has specified that you can only edit messages for 1840820 minutes after you have posted» http://prboom-plus.sf.net/files/chocolate-doom-1.6.0+.zip 0 Share this post Link to post
Archy Posted March 17, 2013 Wow, never heard of that. Could you at least post a link here? By the way, 1840820 minutes is 1278.347222221404 days. 0 Share this post Link to post
Gez Posted March 17, 2013 1840820 minutes is also 3.4999958170865171008911126778023 years. And the thread was started on March 20, 2006, nearly seven years ago. 0 Share this post Link to post
fraggle Posted April 10, 2013 _bruce_ said:Here's a hack of ChocolateDoom 1.6.0 that has its limits raised according to Doom+. (6x scale of 1920x1200 resolution is included too for those who still have a 16:10 lcd monitor). Archy forwarded the idea that it might be of use for some here... http://speedy.sh/BxTPx/chocolate-doom-archy.rar Why 1.6.0? Can you please also post the source code to this mod? Thanks. 0 Share this post Link to post
Feniks Posted April 23, 2013 Forgive my ignorance, but I'm pretty much of a layman when it comes to technical matters. The Chocolate Doom-Plus piqued my interest. Are those links by Archy and entryway to the same exe? Is it already complete and fully playable? Is there any difference between this and the original Choco Doom besides the limits? Playing limit-removing wads in Chocolate Doom would surely be awesome. 0 Share this post Link to post
_bruce_ Posted April 23, 2013 Feniks said:Forgive my ignorance, but I'm pretty much of a layman when it comes to technical matters. The Chocolate Doom-Plus piqued my interest. Are those links by Archy and entryway to the same exe? Is it already complete and fully playable? Is there any difference between this and the original Choco Doom besides the limits? Playing limit-removing wads in Chocolate Doom would surely be awesome. The choco+ mutant is basically done. Just bumping up the limits seemed a bit lame to me so I added screen scaling option via OpenGL and the infamous disk icon which changes in respect to cpu vendor ^^ I'm battling with the correct OpenGL extension to make it more elegant and versatile but should it be too much of a hassle for this release than I'll just throw out a base version which uses OpenGL 1.1 that should even work on Voodoo. Looks like the save game limit needs to be upped again... seems someone "mistook" mobjs for crystal meth. The GL scaler enables usage at high resolutions on slower cpus - a C2D at 1200 Mhz is ~10% occupied regardless of destination screen resolution. 0 Share this post Link to post
Feniks Posted April 23, 2013 Bumping up the limits is enough for me. Being a Chocolate Doom fanboy, I wouldn't change anything else. As long as it's identical to the original Choco Doom and hasn't resulted in any new bugs, I'm more than willing to use it :) 0 Share this post Link to post
_bruce_ Posted April 24, 2013 First grab... http://speedy.sh/VdCvw/Choco-Alpha.7z Beware -setup can't add wads for multiplayer due to linker error given by source -server exe not included -older gfx cards may utter an error during startup - ignore -save game size is now ~5.5 MBytes(original x 32) all other like Doom+ -in software mode the 1920x1200 mode can be scanlined or rastered via command line switches '-scan1920' or '-rast1920'. Latter overturns the former -tried on C2D(new gfx) and A64(old gfx) -disk icon works -source code available at Groom Lake 0 Share this post Link to post
Urban Space Cowboy Posted April 25, 2013 _bruce_ said:-source code available at Groom LakeGreat. Where would that be then? Could you maybe provide a link, say? 0 Share this post Link to post
exp(x) Posted April 25, 2013 You are going to attract the GPL hounds by not making the source readily available. 0 Share this post Link to post
andrewj Posted April 25, 2013 exp(x) said:You are going to attract the GPL hounds by not making the source readily available. There's be no need for "hounds" if people respected the software they modify (and respected the law too). 0 Share this post Link to post
Enjay Posted April 25, 2013 _bruce_ said:(6x scale of 1920x1200 resolution is included too for those who still have a 16:10 lcd monitor). Still have? I bought a 16:10 monitor quite recently. 1920x1200 is my favoured resolution. Much more useful than 1920x1080 for my purposes IMO. I run 2x24" 1920x1200 monitors side by side. :) 0 Share this post Link to post
chungy Posted April 25, 2013 Yeah I used a 1920x1080 monitor for a short while, it didn't SOUND like a huge difference, but it really was. Almost to the point of being unworkable even; 1920x1200 is the smallest resolution I'll settle for. 16:10 might be the widest aspect I'll want for that matter (vertical space ftw), but a 16:9 with more pixels going up than 1200 will probably be acceptable. It'd be nice if 2560x1700 was made as a standalone monitor... ;) 0 Share this post Link to post
exp(x) Posted April 26, 2013 I'm OK with my 1920x1080 resolution because I have dual monitors. 0 Share this post Link to post
GreyGhost Posted April 26, 2013 Urban Space Cowboy said:Great. Where would that be then? Could you maybe provide a link, say? Area 51. Good luck finding a link that doesn't result in your being snatched off the street and renditioned to a third-world hellhole for interrogation. 0 Share this post Link to post
Quasar Posted April 26, 2013 Do not post binaries for GPL port modifications without source code. fraggle is attempting to make contact with you (_bruce_) in regards to this issue. My suggestion would be to get this worked out with him as soon as possible. There are a number of people here, myself included, who have code in that project, and we do take it seriously. 0 Share this post Link to post
fraggle Posted April 28, 2013 For reference, _bruce_ has included a link to the source code in the post at the top of the thread. Thanks! 0 Share this post Link to post
Feniks Posted May 1, 2013 Well, I gave this a shot with Double Impact, ran through the maps pacifist-style and all of them seem to work. However, the floppy disk icon seems a little overused, I'm afraid. I admit it's been ages since the last time I played Doom in DOS (certainly over ten years), and I might not remember it "photographically", but... Unfortunately, it's more of an annoyance than a pang of nostalgia. I get it literally all the time when I play through a map, at least with dbimpact.wad. If my memory serves me right, it didn't work that way in DOS Doom. I played it on a 386 years ago, and I remember it had to load every map in, like, two minutes or so, but the floppy disk rarely showed when actually playing. Then, I used DOSBox for Doom (and plenty of other games) for over half a decade, and it was pretty similar. The floppy flashed shortly after loading up the game, but almost never during my play. Even with wads like Hell Revealed, which consumed more CPU resources (none of my computers are able to emulate anything better than a 486 with DOSBox), the floppy rarely showed when playing (basically never)! I did a quick research, that is, watched a couple of YouTube videos showing Doom in DOSBox and the disk icon never behaved the way it's doing right now. Well, maybe the right answer is "you just have a very shitty computer that is barely able to run limit-removing wads". Maybe this is the nub of the problem. But couldn't you just make the disk icon optional or change it a bit? I would be thankful for a version of Choco Doom+ that isn't any different from the original Chocolate Doom except for raised limits. Edit: The Double Impact INTERPIC doesn't display correctly, I got the Bad V DrawPatch error. 0 Share this post Link to post
_bruce_ Posted May 2, 2013 Feniks said:Well, I gave this a shot with Double Impact, ran through the maps pacifist-style and all of them seem to work. However, the floppy disk icon seems a little overused, I'm afraid. I admit it's been ages since the last time I played Doom in DOS (certainly over ten years), and I might not remember it "photographically", but... Unfortunately, it's more of an annoyance than a pang of nostalgia. I get it literally all the time when I play through a map, at least with dbimpact.wad. If my memory serves me right, it didn't work that way in DOS Doom. I played it on a 386 years ago, and I remember it had to load every map in, like, two minutes or so, but the floppy disk rarely showed when actually playing. Then, I used DOSBox for Doom (and plenty of other games) for over half a decade, and it was pretty similar. The floppy flashed shortly after loading up the game, but almost never during my play. Even with wads like Hell Revealed, which consumed more CPU resources (none of my computers are able to emulate anything better than a 486 with DOSBox), the floppy rarely showed when playing (basically never)! I did a quick research, that is, watched a couple of YouTube videos showing Doom in DOSBox and the disk icon never behaved the way it's doing right now. Well, maybe the right answer is "you just have a very shitty computer that is barely able to run limit-removing wads". Maybe this is the nub of the problem. But couldn't you just make the disk icon optional or change it a bit? I would be thankful for a version of Choco Doom+ that isn't any different from the original Chocolate Doom except for raised limits. Edit: The Double Impact INTERPIC doesn't display correctly, I got the Bad V DrawPatch error. Thx for your thorough input. I checked this out in Dosbox but was not sure if it matched the picture I got on my beloved P60 and DOS. After taking a second look at the flashings I agree that the icon in its current form is a little bit too much of an attention whore ^^ The possibility to disable the icon was there from the start, but I forgot to add the info -> '-no_disk' command line. The crash in the pwad(which is very nice btw) seems to be caused by having the animation frames have a relative offset when they can't because the are already occupying all the vid buffer due to them being 320x200. And thus V_Draw... barfs ^^ Ok, I rechecked the disk icon activity in DOS 7.x on a Celeron366 - it flickers fairly often. The machine is equipped with 64Mbyte ram and the cpu is more than fast enough for sure. Same thing if I run it under Win98SE in Dos mode. The new setting, shorter display times, should "emulate" this behavior somewhat adequately. 0 Share this post Link to post
Quasar Posted May 2, 2013 Different compiles of DOOM had different V_DrawPatch behavior. Some of them silently overwrote portions of memory, some of them called I_Error, and some of them may have returned from V_DrawPatch if bad parameters were detected. To the best of my knowledge fraggle has not tried to emulate this differing behavior on an executable file version level so far. 0 Share this post Link to post
Feniks Posted May 4, 2013 _bruce_ said:The possibility to disable the icon was there from the start, but I forgot to add the info -> '-no_disk' command line. Thanks! I would be more than happy to test more limit-removing wads with this port, since the idea is highly commendable. Maybe creating a "compatibility table" would be of some use. Yet another little snag with Double Impact - E1M9 crashes. I've got no idea what causes the crash, but it might surpass the raised limits. I got a Windows error message. 0 Share this post Link to post
myk Posted May 14, 2013 Nice. I've asked for this in the past because I use Doom+ a lot and this should give people more ways to test limit-raising in a true vanilla engine (because testing in PrBoom+ comp level 2-4 leaves bugs for Doom+). Feniks said: The Double Impact INTERPIC doesn't display correctly, I got the Bad V DrawPatch error. Yeah, I remember that issue playing the WAD (using Doom+). You just need to replace the transparent graphics with smaller ones (1-pixel will do). From what I remember, this was the only issue in Doom+. I've got no idea what causes the crash, but it might surpass the raised limits. I got a Windows error message. Not the limits, I played the map in Doom+ and had no problems. I just redownloaded the WAD in case I had fixed something in e1m9 but it worked fine. Quasar said: Different compiles of DOOM had different V_DrawPatch behavior. Some of them silently overwrote portions of memory, some of them called I_Error, and some of them may have returned from V_DrawPatch if bad parameters were detected. Perhaps but I don't recall v1.9 doing anything other than exiting with the V_DrawPatch error message. 0 Share this post Link to post
Quasar Posted May 14, 2013 myk said:Nice. I've asked for this in the past because I use Doom+ a lot and this should give people more ways to test limit-raising in a true vanilla engine (because testing in PrBoom+ comp level 2-4 leaves bugs for Doom+). Yeah, I remember that issue playing the WAD (using Doom+). You just need to replace the transparent graphics with smaller ones (1-pixel will do). From what I remember, this was the only issue in Doom+. Not the limits, I played the map in Doom+ and had no problems. I just redownloaded the WAD in case I had fixed something in e1m9 but it worked fine. Perhaps but I don't recall v1.9 doing anything other than exiting with the V_DrawPatch error message. Which v1.9 though? There are many. DOOM II 1.9 Ultimate DOOM 1.9 Final DOOM 1.9 Linux Doom (it may call itself 1.10 but whatever) There's evidence that not all of these behave the same way. Note that Chex Quest contains a very easy to trigger V_DrawPatch error which doesn't seem to happen when it is played on the build of DOOM that it normally comes with. This suggests that one or more of the above EXEs (or perhaps earlier versions of DOOM, at least, if Chex Quest wasn't built on 1.9) were compiled without RANGECHECK being defined. Without RANGECHECK, the behavior of unmodified out-of-bounds V_DrawPatch is to corrupt areas in the neighborhood of the VGA buffers in low DOS memory. However I've seen some sources where returns were added, as well, after doing bounds checking. Worth noting that Rogue added bounds checks too, for Strife, so it never I_Errors or overwrites memory. 0 Share this post Link to post
hex11 Posted May 15, 2013 Since you're working on this, maybe you can check out my chocolate-heretic diff, to see where I went wrong. I tried to extend all the hardcoded limits to match the ones in heretic+, in order to have something that can run Blasphemer (it needs limit-removing engine). It worked fine for the IWAD maps, and quite a few other maps I tried, but crashed on E1M4 in Heretic Treasure Chest, and I have no idea why. Anyway, here's the diff: http://pastebin.com/keCXAqV1 Ignore the gamekeydown[127] stuff, that was just so I can bind the Backspace key (normally it's hardcoded, so that changing it in setup or editing the cfg makes no difference). 0 Share this post Link to post
myk Posted May 16, 2013 Quasar said: Which v1.9 though? I mean v1.9, v1.9u and v1.9f (as we call them sometimes). 0 Share this post Link to post
Holering Posted May 17, 2013 Any chance you could hack timidity++ or midi port selection (like zdoom and/or dosbox). This would be really great for unix users (Mac OS and Linux) since SDL_mixer doesn't have proper midi playback (SDL_mixer has a new fluidsynth backend for soundfonts as of recently but amazingly, it's got problems with reverb, stereo panning, missing instrument maps and other possible inconsistencies.). Don't know why sdl maintainers haven't implemented timidity++. If I was a better hacker I'd do it (maybe some day). Zdoom uses timidity++ just fine and you don't even need timidity++ running as a daemon (server mode); don't know how zdoom does that (think it's fmod) but it's totally awesome and wish other source ports such as chocolate-doom, prboom-plus and eternity could do the same. 0 Share this post Link to post