[LeoD]

fgsfds, on 13 October 2012 - 03:37 AM, said:

I use hrp downloaded from svn instead of autoload, and launch game with eduke32 -j"HRP/polymer_hrp"

Hm, I have reproduced your setup but can't reproduce the messages.
Post a directory listing of HRP/polymer_hrp
IIRC there is a setting in Windows about displaying file extensions in Explorer. Activate it and see if the warnings go away.

Non-related proposals:
-to avoid later confusion, add, -noautoload to your command line, even if you don't have that folder ATM
-set CheckForUpdates = 0 in your eduke32.cfg when using latest synthesis builds to avoid wasting time accessing the net
-putting nedmalloc.dll into your EDuke32 folder might give you a small performance improvement
-use r3067

[fgsfds]

Quote

IIRC there is a setting in Windows about displaying file extensions in Explorer. Activate it and see if the warnings go away.

It helped, but it's still weird.

Attached thumbnail(s)

• 

[Mark]

It looks like he might have just grabbed the files directly from the svn instead of exporting the svn to his folders.

[LeoD]

fgsfds, on 13 October 2012 - 04:22 AM, said:

It helped, but it's still weird.

Windows is weird. Apparently cache1d.c relies on some Windows internal function.
Hiding file name extensions is a shitty idea in the first place and has helped spreading lots of malware so far. Btw, your CONs compile pretty fast, what processor do you have?

[fgsfds]

Marked, on 13 October 2012 - 04:32 AM, said:

It looks like he might have just grabbed the files directly from the svn instead of exporting the svn to his folders.

It happens when you adding custom CONs too, not with this svn hrp only

Quote

warning: case mismatch: passed "defs.con", real "defs"
Including: BloodTC/blcons/defs.con (140857 bytes)
warning: case mismatch: passed "sounds.con", real "sounds"
Including: BloodTC/blcons/sounds.con (65629 bytes)
warning: case mismatch: passed "user.con", real "user"
Including: BloodTC/blcons/user.con (16777 bytes)

Quote

Hiding file name extensions is a shitty idea in the first place and has helped spreading lots of malware so far. Btw, your CONs compile pretty fast, what processor do you have?

i5 2500k. Never thought that hiding extenstions could cause the problems, considering I never saw anything like that before build 2693.

[LeoD]

Marked, on 13 October 2012 - 04:32 AM, said:

It looks like he might have just grabbed the files directly from the svn instead of exporting the svn to his folders.

Exporting is nothing more than copying without the .svn tree, isn't it? Since Subversion 1.7* doing the latter is easier and faster anyway.

[Mark]

OK. I just thought that some people having all the checkmarks and other icons or files from the svn present might confuse the others who do not have them in their copies.

[TerminX]

I'm frankly surprised the issue with the file case mismatch warnings when showing file extensions in Explorer is disabled is even still a problem. It was first noticed pretty soon after Helix added it and I was certain someone would have come up with an acceptable fix by now.

So, since that didn't happen, enjoy r3068!

[LeoD]

LeoD, on 13 October 2012 - 04:06 AM, said:

-putting nedmalloc.dll into your EDuke32 folder might give you a small performance improvement

Speaking of nedmalloc: There's an important update available which hasn't found its way into the repo yet. I tried to simply drop in the new files but got a compile error.

[Diaz]

TerminX, on 13 October 2012 - 06:56 AM, said:

I'm frankly surprised the issue with the file case mismatch warnings when showing file extensions in Explorer is disabled is even still a problem. It was first noticed pretty soon after Helix added it and I was certain someone would have come up with an acceptable fix by now.

So, since that didn't happen, enjoy r3068!

Thank you TerminX. I was getting case mismatch spam at one of my work computers and didn't know why. I was also going to mention the bug with custom projectiles (my cultists were throwing supersonic dynamite, lol) but I see it's been fixed in r3067

Now something I have to beg to get fixed is the "allow walk with autorun" thing... it needs to be saved to the config file, so it doesn't have to be constantly turned off each time you run the game.
There is also a bug with light rendering: when you need more than 5 lighting passes and you have to increase r_pr_maxlightpasses, the newly increased number doesn't have any effect until you actually change it on the fly. So if i have r_pr_maxlightpasses set to 10 in the config file and the game starts with that value, it won't be fully effective until I change it on the console (or if I just enter r_pr_maxlightpasses, without any value).

[TerminX]

OK, those should both be fixed as of r3070.

[TerminX]

LeoD, on 13 October 2012 - 01:23 PM, said:

Speaking of nedmalloc: There's an important update available which hasn't found its way into the repo yet. I tried to simply drop in the new files but got a compile error.

Addressed in r3086, though probably not in the way you were thinking.

[Diaz]

That was quick! Thanks a lot, and thanks for the lots of useful updates lately

[Jblade]

That pixel detection thingy Helix added is fucking great! For those who don't check the synthesis/changelog, it basically allows you to define wall-aligned sprites and set them to have a per-pixel detection ability on them for hitscan, which means that they allow shots to travel through empty areas and stop bullets if they hit a solid part of the texture. It works great, thanks for adding it

[Micky C]

Does that require con code to work or does it work on vanilla game sprites as well?

[Jblade]

Micky C, on 15 October 2012 - 04:17 AM, said:

Does that require con code to work or does it work on vanilla game sprites as well?

It requires a def file addition; you don't have to edit CON to get it to work so it could potentially be added to the HRP. I'll quote the changelog:

r3078 | helixhorned | 2012-10-14 13:41:34 -0700 (Sun, 14 Oct 2012) | 12 lines

