[Tetsuo]

Well, like i said I tried removing the savegames entirely and starting over and it still didn't work. In fact it doesn't even seem to be writing a savegame file at all. I just tried saving a game with the folder it goes into open and noticed no savegame file popping up. So unfortunately there's nothing to send over. I don't have any errors in my log either.

Also I'm not having any problems with the shadows but the FBO thing was preventing the game from going full screen previously. But I don't seem to be getting that error with the last build you posted only the previous one to that which I compiled myself.

The only mods I'm using are the polymer HRP, the update pack for it and the duke3d_sc55 music pack.

Everything but the savegame function seems to be working great for me at the moment.

[Plagman]

Is it ATI? Does pr_ati_fboworkaround get applied? If not, try forcing it; the renderer string might be slightly different on OSX?
If not, what FBO number is it? #0 or any of 1-shadowcount?

[Tetsuo]

I can't speak for Helixhorned but pr_ati_fboworkaround gets applied for me and the shadows work here. I have an ATI RadeonHD 4850 on my iMac.

[Helixhorned]

Tetsuo, on 25 September 2011 - 02:41 PM, said:

In fact it doesn't even seem to be writing a savegame file at all. I just tried saving a game with the folder it goes into open and noticed no savegame file popping up. So unfortunately there's nothing to send over.

Maybe there's a problem with the permissions of the directory or something equally silly? I dimly recall having a similar issue while playing zykov eddy's The Wall, where a particular combination of the search paths lead to the savegame being written into another directory than was searched (IIRC). Can you try running plain vanilla Duke and see whether the problem goes away? If it does, that's a strong indication for search-path weirdness.

Plagman, on 25 September 2011 - 02:41 PM, said:

Is it ATI? Does pr_ati_fboworkaround get applied? If not, try forcing it; the renderer string might be slightly different on OSX?
If not, what FBO number is it? #0 or any of 1-shadowcount?

Here's the relevant parts of my log:

Initializing SDL system interface (compiled against SDL version 1.2.14, found version 1.2.14)
Using "Quartz" video driver

...

OpenGL Information:
 Version:  2.1 NVIDIA-1.6.36
 Vendor:   NVIDIA Corporation
 Renderer: NVIDIA GeForce 9400M OpenGL Engine

...

Initializing Polymer subsystem...
PR : FBO #1 initialization failed: 8cdc
PR : FBO #2 initialization failed: 8cdc
PR : FBO #3 initialization failed: 8cdc
PR : FBO #4 initialization failed: 8cdc
PR : FBO #5 initialization failed: 8cdc
PR : Initialization complete.

0x8cdc being the GL macro mentioned earlier.

[Tetsuo]

Plain vanilla duke means without the HRP right? Because I just tried that and it made no difference.

Have you tried compiling the latest source on the Mac? I tried and it's failing on the VP8 stuff and anim.c

[Helixhorned]

Argh, bummer. I'm out of ideas.

As for the VPX stuff, either disable it in the Makefile.common (USE_LIBVPX=0), or get the headers and library. I got mine working with 'sudo port install libvpx' and some Makefile tweaks which I'll throw into the SVN repository another time.

[Plagman]

Helix: can you try forcing on the logic that enables pr_ati_fboworkaround to see if that fixes things? It's possible the Mac driver for NVIDIA has the same behavior as ATI on all platforms.

[Mikko]

Thanks for fixing the memory leak bug!

[Helixhorned]

Plagman, on 26 September 2011 - 11:04 AM, said:

Helix: can you try forcing on the logic that enables pr_ati_fboworkaround to see if that fixes things? It's possible the Mac driver for NVIDIA has the same behavior as ATI on all platforms.

Indeed, forcing the workaround makes the spot lights display correctly, but the shadow is projected in a strange way. I can make screenshots later because it's a bit hard to describe. For example, standing so that one's back is turned to the rotating spotlights in the TROR test map, the width of the shadow in front of you is greatest when the light shines in the same direction as you look, and gets smaller "at the edges", that is, with increasing absolute value of the angle between the light direction and your viewing direction.

[Tetsuo]

Well the VP8 stuff doesn't seem to work even after I installed it via macports and then tried building it. Also after disabling VP8 the full screen bug persists every time I attempt to compile it myself. I'm probably missing something in my environment or something needs to be done other than the things I know of doing. Also should libpng be disabled? I noticed it's disabled by default in that makefile.

BTW, thinking that the issue with the savegames may be because of permissions I attempted to fix them via disk utility but I had done that recently and there was nothing to fix... but I did it anyway just in case. Is eDuke32 programmed to put the savegames in any place other than ~/Library/Application Support/Eduke32/?

Plagman, on 26 September 2011 - 11:04 AM, said:

Helix: can you try forcing on the logic that enables pr_ati_fboworkaround to see if that fixes things? It's possible the Mac driver for NVIDIA has the same behavior as ATI on all platforms.

In a way this reminds me of how on a few games I had to use the nv extension on my ATI card to enable multisampling rather than the ATI extension.

[Searinox Navras]

