Any chances of getting The Spire 2 run in Boom?

When I try to run this wad with Boom 2.02, I instantly get Segmentation Violation error. But prower does state that you need "Boom-compatible, limit-removing source port". So, any chances?

try prboom

It seems huge... I doubt anything could be done other than splitting it up like Deus Vult (that appears "whole" as Map05).

EDIT: I tried it on PrBoom and it seemed visually glitchy. Plus choppy, of course, on my Celeron 666 MHz. Unless you have a mighty system, it's worthless. And it's probably better to play it on something like ZDoom anyway.

Well, to have the mouse control which I'm used to I'm virtually limited to vanilla or Boom. I find Zdoom almost hardly playable in that respect, so I only use it for Zdoom only maps. Prboom is better, though still doesn't seem to be "right" for me. But I guess I will have to try it now. I've got a 1.5Ghz Sempron so that will probably be enough. Thanks for replies.

EDIT: myk, what a hellish CPU speed you have! (666) :)

PrBoom+ always did the signal 11 thing for me when I approached that floor light in the starting area.

Forced me to use GZDoom since ZDoom was unbearably slow.

OK I tried it with the latest Prboom+. Yep, there are visual glitches, and the game slows down frequently (and sometimes the music, too), but it seems bearable at 640x480. It's still much better than when I played Demonized on a 486 at 1 fps :-))

Belial, I didn't get the signal 11 thingy yet, and I already took the chaingun. Maybe I'm just lucky, we'll see.

I play this map in GZDoom and it ran completely fine, other than the usual slow frame rate due to the humongous structure you see at the beginning.

The author said that it was Boom compatible, but as to what settings he was using, is a mystery. I'd just use either ZDoom or GZDoom for this, as it has the most desired effects. No glitches (that I noticed).

Edit: myk, you have a slow pc, 'nuff said. I'm just stating the obvious, not trying to make you feel bad.

For a huge map like this, I'd definitely recommend using GL rendering rather than software rendering. I've just had a quick run around in the current test version of prboom-plus 2.4.8.2. With software rendering I got obvious visual glitches (but no crashes), but none with GL rendering, and it was just a tiny little bit choppy (and that's being very picky) at 1680x1050 resolution (specs: notebook with 1.7 GHz Pentium M, ATI Mob. Radeon 9700).

BTW, I don't know if you have experimented with the mouse acceleration settings, but if not you could try that. Also, the 2.4.8.2 test version has an improvement in mouse behaviour (I don't know if by the "latest version" you mean the 2.4.8.1 release, or the latest test version). Not easy for me to judge though, as (with the exception of the bad start-up behaviour, which now appears to be cured at last in -plus) I have always found the mouse handling in prboom (all versions) to be fine, and fairly easy to adjust when switching backwards and forwards between it and Doom2.exe - maybe I'm just lucky though.

Donce said:

Belial, I didn't get the signal 11 thingy yet, and I already took the chaingun. Maybe I'm just lucky, we'll see.

That used to happen in 2.2.6.29, now that I've tried it in 2.4.8.1 walking into the brighter sector just causes a major gfx glitch.

Grazza said:
For a huge map like this, I'd definitely recommend using GL rendering rather than software rendering.

Yeah, good idea. However, when I executed GlBoom, I experienced the same nearly non-responsive problem that I wrote about earlier. Well, must be some problem on my machine since just two hours ago I got just the same problem in GlQuake.

BTW, I don't know if you have experimented with the mouse acceleration settings, but if not you could try that. Also, the 2.4.8.2 test version has an improvement in mouse behaviour (I don't know if by the "latest version" you mean the 2.4.8.1 release, or the latest test version). Not easy for me to judge though, as (with the exception of the bad start-up behaviour, which now appears to be cured at last in -plus) I have always found the mouse handling in prboom (all versions) to be fine, and fairly easy to adjust when switching backwards and forwards between it and Doom2.exe - maybe I'm just lucky though.

Experimenting could probably help, but I'm pretty fine with Boom 2.02 "out of the box", so there's no need to. And I can live with playing one map with "wrong" behaviour. I meant the 2.4.8.1 release, didn't know yet about 2.4.8.2.

Actually, I notice that most players don't have any problems with mouse handling. Don't know why, but for me the difference is huge and greatly affects my aiming (like it is any good), etc.

Antidote said:
Edit: myk, you have a slow pc, 'nuff said. I'm just stating the obvious, not trying to make you feel bad.

It's okay; I like it how it is and mostly use it for playing Doom and Doom+ compatible maps that work like a charm on it.

Donce said:

However, when I executed GlBoom, I experienced the same nearly non-responsive problem that I wrote about earlier. Well, must be some problem on my machine since just two hours ago I got just the same problem in GlQuake.

OK, silly question, but you don't perhaps have an old copy of opengl32.dll lying around on your system, do you? That's the standard reason for problems with GLQuake (and the most frequently asked Quake question of them all, so I feel a bit silly even bringing it up). The point is that this dll was to work with very old OpenGL cards, and just fouls up newer ones. If you nuke the old one (renaming it is a safe way to do this, rather than actually deleting it), the system will use the one the one that it should do (typically in Windows/System32/ ).

Donce said:

Experimenting could probably help, but I'm pretty fine with Boom 2.02 "out of the box", so there's no need to. And I can live with playing one map with "wrong" behaviour. I meant the 2.4.8.1 release, didn't know yet about 2.4.8.2.

Actually, I notice that most players don't have any problems with mouse handling. Don't know why, but for me the difference is huge and greatly affects my aiming (like it is any good), etc.

The differences could be due to different behaviour in your OS/drivers, which could well be leading to major differences in the actual response in Windows programs compared to DOS programs. The acceleration setting is a way that you can try to compensate for this (it exists in Chocolate-Doom too).

