DRD Team

hmm Graf Zahl you seem to be forgetting to set stuff in the SDL part of the program
is this intentional because you cannot test this or is this because you keep forgetting it?

i have a patch ready for r202 but i should first check out why the engine is opening the GL renderer, then closing it and reopening it
although it seems it only runs through I_InitGraphics() only once...

edit: at first it sets a 4:3 resolution, then my set resolution, which is 1920x1200
and after adding a couple of resolutions in sdlglvideo.cpp, it switches to the 16:10 mode instantly, but it still sets it twice

If you got a patch, please post it. Right now I am in a situation where I can use it without problems.

fine, i'll post the things i have atm now,
and continue to search for the bug

it seems to issue SetResolution twice, but the Resolution: .. string only comes up once :s

edit, this was diffed with r203, but nothing changed when i used r202, so it is completely compatible (for now)

edit2: i don't know if it still occurs, but i used to have problems with the zipping tool when it was used in a directory with uppercase chars
it just lowercased them all, and in a UNIX environment that's not the right choice :p

hmm, i just made a small workaround that checks if the new resolution and bpp is the same as the old, and just print "Keeping old resolution" instead of actually switching
i'll throw the patch online ASAP (dumping out the debugging stuff i put in and the alike)

i don't like this patch though, because the fullscreen switch doesn't like it for example

Btw, is it relevant that (i'm told) Hexen/Heretic have been re-licensed GPLv2

Ozkan wrote stevenaaus:
[spoiler]subject:Raven's hexen/heretic now GPLv2
Monday, September 8, 2008 5:38 PM
From:This sender is DomainKeys verified
"O.Sezer" <******@gmail.com>
View contact details To:
"Steven" <stevenaaus@*****>

See: http://sourceforge.net/projects/heretic/

OZ[/spoiler]

This is already known, and has been discussed extensively.

Indeed, the significance is that it makes GPLing GZdoom possible, but doing so still requires considerable work. IIRC, the main points are that a sound library other than FMOD would have to be used and the software renderer would have to go. The first one is the big issue.

Chris has posted an OpenAL implementation but it still suffers from some problems that make it not an option.

Any update on this? I was looking at this forum thread and it sounds like it's somewhat far along, pending some OpenAL extensions?

The idea of a GPL'd GZDoom is nice if only because it's kind of a pain to try and compile with the FMOD libs which seem to be a moving target.[/url]

I'm having problems running r324 correctly

This version compiles pretty much owkey, but it looked like it was crashing when trying to load the init screen.
When I tried to run it through gdb, it showed me that it's having problems with when i commented out this line, or tried adding a check for exact ( if(exact) ), some wads would just run fine, but as suspected,
when i try to open some wad that changes the texture from the IWAD, you get a lot of messages and the game crashes as soon as you enter a level.

When i added that if(exact) part, gzdoom would just crash on line 431 of w_wad.cpp (with exact set to true) i'm using gcc 4.3.3-r1 (gentoo), and am building a 64b version
Where should i start to look if i want to create a patch? It's been a while since i've been programming in C


edit: copying over zdoom's svn version of that function made it work like a charm

'Sorry for the lack of SVN updates. My local copy of ZDoom is currently not usable for merging because I am working on something larger that needs to be finished first.

Don't worry graf, it's not like you have to release stuff,
it still is something you do for fun (and partially to learn stuff from), am i right?

If only i had more experience in C/C++ .

(btw: my compiler is complaining like mad about checks between unsigned and signed integers, i know this isn't noteworthy most of the time,
but it should be fixed though, just for those special occasions, you never knew)

I know. There's some header file that disables the warning in VC++ and any source that includes this file may have some issues with that. I always forget to re-enable the warnings and actually fix ZDoom's code so that it compiles without messages.

Talking to Graf Zahl over at Doomworld, apparently it would be somewhat useful to have some more eyes on the code. Making much more than very basic patches in C is beyond my skills, but I'd certainly like to help out where possible.

I can compile latest stable ZDoom without a problem. GZDoom r309M (latest official) starts to compile for me but dies a third of the way with some SDL-related stuff on i_main.o, so I assume at least all my depends are satisfied.

Currently, GZDoom r351 won't even cmake for me, and dies with the following:

Spoiler:

---

Code: Select all

superjamie@one:~/Desktop/gzdoom/trunk/release$ cmake -DCMAKE_BUILD_TYPE=Release -DFMOD_INCLUDE_DIR=/usr/local/include/fmodex -DFMOD_LIBRARY=/usr/local/lib/libfmodex-4.24.11.so ..
-- The C compiler identification is GNU
-- The CXX compiler identification is GNU
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Found JPEG: /usr/lib/libjpeg.so
-- Found ZLIB: /usr/lib/libz.so
-- Using system zlib
-- Using system jpeg library
-- Looking for strdup
-- Looking for strdup - found
-- Looking for strndup
-- Looking for strndup - found
-- Looking for sys/types.h
-- Looking for sys/types.h - found
-- Looking for stdint.h
-- Looking for stdint.h - found
-- Looking for stddef.h
-- Looking for stddef.h - found
-- Check size of char
-- Check size of char - done
-- Check size of short
-- Check size of short - done
-- Check size of int
-- Check size of int - done
-- Check size of long
-- Check size of long - done
CMake Error at CMakeLists.txt:82 (add_subdirectory):
  add_subdirectory given source "snes_spc" which is not an existing
  directory.


-- Looking for XOpenDisplay in /usr/lib/libX11.so;/usr/lib/libXext.so
-- Looking for XOpenDisplay in /usr/lib/libX11.so;/usr/lib/libXext.so - found
-- Looking for gethostbyname
-- Looking for gethostbyname - found
-- Looking for connect
-- Looking for connect - found
-- Looking for remove
-- Looking for remove - found
-- Looking for shmat
-- Looking for shmat - found
-- Looking for IceConnectionNumber in ICE
-- Looking for IceConnectionNumber in ICE - found
-- Found X11: /usr/lib/libX11.so
-- Looking for include files CMAKE_HAVE_PTHREAD_H
-- Looking for include files CMAKE_HAVE_PTHREAD_H - found
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - found
-- Found Threads: TRUE
-- checking for module 'gtk+-2.0'
--   found gtk+-2.0, version 2.16.1
-- FMOD include files found at /usr/local/include/fmodex
-- FMOD library found at /usr/local/lib/libfmodex-4.24.11.so
-- Selected assembler: /usr/bin/nasm
-- Looking for filelength
-- Looking for filelength - not found
-- Looking for strupr
-- Looking for strupr - not found
-- Looking for stricmp
-- Looking for stricmp - not found
-- Looking for strnicmp
-- Looking for strnicmp - not found
-- Looking for clock_gettime in rt
-- Looking for clock_gettime in rt - found
-- Performing Test HAS_VA_COPY
-- Performing Test HAS_VA_COPY - Success
-- Configuring incomplete, errors occurred!
superjamie@one:~/Desktop/gzdoom/trunk/release$ 

Please let me know if there's any more info I can provide or things I can do.

If you want to help, please use the SVN trunk, not the stable release which is already a few months old.
Any info regarding that won't help me much.