[TerminX]

Paul B, on 21 August 2013 - 06:03 AM, said:

I do know for a fact when it did crash in Windows 7 there was never any logs associated to the crash. It was a black screen my hard-drive light would flicker intermittently but I couldn't drop out to Windows 7 Desktop or terminate the game. Control Alt Delete wouldn't even bring up taskmgr the only thing I could do was a manual reboot of the PC which would break my mirror from an improper shutdown. It was a pain in the ass and I don't want to disable Disk Caching just to put up with a bug in Eduke which in my opinion caused a video driver fault not reported by windows or Eduke.

You have a hardware or driver problem, period.

[Paul B]

TerminX, on 21 August 2013 - 08:38 AM, said:

You have a hardware or driver problem, period.

Well the fact that I can play Farcry3, Counter-Strike Go, Need For Speed on my Windows 7 Install and run windows 7 without any other issues makes it seem more like a Windows 7 Nvidia Driver problem rather than a "Hardware issue". Of course Eduke runs just fine on my XP installation on the same PC. Meaning the hardware must be ok but more specifically a driver issue in Windows 7. I typically keep pretty current with my video drivers. I'll give Eduke another try on Windows 7 running the latest drivers and if I have any issues i'll be sure to post my results.

***EDITED*** Well I've tried Windows 7 and Eduke. Seems to run fast and smooth in Polymer. Appears a lot better than I remember it. I'll continue using it to see how it works long term its still too early to really know. But I just wanted to say thus far it kicks ass.

[Paul B]

Spoke too soon. Okay I’ve been editing using Mapster on my PC for 4 hours in Windows 7. There is definitely a glitch with Mapster with the way it handles switching between 2D & 3D when using the Polymer renderer. This is not a driver problem or a hardware problem. Sorry to break the news but the program works about 95 percent of the time except every now and then when switching between video modes Mapster causes a big problem: screen goes black and locks the entire Operating system. It would be nice if someone could some how track down this problem by monitoring the code that initiates the switching between graphic modes from 2D/3D if there is any hesitation at all between switching or a hesitation that is longer than expected Mapster will crash the computer. No logs are generated when this occurs. Keep in mind I've been working in mapster for 4 hours before it happened only one time between switching back and forth so it’s a real intermittent bug.

EDITED - When I map I'm always using "full screen" mode and I don't alt - tab between windows and the desktop. When this crash occurs it renders the entire PC useless not just Mapster. It's pretty nasty and I can't see it being good for the hard-drives. So i'll remain mapping in XP.

Makes me wonder if it has something to do with when Mapster disables the Microsoft Areo Interface and maybe when switching between 2D / 3D Windows tries to re-enable Areo before Mapster has a chance to load the display and it crashes. To me it seems like a timing issue with something between Windows 7, Mapster and the display driver.

What I probably should consider is have a fresh vanilla install of Windows 7 and test Eduke that way just incase my antivirus or another background app is interfering with the video modes. But honestly i don't have a lot of crap running in the system tray. Just SEP 11 and Steam maybe.

[MusicallyInspired]

I've had Mapster running for quite a while in Win7 with no issues. However, what does happen is Mapster crashes when you alt+tab out of the program for more than 5-10 seconds.

[Hendricks266]

Paul B: Try running eduke32.exe in XP compatibility mode. That will stop EDuke32 from disabling desktop composition when entering an OpenGL mode.

[Paul B]

Hendricks266, on 22 August 2013 - 07:21 AM, said:

Paul B: Try running eduke32.exe in XP compatibility mode. That will stop EDuke32 from disabling desktop composition when entering an OpenGL mode.

Thank you I will try that next. =)

[The Commander]

I have noticed issues in the past when using mapster in full screen, that is why I started mapping in window mode.
Maybe Mapster should be forced to only be used in window mode... (and a nice hidden cvar for the pros to run it full screen)

[Paul B]

The Commander, on 22 August 2013 - 01:46 PM, said:

I have noticed issues in the past when using mapster in full screen, that is why I started mapping in window mode.
Maybe Mapster should be forced to only be used in window mode... (and a nice hidden cvar for the pros to run it full screen)

