DRD Team

Indeed, that did fix the issue, now the glitch does not show anymore!.

@Costja,
Saw some of your stuff about linux GZDoom, but some links appear dead. Are they against GZDoom 1.0.24 or 1.0.25 ? I can program C (though don't know OpenGL) if I can help out. Could you email me your latest patches ?
stevenaausUNSPAM@yahoo.com

Torr Samaho wrote: I cleaned the GL patch a little and merged it with Skulltag without hampering the Windows code at all. Once the pixel format is selected properly, this should work well and can be backported to GZDoom straightforwardly.

Since I don't have Linux and can't test it I'd appreciate if you could make the patch work in a fashion that I only have to add it to the current code. I'd really like to have a version with native Linux support available without the need of such patches.

Graf Zahl wrote:Since I don't have Linux and can't test it I'd appreciate if you could make the patch work in a fashion that I only have to add it to the current code. I'd really like to have a version with native Linux support available without the need of such patches.

just to be clear, (for my benefit), this is the reason that 1.0.25 didn't have the patch integrated, right? (i'm not complaining, just asking).

Graf Zahl wrote:

Torr Samaho wrote: I cleaned the GL patch a little and merged it with Skulltag without hampering the Windows code at all. Once the pixel format is selected properly, this should work well and can be backported to GZDoom straightforwardly.

Since I don't have Linux and can't test it I'd appreciate if you could make the patch work in a fashion that I only have to add it to the current code. I'd really like to have a version with native Linux support available without the need of such patches.

it would require a load of patches (or at least 1 with multiple files in them :p)
with for ex to use #ifdef _LINUX in the files to compile cleanly on both OS'es

disturbedite wrote:

Graf Zahl wrote:Since I don't have Linux and can't test it I'd appreciate if you could make the patch work in a fashion that I only have to add it to the current code. I'd really like to have a version with native Linux support available without the need of such patches.

just to be clear, (for my benefit), this is the reason that 1.0.25 didn't have the patch integrated, right? (i'm not complaining, just asking).

Indeed. I can't confirm that it's working correctly so I need someone who makes a patch that doesn't render the Windows version inoperable.

Graf Zahl wrote:Since I don't have Linux and can't test it I'd appreciate if you could make the patch work in a fashion that I only have to add it to the current code. I'd really like to have a version with native Linux support available without the need of such patches.

I can make such a patch, but I won't have time to do so soon. So if you don't mind waiting a little for this, I'll do it.

i can check this one out, but my coding skills arent so great so i don't know if it'll be better than torr samaho's version

owkey, almost done creating the zip file including the .patch file (i hope you know how to apply these files graf zahl?)
it's based on 1.0.24 though, i'll update the source to 1.0.25 and PM the link to you when it's finished

Hmmm, maybe there's later work been done than what i found ?
Can anyone provide links/ attachments to the latest code.This is what i've managed to do.....

