[Ninjakitty]

Anyway, every once in awhile, seemingly only after I beat most of the level, the caltrop VS missile glitch still happens, but only once.

[icecoldduke]

Does anyone know how to scale the floor and ceiling textures in mapster?

[Ninjakitty]

icecoldduke, on 25 June 2017 - 01:35 PM, said:

Does anyone know how to scale the floor and ceiling textures in mapster?

LOL
Same as old DOS build, Page Up and Page Down

[icecoldduke]

Ninjakitty, on 25 June 2017 - 02:04 PM, said:

LOL
Same as old DOS build, Page Up and Page Down

That moves the floor or ceiling up or down. I'm looking for how to scale the texture on the floor or ceiling .

[Hank]

icecoldduke, on 25 June 2017 - 02:08 PM, said:

That moves the floor or ceiling up or down. I'm looking for how to scale the texture on the floor or ceiling .

Point towards the ceiling/floor and Press E, no scale per se available

back to my holiday

[Ninjakitty]

icecoldduke, on 25 June 2017 - 02:08 PM, said:

That moves the floor or ceiling up or down. I'm looking for how to scale the texture on the floor or ceiling .

Oh, NVM, then

[Forge]

icecoldduke, on 25 June 2017 - 01:15 PM, said:

I'm not sure what I can do about this. If they believe I'm "invading there turf", I want to fix that, but I don't know how.

They're working on Deadly Kiss.
I'm going to assume they are also working on their own version of a port.

So that means their 'secret' work and your 'public' work are at odds with each other.
They can freely nitpick at you, but don't want to show their cards.
Like they're trying to steer you towards doing things they can use, without actually telling you any specifics.

Could be wrong, but that would be one perspective.

[Hank]

Forge, on 25 June 2017 - 02:25 PM, said:

They're working on Deadly Kiss.
I'm going to assume they are also working on their own version of a port.

So that means their 'secret' work and your 'public' work are at odds with each other.
They can freely nitpick at you, but don't want to show their cards.
Like they're trying to steer you towards doing things they can use, without actually telling you any specifics.

Could be wrong, but that would be one perspective.

http://dukeworld.duk...ke32/synthesis/
EDuke32 with its Shadow Warrior section is coded in public. Hell, even I can open it in VS

[Master O]

Forge, on 25 June 2017 - 02:25 PM, said:

They're working on Deadly Kiss.
I'm going to assume they are also working on their own version of a port.

So that means their 'secret' work and your 'public' work are at odds with each other.
They can freely nitpick at you, but don't want to show their cards.
Like they're trying to steer you towards doing things they can use, without actually telling you any specifics.

Could be wrong, but that would be one perspective.

That doesn't sound very helpful. Logic dictates that both sides should combine their efforts.

[TerminX]

icecoldduke, on 25 June 2017 - 04:44 AM, said:

The Shadow Warrior code is a fucking mess. It is hacks upon hacks upon hacks.

And you thought it would be a good idea to add more hacks on top of that? It's hard to take you seriously when you go and bolt on huge third party libraries to load images, in an effort to improve speed, without even noticing your texcache is broken.

We agree that the cstat bits were a bad idea, though!

Forge, on 25 June 2017 - 02:25 PM, said:

I'm going to assume they are also working on their own version of a port.

Our only port at the moment is the broken one in our tree that ICD used as a base. We just don't want to see one full of odd or outright bad decisions spur a bunch of activity and user content that requires these bad decisions be maintained as baggage later... like our cstat bits.

[icecoldduke]

TerminX, on 25 June 2017 - 02:55 PM, said:

And you thought it would be a good idea to add more hacks on top of that? It's hard to take you seriously when you go and bolt on huge third party libraries to load images, in an effort to improve speed, without even noticing your texcache is broken.

Is there a reason why your against using a faster library for loading images? Can we at least agree Ken's image loading code is fucking terrible?

[Forge]

TerminX, on 25 June 2017 - 02:55 PM, said:

Our only port at the moment is the broken one in our tree that ICD used as a base. We just don't want to see one full of odd or outright bad decisions spur a bunch of activity and user content that requires these bad decisions be maintained as baggage later... like our cstat bits.

Yeah. What I posted and what I meant didn't really translate well.

I was speculating that Evan is working slowly and methodically on that port - and he only releases commits after extensive testing and re-testing.
So he has his own version with his own changes (major or minor) in a holding pattern until he feels comfortable enough to update it and move on to the next piece of code.