Grazza said:
OK, silly question, but you don't perhaps have an old copy of opengl32.dll lying around on your system, do you?

No, but I solved it. For some reason hardware acceleration didn't work, I decreased it by one step, applied, then restored to full acceleration, applied and rebooted.

The differences could be due to different behaviour in your OS/drivers, which could well be leading to major differences in the actual response in Windows programs compared to DOS programs. The acceleration setting is a way that you can try to compensate for this (it exists in Chocolate-Doom too).

Well, I don't notice any difference when playing vanilla or Boom in both Windows and DOS mode. When recording h204 (Hell Revealed 2 Map04) I switched to DOS mode because in vanilla exe there were quite frequent lockups (blame sound hardware) which weren't present is DOS mode. That doesn't happen in Boom, probably because of Allegro or how it is called. Hmm, how to tell... it's as if the balance of walking and strafing speeds is different at desired turning sensitivity in other - Windows - ports. The beta version of PrBoom+ feels better, though still not what I'd prefer, but, combined with nearly perfect framerate (only slows down a bit in the open), this map is fully playable now. And that's good, because this huuuge caco wave is coming :-)

myk said:

It's okay; I like it how it is and mostly use it for playing Doom and Doom+ compatible maps that work like a charm on it.

That'll do it. My machine can run most current games, but I find myself playing Doom more than any current game out. I find it funny.

Donce said:
When recording h204 (Hell Revealed 2 Map04) I switched to DOS mode because in vanilla exe there were quite frequent lockups (blame sound hardware) which weren't present is DOS mode. That doesn't happen in Boom, probably because of Allegro or how it is called.

What are these lockups like? The DOS prompt freezes? Does anything happen to the screen when it happens? Or do you mean instead temporary lockups... kind of like "lag"?

thespire2 needs an engine that supports more than 32768 sidedefs, and can handle the dropoff overflow in the visplane code that you get when walking over the dividing line between two sectors of massively different heights. A recent version of Prboom, Prboom-plus or Eternity should work.

Yes there are visual glitches when you get a dropoff overflow but surely that's better than the engine scribbling all over its internal memory structures, crashing, segfaulting, overwriting your config file with gibberish, freezing X up completely* etc. which is what it used to do to me :)

* okay that's probably more like an SDL bug, fullscreen on linux is well known for having certain issues.

myk said:

What are these lockups like? The DOS prompt freezes? Does anything happen to the screen when it happens? Or do you mean instead temporary lockups... kind of like "lag"?

Yeah, temporary ones, upon playing certain sounds, like picking up a weapon or getting hurt. The game freezes for about 0.5 - 1 second and then goes on, but this results in a shot being missed or, sometimes, getting killed.

Yeah, temporary ones, upon playing certain sounds, like picking up a weapon or getting hurt. The game freezes for about 0.5 - 1 second and then goes on, but this results in a shot being missed or, sometimes, getting killed.

When it plays a sound it tends to use up a definite chunk of memory, and sometimes more than is available or expected. I remember having that effect before I started using a memory manager (such as this RAM Idle), after which using Windows 98 became fully beneficial over switching to DOS mode to play. It could be something else, as about two years ago you mentioned this issue and I replied the same thing, but perhaps you missed my post, or something (as there's no reply to it).

Actually, using Doom on Windows 9x without some sort of memory optimization will always have this type of issue, as far as I've experienced.

Well, Boom doesn't suffer from that. Anyway, it costs nothing to just try with that RamIdle, so I'll see. I remember I used it on Win95 but stopped when I got rid of that 486.

Why Did the author make the spire that freaking huge anyway? I played the map with Zdoom and turned on the "Fly" cheat so I could try and fly up to the top of the spire and see how tall it was. It took me several minutes to reach the top.

Risen3D runs this wad just fine in basic doom mode on my Athlon 2800+\Nvidia 5600 FX.

Craigs said:

Why Did the author make the spire that freaking huge anyway? I played the map with Zdoom and turned on the "Fly" cheat so I could try and fly up to the top of the spire and see how tall it was. It took me several minutes to reach the top.

It looks like a style thing. Personally, I think the construct looks rather bland, just a big wall of one featureless texture.

Belial said:

now that I've tried it in 2.4.8.1 walking into the brighter sector just causes a major gfx glitch.

Say that to RjY and Quasar. OpenGL works fine. More or less. I have 40 fps (640x480) on start. 32 with gzdoom, but gzdoom works without any glitches

Heh, i ran it in EDGE openGL and only had mild slowdown in a few choice areas. Then again this was on bottom skill level so there was less monsters attacking me. This was on a computer with not-that-incredible specs (1.7ghz, 256mb graphics, 512 ram) but its also knackered and has lots of constant errors and fuckups, so isnt all that fast or powerful anyway. I ought to try it on my Laptop really...

(Though i should add, for anyone that wants to try it, there's one switch thats supposed to raise a wall, which if i remember right contains the yellow key, which doesn't work in EDGE as it uses a Boom gemeralised linedef, which EDGE doesnt support, so just noclip in this area)

deathbringer said:

(Though i should add, for anyone that wants to try it, there's one switch thats supposed to raise a wall, which if i remember right contains the yellow key, which doesn't work in EDGE as it uses a Boom gemeralised linedef, which EDGE doesnt support, so just noclip in this area)

Are you talking about yellow card which is near the start? If so, I missed that switch and didn't take the key, bus as I completed the map, it apparently was not necessary :)

Nah this was quite near the end (in an area of red rock with a round room with a deep lava pit in it nearby), i had done everything else possible up to that point and the switch wasn't working, so i checked it in doom builder (thats when i found out about generalised linedefs, wadauthor doesnt support them and i had only just switched editors)