[Gambini]

I think you can tell the difference:

6926



7067

[Fox]

Have you tried deleting your old cfg?

[Gambini]

texture caches, cfgs, autoexecs, yes!

[oasiz]

It looks as if some extra saturation is being applied on top, did you check that nvidia control panel isn't tapping in to this and adding some digital vibrance for instance ?

But yeah, what was said, goal is to get software-like look going on with polymost.

Also remember that eduke stores configs in %appdata% nowdays with newer versions.

[Gambini]

No extra saturation, the most saturated screenshot corresponds to 6926 revision in which shadetables still worked. The screenshot at the bottom shows how it looks like now in 7067. And it's unlikely nvidia is doing anything. That is exactly the old polymost look, before the shadetables thingie were applied.

Just checked %appdata% and no eduke32 configuration was found.

[oasiz]

Gotcha, will have to verify this at home as well.

[Fox]

Are you using globalflags in the defs?

[Gambini]

Not me, but I found this on a personal def file that my annonymous coder has:

globalflags 1
shadefactor 47

I commented them, and now it works! Thank you!

Now that it is a shader, i guess it may be possible to apply the same effect to voxels and models (which skins are saveds as indexed duke palette png files)?

I have been waiting for something like that for so long, would love to see it some day before i release my mod, so i can adjust those assets to the intented look.

[oasiz]

Gambini, on 15 October 2018 - 05:17 AM, said:

Now that it is a shader, i guess it may be possible to apply the same effect to voxels and models (which skins are saveds as indexed duke palette png files)?

Have you tried this recently ? I think I just saw something...
However I'm not sure about models in this case.

Good to hear that you managed to fix it!

[Mark]

oasiz, on 14 October 2018 - 11:26 PM, said:

Also remember that eduke stores configs in %appdata% nowdays with newer versions.

Was there a necessary technical reason for this? I dislike programs that spread themselves around. Or is %appdata% created inside the root folder where Eduke32 is placed?

[Hendricks266]

It's the only way we're guaranteed to have write permissions. Windows does not like it when apps try to write inside Program Files, and that's where most commercial games install themselves.

[Mark]

That makes sense. Many people are wrapped behind protection measures that they would have those issues.

[MusicallyInspired]

I screwed up my Windows 10 installation a couple years back or so by trying to mess with write permissions. Always hated that Windows did that but in the past I could always just give myself permissions. Had to reinstall Windows. Nowadays I just install and work with everything on external hard drives. Screw %appdata%. A necessary evil, but I despise it. Does it have to be a hidden folder that's so cumbersome to navigate to??

[oasiz]

A bit annoying but you get used to it, win + R -> explorer %appdata% - blam

[Gambini]

oasiz, on 15 October 2018 - 07:06 AM, said:

However I'm not sure about models in this case.

Please could this be featured? I have been looking forward for it 5 years now!

I will make a donation if it´s introduced!

[Mark]

Sorry for the dumb question but I haven't run a newer version of Eduke yet. So now if I want to include an autoexec.cfg with certain settings, I have to inform the user to manually transfer that file into their %appdat% folder? What if they haven't run the game yet and have no Eduke32 folder entry there to put the file into?

OR... is it only the Eduke32 and Mapster32 generated cfg files ( not autoexec.cfg ) that are in %appdata% now?

MI: Just now I went to the %appdata% folder and dragged a shortcut to my desktop. No navigating to worry about now. When I run a newer version will the folder show up as "Eduke32"?

[MusicallyInspired]

Doesn't Eduke32 also look in its own folder for these files? If so, which overrides which?

[Mark]

I just happened to think... I keep every project completely separate in their own folders. Would they all write to the same %appdata% folder? That would suck.

[Mblackwell]

Don't overthink it. Just put a file named user_profiles_disabled into your project folder and it will use that folder to store any configurations. In fact you might notice that already existing in many of them...

[Mark]

Its not in any of mine but I see that file in a couple of our svn projects. How long has that been in there? I see its a 0 byte file.

If that file is not present in my folders, would Eduke32 indeed share the appdata and keep overwriting from different projects? I don't have any appdata entries for eduke so it must have been implemented after 6927 which is the newest version I'm using right now.

[Player Lin]

Mark, on 15 October 2018 - 03:50 PM, said:

I don't have any appdata entries for eduke so it must have been implemented after 6927 which is the newest version I'm using right now.

http://svn.eduke32.c...duke32&rev=6730

The %appdata% change was 6730, but...

