[DuduKrazy]

is there a way to disable polymer lights for specific actors like explosions, fires or those green goo barrel thingies?

[TerminX]

Rewrote the mouse and keyboard input recently, replacing the old DirectInput based crap altogether (except for joysticks). This should fix the mouse input problems that pop up when the fps is too low. Since the raw input API is only available on XP or newer, Windows 2000 support has been dropped and there is now no way to ever run EDuke32 on anything earlier than XP other than digging old source revisions out of svn.

The old config file format (eduke32.cfg) has been deprecated now as well. All it will contain when I am done are things used by the startup window; everything else will be configured through settings.cfg (previously called eduke32_binds.cfg).

I think I'm also going to switch to MSVC for official (non-synthesis) builds. I'm a bit sick of the fact that gcc hasn't been able to correctly compile EDuke32 since before version 4.4.0, on Windows OR Linux. Besides, VS2010 is pretty spiffy.

[Night Wolf]

why is this happening?
same thing with E1L1 and probably others

[Fox]

DeeperThought, on Apr 15 2010, 12:05 PM, said:

I'm guessing that TerminX would be reluctant to do that without a good reason, since it would increase the amount of memory used. I'm curious: what are you trying to do that requires more bits?

For example, if I try to make a three rule (cross multiplication) for the status bar scale, it will go like this:

<x coordinate> x 65536 x <current scale> / 100

And if <current scale> is 100, them the maximum for x coordinate is 327, which unfortunatelly I have already bypassed.

Another thing I trying to do is an GTA like map with an big image used as the map that would move in the screen. Since I would use player posx and posy, it turns something very limited.

So far the way I go through it is multipling not by 65536, but (for example) 256 in the multiplication process, and before using rotatesprite16 command I multiply by 256... it works, but I think it kills the purpose of rotatesprite16...

[Hendricks266]

TX, on Apr 21 2010, 03:44 AM, said:

I think I'm also going to switch to MSVC for official (non-synthesis) builds. I'm a bit sick of the fact that gcc hasn't been able to correctly compile EDuke32 since before version 4.4.0, on Windows OR Linux. Besides, VS2010 is pretty spiffy.

Is there any feature/compatibility/other advantage that would give over gcc 4.3.3?

[The Commander]

ozz, on Apr 22 2010, 01:36 AM, said:

why is this happening?
same thing with E1L1 and probably others

It's the way Polymer renders walls...
(At a guess) Because the wall is in an invalid space Polymer won't draw because it thinks the player will never see the wall.

[Tetsuo]

Hendricks266, on Apr 21 2010, 02:39 PM, said:

Is there any feature/compatibility/other advantage that would give over gcc 4.3.3?

I just wonder if it would mean dropping non-windows (Linux, etc.) support.

[Mblackwell]

Tetsuo, on Apr 21 2010, 10:55 PM, said:

I just wonder if it would mean dropping non-windows (Linux, etc.) support.

No.

[Night Wolf]

The Commander, on Apr 22 2010, 09:59 AM, said:

It's the way Polymer renders walls...
(At a guess) Because the wall is in an invalid space Polymer won't draw because it thinks the player will never see the wall.

Interesting , i've only noticed this in newer versions of polymer, may have always been like that, not positive though ...
anyway is there anyway to fix this in future eduke releases?

[The Commander]

ozz, on Apr 22 2010, 06:07 PM, said:

Interesting , i've only noticed this in newer versions of polymer, may have always been like that, not positive though ...
anyway is there anyway to fix this in future eduke releases?

Plagman is the only one that can answer that.

[Fox]

The Commander, on Apr 21 2010, 08:59 PM, said:

It's the way Polymer renders walls...
(At a guess) Because the wall is in an invalid space Polymer won't draw because it thinks the player will never see the wall.

More specifically, it will determine which sector can be seen based on floor and ceiling z coordinates. If you look at it in Build, you can see that if it wasn't an paralaxed sky, you would never see that sector. But that's the issue, it's a paralaxed sky.

[The Commander]

Fox, on Apr 23 2010, 02:55 PM, said:

More specifically, it will determine which sector can be seen based on floor and ceiling z coordinates. If you look at it in Build, you can see that if it wasn't an paralaxed sky, you would never see that sector. But that's the issue, it's a paralaxed sky.

