older cards & bpp, request for a tester, coding standards

[chippo]

Gentleheads,

I was having a problem with the -opengl switch in legacy-2-svn.

Several theories were posited in other threads, and the one that seemed most likely, was that my _system_ SDL (1.2.9) is a different version from the SDL that legacy-2 is linked against (1.2.11).

But this theory was shattered when (by mistake) I ran legacy-1.43 while forgetting to unset LD_LIBRARY_PATH, which was forcing dynamic linking with SDL-1.2.11. Lo! Legacy-1.43 ran just fine while dynamically linked against SDL-1.2.11 and certainly -opengl and sound were working a treat.

So, I started comparing the sources for legacy-1 and legacy-2 (regarding opengl) and eventually got -opengl working in legacy-2 (but broke sound). A right mess, though, and much of it hard-coded and much of it probably uneeded. But I have conclusively proved that one _can_ run legacy-2 with a different SDL to the system one (and not lose -opengl).

In the early days of 3d acceleration, the manufacturers were desperate to be the first (or close behind) to market. As a result, they skimped on broad support, and focussed on just getting one videomode to be accelerated. For cards like the voodoo2 and early nvidia ones, they only attempted to get 3d acceleration in 16bpp (and possibly also a restricted range of resolutions). This skimping was both on the actual hardware as well as the drivers.

Legacy-1 just forces 16bpp in certain circumstances, which is the _only_ depth that my video card (a nasty old riva tnt) can do 3d acceleration. So, I cut'n'paste quite a lot of code from legacy-1 to legacy-2, and now I have a legacy-2 (dynamically linking with SDL-1.2.11) where -opengl works, but sadly I broke sound somehow.

However, I think that maybe I uncovered another bug in legacy-2, which someone with a modern video card could test for me. Please would someone volunteer to test this; should take no longer than 5 minutes. You would need the following:
- Linux
- legacy-2 is working with sound and -opengl
- your X desktop is running in more than 16bpp (24 or 32)
The test you would do for me, is to turn your Xserver in 16bpp (you do this by setting 'DefaultDepth 16' in the Section "Screen" in /etc/X11/xorg.conf), and see whether you can run legacy-2 with sound and -opengl still. I suspect that you won't be able to.

Of course, if you currently run X in 16bpp and have legacy-2 working with sound and -opengl then the test is done.

If someone is kind enough to do the test, could you also please report the output of:
lspci | egrep -i 'vga|video|display'

While doing all my haxoring in legacy-2 (I was fiddling with interface/sdl/i_video.cpp, engine/p_setup.cpp and video/hardware/oglrenderer.cpp mostly), I noticed that there are at least 2 styles of indenting-and-braces, even in one file! While I have my own prefered style (different for C and C++), consistency is much more important to me than the actual style. Do we have somewhere, a coding style guide for legacy? If I end up contributing code, I'd like to ameliorate the consistency issue, rather than exacerbating it.

