PrBoom-Plus, ver. 2.5.1.4

[Graf Zahl]

So far nobody but me has ever added anything to it.

[Gez]

Well, I added a parser for detail textures. All it does is parse them, of course. I'm not going to try implementing detail textures. But the detail_test.wad file can now be loaded without errors.

[entryway]

Gez said:

Well, I added a parser for detail textures. All it does is parse them, of course. I'm not going to try implementing detail textures. But the detail_test.wad file can now be loaded without errors.

I am sure you did it incorrectly, because you do not know syntax. So it is:

detail
{
  (walls | flats) [default_detail_name [width [height [offset_x [offset_y]]]]]
  {
    texture_name [detail_name [width [height [offset_x [offset_y]]]]]
  }
}

Where detail_name is a bmp/png/tga/jpg/pcx/gif lump between HI_START/HI_END markers. You do not need to add it to TEXTURES1 or somewhere else.

Example:

detail {
  walls smooth01 32.0 //default detail for walls (width = 32, height = 16, offset_x/y = 0)
  {
    brick7  detstone 64.0 64 10.532
    brick8  detail02 // detail02 16 16 0 0
    water1 // do not apply default detail to water
    water2
    water3
    water4
  }
  flats // no default detail for flats
  {
    grass1 Grass01 32 32
    NUKAGE1 detslime 16 16 0 0 // different offsets for animated flats make sense
    NUKAGE2 detslime 16 16 4 4
    NUKAGE3 detslime 16 16 8 8
  }
}

[Gez]

entryway said:

I am sure you did it incorrectly, because you do not know syntax. So it is:

detail
{
  (walls | flats) [default_detail_name] [, width] [, height] [, offset_x] [, offset_y]
  {
    texture_name [detail_name] [,width] [, height] [, offset_x] [, offset_y]
  }
}

That doesn't seem right.

detail
{
  (walls | flats) [default_detail_name [width height [offset_x offset_y]]]
  {
    texture_name [detail_name] [width height [offset_x offset_y]]
  }
}

Seems more plausible this way.

[entryway]

Gez said:

Seems more plausible this way.

You can specify width without height and offset_x without offset_y. Default values are (width:16 height:16 offset_x:0 offset_y:0) So it is:

detail
{
  (walls | flats) [default_detail_name [width [height [offset_x [offset_y]]]]]
  {
    texture_name [detail_name [width [height [offset_x [offset_y]]]]]
  }
}

[Gez]

Alright, changed the parser.

[Doom_user]

The 5:4 aspect ratio is incorrect. It increases the player's vertical viewing area by 11.11%, when it should only be increased by 6.66%.

[Mechadon]

Changelog said:

[+] Added support for ZDoom normal uncompressed nodes.

I just wanted to pop in here and say thanks for taking the time to add this feature!

[Gez]

Mechadon said:

I just wanted to pop in here and say thanks for taking the time to add this feature!

Eternity just got that, too, by the way. Today, actually (r1212).

[entryway]

Doom_user said:

The 5:4 aspect ratio is incorrect. It increases the player's vertical viewing area by 11.11%, when it should only be increased by 6.66%.

Fixed?

[Doom_user]

It's unchanged.



I use a test level to check this, if the 5:4 aspect ratio were only increasing the vertical viewing area by 6.66% the steps would line up exactly between the 4:3 and 5:4 screenshots, but since the vertical viewing area is increased by 11.11%, everything gets vertically compressed in the 5:4 aspect ratio.

[entryway]

Doom_user said:

It's unchanged

Are you sure you are using the latest build?

For me it is identical to (g)zdoom now.

http://prboom-plus.sf.net/2506_5x4.png
http://prboom-plus.sf.net/2507_5x4.png

[ReFracture]

Hey entryway, I'd like to bring a few GL rendering tidbits to your attention:

Vrack II start of level:
PrBoom-Plus Software mode: http://img532.imageshack.us/img532/1941/softx.jpg

PrBoom-Plus OpenGL mode: http://img266.imageshack.us/img266/5062/60523425.jpg

GZDoom OpenGL mode: http://img231.imageshack.us/img231/6627/gzgl.jpg

And another different issue in Map 31 of Alien Vendetta:

PrBoom-Plus OpenGL: http://img408.imageshack.us/img408/6240/avprgl.jpg

GZDoom OpenGL: http://img651.imageshack.us/img651/3108/avgzgl.jpg


Not really sure if you know about these or not.

[entryway]

Mike.Reiner said:

And another different issue in Map 31 of Alien Vendetta:

And another on eternal.wad map13
http://prboom-plus.sf.net/doom29.png

[Graf Zahl]

Mike.Reiner said:

Hey entryway, I'd like to bring a few GL rendering tidbits to your attention:

Vrack II start of level:
PrBoom-Plus Software mode: http://img532.imageshack.us/img532/1941/softx.jpg

