[Danukem]

 Fox, on 20 July 2014 - 12:37 PM, said:

How would remapping it break the maps?

If I remapped the tile to a different number, wouldn't it cause the tile to not display in the maps? Also, regardless of that, there is still the problem that nothing I do with future releases will help with the long-released TC when used with the current build.

[Fox]

No, that's not how dynamicremap works. Essentially there is a copy of DEFS.CON in the source code which is used for hard-coded effects, and dynamicremap allows you to modify it.

[Danukem]

 Fox, on 20 July 2014 - 02:12 PM, said:

No, that's not how dynamicremap works. Essentially there is a copy of DEFS.CON in the source code which is used for hard-coded effects, and dynamicremap allows you to modify it.

OK, I'll keep that in mind, but the breakage should still be fixed on the source side -- I think it's reasonable to expect source changes to not break a popular TC that has been around for 4 years and has been working fine for all of that time.

[Fox]

In this case it should because it's v1.5 behavior:

[Hendricks266]

I know exactly what to do now. Thanks. It's not 100% tidy in the code but no biggie.

[Fox]

So I checked that DukeVR executable for Oculus. The concept seems promising, maybe Eduke should already reserve a orientation for HUD sprites?

[Hendricks266]

 Fox, on 20 July 2014 - 12:52 AM, said:

So, what about finally breaking the vertical look limit? My idea would be to have a 11-bits thoriz ("true horizon") player structure and a camera variable that override the value of horiz in Polymost and Polymer. Of course this would only have practical use for custom mods.

Why 11 bits? I would use a full signed 32-bit gamevar as an angle instead of an angle tangent. 0 is straight ahead, -2^31 is straight backwards (and upside down).

EDIT: Nevermind, 2^11 = 2048, standard BUILD angle. That makes sense too.

Keep in mind that this would only have value in Polymer. Classic and Polymost would flip their shit, though some of Ken's notes show he was thinking about ways to improve the freelook in both.

[Fox]

Why would it not work in Polymost? It has a true 3D view, no?

Another use would be for hitscan command. I can think of adding the value shifted left by 20 to the horiz would do the job.

[Micky C]

Polymost glitches when you look too far up and down. Eduke32 mostly compensates for this by stretching (zooming?) the view at the most extreme angles, but you can still see a tiny bit of glitching at the top or bottom.