I'm starting to get the feeling these problems i'm having in Full Screen mode has something to do with Mapster losing window focus and it causing it to display a black screen and not properly releasing the display back to the desktop or the Mapster screen but some where imbetween. This seems to occur on both XP and Windows 7 but definitely worse in Windows 7. With XP I can sometimes get lucky and open the Taskmgr to kill the mapster process. It even occurs just opening Mapster for the first time on the odd ocassion and occurs more frequently when I have other programs open in the background such as a Word Document that's set for full maximized window size.

[DavoX]

i've always had problems fullscreen since Build so I never used anything but Windowed mode.

[Mark]

Like the rest of you, for a long time fullscreen was prone to crashing quite often. But some time earlier this year I switched to fullscreen and its been a whole lot better. The only glitch I see is after hitting "T" test mode to activate 3D and when exiting back to 2D mode I get a white square in the middle of the grid which goes away just by pressing the esc key. I can live with that small problem.

[Fox]

Is it possible for Eduke32 to include Sector Effector based water, like in Zero Hour? I know of that trick of changing the sector lo-tag based on the player position, but that's too much of an ugly hack. I don't know how it would be used, as a reserved or hidden lo-tag, but it would be good to have that feature avaiable.

[Hendricks266]

What impediments are there for you coding your own SE with a water effect in CON?

[The Commander]

 Hendricks266, on 27 August 2013 - 07:44 AM, said:

What impediments are there for you coding your own SE with a water effect in CON?

I suppose it could be used for stand alone maps that could work in MP in future?

[Fox]

 Hendricks266, on 27 August 2013 - 07:44 AM, said:

What impediments are there for you coding your own SE with a water effect in CON?

Objects above the player magically float of sort and smoke trails become water bubbles.

[Micky C]

I'm not sure what its like in zero hour, but DukePlus has SE based water. You can even change the height in-game and have the water submerge new areas as it rises.

I have the feeling DT coded the swimming code from scratch though.

[The Commander]

 Deeper Micky, on 27 August 2013 - 01:58 PM, said:

I'm not sure what its like in zero hour, but DukePlus has SE based water. You can even change the height in-game and have the water submerge new areas as it rises.

I have the feeling DT coded the swimming code from scratch though.

Not everyone likes using DukePlus Micky if you haven't worked that one out yet.

[Mblackwell]

@Fox
Code it so if anything is below the SE its movement is slowed, smoke is changed to bubbles, and you change the screen palette. Yay?

[Micky C]

 The Commander, on 27 August 2013 - 04:14 PM, said:

Not everyone likes using DukePlus Micky if you haven't worked that one out yet.

I was just telling him that it has been done, so that if he wants to look up the code he can make his own code.

[Stabs]

Hey guys version 3737 has made some major changes to vis and the way fog works and it does not look good

here

[Helixhorned]

It's likely the same problem with the same solution as in the BloodTC thread. Blame Plagman for confusing everyone with crappy working titles and not mentioning the cvar in the commit logs .

[Stabs]

k so i noticed another issue, in WGR2 a V with a lotag of 1 multi's the visibility and reall helps tweaking fog to very specific levels based on its hitag, between 3963 seems to have made changes that have stoped this SE effect from functioning. without the amount of fog is so heavy it does not look good.

------------------------------------------------------------------------
r3963 | helixhorned | 2013-07-18 11:08:16 -0700 (Thu, 18 Jul 2013) | 4 lines

Makefile.common: disable -Wstrict-overflow.

It didn't turn out that useful and was giving a warning with one of the
preceding changes.
------------------------------------------------------------------------
r3962 | helixhorned | 2013-07-18 11:08:15 -0700 (Thu, 18 Jul 2013) | 5 lines

Polymer/ART mapping: fix formula for globalvisibility.

Also, very slightly tweak a factor toward a "brighter" (farther visible)
scene overall to account for the "circular" nature of the fragment distance
(as opposed to an "ortho" distance in Build).
------------------------------------------------------------------------
r3961 | helixhorned | 2013-07-18 11:08:13 -0700 (Thu, 18 Jul 2013) | 5 lines

Retire global 'lastvisinc'.

It was only ever used as upper bound to the time that a visibility change
decays, but since it does that in an exponential fashion, there's really
no point.
------------------------------------------------------------------------
r3960 | helixhorned | 2013-07-18 11:08:11 -0700 (Thu, 18 Jul 2013) | 7 lines

Make vis decay with time independent of FPS, treat p->visibility<0 like 0.

