[Hendricks266]

Lesson learned: Don't give your mod assets filenames that collide with the main game's music. If it's not Taking the Death Toll, don't name it dethtoll.mid.

dethtoll.mid being hardcoded is a long-standing problem on the to-do list, that will likely be augmented with def music "usermap" syntax like "intro"/"briefing"/"loading".

[Fox]

I believe it should be more appropriate to include a .def file with Eduke32 that lists files to be replaced, like grabbag.mid with grabbag.ogg. I don't see how it's a better option to have filenames hard-coded.

[Jblade]

Hendricks266, on 09 June 2015 - 10:32 AM, said:

Lesson learned: Don't give your mod assets filenames that collide with the main game's music. If it's not Taking the Death Toll, don't name it dethtoll.mid.

This was never a problem until Megaton edition compatability, so please don't try and tell me about lessons thank you

I figured this out and fixed it ages ago on my end, it was only presenting a problem with the guys who had Megaton installed (I didn't and didn't know that Eduke32 autoloads Megaton content)

[Hendricks266]

Fox, on 09 June 2015 - 01:07 PM, said:

I believe it should be more appropriate to include a .def file with Eduke32 that lists files to be replaced, like grabbag.mid with grabbag.ogg. I don't see how it's a better option to have filenames hard-coded.

Nothing is hardcoded beyond adding the Megaton paths. The automatic "does an OGG or FLAC exist of this MIDI/VOC?" kicks in from there.

Jblade, on 09 June 2015 - 01:41 PM, said:

This was never a problem until Megaton edition compatability, so please don't try and tell me about lessons thank you

Contrarily, naming something in an inaccurate fashion is poor practice in general.

[Jblade]

There was nothing 'inaccurate' about the filenames, and it was never a problem until Megaton content started being autoloaded. It's your port so it's your choice to auto integrate the content, but I think that absolutely nothing should be loaded from Megaton at all by default. I don't bother keeping it installed because it intefers with Eduke regularly if I'm trying to play a TC or whatever.

[Micky C]

Can there be some description added to the wiki for openGL's new fogpal feature? http://wiki.eduke32.com/wiki/Fogpal

[Daedolon]

I was lazy but there you go.

[Hendricks266]

Micky C, on 13 June 2015 - 04:05 PM, said:

Can there be some description added to the wiki for openGL's new fogpal feature? http://wiki.eduke32.com/wiki/Fogpal

http://wiki.eduke32....Language#fogpal

Daedolon, on 14 June 2015 - 10:07 AM, said:

I was lazy but there you go.

The standalone page should have a description of the member of the sector structure also named fogpal.

[NightFright]

I see r5267 finally fixes the automap problem with Polymer. Thanks a lot, folks! ^^

[Paul B]

I was wondering why Eduke32 runs so much faster in an XP operating system as oppose to Windows 7? I have a system which can dual boot between Windows 7 64 Bit and Windows XP. Hands down my FPS are so much better in XP at least 20 fps faster running Polymer. Does anyone have any suggestions as to why this might be? This also isn't something new, this has always been the case for as long as I remember which is why when I map I still map using XP. Is there a way to optimize Eduke32 for Windows 7 so it can run just as efficiently?

[Danukem]

It has been a few years since I was up-to-date on eduke32 capabilities, so I need to ask about sound. Do we have true volume control over sounds using CON commands yet? Back in the day there was not -- you could adjust the volume parameter in the sound definition, but all it did was adjust a distance offset on the sound. Pretty useless if the sound is being played from the player.

EDIT: Wouldn't it be pretty simple to add an optional volume parameter to the sound command? It could be added to the sound's volume parameter in the definition for that particular instance. And yes, I know that I could simulate the same thing by spawning a sprite that plays the sound a certain distance from the player.

[Fox]

No. And it probably will only be added when there is a better sound system (i.e. the volume option in the menu is a distance hack).

[Fox]

The clipdist showing in the editor is interesting. I suggest it to only show in sprites with a cstat of 1.

[Kyanos]

Paul B, on 16 June 2015 - 08:21 AM, said:

I was wondering why Eduke32 runs so much faster in an XP operating system as oppose to Windows 7? I have a system which can dual boot between Windows 7 64 Bit and Windows XP. Hands down my FPS are so much better in XP at least 20 fps faster running Polymer. Does anyone have any suggestions as to why this might be? This also isn't something new, this has always been the case for as long as I remember which is why when I map I still map using XP. Is there a way to optimize Eduke32 for Windows 7 so it can run just as efficiently?

