[Hendricks266]

The other day TX and I spent a few minutes going through your git history, and almost every commit either was achieved wrong, or is fundamentally misguided.

[icecoldduke]

Hendricks266, on 24 June 2017 - 01:46 PM, said:

The other day TX and I spent a few minutes going through your git history, and almost every commit either was achieved wrong, or is fundamentally misguided.

If you have some specific cases(I'm sure you can find a few), I would love to talk them over. Going forward I think I'm going to create a branch from my main depot for my third episode mod. I'll put the blood and extra things I'm working on there and keep bugs fixes to main.

[Ninjakitty]

icecoldduke, on 24 June 2017 - 01:41 PM, said:

I've been working on some blood splats for Shadow Warrior. There are still some things I have to work around(like the blood hanging off the chair in the screenshot) I'll have them togglable on or off in the main menu. Special thanks to Trooper Dan for letting me use the blood splat assets from Duke Plus.

Sorry, but that's way too dark compared to vanilla
Make sure we have the option to choose between that blood and the regular.

[Ninjakitty]

Also, oddly, the newest update seems not only to have fixed the rocket VS caltrop trick, but it also seems to have added a lot more purple to the barrel of the riot gun. Not quite sure why that's happening

[icecoldduke]

Ninjakitty, on 24 June 2017 - 01:57 PM, said:

Sorry, but that's way too dark compared to vanilla
Make sure we have the option to choose between that blood and the regular.

Could someone make a redder blood splat asset that would fit more with shadow warrior?

[Ninjakitty]

icecoldduke, on 24 June 2017 - 02:01 PM, said:

Could someone make a redder blood splat asset that would fit more with shadow warrior?

To be honest, I think the HRP splats are just fine

*EDIT: Or, you could just tint the splats and brighten them.

[icecoldduke]

Ninjakitty, on 24 June 2017 - 02:05 PM, said:

*EDIT: Or, you could just tint the splats and brighten them.

[Ninjakitty]

icecoldduke, on 24 June 2017 - 02:44 PM, said:

MUCH better!
Maybe increase the contrast a little, too?

[icecoldduke]

Here is a video of it in action. Keep in my mind I'm still learning the codebase(I'm not as good as TX or Hendricks in Build), but I think it shows a lot of promises just requires a lot of tweaking. Some places in this video I think it works well, others...huge fail. Tell me what you think .

[Ninjakitty]

icecoldduke, on 24 June 2017 - 03:16 PM, said:

Here is a video of it in action. Keep in my mind I'm still learning the codebase(I'm not as good as TX or Hendricks in Build), but I think it shows a lot of promises just requires a lot of tweaking. Some places in this video I think it works well, others...huge fail. Tell me what you think .

Looks good, but I don't think the uzi should cause that much blood loss.

And blood should probably cut off at the corners of sectors to avoid it going over the edge.

It also still somehow looks a little too dark. Make sure it's about the same brightness as the original blood.

Still, this is a pretty neat modification!

[Forge]

Ninjakitty, on 24 June 2017 - 03:27 PM, said:

Looks good, but I don't think the uzi should cause that much blood loss.

If they bleed enough to put a gun in their mouth, then mouse support is activated

[Ninjakitty]

Forge, on 24 June 2017 - 07:58 PM, said:

If they bleed enough to put a gun in their mouth, then mouse support is activated

Uh...
I have NO IDEA what that meant...

[icecoldduke]

I fixed a whole bunch of errors with this blood system, its getting close to being usable.

[Ninjakitty]

icecoldduke, on 24 June 2017 - 09:24 PM, said:

I fixed a whole bunch of errors with this blood system, its getting close to being usable.

NOOOO!!!
Stupid touch screen!!!
I accidentally hit - instead of + and it won't let me change it!!!
CURSE YOU, TOUCH SCREEN!!!

[Ninjakitty]

icecoldduke, on 24 June 2017 - 09:24 PM, said:

I fixed a whole bunch of errors with this blood system, its getting close to being usable.

It looks really good, BTW.

[Danukem]

icecoldduke, on 24 June 2017 - 09:53 AM, said:

I have noticed a lot of people reporting bugs when playing the HRP, and during testing I noticed the HRP load times were terrible. In a effort to fix it, I re-wrote all of Ken's image load code(png, tga, etc) which were slow as hell. I did choose to use DevIL as a replacement, and I noticed about 2x speed up in load times. This code is now in the depot.