Remember that polymost is essentially the openGL version of classic. Only polymer, which was completely coded from scratch independently (Plagman intentionally never referenced Ken's polymost code) can freely look at any angle.

[Fox]

Since the menu is being worked on, what about a command to add custom options? So if there is any custom option, there will be a Miscellaneous Options entry under Option with all custom options.

[Daedolon]

Yeah, we're currently hooking a key event then capturing mouse movement for custom menus and it's a bit silly.

[Hendricks266]

 Fox, on 22 July 2014 - 05:30 AM, said:

Since the menu is being worked on, what about a command to add custom options? So if there is any custom option, there will be a Miscellaneous Options entry under Option with all custom options.

Definitely not. You'll be able to define and modify menus properly. No hacks. Lua only. And user modification of menus is not at all being worked on beyond making sure my code has the potential for it.

[Fox]

1 - How can I dump the .art files "created" with tilefromtexture?

2 - Can someone upload a Duke 3D palette with additive translucency replacing the default additive (33% and 66%)?

PS: Yeah yeah I know there is a built-in feature in Mapster32, but I probably will perform a sucefull ocular surgery before figuring out how to use it.

[Hendricks266]

 Fox, on 22 July 2014 - 04:08 PM, said:

1 - How can I dump the .art files "created" with tilefromtexture?

Why would you want this?

Tilefromtexture never adds art to the ART banks. It sets a flag for the engine to get the tile from a separate location in memory.

Wait for my art tool.

[The Commander]

 Micky C, on 22 July 2014 - 03:17 AM, said:

Remember that polymost is essentially the openGL version of classic. Only polymer, which was completely coded from scratch independently (Plagman intentionally never referenced Ken's polymost code) can freely look at any angle.

To keep it simple, Polymer basically turns the map into a giant model/mesh like how most modern engines work.

[LeoD]

 Hendricks420, on 22 July 2014 - 10:45 PM, said:

Tilefromtexture never adds art to the ART banks. It sets a flag for the engine to get the tile from a separate location in memory.

This reminds me to ask for a maphack token à la "texture 1234 art" ...

Btw., as of EDuke32 r4543, "make -j" appears to be broken.
As of r4553, LTO fails for MinGW 64bit gcc 4.9* with "make RENDERTYPE=WIN"

c:\Users\leod\_VCS\eduke32\temp\ccazuvvi.ltrans3.
ltrans.o:ccazuvvi.ltrans3.o:(.rdata$.refptr.frameplace.lto_priv.153[.refptr.
frameplace.lto_priv.153]+0x0): undefined reference to `frameplace.lto_priv.153'
c:\Users\leod\_VCS\eduke32\temp\ccazuvvi.ltrans4.ltrans.
o:ccazuvvi.ltrans4.o:(.rdata$.refptr.bytesperline.lto_priv.155[.refptr.bytesperline.
lto_priv.155]+0x0): undefined reference to `bytesperline.lto_priv.155'
c:\Users\leod\_VCS\eduke32\temp\ccazuvvi.ltrans4.ltrans.
o:ccazuvvi.ltrans4.o:(.rdata$.refptr.yres.lto_priv.157[.refptr.yres.lto_priv.
157]+0x0): undefined reference to `yres.lto_priv.157'
collect2.exe: error: ld returned 1 exit status
Failed linking executable eduke32.exe!
make: *** [eduke32.exe] Error 1

[Hendricks266]

make -j has always been broken for me and I thought my restructure would fix it. There is no reason why it should be broken, and it's also broken for other projects. I believe it's a bug in MSYS's make. Does it work in Linux?

`make veryclean all RENDERTYPE=WIN` works for me with gcc (x86_64-win32-seh-rev0, Built by MinGW-W64 project) 4.9.1 from http://sourceforge.n...eads-win32/seh/ .

BTW, it's helpful when you quote the command line to expand your window buffer to something much wider than 80 chars before you run a command, so it doesn't auto line break stuff.

EDIT: I normally use the make bundled with MSYS which is apparently old (3.81) and buggy (2010). I ran the mingw32-make (4.0.90) that came with the distribution and -j works fine.

[Stabs]

Went ahead an ordered a rift so an up to date eduke32/64 would be great come September

Rather interested in using looping 3d demos perhaps some interactive ones that make use of the gyro and combine sleep with VR to see the effect it has on the unconscious mind

[LeoD]

Aah, this is all so weird and complicated...

 Hendricks420, on 23 July 2014 - 01:51 PM, said:

make -j has always been broken for me and I thought my restructure would fix it. There is no reason why it should be broken, and it's also broken for other projects. I believe it's a bug in MSYS's make.
EDIT: I normally use the make bundled with MSYS which is apparently old (3.81) and buggy (2010). I ran the mingw32-make (4.0.90) that came with the distribution and -j works fine.

For me, -j has been working fine for 12-18 months, so I assumed it had been fixed actively. When trying to compile make from source I came across this message:

WARNING: Your system has neither waitpid() nor wait3().
         Without one of these, signal handling is unreliable.
         You should be aware that running GNU make with -j
         could result in erratic behavior.

So there might still some machine-dependant luck being involved on Windows...

 Hendricks420, on 23 July 2014 - 01:51 PM, said:

Does it work in Linux?

All my Linux installations are broken for different reasons and I've been too lazy to fix any of them recently.

 Hendricks420, on 23 July 2014 - 01:51 PM, said:

`make veryclean all RENDERTYPE=WIN` works for me with gcc (x86_64-win32-seh-rev0, Built by MinGW-W64 project) 4.9.1 from http://sourceforge.n...eads-win32/seh/ .

While putting this reply together I ran dozens of compiles on different repo versions with a different outcome each time I thought I had nailed it and could paste the log over here... After all everything seems to work again now. My only explanation is that veryclean got confused over some recent repository updates (and my temporary downgrades) and left some unnoticed stuff which mislead the linker. (I usually run (x86_64-posix-seh-rev0, Built by MinGW-W64 project) 4.9.* btw..)

 Hendricks420, on 23 July 2014 - 01:51 PM, said:

BTW, it's helpful when you quote the command line to expand your window buffer to something much wider than 80 chars before you run a command, so it doesn't auto line break stuff.

Thought I had it that way and the forum software introduced newlines or MBlackwell interfered again...

[Plagman]

I've always built with -j on Linux without issues FWIW.

[Mblackwell]

Same here. Worked since forever and still works on Ubuntu 14.04.

[MusicallyInspired]

What does -j do?

[Hendricks266]

"Normally, make will execute only one recipe at a time, waiting for it to finish before executing the next. However, the ‘-j’ or ‘--jobs’ option tells make to execute many recipes simultaneously."

Parallelism allows the build to take advantage of multiple cores/threads to complete several times faster.

[Mblackwell]

It can turn a 20 minute compile into a 3 minute one! Wonderful business.

[LeoD]

 LeoD, on 25 July 2014 - 11:54 AM, said:

[...]My only explanation is that veryclean got confused over some recent repository updates (and my temporary downgrades) and left some unnoticed stuff which mislead the linker.

make veryclean does not remove build/obj/rawinput.o and build/obj/winlayer.o.

[Hendricks266]

make veryclean RENDERTYPE=WIN does.

[Fox]

Is it possible to give the option to set an sprite height, like you can set the width (.clipdist)? That's a huge limitation of Eduke32 for mods that are not "based" on Duke 3D. There are two effects of this:

- By default, the height of the hitbox of a sprite is defined by the tile pixel height, offset and sprite .yrepeat.

- Notenemy-type actors won't collide with walls above their feet, i.e. they can enter secotors of any height. Enemy-type actors seems to have two static values, depending if .yrepeat > 60.

In both you have little control of what is happening. The only solution I can think of is adding .clipheight and .clipoffset (in z units) to the sprite structure.

[LeoD]

 LeoD, on 30 July 2014 - 09:09 AM, said:

make veryclean does not remove build/obj/rawinput.o and build/obj/winlayer.o.

 Hendricks420, on 30 July 2014 - 01:54 PM, said:

make veryclean RENDERTYPE=WIN does.

Oh boy, this picky type of behaviour really ain't what anyone would expect from a command named veryclean. The outcome should never be dependent of whatever make parameters were used for previous build runs. Academic excuses about cleaner implementation of makefiles or whatever don't apply here. If I can't rely on veryclean, it's useless.

[Hendricks266]

veryclean exists because it cleans both the game and the engine object files, while clean is just the game. I didn't name it. Really, it should be the default for clean, and everything else should be split into cleanengine, cleanduke3d, cleanaudiolib, and cleanmact.

It's not called veryclean because it'll make everything spic & span and wipe your ass while it's at it. Though, as much as I want to reply

Spoiler

I can't find a good reason not to change the behavior so that it once again deletes $(OBJ)/* instead of the list of object files.

[Skulldog]

-addon [0.1.2.3] does not seem to work for megaton addons anymore. Also the megaton addon group files don't show up in the startup window.