[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: 367

[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.

[Helixhorned]

Jblade, on 25 May 2015 - 09:50 AM, said:

move to the specialist weapon section.

Thank you for the bug report, that was the hint that pointed me to the right place. It was about resizearray -- I broke it when I fixed another bug related to it. Should be fixed for real in r5238.

[Jblade]

Cool - I forgot about using that command but that would explain why only the weapon loadout stuff was giving me issues as I never used it anywhere else.

[LeoD]

Helixhorned, on 25 May 2015 - 11:01 AM, said:

Should be fixed for real in r5238.

Not really :

source/gameexec.c: In function 'void VM_Execute(int)':
source/gameexec.c:4658:72: error: invalid conversion from 'void*' to 'intptr_t* {aka long long int*}' [-fpermissive]
                     intptr_t *const tmpar = Xmalloc(GAR_ELTSZ * oldSize);
                                                                        ^
Failed building source/obj/gameexec.o from source/gameexec.c!
makefile:693: recipe for target 'source/obj/gameexec.o' failed
mingw32-make: *** [source/obj/gameexec.o] Error 1

[Hendricks266]

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

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

Reverted in r5253.

[LeoD]

NightFright, on 19 May 2015 - 11:33 AM, said:

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.

Bump.
Any developer's news available?

[TerminX]

LeoD, on 05 June 2015 - 11:14 AM, said:

Bump.
Any developer's news available?

The bug is high priority, but we've been really busy with Hail to the King Collection and another unannounced project. I'll definitely be looking at it soon though.