Hendricks266, on 24 June 2017 - 01:46 PM, said:

The other day TX and I spent a few minutes going through your git history, and almost every commit either was achieved wrong, or is fundamentally misguided.

As an interested observer, I'm confused and a little frustrated when I see this pattern of back-and-forth. I would like to think that icecoldduke is not only building a great SW port but is also making various improvements that can be used in EDuke32. But Hendricks266 and TerminX seem to hate everything he does and I get the impression they think it is all useless.

It doesn't help that the SW port seems to be progressing randomly, without a clear direction (like, why are blood sprites so important all of a sudden?)

[Ninjakitty]

Trooper Dan, on 24 June 2017 - 09:46 PM, said:

As an interested observer, I'm confused and a little frustrated when I see this pattern of back-and-forth. I would like to think that icecoldduke is not only building a great SW port but is also making various improvements that can be used in EDuke32. But Hendricks266 and TerminX seem to hate everything he does and I get the impression they think it is all useless.

It doesn't help that the SW port seems to be progressing randomly, without a clear direction (like, why are blood sprites so important all of a sudden?)

I believe the blood sprites are just an experiment to help him get used to modding SW. They can be toggled on and off. Regardless, they add some nice looking realism to the game.

[TerminX]

Trooper Dan, on 24 June 2017 - 09:46 PM, said:

As an interested observer, I'm confused and a little frustrated when I see this pattern of back-and-forth. I would like to think that icecoldduke is not only building a great SW port but is also making various improvements that can be used in EDuke32. But Hendricks266 and TerminX seem to hate everything he does and I get the impression they think it is all useless.

Unfortunately, random changes without discussion beforehand aren't very useful in the scope of achieving our long term goals with the project. ICD's efforts have helped to identify bugs in the codebase, but I haven't seen anything come out of it that's usable as-is. I don't personally care if he wants to make goofy mods or bolt on random libraries without asking anyone's opinion first, it's just not anything that's useful to us.

[icecoldduke]

Trooper Dan, on 24 June 2017 - 09:46 PM, said:

It doesn't help that the SW port seems to be progressing randomly, without a clear direction (like, why are blood sprites so important all of a sudden?)

Its an effort to help me understand the codebase. There is currently a crash related to spawning and despawning sprites were the game eventually runs out of sprites. I need to understand the codebase and this is my process. I have no documentation on this codebase. There's plenty of documentation on build, but not on this codebase. I have to learn somehow .

TerminX, on 25 June 2017 - 12:22 AM, said:

Unfortunately, random changes without discussion beforehand aren't very useful in the scope of achieving our long term goals with the project. ICD's efforts have helped to identify bugs in the codebase, but I haven't seen anything come out of it that's usable as-is. I don't personally care if he wants to make goofy mods or bolt on random libraries without asking anyone's opinion first, it's just not anything that's useful to us.

I understand where your coming from but again I disagree. The Shadow Warrior code is a fucking mess. It is hacks upon hacks upon hacks. To get this game running, there is no "proper way of doing things". The code is not stable enough to go down that route. I can't ask you guys for permission to do every little thing. If you choose not to take my work that's fine, but I think its the wrong decision. 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" .

The blood shit will go in my 3rd episode branch that I'm making today. I will be working in both "3rd episode branch" and my "main". Code experiments are important. As I'm adding, what are essentially "non essential features", I'm furthering my understanding of the codebase. I can't flush out problems otherwise. Keep in mind, this isn't Duke3D or even Blood, I can count on one hand how many code mods there have ever been for this game.

[icecoldduke]

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. To be clear we are talking about these flags

From http://wiki.eduke32.com/wiki/Cstat

8192 - Sprite will not cast a Polymer shadow
16384 - Sprite will be invisible but will still cast a Polymer shadow

This should have never been implemented as is, because Shadow Warrior uses these bits for:

#define CSTAT_SPRITE_CLOSE_FLOOR    BIT(13) // my def - tells whether a sprite
#define CSTAT_SPRITE_BLOCK_MISSILE  BIT(14) // my def

#define CSTAT_SPRITE_BREAKABLE (CSTAT_SPRITE_BLOCK_HITSCAN|CSTAT_SPRITE_BLOCK_MISSILE)

While the bits below are not fucking up Shadow Warrior, there is a good chance if Redneck Rampage or Blood gets a source release these bits will be a problem as well.

