Welcome to the ZDoom Forums!

Ok, great. Got 'em.

this was a newly created sector so i doubt there was anything wrong with it (i did the F10 checks and it passed). it seemed as if the 'old' sector was no longer recognized, as if it was no longer valid DEU... er... due to the split sector action. I'll check it again see what i can dig up.

And in fact, it is called str(n)casecmp under Linux.

You're right Hirogen2, but I'm not sure if strcasecmp and strncasecmp are defined in the headers for all compilers. Using allegro's version makes sure that it should compile with any platform that allegro supports.

However, I am not really sure why or where stricmp is defined in my gcc headers when strnicmp is not. I think it would be a good idea to change all instances of stricmp to ustricmp too. Other setups probably aren't certain to have it.

So Chris, in case you want to change them too to be certain about compatibility, here is the location (and context) of each use of stricmp:

> grep -n stricmp *
deu.c:697: if (!strcmp( argv[ 0], "-?") || !stricmp( argv[ 0], "-h") ||
deu.c:698: !stricmp( argv[ 0], "-help"))
deu.c:705: if (!stricmp(argv[0]+1, options[ optnum].short_name) ||
deu.c:706: !stricmp(argv[0]+1, options[ optnum].long_name))
deu.c:823: if (!stricmp( option, options[ optnum].long_name))
deu.c:830: !stricmp(value, "yes") ||
deu.c:831: !stricmp(value, "true") ||
deu.c:832: !stricmp(value, "on") ||
deu.c:833: !stricmp(value, "1")
deu.c:838: !stricmp(value, "no") ||
deu.c:839: !stricmp(value, "false") ||
deu.c:840: !stricmp(value, "off") ||
deu.c:841: !stricmp(value, "0")
deu.c if (!stricmp( com, wad->filename))
deu.c if (!stricmp( com, wad->filename))
deu.c if (!stricmp( com, wad->filename))
deu.c if (!stricmp( out, wad->filename))
deu.c if (!stricmp( wadf, wad->filename))
deu.c if (!stricmp( out, wad->filename))
deu.c if (!stricmp( com, wad->filename))
deu.c if (!stricmp( com, wad->filename))
deu.c if (!stricmp( com, wad->filename))
deu.c if (!stricmp( out, wad->filename))
deu.c if (!stricmp( wadf, wad->filename))
deu.c if (!stricmp( out, wad->filename))
edit.c:215: if (!stricmp( outfile, wad->filename))
readcfg.c:221: if(!stricmp(str, colours))
readcfg.c:262: if(!stricmp(buf, header))
readcfg.c:417: if (stricmp (buff, "[wad]\n") == 0)
readcfg.c:514: if (tok && stricmp (tok, "delete") == 0) // Delete an already-defined thing
readcfg.c:568: if (stricmp (tok, "Poly") == 0)
readcfg.c:572: else if (stricmp (tok, "DeathScript") == 0)
readcfg.c:576: else if (stricmp (tok, "NoAngle") == 0)
readcfg.c:580: else if (stricmp (tok, "Start") == 0)
readcfg.c:585: else if (stricmp (tok, "DMStart") == 0)
readcfg.c:589: else if (stricmp (tok, "SectorAction") == 0)
readcfg.c:593: else if (stricmp (tok, "Resizer") == 0)
readcfg.c:597: else if (stricmp (tok, "Path") == 0)
readcfg.c:606: else if (stricmp (tok, "NoPic") == 0)
readcfg.c if (stricmp (keys->Key, tok) == 0)
readcfg.c if(tok && !stricmp(tok, "format")) {

More changes are needed, Chris.

Lines 375-377 of deu.h are currently: Change these filenames to all undercase.

There are still more problems with the makefile. The unix-specific target for clean should be "rm -f depend *.o zeth" rather than "rm -f depend *.o zeth". Also, should be changed to As a note, it is standard to name the makefile "Makefile", that is, with a capital M. Additionally, I would have to say that the use of all of the "ifndef UNIX" does not really make things easier. It requires the user to set the environmental variable UNIX, but there is no indication that this needs to be done unless you look inside the makefile. Thus, there should either be a short README or INSTALL with build instructions, or simply have a separate makefile for unix called Makefile.unix or Makefile.linux.

Jim wrote:More changes are needed, Chris.

Whoops. Forgot about that. Done.

And sorry about the UNIX thing. I thought Unix and all variants automatically set it, or something. Is there any Linux/ Unix environment variable, or something make automatically sets in Unix or Linux, and rarely/never in DOS/Windows, that'd tell me this?

I have an Nviidia vanta card, XP Pro for the OS, the only 2 color depths available are 16 bit and 32 bit. WinZeth only seems to like 256 colors so I'm unable to get it running. Any chance the next release can support additional graphics modes?

TIA

Running it in a window should use the same color depth as your desktop. Set Fullscreen = False in zeth.ini if it exists, or zethdef.ini. The next version may attempt to use the desktop color depth(or the highest one available) first, though.

That worked perfectly.

thanks

The following code (lines 68-75 of gfx.c) makes it impossible to enable windowed mode in Linux via the config file (Fullscreeen = False has no effect):
Since Zeth only works in Linux in windowed mode at the moment (at least for me), I suggest removing the ifdef.

Chris, with the changes I have mentioned, Zeth runs fine in Linux.

Jim wrote:The following code (lines 68-75 of gfx.c) makes it impossible to enable windowed mode in Linux.

Hmm.. actually, I have that check there because certain OS's(*cough*DOS*cough*) that always have a console, can't do windowed modes. My thinking was that if the OS could do windowing, the console would be disabled by default, so if the console existed, the OS couldn't do windowed modes(compiling with USECONSOLE=1 effectively disables windowed modes). Luckilly, I've been able to remove a bunch of the ALLEGRO_CONSOLE_OK dependancy, but it's still quite prevelant and required, without something else in place.

Actually, I think I just came up with something. Should solve that problem, and the problem of the program aborting if it fails to switch between fullscreen <-> windowed.

WinZeth works fine but a few things: The Quit button doesn't work for me. If I click it, WinZeth freezes. Also, sometimes my machine reboots without any error message or thing, when I'm working with WinZeth. Screen gets black and machine restarts, only if I work with WinZeth!

BTW, when do you add Live-Preview to the editor so you don't have to play it just to get the textures, floors and sectors previewed? Doom Builder is already capable of this:

Tormentor667 wrote:The Quit button doesn't work for me. If I click it, WinZeth freezes.

Are you loading pwads? I recently discovered a bug where, in the new cleanup code, it'd free the memory associated with the pwad list, but I failed to realize I forgot to increment the counter, so it kept freeing the first pwad in the list indefinately. Some versions of Windows seems to let you do this, while others would just crash on you. Also, using "invalid" textures or flats(patches, sprites, or non-existant graphics) had a similar bug and would freeze the program. Both problems have been fixed.

As for Live-Preview, that may not be included after all. The Doom-like engine I have in the making, it turns out, is too restrictive to properly display ZDoom levels. What I could do, though, is create a simple way to invoke ZDoom(GL) with all the loaded pwads. Since ZDoom automatically builds the nodes and such for you if they're not present, that should be as simple as specifiying where the exe is. I could probably even make it so you can start out in any specific point in the map, if you can use the console "warp <x> <y>" command from the command line.

The things I really want to work on right now, are:
A) Finding out that damned XP problem. Any of you that have problems using WinZETH, do you have Service Pack 1 installed? What about those of you that run it fine under XP?

B) Saving levels to already-existing pwads, without destroying the pwad. That's my biggest gripe with DEU/DETH/ZETH.

Chris wrote:...if you can use the console "warp <x> <y>" command from the command line.

You can do it by prefixing it with a plus like this: +warp "X Y"