Found GZDoomSDL.tar.gz (md5sum a42d10cd90ee809a2d7e66d3d1aad8)
at http://ifolder.ru/3317824. Thanks for your work. This is looking pretty
cool. With a few hacks, got it compiled and running. I'm using flac-1.1.2,
fmod-3.75.so , xorg-x11-6.8.2-31, SDL-1.2.8-3.2, ATI Radeon Mobility M6 LY rev 0,
alsa-lib-1.0.9rc4-2, fedora 4
-------------
Some issues I had but have solved are:
1. Had to copy over the FLAC directory from the GZDOOM-1.0.25 source tree.
2. Plenty of gtk/gdk/glib include files needed sym-linking from /usr/include.
(I don't know why this happens, but I often come across it)
3. Some "g++ : no input files" errors, solved by , for eg:
g++ ..... -o releaseobj/i_music.o -c
I added found the object source file i_music.cpp, and added it to the command
g++ ..... ./src/sound/i_music.cpp -o releaseobj/i_music.o -c
Guess this is a makefile issue. Some (all?) of the files are:
./src/sound/fmodsound.cpp
./src/sdl/glstubs.cpp
./src/sound/i_music.cpp
./src/sdl/i_main.cp
./src/sdl/i_system.cpp
-------------
Running tutnt.pk3, this anomaly on tut01 (attached picture - everything
dissappears except sky and floor) seems pretty bad. It is skybox related as
setting gl_noskybox 1 removes the skybox and the buildings reappear too. From
the forum, I actually added this line:
gl.flags |= RFL_NOSTENCIL;
to "src/gl/r_render/r_render.cpp" line 951 of 954, which fixed the problem, but
with the same side effects that the skybox messed up and there is white particles everywhere.
(Sorry, but I know NOTHING about OpenGL).
I also had to nix this line in compilation because couldn't find g_access defined anywhere:

"src/gl/gl_hirestex.cpp" line 212 of 264 --80%-- col 11-32

checkName.Format(*checklist, progdir, tex->Name, *extp);
// WHERE IS g_access DEFINED: if (g_access(checkName, 0) == 0)
if (0)
{
hascolorkey = !!strstr(checkName, "-ck.");

Looking forward to playing this wad in linux ;>. Performance seems great.
Thanks.

Yet another update.
To use this patch run command like "patch -p1 <patch" in GZDoom 1.0.25 source directory.

Changes:
- Working SetupPixelFormat (hopefully sky bugs are fixed now)
- Fixed brightness/constrast/gamma
- Removed some unnecessary changes

GuntherDW, heh.. and I'm not a programmer ))
W32 code wasn't removed, I "commented" it using #ifdef blocks.
Should I replace #ifdef unix with #ifdef _LINUX?

If someone can make this version compiling on Windows, feel free to do so )

[ATTACHMENT DELETED, latest patch is below in this thread]

Costja wrote:Should I replace #ifdef unix with #ifdef _LINUX?

#ifdef unix is fine.

and tbh the source was somewhat strange,
what i mean is,
you made the files you worked on have a UNIX encoding (\n line endings),
but left the other ones alone

you should keep the original encoding or convert all the files as well

as it could and WILL confuse tools like diff etc

edit: you still removed code, i'll clean that one up and make a tar.gz for all of the linux users
(and send it to graf to look at the changes)

Will test out the latest patch. Thanx.

Those end of line characters can play havoc when generating file patches.
I guess you know you can convert the end-of-line chars with the
"dos2unix" and "unix2dos" commands.

Playing tutnt.pk3, in a corridor level , those suicide guys "aaarrrgghhh"
just scared me *shitless* as it got louder and louder and i hadn't seen them before.

- New patch works great. Compilation and Skyboxes seem mostly fixed. Only probs: _access and g_access are still undefined and need removing. (I can't find a reference to them in my /usr/include/ and usr/include/GL either). And program now only works for me in 24bpp depth. In 16bpp it hangs and eventually segfaults after a minute or so somewhere inside V_SetResolution. A bit of a downer as my laptop's video is pretty budget.

> ATI Radeon Mobility M6, Module glx: vendor="X.Org Foundation" 6.8.2, v 1.0.0

In case anyone's still with gcc++3.2, for me it has extra problems that g++4.0 doesn't:
......
src/p_things.cpp:261: syntax error before `-' token
src/p_things.cpp:284: request for member `Length' in `aim(...)', which is of
non-aggregate type `FVector3 ()(...)
.....
Something i don't know is happening with aim_t that g++32 doesn't like
and the only other prob is at final linking, though this could be my gcc32 installation
.....
releaseobj/gl_draw.o(.text+0x797): In function `gl_DrawSavePic(DCanvas*, char const*, int, int, int, int)':
gl_draw.cpp: undefined reference to `gl_DrawSavePic(DCanvas*, char const*, int, int, int, int)::palette
releaseobj/gl_draw.o(.text+0x7ef):gl_draw.cpp: undefined reference to `gl_DrawSavePic(DCanvas*, char const*, int, int, int, int)::palette
.....
but i don't any idea about what the issue is here, but I guess gcc-4 is pretty standard now days anyway.