[Hendricks266]

Fox, on 04 May 2015 - 03:33 AM, said:

I came to realize what is the perfect method to overcome the problem with the shade contributing to the fog parameter: applying the standard black fog with the shade parameter, and on top of it the colored fog using screen blend mode.

Where exactly are you proposing to use this?

[Fox]

I just felt it's a feature that has not been perfected.

[Hendricks266]

Fox, on 04 May 2015 - 12:36 PM, said:

I just felt it's a feature that has not been perfected.

But I mean, where? What specific aspect of what feature? Applying the fogpal member in 8-bit?

[Fox]

It was suggested to replace the current .fogpal behavior, which only works on Polymer/Polymost.

[NightFright]

Can anyone confirm automap lines not being drawn in Polymer at all with r5001 and newer? I wanted to bundle the new HRP with latest snapshot, but if it's a common issue, I guess it'd better get fixed first.

[LeoD]

NightFright, on 06 May 2015 - 01:40 PM, said:

Can anyone confirm automap lines not being drawn in Polymer at all with r5001 and newer?

Has been reported elsewhere, but I couldn't reproduce it yet on several machines/OS'es. Maybe it's configuration related. Try a clean install with EXE and GRP only.

NightFright, on 06 May 2015 - 01:40 PM, said:

I wanted to bundle the new HRP with latest snapshot, but if it's a common issue, I guess it'd better get fixed first.

Indeed, otherwise I see no EXE candidate to be included.

[NightFright]

Well, I tried with a clean folder with only duke.rts, duke.grp and eduke32.exe inside. Nothing else, no config files, no folders. Can't get any cleaner than that. Still doesn't work with Polymer. Maybe it depends on specific hardware.

My system here is like this:
Win 7 x64 SP1
Intel Core i5 750 @2.67 GHz
4 GB RAM
nvidia GeForce 9500 GT (Forceware 341.44)

If it doesn't look right for me, I have to assume it's like that for others, too. The last snapshot where that problem didn't occur dates back to February, and quite some features would get lost if I include that with the HRP bundle. As you know, HRP only truly shines with Polymer, so there shouldn't be things like that in a public release.

[Fox]

The automap is also broken for me in Polymer. I also noticed it's being rendered below the status bar (except for the texturing).

[Fox]

[Mark]

Please explain to us common people what message are you trying to convey with those pics.

[Micky C]

Is the mirror thing a polymer effect or did you use TROR and have some code to mirror the sprites?

[Mark]

I assumed those first 3 pics are from doom showing off fancy effects and the last pic is Eduke with it's "same old lighting".

[Jblade]

I'm not sure what message is supposed to be conveyed there, the closest that sprung to mind is that Polymer can do lighting far better than GZdoom can (or rather, GzDoom can have pretty particle effects and built in floors but polymer is real time lighting)

[Hendricks266]

He's pointing out superfluous things certain Doom source ports do that betray the original game, and comparing it to the hardcoded Polymer lights.

[Mark]

One man's betrayal is another man's advanced feature.

[Jblade]

Well none of those things are built into base GZdoom so that point is fairly moot, the hard-coded lights were just always a temporary thing anyway right? (at least, they were back when Plagman was working on Polymer)

[Micky C]

Aww I thought Fox had made some progress with his experiments of replicating Doom in the build engine

[Fox]

Oh yeah, I remember I tried that. lol But that would be posted on the What Are You Working Now thread.

[NightFright]

For the time being, I am holding back the HRP release just because of this Polymer issue with the automap. Otherwise the release is absolutely ready, but since I don't want to include a snapshot which dates back to January/February or is recent but with obvious issues, I hope you folks understand that I prefer to wait patiently until the coder team found a solution for it.

[Fox]

Polymer incorrectly interprets the offset of one-sided masked walls with cstat 2 and 4.

Attached File(s)

•  polymerwall.zip (287bytes)
  Number of downloads: 400

[LeoD]

Compilation fails under Linux as of r5197:

build/obj/startgtk.editor.o: In function `load_banner()':
/var/packages/build/eduke32_debian64vm/build/src/startgtk.editor.c:139: undefined reference to `startbanner_pixdata'
collect2: error: ld returned 1 exit status
Failed linking executable mapster32!
Makefile:501: recipe for target 'mapster32' failed
make: *** [mapster32] Error 1
make: *** Waiting for unfinished jobs....
source/obj/startgtk.game.o: In function `load_banner()':
/var/packages/build/eduke32_debian64vm/source/startgtk.game.c:261: undefined reference to `startbanner_pixdata'
collect2: error: ld returned 1 exit status
Failed linking executable eduke32!
Makefile:484: recipe for target 'eduke32' failed
make: *** [eduke32] Error 1

And I don't appreciate at all that eduke32.exe and mapster32.exe can't have different icons any more.

[Hendricks266]

I committed most of my work on VoidSW to SVN. I haven't put much time into it since an initial sprint in July and August of last year due to other priorities. What is in SVN now does not build, since I only committed changes that I consider complete and needing no revision, and because engine changes in the past eight months have broken the build that worked at one point on my end. Even then, the build was completely unstable, crashing within seconds of starting a new game.

The project has a long road before it is up to par with Duke because many of our advancements to both game and editor are specific to the Duke 3D code and will require factoring out to the engine or replication per-game. My goals for "BUILD Manifest Destiny" will focus on KenBuild and SW for now until they both meet the project's standards, though the sub-project itself will remain low-priority. Eventually I would like to bring TekWar and the Witchavens under our umbrella and merge all games and editors into a single executable.

