[1.0.20] Words no more displayed on the screen

[Jive]

1) I binded keys for "Music On" and "Music Off"
With this version, the words "On" and the word "Off" are no more displayed.
I have only "Music" on the screen.
I verified the congif.ini and autoexec.cfg files, and nothing has been changed in my scripts.

Is it because there is a "space" between the words "Music" and "On" or "Off"?

2) Something else:
I'm playing "Mass Mouth" (July 19, 2003, fourth version)
Map01:
- I had to rise the ceiling upon the first monster (which is not really a monster but a creature helping you), so that its head was not stucked in it...
- I had also to make such a work for the second sprite (a sort of spacial motor), which was stucked in the ceiling. Now, it appears normally, and it's on a normal support (larger than the original one)
http://doom.vect.org/sp/massm_do.zip
Is it a map bug or what?
I can't believe that it's a map bug, because I passed 3 minutes to rectifiy it, and to test it. If it was a map bug, the author (Cyb) should have correct it, no? It was so obvious and so easy to correct it...

Message edited: I gave a wrong file for massmouth.zip (it was the very first version)!!!

[Shinjanji]

I believe this map was made for the original ZDoom, which did not cut off sprites that extended into the ceiling or floor.

[Jive]

"This wad now needs ZDoom 2.0 to run" (as of July 19, 2003, fourth version)

So, it was a map bug...
Incredible!!
Yes, I speak of a bug when something is done wrongly because it doesn't matter with the actual engine, and it's rather bad because, when the engine don't cover anymore such errors, the map appears to be badly built, which is exactly the case: you have... let me say a sprite with a height of 100 in a space with a height of 80 (wrong values, but it was for the example)

Cyyyyyyyyyyyb, come here, now!!!

Thank you a lot for your answer, Shinjanji.
You were right!

[Enjay]

It all depends on your point of view. The map was made for Zdoom. Zdoom does not cut off sprites when they meet the floor/ceiling but OpenGL ports have to. So, it's quite common to place an item in a room that is shorter than the sprite but in (Z)Doom this simply isn't noticeable. However, as soon as you play the map in an OpenGL port, you'll see items with their tops cut off. It's not unusual, for example, to see monsters with tall sprites wandering around in OpenGL ports with their heads cut off by the ceiling when they looked fine in a software port.

If you consider that a WAD bug, then almost every sprite in DOOM2.WAD also has the bug. As you probably know, most sprites are offset so that the bottom of the sprite is about 4 pixels below floor level. If you switch off sprite adjustment in GZdoom's options, you'll see that most monsters loose the bottom of their feet. Sprite adjustment moves the whole sprite up so that the bottom of the sprite is at floor level - so it can't be made to work for both the bottom and the top of the sprite unfortunately.

[Jive]

Zdoom does not cut off sprites when they meet the floor/ceiling but OpenGL ports have to. So, it's quite common to place an item in a room that is shorter than the sprite but in (Z)Doom this simply isn't noticeable.

In Zdoom, ok, but ZdoomGl, GZDoom...
Bah, that's not correct to do such a thing!!!
When a room has a height of 100, the sprite should have a height of 100 maximum, period. The fact that it's not noticeable is NOT a correct idea.
And my intervention here is the proof of it.

[TheDarkArchon]

Proof, eh?

OBJECTION!

(I had to )

[Enjay]

Sometimes the sprite going into the ceiling/floor is a desired effect. I'd actually say the bug was more in the item coding than the level. If a sprite is 100 units tall, then the monster (etc) should also be 100 tall. If that was the case, the item simply wouldn't fit into a room smaller than the sprite. EG a Baron's height is 64 units but most front-on sprites are over 70 units tall. The archvile is worse. It has similar height sprites to the baron but the item only has a height of 56.

[Graf Zahl]

The sprite clipping issue ois obviously something that can't be done reasonable in a GL port and the music message is not part of the EXE so there's nothing to fix. Can you post the script that prints it?

[Jive]

http://gzdoom.doomwadstation.com/tricks.html#codes

Code: Select all

//////////////////////////////////////////////////////////////
// Music on/off script for Doom, by Jive for GZW
// http://gzdoom.doomwadstation.com (GZW)
// Originally created by janiz on Jan 06, 2003
// http://www.kolumbus.fi/janiz/doom/mystuff/zdoom_cfgscripts/
// Modified and simplified to fit my own needs
//////////////////////////////////////////////////////////////