Yeah, thats another way of explaining it.

[Skulldog]

TX, on Apr 21 2010, 03:44 AM, said:

I think I'm also going to switch to MSVC for official (non-synthesis) builds. I'm a bit sick of the fact that gcc hasn't been able to correctly compile EDuke32 since before version 4.4.0, on Windows OR Linux. Besides, VS2010 is pretty spiffy.

The free VS2010 Express Edition I hope.

[TerminX]

EDuke32 should continue to build with the free versions of VS.

[supergoofy]

GCC 4.4.x - 4.5.0 fix by Plagman

r1624: %esi gets modified by swapchar2 but isn't listed as an output operand for the GCC extended assembly version. This causes the compiler to fail to restore it after swapchar2 executes, causing crashes if used in a loop. This change fixes the security camera crash when using GCC 4.4.x or 4.5.0.

[LeoD]

Hail to the Plagman. (Could not get the MinGW version of gcc 4.5 to compile it, though.)

[supergoofy]

maybe you forgot to compile and install in mingw the libogg and libvorbis libraries

[Plagman]

MinGW 4.5.0 is what I was working against when I fixed that, so I know it works; what errors are you running into?

[NF64]

Quick question:
Ok a long time ago for the polymer trailer we seen the Pig Recon Patrol Vehicle casting spotlight lighting, i was thinking if this feature can still be done in polymer. If so how?

[LeoD]

supergoofy, on Apr 26 2010, 10:49 PM, said:

maybe you forgot to compile and install in mingw the libogg and libvorbis libraries

No. Please note that there are new versions (libogg-1.2.0, libvorbis-1.3.1). Seems to me that there are less crashes for me since I use them. (Although there haven't been many before that anyway.)

Plagman, on Apr 26 2010, 10:50 PM, said:

MinGW 4.5.0 is what I was working against when I fixed that, so I know it works; what errors are you running into?

There were some strange assembler related error messages IIRC. But I have deleted that stuff some weeks ago after deciding to wait for the TDM version. Maybe I will give it another try in the not so far future now that i know that others have succeded in using it.

[Night Wolf]

Has anyone run into this problem ....

its quite odd ... it only ever happens on the 3rd or 4th time you load a level , say you die 2-3 times and load the same level on any episode on any level..
its causes the frame rate to drop below 5 fps and becomes incredibly unstable

[Night Wolf]

I would try deleting the texture cache but for some reason its disappeared and nowhere to be found in the eduke folder
??

[The Commander]

Changing the texture quality in the options will reset the cache if you can't find it.

[Night Wolf]

that did work to reset the textures... however the problem still happens on the 3rd - 4th time... the textures go screwy just shows maps and games runs very slow... possible windows 7 eduke issue??

[TerminX]

I suspect if there were Windows 7 issues I would have noticed them during the 16 months I've been running Windows 7.

[Sobek]

I've had something kind of similar happen in the past. However instead of just textures going a bit iffy, models tended to have pieces missing (possibly with some goofed up textures like above), along with the same unplayably slow framerate.

In my case, it turned out that it was a side-affect of running the game with some specific high-poly models at too-high a resolution and with too much AA applied. Not sure why it caused everything to stuff up, but just reducing the amount of AA I had applied, or dropping the resolution a bit would always take care of it.

Though to be honest I've never seen anything of mine just start showing normal maps. But the low performance + buggered textures would indicate that it's possibly a similar problem. I haven't yet pushed the resolution / AA high enough again to try and replicate this, but I have since also changed videocards (this happened on my 2900xt, which I changed to a 3870 and now a 3870x2).

[Night Wolf]

Interesting .... its possible its something I've done , maybe I've added a texture that's too big as I tend to experiment with my hrp' hmmm ... i might explain why its only happened in the last few weeks ... just couldn't be bothered saying anything till now, or it could be something else altogether

[Night Wolf]

I fixed it!

turning off "Pre load map textures" fixed the problem... how odd

[SwissCm]

i liiiike to make waaafflesss

[The Commander]

SwissCm, on May 2 2010, 01:09 AM, said:

i liiiike to make waaafflesss