[Helixhorned]

DeeperThought, on Jul 16 2010, 06:51 PM, said:

I agree, and I think that hardcoded lights should be kept to a minimum. In addition to the performance issue, there's the fact that mappers didn't consider many sprites to be light sources. Take switches, for example. Sometimes switches that are supposed to be hidden give themselves away in Polymer because of the light they give off. And there is another issue. In a TC, there may be a completely different tile of that number which the light doesn't fit, and it just adds one more annoying hardcoded thing for the scripter to deal with.

I agree with DeeperThoght, hardcoded sprite lights should be kept to a minimum and applied very carefully. There's another issue with them: when there are many light-emitting sprites on a small area, their effects on the textures are added together an the result looks completely "overexposed". The room with the slime babes and explosives in E3L1 is a good example.

High Treason, on Jul 16 2010, 08:15 PM, said:

I've had an idea, how difficult would it be to add a feature to Mapster32 where point lights show a circle on the 2D View like ambient sounds? This would be really useful. Just an idea.

Micky C, on Jul 17 2010, 09:41 AM, said:

I always thought it'd be nice if there was some way to see what colour polymer lights are in 2D mode, the only way to tell at the moment is to switch into 3D mode, which usually takes a few seconds, and it can be a bit time consuming if you have to make constant corrections to get the colour right. Although High Treason's idea would be more practical and easier to implement.

Been hacking that the whole evening (way too long), it's implemented in m32script. To fully display the projection of a spotlight would be pretty tricky, so only the general direction is shown. By the way, you don't need to tweak light parameters in 2d mode: if you enable EVENT_PREKEYS3D, some keypad keys will be overridden for SE light manipulations and some Polymer texture parameters, the usage is documented in a.m32. If you want the script extensions loaded when Mapster starts, you can now have a file m32_autoexec.cfg somewhere on you load path with

include samples/a
enableevent all

I've fixed that Mapster crash but, TX, there's something strange going on with the caching system it seems...

[Stabs]

Can you explain that fiddlewithlights defstate in a bit more detail helix, ive looked over it but cant seem to get it to do anything

[Helixhorned]

You don't actually need to fiddle with it explicitly, it's called from EVENT_PREKEYS3D. Take a look here.

[Night Wolf]

Helixhorned, on Aug 4 2010, 08:51 AM, said:

I agree with DeeperThoght, hardcoded sprite lights should be kept to a minimum and applied very carefully. There's another issue with them: when there are many light-emitting sprites on a small area, their effects on the textures are added together an the result looks completely "overexposed". The room with the slime babes and explosives in E3L1 is a good example.

Yeah the slime canisters look horrible, be good if it wasn't so bright...
The thing is with the "red siren light" sprite, in some of the duke maps people have added a red light source to it , but when the light is destroyed the lighting remains which it stupid.
I agree it should be kept to a minimum, but I think that particular sprite should be hardcoded.

[Stabs]

Helixhorned, on Aug 4 2010, 05:57 AM, said:

You don't actually need to fiddle with it explicitly, it's called from EVENT_PREKEYS3D. Take a look here.

best script ever!

[Searinox Navras]

Pardon me if there is an answer to this but... for 2 years I've been using the HRP and since then and up to polymer one issue has stuck no matter what I did - the hidden text on dark walls supposed to be visible with night vision goggles just doesn't show. Got any ideas?

[Sobek]

DanM, on Aug 5 2010, 08:17 PM, said:

best script ever!

I'll second that. That makes things a heck of a lot simpler.

[Stabs]

there is EVENT_KEYS3D opens swing doors I'am not sure how useful that is too you in space, need something for slide doors, they are a PITA in mapster

Helix seeing as the lights X Y Z can be modified with alt+kp1 can something be made like that for every other sprite, i would love something that could modify those values in 3d mode

[Tea Monster]

Searinox Navras, on Aug 8 2010, 11:20 PM, said:

Pardon me if there is an answer to this but... for 2 years I've been using the HRP and since then and up to polymer one issue has stuck no matter what I did - the hidden text on dark walls supposed to be visible with night vision goggles just doesn't show. Got any ideas?

They glowed due to the way that the ancient palette of Duke 3D worked. Now that everything is using a full colour palette, the engine ignores those colours.
You could do it by having those sprites tagged somehow by the engine, and you could then make glow-maps for them in typically night-vision style.

[Helixhorned]

DanM: which values? The SE lights were good candidates because their properties are directly visible in 3D mode, but for a lot of other effector sprites that's not true. I do have in the back of my head more WYSIWYG-style enhancements, though there's always the question how practicable they are... the swinging door tester for example sometimes corrupts maps in cases where the door sector is not a single island sector, so don't use it for now.

[Stabs]

the x y zvel values, the command alt+kp1 that brings up red green blue could just say xvel yvel zvel anyway, if your using polymer you should already know these things so if it could be extended to effect all sprites that would be quite handy.

[Hendricks266]

Hey Helixhorned, you broke the win32 build.