My next project is to write a test program to get to know SDL a little (never used it before; I mostly write user-interfaceless networking code) which will do the following:
- print out all the video modes that SDL could switch to (under the current Xserver restrictions)
- print out all the video modes that SDL could have opengl 3d acceleration
- given some minimum resolution and colour depth, print out the _best_ mode to switch to which will have opengl.
('best' hasn't been defined yet)

L8r,
choppo

[chippo]

My next project is to write a test program to get to know SDL a little (never used it before; I mostly write user-interfaceless networking code) which will do the following:
- print out all the video modes that SDL could switch to (under the current Xserver restrictions)
- print out all the video modes that SDL could have opengl 3d acceleration
- given some minimum resolution and colour depth, print out the _best_ mode to switch to which will have opengl.
('best' hasn't been defined yet)

I've finished my program. It doesn't quite do the above, but simply prints out for each possible colour depth, the resolutions that would be able to be both fullscreen and opengl.

Here's the program:#include "SDL/SDL.h"
#include <iostream>
using namespace std;

int main()
{
if(SDL_Init(SDL_INIT_VIDEO) != 0)
{
cout << "SDL_Init failed: " << SDL_GetError() << endl;
return 1;
}
const SDL_VideoInfo* info = SDL_GetVideoInfo(); // Can this function not fail?
SDL_PixelFormat format = *info->vfmt;
SDL_Rect** modes;

for (unsigned bpp = 8; bpp <= 32; bpp+=8)
{
cout << endl << "Checking out " << bpp << " bits per pixel" << endl;
format.BitsPerPixel = bpp;
format.BytesPerPixel = bpp / 8;
if ((modes = SDL_ListModes(&format, SDL_FULLSCREEN|SDL_OPENGL)) == NULL)
{
cout << "No modes are fullscreen and opengl" << endl;
continue;
}
if (int(modes) == -1)
{
cout << "Any dimension is OK? I dunno what that means." << endl;
continue;
}

cout << "Found the following modes (width x height x bpp):" << endl;
for (unsigned i=0; modes[i] != 0; i++)
cout << modes[i]->w << " x " << modes[i]->h << " x " << bpp << endl;
}
return 1;
}Oh no! What's happened to the formatting? All leading spaces on a line have been thrown away. But it should still compile if you cut'n'paste it (at least nothing's been turned to smilies).

I expect that the following command should work for you on a linux system:g++ -Wall -g -o modes -lSDL modes.cpp
But I happened to have to used:g++ -Wall -g -o modes -I/usr/local/chippo/include -L/usr/local/chippo/lib -lSDL modes.cpp

If I run modes on my machine, I get the following output:chippo@chipnew:/usr/local/chippo/games$ ./modes

Checking out 8 bits per pixel
No modes are fullscreen and opengl

Checking out 16 bits per pixel
Found the following modes (width x height x bpp):
1600 x 1200 x 16
1400 x 1050 x 16
1280 x 1024 x 16
1280 x 960 x 16
1280 x 800 x 16
1280 x 768 x 16
1152 x 864 x 16
1024 x 768 x 16
960 x 600 x 16
840 x 525 x 16
832 x 624 x 16
800 x 600 x 16
720 x 450 x 16
720 x 400 x 16
700 x 525 x 16
640 x 512 x 16
640 x 480 x 16
640 x 400 x 16
640 x 384 x 16
640 x 350 x 16
576 x 432 x 16
512 x 384 x 16
416 x 312 x 16
400 x 300 x 16
320 x 240 x 16
320 x 200 x 16
320 x 175 x 16

Checking out 24 bits per pixel
No modes are fullscreen and opengl

Checking out 32 bits per pixel
No modes are fullscreen and opengl

That's the answer! I can only run fullscreen and opengl in 16 bpp.

Legacy-1 works fine in fullscreen and opengl but I can't run legacy-2. And here's the reason why. My stderr.txt contains:Error: Could not set OpenGL vidmode.My stdout.txt contains (amongst a lotta other stuff):I_SetVideoMode: fullscreen 320 x 200 (8 bpp)
Could not obtain requested resolution.

But what's the correct solution? Obviously I could add some logic that said: "if we want fullscreen and opengl and bpp != 16 and SDL_ListModes says the mode is not available, then try again with bpp = 16".

This would help me, and wouldn't hurt anyone else, but surely we could do better? Any help on the logic for a generic solution?

TIA,
chippo

[Pate]

I suppose you could remove these from oglrenderer.cpp


SDL_GL_SetAttribute(SDL_GL_RED_SIZE, 8);
SDL_GL_SetAttribute(SDL_GL_GREEN_SIZE, 8);
SDL_GL_SetAttribute(SDL_GL_BLUE_SIZE, 8);


And then SDL would autoselect a proper 3D mode. At least it should. I have not tested this.

Also, cards that cannot do 24bpp are really, really, really old. I feel that supporting those would be mostly just wasted energy. Also they probably miss features that are needed for the effects we want to add later.

[chippo]

Hey! How did you do that 'Code:' markup? I found some info on vB code here:
http://forums.newdoom.com/faq.php?faq=vb_read_and_post#faq_vb_special_codes
which directed me here:
http://forums.newdoom.com/misc.php?do=bbcode

They only mention the markups 'highlight', 'img' and 'quote'. 'Quote' is semi-usable for code, but is a pain for 2 reasons:
- All tabs are turned to spaces.
- All leading whitespace on a line disappears.

[chippo]

Hey! How did you do that 'Code:' markup?

Don't worry; I found out how. It's with a 'code' tag. Duh! Obviously.

When I 'quote'ed you, your post had been turned back into markup language.

Don't suppose there's some markup to turn off smileys? And have you got a link to a complete list of all tags supported?

TIA,
chiphund

[chippo]

I suppose you could remove these from oglrenderer.cppSDL_GL_SetAttribute(SDL_GL_RED_SIZE , 8);
SDL_GL_SetAttribute(SDL_GL_GREEN_SIZE, 8);
SDL_GL_SetAttribute(SDL_GL_BLUE_SIZE, 8);And then SDL would autoselect a proper 3D mode. At least it should. I have not tested this.Wow! Such a big improvement for such a small change. What bad stuff would have happened to other people by removing those lines?

Now I can play in the menus to my heart's content, I can happily change resolutions and I can set my controls. This is running with opengl, i.e:
./Legacy -opengl -iwad Doom1.wad

Interestingly, _all_ the other bugs I've reported relating to menus have disappeared. Probably a case of not checking return values of system/library calls and probably easy to fix.

Your suggestion didn't allow the game to run, though. When I'd set everything up (including checking that QUIT worked and saved my settings correctly), I selected NEW GAME and then it bombed.

Stderr.txt contained only:
Error: Error during map setup.

The relevant piece of stdout.txt was:
Couldn't load music lump: OpenGL video mode has not been set
Level E1M1 has no GL nodes.
Trying to use OpenGL renderer without GL nodes. Exiting.

Ahh well. Thanks though anyway, that has helped a lot.

Also, cards that cannot do 24bpp are really, really, really old. I feel that supporting those would be mostly just wasted energy. Also they probably miss features that are needed for the effects we want to add later.

But surely we can support old hardware with (almost) no work on our part? Would the following promise to the user (of video hardware) not be easy to implement and not give users of older hardware the ability to play (at least) the older games? Remember, that in my case, legacy bombed because it wanted fullscreen+opengl+8bpp, but my card could only offer fullscreen+opengl+16bpp.

Promise to the User:
- If SDL says that you don't have a feature that is configurable (via the menus, console, command-line or config-file), then we'll turn it off for you, and grey it out so that you can't turn it on.
- If SDL says that you don't have a feature that is not configurable, then tough! Live without Legacy or buy more modern hardware.
- If SDL can give us all the info and we can't get all the required features in the wanted colour depth but we can get all the required features in a greater colour depth, then we'll use the higher colour depth.
- If SDL can give us all the info and we can't get all the required features in the wanted resolution but we can get all the features in a greater resolution, then we'll use the higher resolution and the game will appear in a (smaller) box centered on the screen.

Comments? Too difficult? Could we promise more without difficulty?

Tchuss,
chiphog

[Planky]

If you place code in the code tags, no smiley's will be displayed.

:D

[Planky]

Your suggestion didn't allow the game to run, though. When I'd set everything up (including checking that QUIT worked and saved my settings correctly), I selected NEW GAME and then it bombed.

Stderr.txt contained only:
Error: Error during map setup.

The relevant piece of stdout.txt was:
Couldn't load music lump: OpenGL video mode has not been set
Level E1M1 has no GL nodes.
Trying to use OpenGL renderer without GL nodes. Exiting.

You need to build gl nodes for the IWAD you are using. Simply download GLBSP (http://glbsp.sourceforge.net/), then drag and drop the IWAD onto the executable (Im assuming it will behave the same way in Linux). This will build the gl-nodes and allow you to play it with Legacy 2.

[smite-meister]

You need to build gl nodes for the IWAD you are using
Just to clarify, "building GL nodes" for a map means rebuilding the BSP tree and some other resources using a more reliable and complete algorithm (and format) than the original Doom used.
Nearly all OpenGL renderers require these new resources in order to work, and so does ours.
Here's the program you need: http://glbsp.sourceforge.net/

[MR_ROCKET]

This kind of got me thinking of what was going on in the other thread, anyways yeah it simply wont do anything unless you run glbsp and glvis node utils on any wads, whether it's an iwad or pwad..currently. Will these be built into Legacy2 later on Smite?

[chippo]

However, I think that maybe I uncovered another bug in legacy-2, which someone with a modern video card could test for me. Please would someone volunteer to test this;

I withdraw my request for a tester. My daughter brought her computer to get some stuff copied and she has a more recent video card:
$ lspci | egrep -i 'video|vga|display'
0000:01:00.0 VGA compatible controller: nVidia Corporation NV18 [GeForce4 MX 440 AGP 8x] (rev c1)

I'm sure this is recent enough, 'cos I can run unpatched legacy -opengl on her computer when the Xserver DefaultDepth is either 24 or 32.

And, as I suspected, when her Xserver is running in 16 bpp, then unpatched legacy -opengl dies (with the same error as my machine).

So, until I get round to implementing my be-kind-to-older-cards framework, I would suggest that the legacy install docs (more or less docs/compile.html) should mention that you _must_ be running your Xserver in 24 (or higher) bpp. Also, I would suggest a test added to legacy, which would bomb early with the error:
Sorry, to run legacy with -opengl you need your Xserver to be in 24bpp or higher. Set DefaultDepth in /etc/X11/xorg.conf.

Obviously we'd also need the Windows equivalent.

Ciao,
chippenbronx

[Planky]

Obviously we'd also need the Windows equivalent.

Ciao,
chippenbronx

Bluescreening?

[Pate]

And, as I suspected, when her Xserver is running in 16 bpp, then unpatched legacy -opengl dies (with the same error as my machine).


Does it work if you do the fix I mentioned above?

[MR_ROCKET]

Bluescreening?

Planky be nice, the windows builds haven't been to bad at all, in fact I haven't had any problems with them. However, don't try adding any bots or you might run out of memory :D

[chippo]

Does it work if you do the fix I mentioned above?

Oh yes, oh yes, Oh YES!!! Sorry I didn't make that completely unambigously clear earlier. But commenting out those three lines made it work with all (even ancient) cards that have a semblance of hardware 3D acceleration (that I have access to; which are voodoos and nvidias), in all Xserver bit depths (all of 8, 16, 24 and 32 tested) where any other app (like glxgears) can do opengl.

It's working so well, that I tentatively ask, "What bad stuff would have happened to other people by removing those lines?"

Thanks again for the fix,
chiphog

[iori]

The amount of energy you have astounds me.

I wish to extend my apologies to anyone who reads my posts, you will not be getting those brain cells back.

[Pate]

It's working so well, that I tentatively ask, "What bad stuff would have happened to other people by removing those lines?"


I'm guessing nothing, so I removed them in SVN.

[chippo]

I'm guessing nothing, so I removed them in SVN.

I see! 'svn update' gives me a conflict. Viva!

But should it be neccessary to put them back, I'm quite serious about building an infrastructure to fall back to different depths, resolutions etc. for older hardware.

It's just that, right now, the software renderer doesn't care what hardware you have, and the oldest nastiest 3d accelerated cards are working fine.

Of course, I should be thanking SDL for that.