PrBoom-Plus OpenGL mode: http://img266.imageshack.us/img266/5062/60523425.jpg

GZDoom OpenGL mode: http://img231.imageshack.us/img231/6627/gzgl.jpg

Please don't remind me!

I can't remember how long I needed to make this horrendously broken sky setup work...

[entryway]

Graf Zahl said:

Please don't remind me!

http://prboom-plus.sf.net/gzdoom_av_map20.png

[Doom_user]

I redownloaded from http://prboom-plus.sourceforge.net/prboom-plus-2.5.0.7.test-win32.zip and redid the test just to be sure.





Unless I'm overlooking something, it appears to be unchanged.

[entryway]

I do not understand your test map and I do not know your resolution and settings. The only way I can test it is comparison with gzdoom at for example 800x600w. And it is absolutely similar now.

[Doom_user]

GZDoom's 5:4 aspect ratio is incorrect too.

GZDoom


If you want to test this in PrBoom Plus do this.

Using render_aspect 3 and any 4:3 resolution take a screenshot of any level without moving from the player start.

Now, using render_aspect 4 and a 5:4 resolution that's the same width as the 4:3 resolution take a screenshot of the same level without moving from the player start.

Now put the screen shots side by side (vertically center the 4:3 screen shot). Everything in the 5:4 screen will look scrunched in/vertically compressed compared to the 4:3 screen shot. This is because the 5:4 screen is 6.66% taller then the 4:3 screen, but the player's vertical viewing area is being increased by 11.11%.

The test level I'm using is nothing but a series of stairs in front of the player to make the scrunched in/vertically compressed effect more obvious. If the 5:4 aspect ratio was correct the stairs in the 4:3 and 5:4 screenshots would line up when put side by side.

Test level
http://download1002.mediafire.com/cnwvjgzmsywg/ldz4ucgrifm/stripe.wad

[entryway]

Doom_user said:

GZDoom's 5:4 aspect ratio is incorrect too.

Ok. I think I have fixed it. Check it again.

I do not know why 5/4 == 1.2 in gzdoom. It should be 1.25, right?

[Doom_user]

I just tested the software renderer, the 5:4 aspect ratio works correctly in it.

http://img96.imageshack.us/img96/3426/bigcompalt.png

Notice how everything is perfectly lined up between the 4:3 and 5:4 sides.

Now look at the same thing in the gl renderer.

http://img195.imageshack.us/img195/194/bigcomp.png

Edit:Nevermind I didn't see entryway's previous post.

[Doom_user]

entryway said:

Ok. I think I have fixed it. Check it again.

I do not know why 5/4 == 1.2 in gzdoom. It should be 1.25, right?

1.25 is correct.

This explains why there was an 11.11% increase in the player's vertical viewing area, in a 6:5 resolution that would be the correct amount to increase it by.

I'll download and check it.

[entryway]

Doom_user said:

Now look at the same thing in the gl renderer.

Are you sure you are using the latest version?

glboom-plus.exe 1 138 688, 16 Jun 10, 12:38

http://prboom-plus.sourceforge.net/aspect_comparing.png

Left: glboom-plus.exe stripe.wad -geom 800x600w and 4x3 aspect
Right: glboom-plus.exe stripe.wad -geom 800x640w and 5x4 aspect

Doom_user said:

Edit:Nevermind I didn't see entryway's previous post.

Oh ok :)

[Doom_user]

It works perfectly now.

[entryway]

Doom_user said:

It works perfectly now.

GrafZahl needs to check his calculator then. Or probably 1.2 was there, because pixels are not square at 5x4? Does it matter? Al least now it is similar to software...

[Gez]

Doom_user said:

GZDoom's 5:4 aspect ratio is incorrect too.

GZDoom

Now, using render_aspect 4 and a 5:4 resolution that's the same width as the 4:3 resolution take a screenshot of the same level without moving from the player start.

I see only one 5:4 resolution in GZDoom (720x576), and no 4:3 resolution available has the same width (640x480 or 768x576, but no 720x540).

[entryway]

Gez said:

I see only one 5:4 resolution in GZDoom (720x576), and no 4:3 resolution available has the same width (640x480 or 768x576, but no 720x540).

That is because zdoom does not allow to set any resolution if it is windowed. Or probably I do not know corresponding command line switches. PrBoom allows any with -geom WxHw

http://prboom-plus.sf.net/res01.png
http://prboom-plus.sf.net/res02.png

[Gez]

entryway said:

That is because zdoom does not allow to set any resolution if it is windowed. Or probably I do not know corresponding command line switches. PrBoom allows any with -geom WxHw

Console command: vid_setmode <width> <height>

But it still doesn't allow any arbitrary resolution, however. (E.g., vid_setmode 400 800 will tell you it's an unknown mode.)

[TimeOfDeath]

When I set the resolution to anything below 512x384, it looks like this in fullscreen mode:



The display area is squished to the top with a bunch of junk underneath.

[entryway]

I don't confirm