[Plagman]

And try changing -lsupc++ to -lstdc++

[Tetsuo]

OK I did a spotlight search and I guessed that since makefile.shared showed up you have to change it there and it seems to have worked now. But damn that was not an obvious answer for a programming layman like myself. The only thing is now full screen isn't working... it either kicks to a smaller screen in the bottom corner of my desktop or fails to show up and I only hear music. Also the mouse isn't working....... I tried redownloading the source code and doing the two things recommended here and the mouse works now...

Here's my log:

Spoiler

EDuke32 2.0.0devel rXXXX
Compiled Aug 31 2011 13:54:42
Using /Games/ for game data
Using /Games/EDuke32.app/ for game data
Using /Users/tetsuo/Library/Application Support/EDuke32/ for game data
Initializing SDL system interface (compiled against SDL version 1.2.14, found version 1.2.14)
Using "Quartz" video driver
Searching for game data...
Using 'duke3d.grp' as main game data file.
Using file 'autoload/duke3d.grp/duke3d_sc55.zip' as game data.
Using file 'autoload/duke3d.grp/polymer_hrp.zip' as game data.
Using file 'autoload/duke3d.grp/polymer_upd.zip' as game data.
Compiling: GAME.CON (151190 bytes)
Including: DEFS.CON (35992 bytes)
Including: USER.CON (45482 bytes)
GAME.CON: In actor `ORGANTIC':
GAME.CON:3967: warning: found `else' with no `if'.
GAME.CON: In state `pigshootenemystate':
GAME.CON:5890: warning: found `else' with no `if'.
Found 2 warning(s), 0 error(s).
Resizing code buffer to 16187*8 bytes
Relocating compiled code from to 0x1161cf000 to 0x7f8ad104b600
Script compiled in 13ms, 16179*8b, version 1.4+
1918/11264 labels, 321/2048 variables
125 quotes, 207 actors
Initialized 24.0M cache
Loading 'duke3d.def'
Warning: defined hightile replacement for empty tile 9000. Maybe some tilesXXX.art are not loaded?
Definitions file 'duke3d.def' loaded.
RTS file DUKE.RTS was not found
Initializing OSD...
1 joystick(s) found
1. Logitech Cordless RumblePad 2
Joystick 1 has 4 axes, 12 buttons, and 1 hat(s).
Executing "settings.cfg"
Setting video mode 1920x1080 (32-bpp windowed)
Enabling ATI FBO color attachment workaround.
OpenGL Information:
Version: 2.1 ATI-7.4.10
Vendor: ATI Technologies Inc.
Renderer: ATI Radeon HD 4850 OpenGL Engine
Unable to open cache index: No such file or directory
Initializing Polymer subsystem...
PR : Initialization complete.
Initializing music...
Initializing sound... 96 voices, 2 channels, 8-bit 48000KHz
Load tile 2492: p0-m4-e0 highres/screen/menu/2492_ver.png... 48 ms
Load tile 2493: p0-m4-e0 highres/screen/menu/2493.png... 94 ms
Load tile 3281: p0-m4-e0 highres/screen/menu/3281.png... 82 ms
Load tile 2456: p0-m4-e0 highres/screen/menu/2456.jpg... 36 ms
Load tile 2499: p0-m4-e0 highres/screen/menu/2499.png... 11 ms
Load tile 2503: p0-m4-e0 highres/screen/menu/2503.png... 12 ms
Setting video mode 1920x1080 (32-bpp fullscreen)
Unable to set video mode!
Initializing Polymer subsystem...
PR : FBO #0 initialization failed.
PR : FBO #1 initialization failed.
PR : FBO #2 initialization failed.
PR : FBO #3 initialization failed.
PR : Initialization complete.
PR : Failed to compile GPU program with bits 528449!
PR : Compilation log:

PR : Vertex source dump:

PR : Fragment source dump:

PR : Failed to compile GPU program with bits 528449!
PR : Compilation log:

PR : Vertex source dump:

PR : Fragment source dump:

PR : Failed to compile GPU program with bits 528449!
PR : Compilation log:

PR : Vertex source dump:

PR : Fragment source dump:

PR : Failed to compile GPU program with bits 528449!
PR : Compilation log:

PR : Vertex source dump:

*snip... it goes on ad nauseum for hundreds of lines*



PR : Vertex source dump:


PR %3

OK this seems to only happen when setting the game full screen it fails when I try to do that. On the other hand the long standing bug I had been talking about where sectors outside the one you are in cease to draw showing the skybox after a while seems to have been fixed so that's something.

[Kyanos]

Plagman, I have a model that looks wrong in polymer, but correct in polymost. It only does this when I combine the normal and detail textures. I think it might have to do with a lack of transparency in the normal and detail?
See WGR2 Models thread for download.

[Plagman]

That's because you're trying to set up parallax mapping with huge factors; your height map probably isn't anywhere close to correct looking at these shots.

[Plagman]

To be clear the default factors are non-zero, so if your height map doesn't exist or has garbage in it, you want to manually set parallaxscale to 0.

[Kyanos]

Plagman, on 31 August 2011 - 08:33 PM, said:

That's because you're trying to set up parallax mapping with huge factors; your height map probably isn't anywhere close to correct looking at these shots.

I figured it was something I did. I just wanted to show you in case it was a polymer issue. And the height map came from that crazybump program, so it's probably flawed somehow, they base it from a picture. I will make my own and hope for better results. Thanks Plagman.

[MusicallyInspired]

TX, on 28 August 2011 - 11:31 AM, said:

I guess nobody posted about this here yet, but Plagman fixed the huge problems ATI users were experiencing with Polymer last night. Go Plagman.

Hooray! Congrats, Plagman! Not that it matters to me anymore. I've since upgraded to a NVidia card with no issues at all. But this will be a godsend for people still living under ATI's regime. Thank you for all your hard work!

[Kyanos]

So Plagman, I've come across another issue with the same model as yesterday.

DeeperThought, on 01 September 2011 - 12:50 PM, said:

I did some more testing. The shimmering bug only happens in Polymer. It happens regardless of whether the normal is being used, so the normal is not causing it. Apparently it is a Polymer glitch.

I am attempting to replace a set of fence tiles with this one md3. The model has 2 planes in the center, each facing opposite directions. These two planes are what change for each different sprite via separate skins. This is the area DT is talking about in this quote. Both planes coexist at the exact same location, just a mirrored duplicate. I will try some adjustments on the model. I just wanted to let you know about this because it does work in polymost.

[Mark]

I don't want to turn this into a modeling thread so I will post my response over in the other WGR section. I'm pretty sure I know what the problem is with the model itself.

[Danukem]

Is synthesis taking an abnormally long time to get updated with the latest snapshot? As of this posting, the latest revision in there is r1994.

[Plagman]

A package update on the server broke it for a while; I tried to get it back up earlier today, but failed to fix all the problems. It should be fixed now, the build should be up momentarily.

[Plagman]

And I think that Polymer-specific model problem might just be a symptom of the different backface culling behavior. I'll take a look.

[Kyanos]

Quote

TX, on 28 August 2011 - 02:31 PM, said:
I guess nobody posted about this here yet, but Plagman fixed the huge problems ATI users were experiencing with Polymer last night. Go Plagman.

Thanks Plagman, this fix finally makes polymer playable for me on my laptop

[Tetsuo]

Yeah those fixes also fixed the problem I was having on my eDuke32 although it seems now fullscreen is broken for me for now like I indicated earlier.

[Danukem]

There's a Polymer related bug that no one has reported yet, and I think was recently introduced (I'm not sure how recently, but I started noticing it a few weeks ago...I didn't realize what it was back then and didn't report it).

There is a problem with floor aligned and wall aligned sprites not being displayed with the correct game palette when the game palette changes (e.g. when nightvision goggles are used). I have only seen this happen in WGR2, which has a modified nightvision palette.

-Many wall aligned sprites continue to look normal when the goggles are on, instead of having the altered palette.
-Some floor aligned sprites do have the altered palette when the goggles are on, but then they continue to have it even after the goggles are off.
-In one instance which I haven't been able to replicate, all of the wall aligned wood planks in the map (even those miles away from where the goggles were used) continued to be displayed with the altered palette after the goggles were turned off. Turning goggles on/off again did not fix it. I have a screenshot of this attached.