1024 - Sprite will take priority being drawn over other sprites (may be subject to change)
2048 - Sprite will not be forced to take shade of sector

When I started this project monsters would disappear in Polymer and other objects would do weird shit. My original approach to the problem was incorrect, I tried shifting the bits around to see if I could minimize the problem. I couldn't do that because all the other bits were being used for something else(again because you guys added features that rely on cstat bits, that were unused in the original engine, but licensees could use). This is what caused the caltrops rocket bug. I instead went in, put the bits back where they were, and instead just disabled the extra eduke32 features in GAME_SW.

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?

[Mark]

^

Attached File(s)

•  you-go-girl.jpg (27.86K)
  Number of downloads: 5

[icecoldduke]

Anyone who is interested in coding for Shadow Warrior, I am taking more time to update my random notes.txt file in my depot with callstacks for various things.

https://github.com/j...dom%20Notes.txt

[icecoldduke]

I would like to point out I was able to find another crash and fixed it. Inside of DoDamage there was a branch that early exited if the SUMO actor was running. The problem was 3dr didn't check if wp->owner was > 0, so what happened was, the game tried to access an array with a -1 index. This wouldn't always crash. It would only crash if the memory that proceeded the array was protected(aka non allocated memory).

I have also created the ThirdEpisode branch which will house my third episode work.

https://github.com/j...ee/ThirdEpisode

[Forge]

icecoldduke, on 25 June 2017 - 11:39 AM, said:

I would like to point out I was able to find another crash and fixed it. Inside of DoDamage there was a branch that early exited if the SUMO actor was running. The problem was 3dr didn't check if wp->owner was > 0, so what happened was, the game tried to access an array with a -1 index. This wouldn't always crash. It would only crash if the memory that proceeded the array was protected(aka non allocated memory).

Good.
This bug was making it near impossible to get past episode 2's Sumo Sky Palace level.
So hopefully the next binary won't be such a crash-happy annoyance to test.

[Danukem]

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

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?

They already have the mdflags member which does model rendering related stuff, it seems to me the polymer shadow stuff could be moved to there.

[icecoldduke]

Trooper Dan, on 25 June 2017 - 12:29 PM, said:

They already have the mdflags member which does model rendering related stuff, it seems to me the polymer shadow stuff could be moved to there.

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.

[Kyanos]

I for one really like the open manner in which this open source port is being made.

[Danukem]

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

Its an effort to help me understand the codebase. There is currently a crash related to spawning and despawning sprites were the game eventually runs out of sprites. I need to understand the codebase and this is my process. I have no documentation on this codebase. There's plenty of documentation on build, but not on this codebase. I have to learn somehow .

That makes sense, but I don't like to see the constant sniping and the adversarial relationship between you the EDuke32 guys. It was 100% predictable that when you added the blood sprites you were going to get some version of the "goofy mod" comment and other negative judgments that went unsaid. I'm looking at this from the standpoint of someone who will probably keep making Build mods for years to come -- I would hate to see a lot of potential improvements go unrealized because you have a bad relationship with Hendricks266 and TerminX. Right now they seem to perceive you as someone who is invading their turf and acting like a bull in a china shop. For my own selfish reasons, I would like to see this improve. If you get tired of the acrimony and disappear, or if they hate your guts too much to cooperate with you, modders such as myself would miss out on a lot of cool stuff.

[Ninjakitty]

ICD, from now on, when making a change, make the reasons obvious and in a huge font as I seem to be the only actually seeing them.

For example:

*More blood splat sprites
REASON:
To help understand more about the code base.

That way, you can avoid all this confusion.

[icecoldduke]

Ninjakitty, on 25 June 2017 - 01:03 PM, said:

That way, you can avoid all this confusion.

Lol I've been here long enough to know big bold letters won't do anything to stop confusion .

That being said, I do not want to have a bad relationship with Evan and Richard. Its annoying when either one of them say "Ice your doing it wrong", and "I go why?" and never hear anything back. I can also understand people frustration when I go off and add new features instead of fixing bugs. You guys have to keep in mind, I fix bugs during the day at my real job. I have to have a change of pace; this can't feel like a 2nd job for me. I'm doing this because I love the game. I need to figure out the codebase and have fun doing it, following that process, bugs get fixed and I have fun .

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

Quote

Right now they seem to perceive you as someone who is invading their turf and acting like a bull in a china shop

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.