The rest of my offhand comments still stand though.
Is there some kind of coders-envy thing going on? It's like you guys enjoy throwing rocks, but don't really offer any specific pointers until you want to rub his nose in his mess. (e.g. finally getting around to telling him his texcache is broken)

[TerminX]

icecoldduke, on 25 June 2017 - 03:03 PM, said:

Is there a reason why your against using a faster library for loading images? Can we at least agree Ken's image loading code is fucking terrible?

It's extra baggage and I'm not even sure if the library in question is compatible with our licensing, or if all of the libraries it uses are. Are you testing without optimizations or something? A lot of our code more or less requires them be enabled to perform at a reasonable speed, by design. I can load the entire Duke3D HRP at startup in around 4 seconds on an AMD processor from 2012 so I don't see what the problem is. I don't think Ken's code is that bad--it successfully loads the most popular and common formats without any external library dependencies.

[Forge]

icecoldduke, on 22 May 2017 - 07:48 AM, said:

Hey guys,

As many of you know I'm back and hooking up the Shadow Warrior codebase to Eduke32. What I've also touched on is creating a new episode for Shadow Warrior. I want to focus on making gameplay, with the exception of redueing the panel(status bar) code. I want to make new weapons, and the code is not as malleable as I would like. Termit has graciously given me permission to include the HD status bar assets from Redux in the project. On my GitHub these assets will be located in swhd/redux/*.*. I have received permission for non commercial useage of these assets. If anyone else would like to use these assets, I would contact Termit directly. Thanks again Termit!!

So is ICD supposed to be making an 'official' eduke32 port for SW, or is he working on his own special edition port for his planned mod?

[Hendricks266]

icecoldduke, on 25 June 2017 - 04:44 AM, said:

Evan said you guys went through my github and hate everything. It would help if you guys would give more feedback then "it just sucks" .

It is not worth the time to give you feedback because we tried during PolymerNG's development and you don't show any signs of "getting it" on your own any time soon. Furthermore, even if I choose to help you sometimes, it would be counterproductive because improvements to your port will encourage its adoption, even in spite of other glaring issues I would not have addressed. To address them all is for me to do the work myself.

icecoldduke, on 25 June 2017 - 05:00 AM, said:

Let me start this off.

TerminX and Hendricks added extra features to the build engine that used "unused bits in cstat". This was a terrible idea, because those bits were only unused in Duke3D.

I never added any such thing, but you should add Helixhorned and Plagman to that list. I've been aware of this problem since I worked on SW in 2014, and let me tell you that it is not the only thing that makes reconciling JFSW with our engine difficult. Many changes were made in various places, particularly by Helixhorned, which at least make breaking API changes with all other Build games, and at most seem to treat the engine like it exists solely for Duke 3D.

icecoldduke, on 25 June 2017 - 05:00 AM, said:

One way to solve this problem is to add more bits to cstat and doing that with Shadow Warrior will be a huge undertaking. The problem is the game bashes cstat all the time.
If I change cstat in SPRITE to 32 or 64bits internally, the game will bash cstat back down to 16bits because the game changes cstat all the time and immediately reverts it back(the game stores these backup vars as 16bits). It would be huge undertaking, and in my opinion a almost impossible task to go down that route. Instead we should have a new sprite struct, that deals with these extra features in EDuke32(such as toggling shadows in polymer). What do you think Evan?

It's good that you identify the problem, and your solution has some merit, but I can't even begin to discuss the tradeoffs of various ideas without talking at length about our roadmap. There are two separate problems here.

The first is getting SW to work with our engine. Much like SW overloaded cstat bits that Ken did not use, we need to treat EDuke32's new bits as applying to Duke 3D and its maps only. There is a fairly involved engine change we would like to make, where the engine and the game have separate copies of the map structures that aren't necessarily the same, and the game converts from its form to the engine's form every frame. In this way, Duke 3D could mask out the bits and put them somewhere else (probably tspr.extra or .clipdist). SW could also mask out its bits. The full list of features that would depend on this are:

Letting mappers make TROR Duke 3D maps without clobbering sector and wall members like x/ypanning
Shadow Warrior support (cstat bits)
Tekwar and Witchaven 1/2 support (v5 game state, v7 engine state)
Duke Nukem 64 mod performance (adjusting what the renderer sees without needing to reset it back every frame to avoid game logic being affected)
Shrinking the tspr struct by removing unused members toward the end to save memory and increase performance.
Splitting the game loop and the renderer into separate threads
[unannounced project]

That's just what I can think of as of this post.

The second problem is finding a clean way to expose this functionality to other Build games. We have plans and designs for a text-based map format, which could work for this. For now, thinking about exposing these features is too speculative, and it should not be worked on.

icecoldduke, on 25 June 2017 - 12:40 PM, said:

For Shadow Warrior I'll move all the eduke32 cstat bits over there. I imagine TX and Hendricks can't do that for Duke3D since its possible you guys have made maps using the new cstat flags.

Don't touch spriteext. Similar to those cstat bits, it's something I would like to move solely into Duke 3D's code to keep compatibility but drop baggage for everything else, since it mostly deals with 3D models, and even the features it has are naive.

Also, forking the engine is unacceptable. You're fighting fire with fire, and that's not what we need here. I can understand having the engine mask out those cstat bits as a stopgap, but not much else.

icecoldduke, on 25 June 2017 - 01:15 PM, said:

So please bear with my process. I'm still hopeful Evan and Richard will take my code at some point.

There's no way in hell. It's fundamentally broken.

icecoldduke, on 25 June 2017 - 01:15 PM, said:

I'm not sure what I can do about this. If they believe I'm "invading there turf", I want to fix that, but I don't know how.

It's not about territoriality. Otherwise, we wouldn't have given BloodGDX a subforum. You're making our lives harder.

Forge, on 25 June 2017 - 03:08 PM, said:

I was speculating that Evan is working slowly and methodically on that port - and he only releases commits after extensive testing and re-testing.
So he has his own version with his own changes (major or minor) in a holding pattern until he feels comfortable enough to update it and move on to the next piece of code.

You can consider whatever I've committed as the current state of progress. Anything not committed would be tests and experiments from 2014 that weren't suitable for pushing when I did so in 2015, and these likely would not cleanly apply to the current code anyway.

There is also something to be said for "work" that needs to be done in my head as far as decision making, not just actual changes to the code.

I believe I've mentioned this before, but many things in the code would either take some work to build up to work as a duplicate copy of Duke's code, or 1.5x-2x the work to factor existing code out into one system that will work everywhere and can be more easily maintained and augmented.

A list of just what I've written in my notes:
startup windows
GRP scanning
OS path handling
Steam & GOG install detection
input systems
ANM files
RTS files
cfg files
cvars

I would not want to enable synthesis builds until these are covered to avoid any perception of my port being broken.

There is another Build game that is getting all of my attention right now, and it's not one mentioned in this post.

[Hank]

Forge, on 25 June 2017 - 03:25 PM, said:

So is ICD supposed to be making an 'official' eduke32 port for SW, or is he working on his own special edition port for his planned mod?

No one is asking to make an official port for SW. What seems to be asked here is: Since you are working on one, why not follow our lead.

[Danukem]

Hendricks266, on 25 June 2017 - 03:52 PM, said:

even if I choose to help you sometimes, it would be counterproductive because improvements to your port will encourage its adoption

Hendricks266, on 25 June 2017 - 03:52 PM, said:

There's no way in hell. It's fundamentally broken.

So your strategy is: make icecoldduke know that he is unwelcome, and hope that he eventuallly goes away. That might work, or it might not. Here's the problem you have: something always beats nothing. No matter how flawed his approach is, his port is something. And it will get better. He works hard and he has a fast work-rate. He is learning. If he is motivated enough to endure all the criticism, he will eventually emerge with something that --as far as players and modders are concerned-- is pretty darned good. Then you will be remembered --perhaps unfairly-- as the bitter naysayer who was proved wrong. I'm not saying this because I'm taking a side. I have every reason not to. But it's obvious to outside observers that your emotions are getting the better of you and I don't think that serves your interests or the those of the community.

[Forge]

Hank, on 25 June 2017 - 04:20 PM, said:

No one is asking to make an official port for SW.

that's the point
all the criticisms with no helpful content can be summed up with that one simple observation

[TerminX]

Trooper Dan, on 25 June 2017 - 04:23 PM, said:

Here's the problem you have: something always beats nothing.

I disagree. ICD has a long history of abandoning projects and I don't personally feel like this project is still going to be around 6 months from now. We really can't work with him if he just does whatever he wants without consulting the people who have maintained the engine for over a decade.

If he really wanted to work with us, he could just as easily do things our way and submit patches that work towards our goals and not against them. Evan did most of the work rebasing SW against our engine and I completely understand why he would be against someone taking that unfinished work and making a bunch of changes to it that he doesn't agree with. The kind of things ICD has been working on are things that shouldn't even be on the radar until people can actually play the game through to completion. That's a big problem... he just wants to work on whatever the hell he wants to work on rather than the things that seriously need the attention.

But hey, why fix crashes when you can bolt on Lua and mod in blood splats, right?

[Hank]

Forge, on 25 June 2017 - 04:49 PM, said:

that's the point
all the criticisms with no helpful content can be summed up with that one simple observation

No, this is not my point!
Someone is making a Shadow Warrior port, using existing EDuke32 code. Now, after a few sardonic comments, the EDuke32 team are the bad guys? Coorporation works two ways!

[yes, honey I'm shutting down .... I better shut my comp for good, internet is as addictive as coke ]

[Mark]

I'm assuming then that a decision was made long ago that its better to go through years of a slow and frustrating process to get all Build games to run under Eduke32 as opposed to faster separate projects? Since we don't do the work its easy for some of us to say we want faster separate projects.

Its problems enough trying to keep Eduke32 backwards compatible and bug free. Now imagine doing it for code, maps and mods for all Build games. I worry compromises will need to be made. And after hearing so many times how jumbled our code is now, how much worse is it going to get with an all-in-one solution? And having to rely on just 1 or 2 people to maintain this new mountain of code gives me the willies. If we get another exit like Helix or Plagman we will be left hanging with bugged multiple games instead of just duke3d.

Like Trooper Dan I'm in this for years to come. I'll wait if I have to but would prefer separate projects if given a choice. My opinion is based on a total lack of the behind the scenes technical goings on.

In summation, I don't want the devs to bite off more than they can chew.

[TerminX]

Mark., on 25 June 2017 - 05:00 PM, said:

I'm assuming then that a decision was made long ago that its better to go through years of a slow and frustrating process to get all Build games to run under Eduke32 as opposed to faster separate projects? Since we don't do the work its easy for some of us to say we want faster separate projects.

Its problems enough trying to keep Eduke32 backwards compatible and bug free. Now imagine doing it for code, maps and mods for all Build games. I worry compromises will need to be made. And after hearing so many times how jumbled our code is now, how much worse is it going to get with an all-in-one solution? And having to rely on just 1 or 2 people to maintain this new mountain of code gives me the willies. If we get another exit like Helix or Plagman we will be left hanging with bugged multiple games instead of just duke3d.

Like Trooper Dan I'm in this for years to come. I'll wait if I have to but would prefer separate projects if given a choice. My opinion is based on a total lack of the behind the scenes technical goings on.

In summation, I don't want the devs to bite off more than they can chew.

After the SW port is properly working it won't be too much more difficult to maintain than Duke3D already is. It's just a matter of keeping it up to date with any engine API changes we make, etc. The code is already in our tree and already implemented into our Makefiles, so keeping it up to date isn't nearly the hassle you imagine. Back when JFDuke3D was a thing I used to merge changes to that into EDuke32 by hand.

[icecoldduke]

TerminX, on 25 June 2017 - 04:51 PM, said:

...

I would agree you guys are the best at the build engine. No question there. To my knowledge, you have very little experience in the Shadow Warrior codebase. Neither Evan or yourself has made Shadow Warrior gameplay code mods. This isn't a diss on you, its just a fact, we are all on even footing on this one. Wether or not my project gets mass adoption or yours does, I frankly don't care. If at the end of day my contribution to this community is making the codebase more understood then it is now; then I have accomplished something huge.

Lets talk about DevIL. Yes I missed the cache system. Mistakes happen, lets more forward. The eduke32 engine is a mess code wise. I wish my assessment of the code was better, but frankly its not maintainable. Wether or not DevIL was a positive move from a production standpoint is more then just "does it actually help load times". It helps to make the code be more readable, which makes it easier to maintain. I tried going through the code this weekend to see if I could add FBX support. I forgot how much of a mess the entire model loader is. Its beyond convoluted. In order to get FBX support into the engine, I have to re-write the entire model loader. I suspect you guys already know that, or you would have added new model formats a long time ago.

I have identified and fixed numerous issues in the Shadow Warrior code. All these issues are still in your code right now. It's not productive for us to be fighting. It serves no purpose. So how do we make this right?

[Danukem]

TerminX, on 25 June 2017 - 04:51 PM, said:

If he really wanted to work with us, he could just as easily do things our way and submit patches that work towards our goals and not against them. Evan did most of the work rebasing SW against our engine and I completely understand why he would be against someone taking that unfinished work and making a bunch of changes to it that he doesn't agree with.

I do understand that and I would not like it either if I were in Evan's position. But clearly, icecoldduke is not willing to do things your way. For what it's worth, I do not believe he is deliberately being antagonistic to your goals. I think what's happening is that he has to toe the line at his job, and this is his opportunity to do whatever the fuck he wants and not follow the rules of a gameplan that has been set out for him by someone else, so he is taking advantage of that.

TerminX, on 25 June 2017 - 04:51 PM, said:

The kind of things ICD has been working on are things that shouldn't even be on the radar until people can actually play the game through to completion. That's a big problem... he just wants to work on whatever the hell he wants to work on rather than the things that seriously need the attention.

You say it's a big problem, but what if his whimsical and seemingly haphazard workflow actually keeps him motivated to work at a high rate, and he eventually does get to those bugs etc? Time will tell.

[TerminX]

icecoldduke, on 25 June 2017 - 05:17 PM, said:

its just a fact, we are all on even footing on this one.

What? It's bolted on to engine code we've written and maintained since 2004! Even footing my ass.

Quote

Lets talk about DevIL. Yes I missed the cache system. Mistakes happen, lets more forward. The eduke32 engine is a mess code wise. I wish my assessment of the code was better, but frankly its not maintainable. Wether or not DevIL was a positive move from a production standpoint is more then just "does it actually help load times". It helps to make the code be more readable, which makes it easier to maintain. I tried going through the code this weekend to see if I could add FBX support. I forgot how much of a mess the entire model loader is. Its beyond convoluted. In order to get FBX support into the engine, I have to re-write the entire model loader. I suspect you guys already know that, or you would have added new model formats a long time ago.

The engine definitely has maintainability issues. The correct answer to them is to have discussion and vet the variety of possible solutions, not make haphazard decisions that leave the guys who did most of the work raising their eyebrows.

Quote

I have identified and fixed numerous issues in the Shadow Warrior code. All these issues are still in your code right now. It's not productive for us to be fighting. It serves no purpose. So how do we make this right?

You're right, you have identified and fixed a bunch of issues in SW, and those issues are still in our code. Unfortunately, many of your fixes involved questionable changes which lead us back to needing to discuss and vet solutions. Why don't you start by identifying the simplest way to fix those problems without incurring a slew of other changes, and submit those to us as a patch? That would be helpful.

[icecoldduke]

TerminX, on 25 June 2017 - 05:26 PM, said:

What? It's bolted on to engine code we've written and maintained since 2004! Even footing my ass.

The similarities with Shadow Warrior and Duke3D end at they share the same engine. GameCode != Engine code. Do you disagree with that? If so can you elaborate?

TerminX, on 25 June 2017 - 05:26 PM, said:

The engine definitely has maintainability issues. The correct answer to them is to have discussion and vet the variety of possible solutions, not make haphazard decisions that leave the guys who did most of the work raising their eyebrows.

I agree but if we could talk about why your "raising eyebrows" at deprecating Kens image loading code?

TerminX, on 25 June 2017 - 05:26 PM, said:

You're right, you have identified and fixed a bunch of issues in SW, and those issues are still in our code. Unfortunately, many of your fixes involved questionable changes which lead us back to needing to discuss and vet solutions. Why don't you start by identifying the simplest way to fix those problems without incurring a slew of other changes, and submit those to us as a patch? That would be helpful.

Where do you want to start?

[TerminX]

icecoldduke, on 25 June 2017 - 05:30 PM, said:

The similarities with Shadow Warrior and Duke3D end at they share the same engine. Do you disagree with that? If so can you elaborate?

Maybe the engine is much more ingrained in the games than you think. It's not as different as, say, two programs that happen to use the same libraries. When I look at the source code to any Build game it's almost immediately clear what is going on with most things.

Quote

I agree but if we could talk about why your "raising eyebrows" at deprecating Kens image loading code?

It didn't need to be deprecated. It's a solid, all-in-one solution that needs little to no maintenance. You've replaced it with a giant library that loads dozens of useless formats, seemingly uses a ton of additional libraries itself, and becomes its own additional maintenance work. I hope none of those formats it loads have patent issues or exploitable flaws!

Quote

Where do you want to start?

With what I said... send us patches to fix the crashes you've mentioned. Hell, send us patches to get our build system to produce a working SW binary if you want. If they're good, we'll accept them. If they're not, I'll tell you what's wrong with them and what would need to change. We have ways of doing things, and if you want to work together you can't just shit all over them and replace them with whatever you like. I am not a difficult person to work with if you're willing to play ball.

[icecoldduke]

TerminX, on 25 June 2017 - 05:44 PM, said:

Maybe the engine is much more ingrained in the games than you think. It's not as different as, say, two programs that happen to use the same libraries. When I look at the source code to any Build game it's almost immediately clear what is going on with most things.

You are very wrong, but don't take that statement as accusatorial(I just can't phrase my objection any other way). The fact is simple: going between games that use the same engine does not mean you understand the game code. You can look at how the game calls the engine code and immediately see what the game is doing, but that's as far as your logic goes.

TerminX, on 25 June 2017 - 05:44 PM, said:

It didn't need to be deprecated. It's a solid, all-in-one solution that needs little to no maintenance. You've replaced it with a giant library that loads dozens of useless formats, seemingly uses a ton of additional libraries itself, and becomes its own additional maintenance work. I hope none of those formats it loads have patent issues or exploitable flaws!

Why is Ken's PNG loader better(and safer) then libpng? Keep in mind libpng was developed by the developers that created the png format. Same with the JPEG loader, why is Ken's code better then libjpeg(also created by the developers of the jpg format)? DevIL is just a frontend that deals with the original developer libraries. Using the developers image load libraries is so much more reliable, safer, and a better approach then custom, half assed solutions; which is what Kens loader was.

TerminX, on 25 June 2017 - 05:44 PM, said:

With what I said... send us patches to fix the crashes you've mentioned. Hell, send us patches to get our build system to produce a working SW binary if you want. If they're good, we'll accept them. If they're not, I'll tell you what's wrong with them and what would need to change. We have ways of doing things, and if you want to work together you can't just shit all over them and replace them with whatever you like. I am not a difficult person to work with if you're willing to play ball.

I personally didn't say you were difficult. I can't vouch for the rest of these fucks, but those words never came out of my mouth . I just disagree with some of your logic and would like to talk it over. Really that's it.

[TerminX]

Ken's kplib is better because it's one source file and one header, and safer because anything that exploited it would have to explicitly target it. The second point isn't a realistic reason to prefer it over something else, but the first definitely is.

And no, I'm not wrong about understanding the SW source. I've looked at a lot of it. Other than the odd formatting, it's fairly well written--I'm really a fan of how everything is #defined instead of using hard-coded magic numbers everywhere. Some of the macros from the SW source are even in EDuke32, because I put them there. To say we have no understanding of the SW source when you're talking about code in our own source tree and build system is pretty far out there.

[icecoldduke]

TerminX, on 25 June 2017 - 06:27 PM, said:

Ken's kplib is better because it's one source file and one header, and safer because anything that exploited it would have to explicitly target it. The second point isn't a realistic reason to prefer it over something else, but the first definitely is.

Its not maintainable. There is no other way to say it. Can you explain how that loader works? If there was a bug in it, could you or Evan go in and fix it? How long would it take you to find the bug?

I would trust a library that is being maintained by numerous talented engineers over the past twenty years, then anything custom made in house(not knocking you guys, but you can't argue the ISV libraries have more dev hours on them, then Kens code). If its security your worried about Richard, remember I have a unique view on stuff like this .

TerminX, on 25 June 2017 - 06:27 PM, said:

And no, I'm not wrong about understanding the SW source. I've looked at a lot of it. Other than the odd formatting, it's fairly well written--I'm really a fan of how everything is #defined instead of using hard-coded magic numbers everywhere. Some of the macros from the SW source are even in EDuke32, because I put them there. To say we have no understanding of the SW source when you're talking about code in our own source tree and build system is pretty far out there.

We will agree to disagree on this, moving forward on this particular topic is pointless and doesn't get us anywhere.