Now, if p->visibility differs from the constant visibility, the former converges
toward the latter by three-quartering the difference each second totalclock
increment (1/60th second).
Negative player visibilities are not handled consistently throughout the
different renderers, so make it look the same as 0 (can view to infinity).
------------------------------------------------------------------------
r3959 | helixhorned | 2013-07-18 11:08:10 -0700 (Thu, 18 Jul 2013) | 3 lines

Polymodes: properly calc start/end fog dist for r_usenewshading=2, vis=0, shade>0

So there's no "jump" from vis!=0 to vis=0 making the texture appear brighter.
------------------------------------------------------------------------

[Plagman]

 Helixhorned, on 03 September 2013 - 10:21 AM, said:

It's likely the same problem with the same solution as in the BloodTC thread. Blame Plagman for confusing everyone with crappy working titles and not mentioning the cvar in the commit logs .

?

[Plagman]

DanM, on 02 September 2013 - 10:35 PM, said:

Hey guys version 3737 has made some major changes to vis and the way fog works and it does not look good

here

Hmm, that sucks. Artmapping should look similar to classic for your map, can you send it to me? Do you use an unconventional pal by any chance? Sorry I broke it!

[Micky C]

You might as well just download it from the SVN if you have access.

He's using a custom defined fog pal.

[Stabs]

Yeah its not so much 3737 as long as i add that extra commandline helix mentioned

r_pr_artmapping 0

to the autoexec.cfg files, just somewhere between 3960 & 3963 the V effect in WGR2 will not work, it basically multiply the vis levels so they are not so heavy and i only need to change one hitag instead of selecting all the sectors and setting a global vis level which dosn't work that well with TROR as it only seems to effect one TROR level at a time even if i have the whole level selected with ALT (yes i turned of the greying out)

also vis is just crazy to begin with 0 is the furthest it gets besides 240 which looks non exsistant, all vis levels 1 - 239 makes the fog come closer

yeah micky should be able to set you plagman with SVN access it should have the town map, i left the V controller out the front of the tavern.

[Helixhorned]

Plagman, on 03 September 2013 - 09:50 PM, said:

Hmm, that sucks. Artmapping should look similar to classic for your map, can you send it to me? Do you use an unconventional pal by any chance? Sorry I broke it!

Actually, it's the same reason why I broke that map with r_usenewshading 2: it has been built with legacy Polymodes visibility in mind, and with colored fog it looks way off because it's usually closer to the player then. [Edit: classic fog vs. old-Polymodes, that is.]

DanM, on 03 September 2013 - 10:45 PM, said:

also vis is just crazy to begin with 0 is the furthest it gets besides 240 which looks non exsistant, all vis levels 1 - 239 makes the fog come closer

Yes, the visibility member of the sector structure is biased by 16: you should think of the value 240 as 0 (= 256 mod 256), 241..255 as 1..15 and 0..239 as 16..255.

[Helixhorned]

DanM, on 03 September 2013 - 10:45 PM, said:

just somewhere between 3960 & 3963 the V effect in WGR2 will not work, it basically multiply the vis levels so they are not so heavy and i only need to change one hitag instead of selecting all the sectors

Seems to work fine here, ud.const_visibility gets set to 16 on entering that level, the hitag of the VISOVERRIDE. But what has changed between these revisions is that negative const_visibility/p->visibility values will be considered the same as 0: view to infinity.

Quote

and setting a global vis level which dosn't work that well with TROR as it only seems to effect one TROR level at a time even if i have the whole level selected with ALT (yes i turned of the greying out)

Global visibility is temporary in the editor and is not saved to maps. But it's the same thing (give/take tweaking) as ud.const_visibility at game run time.

[Helixhorned]

Plagman, on 03 September 2013 - 09:49 PM, said:

?

r3729 said:

New Polymer feature: shitty mode.

r3737 said:

Finish Polymer cancer mode and enable by default.

r3738 said:

Fix interaction between ART mapping and lighting.

pk:~/dl/esrc_git/eduke32$ git log | grep r_pr_artmapping
pk:~/dl/esrc_git/eduke32$

I think it's praiseworthy that users read our commit messages to figure out stuff, but the connection gets slightly lost here.

[TerminX]

Hey, at least the messages weren't blank.

[Stabs]

alll fixed now cheers! can finally just get down to cleaning this ACT up