LeoD, on 20 May 2015 - 08:02 AM, said:

Compilation fails under Linux as of r5197:

build/obj/startgtk.editor.o: In function `load_banner()':
/var/packages/build/eduke32_debian64vm/build/src/startgtk.editor.c:139: undefined reference to `startbanner_pixdata'
collect2: error: ld returned 1 exit status
Failed linking executable mapster32!
Makefile:501: recipe for target 'mapster32' failed
make: *** [mapster32] Error 1
make: *** Waiting for unfinished jobs....
source/obj/startgtk.game.o: In function `load_banner()':
/var/packages/build/eduke32_debian64vm/source/startgtk.game.c:261: undefined reference to `startbanner_pixdata'
collect2: error: ld returned 1 exit status
Failed linking executable eduke32!
Makefile:484: recipe for target 'eduke32' failed
make: *** [eduke32] Error 1

And I don't appreciate at all that eduke32.exe and mapster32.exe can't have different icons any more.

Sorry man, my bad. I'll look at reverting the icon changes.

[Chip]

It appears that the game-chat's text size is directly linked to the level stats size. To increase the size of the game-chat is to also increase the size of the level stats. Unfortunately, the game-chat text is considerably smaller than the level stats text and so to increase the game-chat's size to something practical results in the level stats consuming a large portion of the screen. Could the game-chat be given its own sizing options or at least be made much larger?

[Helixhorned]

Fox, on 20 May 2015 - 04:53 AM, said:

Polymer incorrectly interprets the offset of one-sided masked walls with cstat 2 and 4.

Should be fixed in r5230, thanks for reporting.

[Fox]

Hendricks266, on 16 May 2015 - 02:07 PM, said:

He's pointing out superfluous things certain Doom source ports do that betray the original game, and comparing it to the hardcoded Polymer lights.

What's the best option?

• Doom source ports have the effects hard-coded, the only possible way to disable them is to download external scripts, and there aren't tools to correctly apply these effects in mods;
  
  
• Source ports make the game as close as possible to original Doom, and users can download fancy_effect.wad if they want;

[Jblade]

I don't know if this is a bug or whatever but if the game tries to read an array file that hasn't been made yet, it just seems to set a bunch of random values or whatever. I'm starting a game of AMC TC from scratch and with an empty data folder, the loadout section shows a bunch of items that shouldn't be there (as the array file granting access to them doesn't exist yet)

[Hendricks266]

Jblade, on 23 May 2015 - 01:43 PM, said:

I don't know if this is a bug or whatever but if the game tries to read an array file that hasn't been made yet, it just seems to set a bunch of random values or whatever. I'm starting a game of AMC TC from scratch and with an empty data folder, the loadout section shows a bunch of items that shouldn't be there (as the array file granting access to them doesn't exist yet)

Hmm. The code is a no-op if the file cannot be opened.

[Helixhorned]

Jblade, on 23 May 2015 - 01:43 PM, said:

I don't know if this is a bug or whatever but if the game tries to read an array file that hasn't been made yet, it just seems to set a bunch of random values or whatever. I'm starting a game of AMC TC from scratch and with an empty data folder, the loadout section shows a bunch of items that shouldn't be there (as the array file granting access to them doesn't exist yet)

That's somewhat strange. Here's what readarrayfromfile does:

• Attempts to open the named file. If that fails, the entire operation is aborted with the array unchanged.
  
• Determines the number of elements in the file as its length in bytes divided by 4. If is is 0, aborts the operation. [LunaCON: and resizes the array to size 0.] Otherwise:
  
  • Resizes the array to the determined number of values.
    
  • In the 64-bit build, allocates a temporary array for 32->64 bit integer conversion, reads in the contents of the file into this array, and copies the values into the actual gamearray. In the 32-bit build, reads the values directly into the gamearray.

The allocation in the last point is done using malloc(), i.e. has uninitialized values in it, but since we determined the number of elements via the file size, the following kread() call should read that number of bytes and leave no "tail" of garbage values. (Except if the file was truncated somehow between the two events.)

Could you:

• Try your test case with the most recent LunaCON build (r5237) and see if it complains somewhere?
  
• Say what you mean by "loadout section" so I can try to reproduce it myself? Is that some kind of PDA menu, accessible in the missions computer, or something else?

[Mblackwell]

Hm, how do we know it was inaccessible though (on the CON end)? Is the only way to clamp all of the values to something we know is out-of-bounds at startup and then attempt the read (I believe that's what I'm doing at the moment)?

It would be nice to have some error returns.

[Jblade]

Helixhorned, on 25 May 2015 - 05:23 AM, said:

[*]Say what you mean by "loadout section" so I can try to reproduce it myself? Is that some kind of PDA menu, accessible in the missions computer, or something else?

Basically - load up a fresh game of the AMC TC, making sure your data folder is completely empty. If you go into the armoury section of the underground base and use the terminal to the left of the desk with the guy sitting behind it, use the menu or left/right keys to move to the specialist weapon section. That section should be completely empty, but when I try doing that random weapons are accessible there that should not be (the code checks to see if the appropriate variable is greater than 0, and considers it unlocked if so) I've done a search for the con files to see if I'm made a mistake and read from the wrong array file, but I can't see anything like that at all.

Not sure if this is relevant at all but I'm on windows 8.1 now and I've tried both 32bit and 64bit of Eduke32. I'll check out the lunatic version when I get time.