[Plagman]

Yeah, MD2s were transparently converted for a long while now, but didn't have any usable normals information which made them incompatible with Polymer lighting, so we did a one-time conversion of all the MD2s in the HRP we didn't have source materials for (because re-exporting from source is always superior as MD2 has pretty destructive compression, not unlike JPEG).

[Jimmy]

Hendricks266, on 20 September 2011 - 04:31 PM, said:

I side with Plagman on this one. 256 color palette-limited, 256x256x256 KVX files are not the way of the future. They are, however, a defining characteristic of BUILD.

I don't think you quite got what I was saying. I was rather saying that even though voxels are old technology in his eyes, that they were in fact ahead of their time because that's probably what the future of gaming will come down to. It really seems to me that mostly only people before the age of the source code get a lot of stuff like the clamoring for voxels. But whatever, I find Plagman's point of view much clearer in this case, but I hope that sooner than he thinks they can be implemented proper, or at least someone can come up with a good KVX-MD3 converter.

[Hendricks266]

Plagman, on 20 September 2011 - 05:05 PM, said:

I don't understand your concerns about Polymer preprocessing. The MD3 file would still be there, you'd just have to re-process it if you modify it.

Please elaborate on what the preprocessing does; I forgot to ask you that before. As long as the results can be opened by other programs (in other words, so the output files as distributed in the HRP won't be orphaned) then I think that's a great idea.

Plagman, on 20 September 2011 - 05:05 PM, said:

You say your understand my point of view but claim you want the conversion to happen on-the-fly. Please let it be standalone.

I understand it, that doesn't mean I agree with it. I understand that you are worried about the three factors I pointed out in my post:
1. source code bloat
2. waste of CPU time/cycles/electricity for having to re-convert the voxels every playtime
3. unoptimized resulting models
I agree that these factors need to be mitigated for an effect implementation. However, I disagree that their existence should preemptively stop any work on overcoming them. It's my time, I'll waste it as I choose. In any case, a kvx2md3 would be a good thing to have.
(#2 could be solved by implementing a "model cache" if you will, but that has its own disadvantages.)

Plagman, on 20 September 2011 - 05:05 PM, said:

This also bugs me greatly, as lots of people like to jump on that bandwagon. What do you propose as a replacement? What exact benefits would it provide? If you say skeletal animation, that's wrong; you'd implement support for a model format that has skeletal animation _because_ you implemented support for it in the engine beforehand, not the opposite. Implementing MD5 support before a complete rewrite of the animation system would be a step backwards since you'd have to pre-render all the animations to static meshes.

I didn't know any of that, but I'm glad you explained that in a public place. I think the main concern was the loss of bones so modifications are difficult without the source, and sources are lost all the time and withheld too for good reasons.

[Plagman]

Hendricks266, on 20 September 2011 - 06:14 PM, said:

Please elaborate on what the preprocessing does; I forgot to ask you that before. As long as the results can be opened by other programs (in other words, so the output files as distributed in the HRP won't be orphaned) then I think that's a great idea.

The preprocessing does a few differents things:

• It calculates the bounding box information for the models; this is part of the MD3 spec, but none of the exporters actually seemed to correctly fill these members. I assume Quake 3 didn't actually use them, hence the disregard.
  
• It repacks all the geometry from the formats used in MD3 to raw data that can directly and efficiently be fed to a GPU
  
• It calculates the TBN basis for every triangle, which is needed to use tangent-space normal maps

I would probably want this information to be dumped in a companion file to the MD3 model, such that the MD3 file by itself can still be used as-is by other things.

Hendricks266, on 20 September 2011 - 06:14 PM, said:

I understand it, that doesn't mean I agree with it. I understand that you are worried about the three factors I pointed out in my post:
1. source code bloat
2. waste of CPU time/cycles/electricity for having to re-convert the voxels every playtime
3. unoptimized resulting models
I agree that these factors need to be mitigated for an effect implementation. However, I disagree that their existence should preemptively stop any work on overcoming them. It's my time, I'll waste it as I choose. In any case, a kvx2md3 would be a good thing to have.
(#2 could be solved by implementing a "model cache" if you will, but that has its own disadvantages.)

You know what they say: freedom with your own code stops where the freedom of the other dude's code begins. A model cache would essentially be the exact same thing as an offline converter too, just lumped in there for no good reason. I really think a good and efficient suite of tools is the way to go here.

About 3), most of what I was talking about on IRC regarding potential for optimization was based off the assumption that the Polymost code wasn't repacking voxel colors to a texture. I re-read it a few days ago and it does, which means that doesn't really apply anymore. Using the same logic verbatim should pretty much do what we want on the first try.

[Jblade]

MD2s are/were converted at run time to MD3? Or something like that? I guess that explains the terrible start up times I had with IW. I'm assuming converting all of my models to MD3 would then help speed up start times?

[Tea Monster]

Captain Awesome, on 20 September 2011 - 06:00 PM, said:

I don't think you quite got what I was saying. I was rather saying that even though voxels are old technology in his eyes, that they were in fact ahead of their time because that's probably what the future of gaming will come down to.

The future of gaming may use point-cloud technology, but lets be honest about this and admit that you only want to see colored lights on those 64x64(x64) pixel voxels. Saying that the sort of voxels that you want are the future of gaming is like saying that a couple of cavemen with clubs in a dugout canoe is a guided missile cruiser. Polymer should be used for what it was intended so that EDuke32 and Duke Mods in general can move FORWARDS, not backwards. Spending a shed-load of time making a 20 year old game look like a 20 year old game is a waste of time.

[Plagman]

James, on 21 September 2011 - 12:41 AM, said:

MD2s are/were converted at run time to MD3? Or something like that? I guess that explains the terrible start up times I had with IW. I'm assuming converting all of my models to MD3 would then help speed up start times?

They are, yes. That might explain some of it; were you using Polymer at any point? You'd also get the pre-processing pass which is known to take a pretty long time as well. If you have tons of high-res assets and models the startup times generally won't be stellar as all the DEFs are parsed at startup.

[Jblade]

Plagman, on 21 September 2011 - 09:40 AM, said:

They are, yes. That might explain some of it; were you using Polymer at any point? You'd also get the pre-processing pass which is known to take a pretty long time as well. If you have tons of high-res assets and models the startup times generally won't be stellar as all the DEFs are parsed at startup.

I wasn't using polymer but I did notice that startup times increased greatly with 'newer' snapshots (This was last year I'm talking about though, I haven't tried IW with a new version in a long time since it's finished and all)

[Plagman]

"Newer" snapshots had the polymer-preprocessing enabled unconditionally, so that's probably what you were seeing. Helixhorned changed it so it would only perform that pre-processing the first time you enable Polymer with rev 1750. Can you check that any snapshot that's newer than that mitigates your long startup issues?

[Jimmy]

Tea Monster, on 21 September 2011 - 05:52 AM, said:

The future of gaming may use point-cloud technology, but lets be honest about this and admit that you only want to see colored lights on those 64x64(x64) pixel voxels. Saying that the sort of voxels that you want are the future of gaming is like saying that a couple of cavemen with clubs in a dugout canoe is a guided missile cruiser. Polymer should be used for what it was intended so that EDuke32 and Duke Mods in general can move FORWARDS, not backwards. Spending a shed-load of time making a 20 year old game look like a 20 year old game is a waste of time.

Voxels are a feature that have been requested since the beginning of time. Stop being a dumbass, just because you don't want a feature doesn't mean that someone else doesn't value it. You'd have a hell of a fun time trying this shit over in the Doom community.

[Hendricks266]

The new ebacktrace1.dll fails to build for me. http://pastebin.com/gyWyKuPi

[DavoX]

If I offended you in some way or didn't get what you were saying then I apologize Plagman, sorry!

[Tetsuo]

I appear to be having a problem with the savegame function with the lateset build for OS X posted by Helixhorned recently. The full screen is fixed however and the rendering works great for the most part although I did have some slowdown happen if I try to start a new game twice.

[Jblade]

Plagman, on 21 September 2011 - 12:19 PM, said:

"Newer" snapshots had the polymer-preprocessing enabled unconditionally, so that's probably what you were seeing. Helixhorned changed it so it would only perform that pre-processing the first time you enable Polymer with rev 1750. Can you check that any snapshot that's newer than that mitigates your long startup issues?

Just checked IW with a new snapshot and yeah it starts up much quicker than it ever did

But I've noticed that globalsound doesn't seem to work reliably. I use it for cutscene voiceovers and stuff in IW and AMC TC and half the time it doesn't play the sound at all. This bug's been around for some time but I always thought it was my laptop and not an eduke32 issue, but I swear I've seen other people report it as well.

[Helixhorned]

Hendricks266, on 21 September 2011 - 04:47 PM, said:

The new ebacktrace1.dll fails to build for me. http://pastebin.com/gyWyKuPi

Looks like your libbfd.a needs libintl_*printf symbols and can't find them at build time. I have no idea where they reside (did a quick search for them in every *.a file in my mingw install).

Tetsuo, on 21 September 2011 - 05:32 PM, said:

I appear to be having a problem with the savegame function with the lateset build for OS X posted by Helixhorned recently. The full screen is fixed however and the rendering works great for the most part although I did have some slowdown happen if I try to start a new game twice.

Maybe you're mixing up saves of 32 and 64-bit sessions? Just an idea, even if it's a bit far-fetched. What's happening precisely?

James, on 22 September 2011 - 01:01 AM, said:

Just checked IW with a new snapshot and yeah it starts up much quicker than it ever did

But I've noticed that globalsound doesn't seem to work reliably. I use it for cutscene voiceovers and stuff in IW and AMC TC and half the time it doesn't play the sound at all. This bug's been around for some time but I always thought it was my laptop and not an eduke32 issue, but I swear I've seen other people report it as well.

I noticed these sound dropouts too, especially with custom mods. If you're getting this reliably (and reasonably quickly), you could do us a huge favor by attempting to bisect the bug. Just start with some old version X, if that doesn't show the bug, look at version round((newest-X)/2), and so on...

[Jimmy]

I've had the same issue with the regular sound command.

[Tetsuo]

Helixhorned, on 22 September 2011 - 09:22 AM, said:

Maybe you're mixing up saves of 32 and 64-bit sessions? Just an idea, even if it's a bit far-fetched. What's happening precisely?

No well firstly I never loaded an old save but I did notice it hasn't been showing saves properly at all no thumbnails and incorrect level names then I try saving over it and it didn't save. So then I tried removing the old saves to see if it just doesn't like saving over them and saving and it still doesn't work it forgets the savegames the next time I launch it and wont load any.

[Hendricks266]

 Helixhorned, on 22 September 2011 - 09:22 AM, said:

Looks like your libbfd.a needs libintl_*printf symbols and can't find them at build time. I have no idea where they reside (did a quick search for them in every *.a file in my mingw install).

I added "-lintl" to the Makefile entry for ebacktrace1.dll and it compiled after that, but the string "libintl-8.dll" appears in the output leading me to believe it has an unwanted dependency.

[Helixhorned]

 Tetsuo, on 22 September 2011 - 10:11 AM, said:

No well firstly I never loaded an old save but I did notice it hasn't been showing saves properly at all no thumbnails and incorrect level names then I try saving over it and it didn't save. So then I tried removing the old saves to see if it just doesn't like saving over them and saving and it still doesn't work it forgets the savegames the next time I launch it and wont load any.

This is very strange and I can't reproduce it with vanilla Duke savegames. Are you using a mod? I could have a look at the produced savegames if you sent them over.

Speaking of OSX, does anyone else get 'FBO initialization failed' messages? (And subsequently, shadows not rendering.)
Plagman: glCheckFramebufferStatusEXT returns GL_FRAMEBUFFER_INCOMPLETE_READ_BUFFER_EXT for me.

[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.