Texel-granular hitscan() for wall-aligned sprites.

The attribute is set per tile from DEF: either
    texhitscanrange <begintile> <endtile>
or
    tilefromtexture <tile> { ... texhitscan ... }
(As a special case, the list may only contain "texhitscan", in which case the
texture is not changed.)

In passing, do some cleanup for "tilefromtexture" DEF parsing: the list tokens
should now be accepted in any order, and errors don't appear in the middle of
the list parsing.

[LeoD]

TerminX, on 14 October 2012 - 04:20 PM, said:

Addressed in r3086, though probably not in the way you were thinking.

I rarely think nowadays but I had hoped to build my own bdver1 version from that.

[Helixhorned]

James, on 15 October 2012 - 04:12 AM, said:

That pixel detection thingy Helix added is fucking great! For those who don't check the synthesis/changelog, it basically allows you to define wall-aligned sprites and set them to have a per-pixel detection ability on them for hitscan, which means that they allow shots to travel through empty areas and stop bullets if they hit a solid part of the texture. It works great, thanks for adding it

Cool you're finding it useful! It was requested by M210 for his Blood mod, but currently it doesn't help his case as it only handles wall-aligned sprites. For a quick demo of what it's about, add

texhitscanrange 0 32768

to your duke3d.def and try shooting the fan in E1L1. (Caveat: won't work on the fences, since all MASKWALL* sprites clear the hitscan-sensitivity bit on spawn.)

[Jblade]

Helixhorned, on 15 October 2012 - 11:26 AM, said:

(Caveat: won't work on the fences, since all MASKWALL* sprites clear the hitscan-sensitivity bit on spawn.)

Heh, I had always wondered why that chainlink fence sprite at 913 never seemed to keep it's tag, now I know It works great with some new chainlink fence sprites I added in the AMC TC since they were coded to spawn sparks and sounds and stuff, it works really well with this new feature now.

[Kyanos]

Is there any way to increase the drawing radius of the renderer?
If not, I would like to request that the drawing radius be made adjustable some how. Either via con or preferably a way in Mapster to adjust the drawing distance for new user maps.

[Mblackwell]

Are you talking about visibility? In USER.CON change DEFAULTVISIBILITY.

http://wiki.eduke32....wiki/Visibility

[Micky C]

He's referring to the draw distance in polymer. It's a great way to boost the frame rate, but can be incredibly obvious and ugly in open maps where half the map is missing. Specifically there are a set of maps I'm working on for WGRealms 2 that require polymer and a draw distance of maybe 3 times as far as it is currently, so some way to change the distance in con would be ideal and welcome.

[Fox]

I have some ideas for effects that could be added in the future. In both cases it would especially usefull in making the transition from water to the skybox

The first would be to have a "transparent fog" effect. Here is a mock-up:



The second would be to render the sector floor ad infinitum in a wall. In other words, to stretch the floor texture to the horizon while that area doesn't really exists. I suppose the renderer can make it in a way that can save more CPU than making a gigantic sector.

[Mblackwell]

Micky C, on 16 October 2012 - 04:51 PM, said:

He's referring to the draw distance in polymer. It's a great way to boost the frame rate, but can be incredibly obvious and ugly in open maps where half the map is missing. Specifically there are a set of maps I'm working on for WGRealms 2 that require polymer and a draw distance of maybe 3 times as far as it is currently, so some way to change the distance in con would be ideal and welcome.

Ah, I see what you're/he's saying now.

[Plagman]

I finally hooked up the bit to prevent spotlights from casting shadows; it's linked to the one-way bit on SEs, so pressing '1' on a spotlight SE should remove its shadow.

I also implemented support for negative lights; they remove light from the scene instead of contributing more to it. To activate it, just set the half-submerged bit on any light SE ('C' in mapster) and it will become negative. The color components work as usual, except they're substracted from the scene.

I can think of several uses; a fully white negative light would just create darkness and could be used as a shading tool that's a little smoother than sector shading.



If you only keep one component (eg. a cyan negative light would remove green and blue, leaving only red), it can create a fluorescent kind of effect:




Or just for 'unreal' effects, evil-looking auras, etc:



Thanks Charlie for submitting the idea.

[Fox]

That's an interesting effect.

But I always felt that some game sprites and HUD sprites shouldn't be affected by Polymer lights, and these negative lights only reinforces it.

[Micky C]

I agree, it's definitely interesting. I look forward to testing it out some time and seeing what juicy goodness is possible.

[Diaz]

Very interesting Plagman, the negative lights indeed seem to be a great shading tool, I'll make sure to get some good use out of them. And thanks for the shadow-less spotlights! As you mentioned in the changelog, if we had a usecase where we needed no shadows but actual texture projections (if that's what lightmaps means) we should let you know... well, I have to say that's exactly the primary use I was going to give them! I'm using spotlights with projections to simulate water caustics, and those are the ones that should not cast shadows; but they do need to project a texture.

[Mark]

It would be cool to have that negative light attached to an enemy so darkness surrounds him wherever he goes. And it would drain health just being near him. A soul sucker.

[Plagman]

Fox, on 20 October 2012 - 10:03 PM, said:

That's an interesting effect.

But I always felt that some game sprites and HUD sprites shouldn't be affected by Polymer lights, and these negative lights only reinforces it.

Particle kind of sprites, sure; most of them should be fullbright no matter what, I agree with that. Why HUD models though? They looked very off before while they weren't affected by surrounding lights and pretty much everyone was complaining about that.