I downloaded r7067(I forgot the last build I used was, guess it was early this year), and put that into my currently (and usually) eduke32 installation which in drive D, and runs it, and then it still loaded my eduke32.cfg well and put my savegame on the same directory of my eduke32 installation, like the past(I don't have the user_profiles_disabled file on my eduke32 installation at all) , I guess it only put eduke32.cfg and savegames on %appdata% if the directory is not write-able(like the goddamn "Programs Files" directory)?

And nothing about eduke32 in my %Appdata%, using Win7 SP1 64bits.

At least on my end, I don't needed to care because eduke32 will found my cfg and savegames on the same directory I use, just not sure about other mods, but the first release of Alien Armageddon mod which using r6969 seems still save its cfg and savegames on the same directory of the mod files, also just a sub-directory, inside of my currently eduke32 installation.

[Mark]

That makes sense. I don't have anything Eduke32 related in Program Files so that would explain my lack of %appdata% entries. Its nothing I need to concern myself with after all. Thanks.

[Sanek]

How do you handle constant sprite glitches in polymost renderer? It's almost impossible to use sprites as shadows and any kind of spritework in general because it glitches all the time.

Besides, there's even weirder sort of glitches with polymost:

Spoiler

Here's glitches in the old build, from aug 2017:


And the latest build:


What happened?

[Mark]

I can't see what the glitches are in your pics. You'll have to be more specific.

[Sanek]

You can see shadow glitching in the left corner of the 1st pic

In the second shot the sky becomes pitch black. Also, the whole map is darker than it should be.

[Mark]

The shadow glitch might be from overlapping sprites. Without checking the map in Mapster I don't know what to say about the skybox

[Sanek]

There's no overlapping sprites. It's just how sprites behavior while it's on the floor (in polymost).
While playing with software, everything is fine. But once opengl is on, everyting turns into shit.

[Gambini]

I just realized there´s no documentation regarding clipshapes on the eduke32 wiki and sadly I couldn´t find where Helixhorned explained its use. Can anybody point me to his explanation?

I know how to use them but i believe i may be missing something and would love to read what the creator said about them. For instance, the Tank sprite´s clipshape has some weird tags on walls and I would like to know what they are for. Any light into this would be very appreciated.

[Mark]

I never knew about tags on clipshape walls. Now I'm curious too. I'm assuming they have the same function as when in the regular map. I have no idea what those are either. But I'm sure those are documented.

[Danukem]

The documentation is included with EDuke32 in a file named "spriteclip.txt" Helixhorned mentions tagging in the paragraph about picnums being "aliased to a layer". I have pasted the documentation below.

Quote

Sector-like clipping for sprites
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Sprite picnums can be assigned to a bunch of connected sectors so that
clipping against these sprites will work as if it is carried out on the
associated sectors. For this, files named _clipshapeX.map (where X is
in 0..9) should be present at program start time. Every such map must be
built to certain rules, and loading many of them has the same effect as
loading a single map with all sectors/walls/sprites thrown together.

* Every sector that contains at least one white wall is considered an "outer" sector.
Conversely, sectors with only red walls are "inner" (clipping) sectors.

* Sprites in outer sectors are ignored.

* To associate a picnum with a bunch of sectors, place a sprite with that picnum in
some inner sector of the lot. At the end stage of editing, align the sprite so that
the model matches the sectors well. See samples/_clipshape0.map for examples.

* A picnum may be associated with many "layers" (called "indices" in the code) of
sectorwork. This serves two purposes: one is to enable more complex shapes than
would be possible using only one sector. The other reason is that a sprite may differ
in orientation in such a way that it is not possible to calculate one from another.
In particular, floor-aligned sprites and face/wall sprites should have their own
sector versions (of course only if they are intended to be used in a particular
orientation).

* The sprites in inner sectors should point northward and should not have any orientation-
changing bits like x-flip or y-flip set. Setting centering and a custom size is permitted,
though.

* A set of picnums can be aliased to a layer. This is useful if "secondary" picnums
are going to be used as decoration, for example. For this, set lotags and/or hitags
of any wall of an inner sector to the picnums to be aliased to layer containing the wall.
If only one of them is set, it is taken as a picnum, otherwise as a both-sided inclusive
range, the order doesn't matter. The pigcop tank is present as an example in
samples/_clipshape0.map. If a picnum has multiple layers, it is advisable to set the same
lotags/hitags for each layer. Note that you do not need to set tags unless you intend to
have more than one picnum to share a clipping shape.

* The inner sectors of a given layer must be all interconnected (not necessarily directly)
and for a layer there must be a unique outer sector.

* Making the floor or ceiling of a sector parallaxed will disable clipping on it in certain
ways. Normally, there are four horizontal clipping planes per inner sector (see the round
table for an example). Making the ceiling parallaxed disables the upper two, and analogously
for the floor.

* Making a sprite transparent will disable rotation around its origin to match a given sprite's
angle. Use it on models with rotational symmetry.


Notes:
------

* The clipping will not change with rendering modes or options.


Predicted bugs:
---------------

* Clipping may not work across playing map sector boundaries, especially with large sprites.


--Helixhorned