alias mus_off "snd_musicvolume 0;snd_midivolume 0"
alias mus_on "snd_musicvolume 0.2;snd_midivolume 0.5;echo Music On"
alias mus_0 "mus_off;echo Music off"

bind m mus_0
bind , mus_on
// French keyboard: ";" will put "on" the music, and "," will cute it off

This code was perfectly efficient with the version 1.0.18
Not now, with the v1.0.20...

[Jive]

Proof, eh?

OBJECTION!

(I had to )

My answer: if you don't respect the rules of the edition, don't expect a good result... The rule is to put a sprite of the same height than the room surrounding it... It's so obvious that I should not have to tell it, even if it's correct in Software mode.
And when you know that the affitionnados playing on Software mode are a very small minority, you have understand an important part of the creation of a wad ==> OpenGl mode represents 85% of the modes used to play Doom. Did you know it?
So, making a wad should be dedicated to OpenGl mode. And if the author has really a lot of time to spend, testing his work with the Software mode is always possible...
Anyway, I agree 1000 % with Graf, when he don't want to bother with this outdated mode.

Software mode should be forgotten!!!
Or... You could use Win95 and Pacman, instead of it?

Here is my correction:


and here is the original version, with the stucked sprites:

[Shinjanji]

Were OpenGL ports as popular three years ago as they were today?

Also, was ZDoomGL even <i>around</i> 3 years ago, much less actually used by more than a handful of people?

Face it. The WAD was designed before OpenGL in Doom was so popular, and cannot be held responsible for the sprite clipping issues that arise when you play in a port other than what was suggested.

It's not a map bug. It's an engine limitation that Graf is unable to change without a whole hell of a lot of hacks and workarounds.


Also, I believe that the lack of ceiling and floor clipping for sprites may have been intentional in the original Doom, though I'm not 100% sure of that.

[Enjay]

Yeah unfortunately, however, you (Jive) are complaining about a WAD that was made for a different version of the game. Sure, it doesn't look right in OpenGL but it wasn't designed with OpenGL in mind. It did what it was supposed to in the port it was meant for. In fact, as Shinjanji said, a Zdoom compatible mod wasn't even possible in OpenGL mode when this was released (you can't count the old ZdoomGL because it didn't work for so many people). So whether the room should have been tall enough for the sprite or not is a debatable, if not an irrelevant, point because it looked OK in the Zdoom engine of the time. Who knew (or cared for that matter) that a port released years later, and using an entirely different rendering system, would not show it properly?

Of course I wouldn't want to go back to Win'95 or Pacman but equally I wouldn't expect either of these to work flawlessly on a system that was newer and significantly different to its originally intended one.

Oh and, unfortunately, I think your fix for the worm on the chair looks pretty bad (although not as bad as him having his head cut off). He's sitting on a chair with his head shoved up into a square alcove in the ceiling. It just looks odd and somewhat unpleasant for the worm.

[Jive]

You are all absolutely right, and I'm glad to be well informed thanks to you all.

Enjay, I didn't do it to have something beautiful, but to experiment how high should be the ceilings, and what part of the sprites were missing.
On the other hand, the fact to have its head half hidden is quite correct: if you want to see its head, you have to come closer... and to say quite.
If I have the idea to release it, I will have to contact Cyb and to ask to him if he agree or not, and if he prefer to do the corrections himself.
By the way, the idea of Cyb was NOT to have an alcove uppon its head, like I made it. But, once made, I thought that it was finally quite correct, and straight with the idea of such a mysterious creature. Most of the time, those creatures helping humans are more or less hidden, from one way or another.
Now that I experimented the correct height of the ceilings, I must consider the esthetic aspect. But it was NOT my purpose.

[Jive]

Here is the final version

[chopkinsca]

I didn't notice this post when I posted something similar here regarding number 1.

If you are going to be updating massmouth 2 (with Cyb's permission of course), be sure to fix the slopes that block your way since a fix in slope handling. There are two I can think of; one in the Texas Linguine foundation for the throat tunnel, second is in the forest when you have to bring that thing to a cage.