[Micky C]

This post is mostly directed towards Plagman I guess.

So I've got a map with almost 900 SE polymer lights, and over 100 con spawned lights in this map I'm currently working on. However I fire it up in-game and the vast majority of lights in the first section of the map simply aren't there. They're clearly there and working fine in mapster, but not in-game. Is there a maximum number of lights you can have in a map that would cause this?

I'm willing to send the map in a PM if there's no clear solution for this. I have no idea what's wrong and it's probably only 2 weeks from release so things are tense.

[Diaz]

What's your r_pr_maxlightpasses value? You could try increasing it... sometimes it looks like Mapster draws more lights than the value reflects, but not the game.

[Micky C]

There are entire areas where the lights aren't working, and the lights I was adding to it when I noticed they stopped working are so remote it wouldn't make the slightest difference.

I'll try it when I get home anyway.
Edit: Yeah changing it does nothing. Highest I tried was 9. But that makes no difference when there are 0 to start off with

[Micky C]

Ok thanks for the lack of response with this significant problem everyone

I was reluctant to break the map up into smaller maps (who doesn't like a mega polymer map?), but I did a few tests and the frame rate is actually noticeably better (sometimes double!) when most of the map is cut away even though the chunk that's missing shouldn't be rendered. It's weird, but it's reason enough to break it up, and that ought to solve the problem with the missing lights. Killing 2 birds with 1 stone

[Jblade]

The latest snapshot refuses to load for me - it doesn't give me a log or anything, I click to start the exe and even the little startup window doesn't work. I also noticed the zip file only has the Exes and nothing else that's normally in there, is this intentional?

EDIT: Ok nevermind, I take it we don't need the DLLs anymore then? I deleted them and it loaded up fine.

[Mark]

I had the same problem. Thanks for the solution.

[Helixhorned]

r2341 and below will crash if the URL against which the EDuke32 version is checked (http://eduke32.sourceforge.net/VERSION) is unavailable, like earlier today. I fixed this in r2344, but there's no synthesis build yet. I don't think it's my fault though... r2341 only has exe's in it, and that's wrong .

Btw, I'm in favor of removing that check entirely. It serves no purpose now that we (kinda) recommend everyone to download synthesis builds, and I strongly prefer my programs not to access the network unless I tell them to do so. This also might be the cause of some (false positive) heuristic virus checker alerts.

edit:

r2345 said:

Fix build. It was my fault after all since I forgot common.h in r3243.

[Fox]

Plagman, on 21 November 2012 - 10:35 AM, said:

Trooper Dan, on 21 November 2012 - 10:18 AM, said:

Here is a formula that does it properly, which can be implemented in CON

http://www.mathopenr...olygonarea.html

Now, you'd also need to calculate the area of any islands inside the sector and substract it from the area of the outer edge.

How exactly I do that? I have been thinking, I can't figure out the way to diff beetween the sector walls and "island" walls.

[Plagman]

Well, when you finish a loop and there are still walls remaining in the sector, you know you're done with the outer loop, don't you?

[Fox]

Plagman, on 29 November 2012 - 10:33 AM, said:

Well, when you finish a loop and there are still walls remaining in the sector, you know you're done with the outer loop, don't you?

But how do I know what is the "outer loop", since the firstwall can be in a island? Or it has something to do with the defined order of wall IDs?

[Plagman]

Good point; islands have reverse winding order compared to the outer loop, so checking the angle between all the walls for each loop would tell you.

[Helixhorned]

The engineeditor has a function named "clockdir" (src/build.c, line 8318 in r3245) that calculates the winding orientation of a loop, given its first wall-point. So if you absolutely need to, you could port it to CON. But, out of curiosity, what do you need the sector area for? Is there no approximation that would suffice?

[Fox]

I just wanted to use the "right" code to calculate the area, but there are other means for what I want to achieve. Since I just want to calculate the area of an sector made of blocks, there are workarounds.

Plagman, on 29 November 2012 - 10:42 AM, said:

Good point; islands have reverse winding order compared to the outer loop, so checking the angle between all the walls for each loop would tell you.

[Hendricks266]

James, on 29 November 2012 - 01:29 AM, said:

EDIT: Ok nevermind, I take it we don't need the DLLs anymore then? I deleted them and it loaded up fine.

No, they were omitted (along with all of samples) because when bash scripts execute, changes made to them during their execution do not affect them for that run, so when synthesis.sh svn updated, the new instructions I sent it would not have taken effect until the next run. I asked TerminX to fix it by setting the cronjob to svn update synthesis.sh before it runs and he did.

[Danukem]

I have used the following method for calculating a rough estimate of sector area: loop through all the wall points of the sector, and save the smallest x coordinate, the largest x coordinate, the smallest y coordinate, and the largest y coordinate in vars. Then use those values to calculate the area of the rectangle formed by the corresponding points. Depending on the shape of the sector and whether it has islands, this method can overestimate the area by a lot, but it's close enough for my purposes for typical sectors.

[RichardStorm]

Why are we discussing about con features here ?

Anyway, i found (not tested, not used) a method for calculating area of any sector with a good approximation, it works by "counting square elements" in the sector : save maximum and minimum x and y as you mentioned, then start two loops (one inside the other) to scan if the point "x,y" is in the sector, spacing x and y with a constant step between sector extension; when the point is in the sector (updatesector) , the "area" var is increased and you'll get the total area at the end of the process after a proper conversion factor.
The same method could be used to calculate a volume just adding the z scaled by 8 ; It's also possible to choose the dimension of the step, or to get it by sector extension, for optimizing the process and choose between speed or accuracy of the method.

Damn, this "mesh" approach remind me computational fluid dynamic lessons...

[Danukem]

RichardStorm, on 01 December 2012 - 01:28 AM, said:

Anyway, i found (not tested, not used) a method for calculating area of any sector with a good approximation, it works by "counting square elements" in the sector : save maximum and minimum x and y as you mentioned, then start two loops (one inside the other) to scan if the point "x,y" is in the sector, spacing x and y with a constant step between sector extension; when the point is in the sector (updatesector) , the "area" var is increased and you'll get the total area at the end of the process after a proper conversion factor.

thanks, that sounds like it would be a nice improvement!

[Fox]

That's the plan I already had in mind.

[Plagman]

It'd be slow as hell with smaller steps, though. You'd probably only want to be doing at map load, and you're out of luck if sectors change shape after that.

[Fox]

It won't be a problem for me, I am going to calculate the area of something as simply as this:

[Kyanos]

What's going on here with the dlls? I planned on releasing an add on for Wgr2 soon with instructions to get the latest version of Eduke32 for better performance. Now it won't run without deleting preexisting dlls in the released version of wgr2.

[Hendricks266]

The DLLs in question are nedmalloc.dll and ebacktrace1.dll, right? ebacktrace only runs for the debug exe, and nedmalloc should work. At some point the DLL was updated so maybe that's the cause.

The latest synthesis (r3250) has both DLLs properly packaged.

[Kyanos]

When I use it ( I only copy over exuke32.exe and nedmalloc.dll ) it won't run. I'll do some more investigating when I get back to my PC. Rev. 3219? Is the last one I was working with and it was fine.
Polymer has improved a lot in the past year and a half so I really want to use a newer executable.

Added.
R 3250 eduke32.exe will not run.
This is tested in its own freshly unzipped folder. It won't bring up the start menu or anything. The debug exe does work.

[Helixhorned]

Does it run without nedmalloc.dll? In any case, it's safe to remove and I recall TX saying that it doesn't matter much on newer Windowses.

[Kyanos]

It just doesn't run. Unzipped by itself, run eduke32.exe or mapster32.exe nothing. the debug.exe files run.
I'm not talking about wgr2 anymore, just the synthesis download as is doesn't work.

edit:
I'm using windows 7, haven't changed anything on my end in ages, these packages are always just extract and run for me.

[Plagman]

Is 3233 the first one that breaks for you?

[Kyanos]

 Plagman, on 02 December 2012 - 01:12 PM, said:

Is 3233 the first one that breaks for you?

Confirmed.

[Plagman]

OK, it's reverted until we figure out what's wrong with the native cross-compiler we switched to. Can you confirm 3251 works again?

[Micky C]

Is there any progress on finding that bug that causes sprite shadows to be incorrect at some angles? The project it will be useful for will probably be out in a week if that's any motivation. It's not a game breaking bug but if it's going to be looked at in the near future at all it would be nice if the fix was squeezed in before the deadline.

[Kyanos]

 Plagman, on 02 December 2012 - 03:26 PM, said:

OK, it's reverted until we figure out what's wrong with the native cross-compiler we switched to. Can you confirm 3251 works again?

All better. Thanks guys.