Maes
I like big butts!

Posts: 10165
Registered: 07-06 |
I never changed default settings for Chocolate, so I guess it's DirectX mode.
I remember distinctly that at least in terms of map code Mocha could smoke the old prboom in nuts.wad on a Celeron 1200. Mocha Doom: a slideshow, but at least playable, and recouped normal speed in automap mode. PrBoom: more of a slideshow, not playable, and even automap mode didn't recoup any speed ;-)
As that map didn't actually become playable until prBoom+ to the best of my knowledge (perhaps to blame to the default prBoom settings), that was kind of expected.
Then again that was on an XP machine with little RAM (384 MB). My theory is that Java's GC mechanism might give it an advantage in such maps where a lot of stuff is being created and destroyed continuously, since memory for dead mobj_t's is not freed immediately, and so the associated overhead does not occur right "there and then". Of course, such mechanisms could be hacked into the Zone subsystem.
I also made some tests in the built-in E2M2/E3M5/E4M2 demos of Ultimate Doom on a Core 2 T8300, in software mode (OpenGL mode for prBoom just didn't pump out enough FPS to be competitive), and Mocha still beat normal prBoom by a measurable margin, or at least was practically head-to-head (gotta dig those benchmarks out...).
BTW, these are the only demos I know of that run OK in all four ports, so I use them as timedemo benchmarks. Sadly I still have some issues syncing the other built-in demos due to some vexing desync issues I still can't pinpoint.
|