Having a problem here with EVERY SINGLE BUILD AFTER 2031. Some graphical elements such as the fence on the roof of E1M1 or part of the lefthand gun when holding dual pistols with DukePlus are missing. Reverting to 2031 or prior fixes the issue, no other build after that displays these elements.

Setup: DukePlus 2.30, Win7 x64, GeForce 9600GT, latest HRP and update.

[Plagman]

Yeah, it's a known issue; the fence model has to be fixed, but the flipped models are a legit regression caused by a fix of mine, I'll sort it out soon.

[Hendricks266]

Searinox Navras, on 01 October 2011 - 01:38 AM, said:

Having a problem here with EVERY SINGLE BUILD AFTER 2031. Some graphical elements such as the fence on the roof of E1M1 or part of the lefthand gun when holding dual pistols with DukePlus are missing. Reverting to 2031 or prior fixes the issue, no other build after that displays these elements.

Setup: DukePlus 2.30, Win7 x64, GeForce 9600GT, latest HRP and update.

Helixhorned, on 25 September 2011 - 07:38 AM, said:

The recent face culling change to Polymer breaks many models (I agree that back faces shouldn't be drawn though). Some of them are those that are mirrored, like the left devastator part or the left pistol in DukePlus. Here are a couple of others I noticed:

- keycard hand?
- China vase
- quick foot
- fence, but that's well-known

[Kyanos]

Searinox Navras, on 01 October 2011 - 01:38 AM, said:

Having a problem here with EVERY SINGLE BUILD AFTER 2031.

This is due to a change in how polymer shows models. I feel somewhat responsible for this because the change was made to fix an issue I had with a model I made for WGR2. I will offer to fix the models in DukePlus.

Edit: I was a page behind when I posted, sorry. My offer still stands if it's needed after Plagman sorts this out.

[Plagman]

Everything should be fixed in r2052 except the fence, which is a model problem rather than just flipping causing problems. If you want to fix it, that sounds great to me.

[Plagman]

I also fixed a problem that someone reported where flat sprites didn't always get updated properly when switching global palettes (such as enabling nightvision or going underwater). I couldn't find who was complaining about it, so hopefully he'll find this post.

[Danukem]

Plagman, on 01 October 2011 - 05:14 PM, said:

I also fixed a problem that someone reported where flat sprites didn't always get updated properly when switching global palettes (such as enabling nightvision or going underwater). I couldn't find who was complaining about it, so hopefully he'll find this post.

That was me who complained about it. Thanks!

[Micky C]

This hasn't been mentioned publicly yet I don't think, but Plagman has fixed projected textures so they face the right way, and animate when used with animating textures! Go Plagman!

I modified e1l1 to make an example of the effect, as seen below. However when I tried it out in-game, the angle it was projecting at was further down than it should be, as though it had an extra of -1 when it was supposed to be 80 (this is with revision 2062.)
Can someone verify to see if this works on their system? Edit: it's been fixed now.

Attached File(s)

•  lighttest.zip (30.35K)
  Number of downloads: 494

[Kyanos]

Here is what I see.

[Plagman]

Sorry, my fault. r2057 had a typo that made it useless; this should be fixed with r2063:

[Stabs]

so that spotlight can be made to turn on / off with maphacks?

the shadows and general look is great on yours, do you have special settings plagman?

[Plagman]

Right now it's an SE and not a maphack since Micky attached a whole map, but either way you can't dynamically affect the light. Maphacks lights have something where you can have the light intensity depend on the shade of a sector to turn on and off with light switches, but it's pretty hackish and wouldn't even work in this case. The only way to actually make this work right would be to keep it as an SE and write some CON code, methinks.

[Plagman]

DanM, on 02 October 2011 - 03:48 AM, said:

the shadows and general look is great on yours, do you have special settings plagman?

Nothing but the EDuke32 defaults, I think. IIRC Duke Plus ships with a config that lowers some Polymer perf knobs, including shadow count and resolution so maybe that's why you're seeing lower detail?

[Micky C]

That particular spotlight has a very high shade and hence a narrow angle of projection, which seems to increase it's shadow resolution, which is why the shadows look so good there.

[Plagman]

Right, because the shadow maps each have the same amount of pixels (depending on r_pr_shadowdetail) regardless of how the spotlight looks like. The narrower your spotlight is, the more shadow map pixel density you'll get for a given projection area.

[Stabs]

Well here is how "caustics" is turning out for me

but arnt true caustics where volumetric lights beams are made by the water surface?



sorry about the quality i uploaded a better version the first time but youtube in its greatness decided it should be played at double speed

[Plagman]

Yeah, true caustics would both need an actual distorted water surface and some serious rays calculation. I think what you have works out pretty well for the time being, looks gorgeous as usual!

[Stabs]

ta, you've been doin a bang up job on the renderer lately, iam really happy with it the only things i could use but am quite happy to wait for is volumetric lights and 3d skybox's with the whole 1/16th size thing too

[Mark]

A number of my custom models also get goofed up with the new face culling feature. But if the feature leads to an FPS increase I guess I'll go with the flow and re-work my models. Along with the previously mentioned HUD problems, the knuckle cracking "c'mon" model is also in need of repair.

[Tetsuo]

They where going to get replaced with new models with all the new features like normal maps, etc. anyway right?