EDIT: The easiest way to see an example of the bug is to kill some enemies with the rocket launcher while using nightvision ("spirit vision" in WGR2). When you turn them off, some or all of the blood pools will still have the goggle palette.

Attached thumbnail(s)

• 

[Jblade]

anyway to disable Mapster32 spamming it's console with map corrupt errors? It's telling me every level I load has corruptions in it and I've lost track of what keys I have to press to try and fix it or what console commands to use.

[Mike Norvak]

James, on 05 September 2011 - 01:49 PM, said:

anyway to disable Mapster32 spamming it's console with map corrupt errors? It's telling me every level I load has corruptions in it and I've lost track of what keys I have to press to try and fix it or what console commands to use.

Yeah is kinda annoying, anyways you can enter this on the console: corruptcheck tryfix

[Danukem]

Norvak, on 05 September 2011 - 05:40 PM, said:

Yeah is kinda annoying, anyways you can enter this on the console: corruptcheck tryfix

Is there any possibility of that raping the map? It scares me. I just did it on a map, and it changed literally hundreds of sectors. Here's a sample:

 -> auto-correction: reset sector 11's ceiling slope
 -> auto-correction: reset sector 12's ceiling slope
 -> auto-correction: reset sector 13's floor slope
 -> auto-correction: reset sector 14's floor slope
 -> auto-correction: reset sector 15's ceiling slope

The map looks fine, but it's huge and I may have missed something.

[Fox]

I am not sure, but it seems for that is imply removed the slope cstat from sectors with a slope value of zero.

[Micky C]

I think it's to do with a bug that potentially caused slopes sectors to reset their slope to zero, and corruptcheck tryfix prevents that.

[rasmus thorup]

maybe it could have something to do with floorstat and ceilingstat. Maybe if it resets the stat quickly, then the floor or ceiling automaticly sets heinum to zero when the statnum 2 is not set.

[Danukem]

Fox, on 05 September 2011 - 06:25 PM, said:

I am not sure, but it seems for that is imply removed the slope cstat from sectors with a slope value of zero.

That sounds plausible. But that's so minor it shouldn't be considered "corruption". The game could easily fix that at map load time, anyway.

[Helixhorned]

There are two pieces of information about the slope of a ceiling or floor that are stored for each sector: ...heinum determines the amount of the slope, but ...stat's bit 2 determines whether it's drawn (and collision-handled) as a slope at all. If the two are inconsistent, mild annoyances may occur in the editor. I didn't make it run at load-time for the unlikely case that some clever person used heinum as an additional tag.

[Danukem]

Helixhorned, on 06 September 2011 - 01:05 PM, said:

I didn't make it run at load-time for the unlikely case that some clever person used heinum as an additional tag.

Is having inconsistencies between stats and heinum safe, or is it not safe? If it's not safe, then I don't see why the inconsistency needs to be allowed for the sake of a possible tag, especially when there are other ways to achieve the same result (moreover, I doubt that anyone has actually used it that way or plans to). If it is safe, then it's not what should be considered "corruption". When mapster reports "corruption", that sounds very serious; it's too bad there's no easy way to tell how serious the corruption actually is without having a lot of technical knowledge.

[Helixhorned]

OK, point taken. What I'll do then is to collapse all such instances into one. The slope inconsistencies are absolutely harmless, and there is a way to judge the severity of the others: every one has a 'corruption level', which should be read like this:
5 -- run for your life (clearly invalid values that can lead to a crash)
4 and 3 -- very serious and serious
2 and 1 -- warnings
Right now, only the maximum is reported though.

[ReaperMan]

So is there any chance of polymer getting voxel support?

[TerminX]

No, not really.

[ReaperMan]

TX, on 11 September 2011 - 02:46 PM, said:

No, not really.

[Hendricks266]

ReaperMan, on 11 September 2011 - 01:29 PM, said:

So is there any chance of polymer getting voxel support?

TX, on 11 September 2011 - 02:46 PM, said:

No, not really.

[Jimmy]

Well that's a bummer. I have no reason to develop my projects with polymer in mind.