turn off aero

[Fox]

Flat sprites are dislocated in Polymost mode, which creates see-through holes in structures.

[Jblade]

when using the save command the game changes the quicksave slot to whatever slot was specified in the command - any way to fix this so the player's choice of quicksave slot isn't overridden?

[Mr. Alias Nameless]

Hi all. I have problems with the launch of the polymer (in eduke32.exe and mapster32.exe) in the 5298 revision or older. The game is interrupted immediately after the start. Last log message:

Initializing Polymer subsystem ...
g_errorLineNum: 0, g_tw: 0

The problem occurs only when using a polymer mode. Revision 5297 is working correctly.
Graphic card is integrated Intel Intel® HD Graphics 2.1.0 - Build 8.15.10.2993

Attached File(s)

•  eduke32.log (1.22K)
  Number of downloads: 327

[Fox]

Does Mapster still uses the x-y offset for ROR?

[Helixhorned]

Fox, on 11 September 2015 - 04:52 PM, said:

Does Mapster still uses the x-y offset for ROR?

Yes, in the non-Lunatic EDuke32 build, the sector's {ceiling,floor}xpanning member is used to hold the bunch number of the ceiling or floor.

[Micky C]

And IIRC you can't save TROR maps in the lunatic build

[Fox]

Helixhorned, on 20 September 2015 - 04:30 AM, said:

Yes, in the non-Lunatic EDuke32 build, the sector's {ceiling,floor}xpanning member is used to hold the bunch number of the ceiling or floor.

Is there anything that prevents non-Lunatic build from having new structures in the map format? Or is it a matter of the classic Build engine code being too messy?

[Micky C]

I think a big part of it is that the lunatic map files can be extended without having to increment the map version number, by using reasonable default values for new structures, being some kind of text-based format.

I'd guess there must be something stopping the current map system from adding new stuff in otherwise Helix wouldn't have used the offsets for TROR in the first place.

[TerminX]

Micky C, on 20 September 2015 - 03:53 PM, said:

I'd guess there must be something stopping the current map system from adding new stuff in otherwise Helix wouldn't have used the offsets for TROR in the first place.

OK, you know how every time we change something internally, savegames break? Imagine that but with map files. We'd end up with thousands of lines of compatibility code to support loading every map version we ever went through, and everyone would end up with maps that only worked in EDuke32/Mapster32 and could never be altered by any other existing utility again. That would be bad.

[LeoD]

make RENDERTYPE=WIN fails as of r5352:

build/src/winlayer.c: In function 'void UninitDirectInput()':
build/src/winlayer.c:1161:59: error: invalid conversion from 'const void*' to 'void*' [-fpermissive]
         for (i=joynumaxes-1; i>=0; i--) Bfree(axisdefs[i].name);
                                                           ^
In file included from build/src/winlayer.c:31:0:
C:/Progs/mingw64/x86_64-w64-mingw32/include/malloc.h:77:16: note:   initializing argument 1 of 'void free(void*)'
   void __cdecl free(void *_Memory);
                ^
build/src/winlayer.c:1166:64: error: invalid conversion from 'const void*' to 'void*' [-fpermissive]
         for (i=joynumbuttons-1; i>=0; i--) Bfree(buttondefs[i].name);
                                                                ^
In file included from build/src/winlayer.c:31:0:
C:/Progs/mingw64/x86_64-w64-mingw32/include/malloc.h:77:16: note:   initializing argument 1 of 'void free(void*)'
   void __cdecl free(void *_Memory);
                ^
build/src/winlayer.c:1171:58: error: invalid conversion from 'const void*' to 'void*' [-fpermissive]
         for (i=joynumhats-1; i>=0; i--) Bfree(hatdefs[i].name);
                                                          ^
In file included from build/src/winlayer.c:31:0:
C:/Progs/mingw64/x86_64-w64-mingw32/include/malloc.h:77:16: note:   initializing argument 1 of 'void free(void*)'
   void __cdecl free(void *_Memory);
                ^
Failed building build/obj/winlayer.o from build/src/winlayer.c!
makefile:626: recipe for target 'build/obj/winlayer.o' failed
mingw32-make: *** [build/obj/winlayer.o] Error 1

