Release 1.48.18 archive files

Michael Bäuerle — Mon, 26 May 2025 09:47:46 -0000

Yes, it's OK now.

Release 1.48.18 archive files

Ville Bergholm — Sun, 25 May 2025 21:55:22 -0000

https://sourceforge.net/projects/doomlegacy/files/1.48.18/doomlegacy_1.48.18_common.zip looks fine to me now, I guess Wesley fixed it?

How do you make this run at a smaller screen?

Wesley Johnson — Thu, 15 May 2025 09:26:59 -0000

If you downloaded the common zip file, then there is a docs directory in that.
There are two html files, legacy.html that covers the command line, and console.html that covers console commands within the game.

Otherwise, these doc files can be read on the docs page of the DoomLegacy home site.

Release 1.48.18 archive files

Wesley Johnson — Thu, 15 May 2025 09:16:59 -0000

Replaced the common file with a new one that I made by hand this time.

Ville did not reply, so after waiting 2 weeks, I decided to put up the files myself. I did not expect it to go without problems. Usually Ville (smitemeister) creates the common file, which is created using a script tool.

These files are made by a combination of automated scripts, which I use sometimes, and do not have any idea of what happened, or was it right, and hand operations to fix things that I do notice were not right.. Otherwise, I try to create them by hand by looking at the previous release files that I have.

I actually had looked at that common file to see if it at least looked reasonable, but it scrolled off the screen, and since Linux 15 fixed the console to not have any scrollback anymore, I could not look back at the top part of it, where the directory structure was.
Don't know how the legacy.wad went missing.
At this point, I just put in the legacy.wad that I have been using for testing.

I will have to think about the source files. Does not seem like it will hurt anything for the time being.

Thank you for checking things. At this point I am just seeing what I expect to be there.

Release 1.48.18 archive files

Michael Bäuerle — Wed, 14 May 2025 09:21:22 -0000

Looks like the file "doomlegacy_1.48.18_common.zip" is wrong/incomplete.
It contains a subdirectory with the version number "doomlegacy_1.48.16_common" and the file "legacy.wad" is missing.

In the archive "doomlegacy_1.48.18_source.tar.bz", the path to the sources has changed from "src" to "svn1749/src". Is this intended?

Syntax error in r_things.c

Wesley Johnson — Sun, 27 Apr 2025 03:59:21 -0000

I tried the -pedantic and it produced 100's of warnings, went on for pages and pages.
I only found two of those warnings could be fixed, and many that I could not do anything about. As we have achieved compiling without warnings, this -pedantic does not represent what the standard the code it written to.

The code was originally C89, but uses "//" comments heavily (I do not use the old commenting) .
It is also not C99, because it uses alloca, which that does not recognize.
I have been through this before, several times. The doomlegacy code is what works to compile on about six different systems, include MinGW on windows, which is probably the most demanding.
Much of that was done before 2005.

Maybe some day I will accomplish making the code to agree with some standard, but right now those standards would not help, as they do not codify reality What it was complaining about were things that any compiler should be dealing with on its own, even 20 years ago.
For instance, it wants all the enum declarations to be "signed int", as it seems it cannot cope with them being "unsigned", specifically "0x80000000", and it does not matter if I put an "L", or even "LL" on it. I am not willing to make enums into a unmaintainable kludge just to satisfy that kind of pedantic nonsense..

Syntax error in r_things.c

Michael Bäuerle — Wed, 16 Apr 2025 12:28:48 -0000

For C99 I have checked draft N1256:
Section 6.8 (Statements and blocks) defines a "labeled-statement" as:

labeled-statement:
       identifier : statement
       case constant-expression : statement
       default : statement

Declarations are defined in Section 6.7 (Declarations).
The block with braces forms a "compound-statement":

compound-statement:
        { block-item-list opt }
block-item-list:
        block-item
        block-item-list block-item
block-item:
        declaration
        statement

I cannot think of a way to stop that from happening.

Specify the language revision and try with GCC in pedantic mode:
gcc -std=c99 -Wpedantic

The GCC man page says:

       -Wpedantic
       -pedantic
           Issue all the warnings demanded by strict ISO C and ISO C++; reject
           all programs that use forbidden extensions, and some other programs
           that do not follow ISO C and ISO C++.  For ISO C, follows the
           version of the ISO C standard specified by any -std option used.

Syntax error in r_things.c

Wesley Johnson — Sun, 13 Apr 2025 16:24:07 -0000

Got it.
I cannot think of a way to stop that from happening.
Was generally happy that finally found what was causing the bushes to be missing.
Caused by introducing the fnd_count, which as it ended up was not used exactly as I expected.

Syntax error in r_things.c

Michael Bäuerle — Fri, 11 Apr 2025 10:22:31 -0000

Since SVN r1746 my GCC 10 again has problems with a label that is not part of a statement:

r_things.c: In function 'R_AddSpriteDefs':
r_things.c:909:9: error: a label can only be part of a statement and a declaration is not a statement
  909 |         int fnd_count = R_AddSingleSpriteDef ( sprname, &sprites[sprindx], wadnum, ln1, ln2);
      |         ^~~

--- r_things.c.orig     2025-04-11 10:35:37.018924659 +0200
+++ r_things.c  2025-04-11 12:00:45.073314356 +0200
@@ -905,23 +905,25 @@
         continue;

      add_this_sprname:
-        // Load sprites from lumps with sprname.
-        int fnd_count = R_AddSingleSpriteDef ( sprname, &sprites[sprindx], wadnum, ln1, ln2);
-        if( fnd_count )
         {
-            if( verbose )
+            // Load sprites from lumps with sprname.
+            int fnd_count = R_AddSingleSpriteDef ( sprname, &sprites[sprindx], wadnum, ln1, ln2);
+            if( fnd_count )
             {
+                if( verbose )
+                {
 #ifdef ENABLE_DEH_REMAP
-                if( remap_index && (verbose > 1) )
-                    GenPrintf( EMSG_debug, "  Found remap sprite: %s\n", sprname );
+                    if( remap_index && (verbose > 1) )
+                        GenPrintf( EMSG_debug, "  Found remap sprite: %s\n", sprname );
 #endif
-                GenPrintf(EMSG_debug, "Sprite %s: Wad %i, Loaded to %i\n", sprname, wadnum, sprindx );
-            }
+                    GenPrintf(EMSG_debug, "Sprite %s: Wad %i, Loaded to %i\n", sprname, wadnum, sprindx );
+                }

-            // if a new sprite was added (not just replaced)
-            addsprites++;
-            if (devparm)
-                GenPrintf(EMSG_dev, "sprite %s set in pwad %d\n", sprname, wadnum);//Fab
+                // if a new sprite was added (not just replaced)
+                addsprites++;
+                if (devparm)
+                    GenPrintf(EMSG_dev, "sprite %s set in pwad %d\n", sprname, wadnum);//Fab
+            }
         }
     }

Syntax error in p_blockmap.c

Michael Bäuerle — Mon, 17 Mar 2025 12:51:50 -0000

Any comments on the giving the for loops their own loop variable

Limiting the scope of the variable looks right in general.

Recent posts to Discussion

Release 1.48.18 archive files

Release 1.48.18 archive files

How do you make this run at a smaller screen?

Release 1.48.18 archive files

Release 1.48.18 archive files

Syntax error in r_things.c

Syntax error in r_things.c

Syntax error in r_things.c

Syntax error in r_things.c

Syntax error in p_blockmap.c