source/m32exec.c: In function 'VM_OnEvent':
source/m32exec.c:155: error: implicit declaration of function 'alloca'
source/m32exec.c:155: warning: incompatible implicit declaration of built-in function 'alloca'
source/m32exec.c: In function 'VM_Execute':
source/m32exec.c:344: warning: incompatible implicit declaration of built-in function 'alloca'
Failed building obj_win/m32exec.o from source/m32exec.c!
make: *** [obj_win/m32exec.o] Error 1

[Helixhorned]

Heh, I "kinda" knew that. Working on it.

[Searinox Navras]

Tea Monster, on Aug 10 2010, 11:04 AM, said:

They glowed due to the way that the ancient palette of Duke 3D worked. Now that everything is using a full colour palette, the engine ignores those colours.
You could do it by having those sprites tagged somehow by the engine, and you could then make glow-maps for them in typically night-vision style.

Yet monsters do still glow with nightvision.

[MusicallyInspired]

Because they have glowmaps? I don't know why nobody thought to make any for those letters, though. Those are fairly important.

[Hendricks266]

No, monsters glow because they are hardcoded to turn pal 6 when nightvision is on.

[Chip]

And can also be setup through CONs using a simple command.
Use that for all the letter / number tiles and place them somewhere loose within the GAME.con, lets say right at the bottom.

[Danukem]

Chip, on Aug 13 2010, 09:40 AM, said:

And can also be setup through CONs using a simple command.
Use that for all the letter / number tiles and place them somewhere loose within the GAME.con, lets say right at the bottom.

I think it would be better to put nightvision glow on selected sprites using maphacks, because we don't want all letters in the maps to have that property, also it would be nice if it worked without modified CONs.

[Fox]

What happen in classic mode is a palette feature, which doesn't work in a 32-bit mode. I.e. it's done so that the nightvision googles color has a higher contrast than normal palette, so almost black colors will show up. Something like that.

Either way, I am not sure about turning the heat sensor on letters. =/

[Hendricks266]

What Fox said.

Compare:


This could be fixed (as well as the problem of nightvision being useless in general) by boosting the contrast.

[MusicallyInspired]

But in 8-bit mode using nightvision on letters allows you to see them brightened up just like enemies. Why can't one do the same thing that gets the enemies lit up for the letters as well in polymost/polymer?

[Fox]

No, it don't, otherwise that wouldn't change in Polymost/Polymer since it doesn't change that kind of stuff.

[Hendricks266]

MusicallyInspired, on Aug 13 2010, 08:02 PM, said:

But in 8-bit mode using nightvision on letters allows you to see them brightened up just like enemies. Why can't one do the same thing that gets the enemies lit up for the letters as well in polymost/polymer?

It brightens them up like Fox and I explained. The letters do not turn pal 6.

[Helixhorned]

@mappers: just dropping by to say that the keys for the Polymer override variable tweaking have changed. They're now activated with Ctrl-KP/ and are themselves much easier to remember:
KP*, KP/ -- specularfactor (mnemonic: * as in 'factor')
KP7, KP9 -- speclarpower
KP5, KP8 -- parallaxscale
KP4, KP6 -- parallaxbias

[Roma Loom]

Helix, could you please make some small changes for parallax and spec routines? Clamp parallaxscale and bias like 0 to 1 with 0.001 increment step, and spec values from 0 to 255 by 0.1 increment step. Maybe just defining such vars like minspec maxspec specstep and minparallax maxparallax parallaxstep or something, so anyone could change their values in the script not touching the procedure itself...

[king karl]

when i switch on polymer dead bodies and ground pickups will appear as sprites not as models (although living enemies are 3D....)

im using the attruition mod too but i didnt think that would make a difference

[Micky C]

I've also experienced this, and the player duke model seems to alternate rapidly between model and sprite

[Searinox Navras]

Latest build of EDuke32 indeed does that. I don't know what version it is but the build in DukePlus 2.11 handles the models correctly.

[Danukem]

king karl, on Aug 15 2010, 01:00 AM, said:

when i switch on polymer dead bodies and ground pickups will appear as sprites not as models (although living enemies are 3D....)

im using the attruition mod too but i didnt think that would make a difference

Can you confirm:

1) Whether this happens only in Polymer
2) Whether it happens with the eduke32.exe that Attrition comes with, or only with later builds


Here is some technical information which might be helpful for fixing the problem:
In the latest versions of my mods, bodies and pickups get some extra processing in EVENT_ANIMATESPRITES to make them appear to float on the surface of water (lotag 1 sectors). If the sprite is on the floor in a lotag 1 sector, my code adjusts the z position of the corresponding tsprite. To make that possible, the mdflags member of the sprites are set to 16. Setting that flag should not turn off models or model animation (http://wiki.eduke32.com/wiki/Mdflags) but apparently it is, at least in Polymer. Right now I'm downloading a copy of the HRP to test this (I had to trash my old copy a few weeks ago).

EDIT: I finished downloading the HRP and checked it out. The bug only happens when using Polymer (Polymost works correctly), and it does happen before the latest builds. It appears that Polymer is not handling model flags correctly.

[Plagman]

Does that still happen before 1680? That's when Polymer picked up support for the first mdflags bit, but I'm also pretty sure it checks for the right value. Something else must be going on.