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

Chocolate Doom Plus (raised limits)

Recommended Posts

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.

Share this post


Link to post

Wow, never heard of that. Could you at least post a link here?

By the way, 1840820 minutes is 1278.347222221404 days.

Share this post


Link to post

1840820 minutes is also 3.4999958170865171008911126778023 years.

And the thread was started on March 20, 2006, nearly seven years ago.

Share this post


Link to post
_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.

Share this post


Link to post

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.

Share this post


Link to post
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.

Share this post


Link to post

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 :)

Share this post


Link to post



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

Share this post


Link to post

You are going to attract the GPL hounds by not making the source readily available.

Share this post


Link to post
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).

Share this post


Link to post
_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. :)

Share this post


Link to post

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... ;)

Share this post


Link to post
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.

Share this post


Link to post

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.

Share this post


Link to post

For reference, _bruce_ has included a link to the source code in the post at the top of the thread. Thanks!

Share this post


Link to post

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.

Share this post


Link to post
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.

Share this post


Link to post

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.

Share this post


Link to post
_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.

Share this post


Link to post

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.

Share this post


Link to post
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.

Share this post


Link to post

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).

Share this post


Link to post

Quasar said:
Which v1.9 though?

I mean v1.9, v1.9u and v1.9f (as we call them sometimes).

Share this post


Link to post

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.

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
×