[Fox]

TerminX, on 21 September 2015 - 11:04 AM, said:

OK, you know how every time we change something internally, savegames break? Imagine that but with map files. We'd end up with thousands of lines of compatibility code to support loading every map version we ever went through, and everyone would end up with maps that only worked in EDuke32/Mapster32 and could never be altered by any other existing utility again. That would be bad.

But wouldn't it make sense if you could only open ROR maps with Eduke/Mapster? As a last resort, Mapster could have the option to export ROR maps without the ROR data. The lack of y-xpannign is what prevents me from releasing a ROR map. You may think it's nitpicking, but I want my E1L3 with transparent water to have the correct texture alignment.

Also I don't understand why it has to use x-ypanning instead of the sector extra, since it's a structures unused by the map editor and has the same amount of bits. The only reason I can think of is that it was thought at the time that some existing mod could be using it. But that wouldn't have been a good decision, since the alternative is to prevent textures from being properly aligned, and the sector extra is not accessible via CON (the value is overwritten before any game event can read it) so no mod has ever used it.

[Helixhorned]

Quote

Also I don't understand why it has to use x-ypanning instead of the sector extra, since it's a structures unused by the map editor and has the same amount of bits.

sector[].extra is used in Duke3D game logic: it's the lotag of the GPSPEED sprite found in it, or 256 by default.

Fox, on 24 September 2015 - 03:02 PM, said:

I want my E1L3 with transparent water to have the correct texture alignment.

If you have the sectors of the water area in one bunch, the floor textures will be aligned to each other, although they will have "arbitrary" global alignment, assuming no wall-relative alignment. I agree that it's a bug that the renderer still regards the panning value when it's actually a bunch index -- it could be made to have a fixed panning such as 0 then. Even if you have to split one sector into multiple bunches (for example because you want every one of them to be convex for the classic renderer's sake), if you end up small panning differences (say 1 to 5), it shouldn't be noticeable at a casual glance.

[Fox]

Helixhorned, on 25 September 2015 - 09:42 AM, said:

sector[].extra is used in Duke3D game logic: it's the lotag of the GPSPEED sprite found in it, or 256 by default.

AFAIK, after the map is loaded the sector bunchs are stored in the floorbunch and ceilingbunch structures, so it should't conflict with GPSPEEDs.

[Helixhorned]

Fox, on 25 September 2015 - 10:05 AM, said:

AFAIK, after the map is loaded the sector bunchs are stored in the floorbunch and ceilingbunch structures, so it should't conflict with GPSPEEDs.

Well, these structures are present in the Lunatic build. The GPSPEED sprites are deleted after premap, sector[].extra stays.

[Fox]

Even so, is it not doable? The game already store sector/wall/sprite data in the memory (i.e. cyclers and mirrors), and I believe that would be a preferable option than eliminating the texture panning.

[Jblade]

I just checked the synthesis notes and saw some stuff pertaining to palettes:

------------------------------------------------------------------------
r5352 | hendricks266 | 2015-09-23 10:55:31 -0700 (Wed, 23 Sep 2015) | 1 line

Remove NULL checks before calling free(): they are unnecessary as per the C standard. Other cleanup includes factoring code into DO_FREE_AND_NULL() macros.
------------------------------------------------------------------------
r5351 | hendricks266 | 2015-09-23 10:55:19 -0700 (Wed, 23 Sep 2015) | 1 line

Defs: Add basepalette, palookup, and blendtable tokens.
------------------------------------------------------------------------
r5350 | hendricks266 | 2015-09-23 10:55:15 -0700 (Wed, 23 Sep 2015) | 1 line

Defs: Prevent tilefromtexture from ever assigning index #255 (the transparent color) to the processed image.
------------------------------------------------------------------------
r5349 | hendricks266 | 2015-09-23 10:55:11 -0700 (Wed, 23 Sep 2015) | 1 line

Internally, work with 24-bit palettes instead of 18-bit.
------------------------------------------------------------------------
r5348 | hendricks266 | 2015-09-23 10:55:02 -0700 (Wed, 23 Sep 2015) | 1 line

Restructure the basepaltable subsystem to support up to 256 palettes and use dynamic allocation like palookup and blendtable.

Just curious, what stuff can this be used for?