FLATSPRITE discussion

[DBThanatos]

I will admit i know nothing of the technical stuff of implementation or anything like that, but this feature has been quite handy for the effects major cooke showed above.

The half life styled beams and lightning are a never seen type of effect in gzdoom. It'd be a shame to lose the ability to use them.

Again, i dont understand why are they a problem since i dont understand one drop of the technical stuff behind it so it's not like im trying to be a pain in the ass, but for what i kinda got from the post, this is never meant to be possible? Then im missing what was the point of flat sprites if crazy experimentation and pushing their usage wasn't intended. Was it really only just to put a sprite in a wall?

[Major Cooke]

LINK

[Rachael]

I will admit i know nothing of the technical stuff of implementation or anything like that, but this feature has been quite handy for the effects major cooke showed above.

The half life styled beams and lightning are a never seen type of effect in gzdoom. It'd be a shame to lose the ability to use them.

Again, i dont understand why are they a problem since i dont understand one drop of the technical stuff behind it so it's not like im trying to be a pain in the ass, but for what i kinda got from the post, this is never meant to be possible? Then im missing what was the point of flat sprites if crazy experimentation and pushing their usage wasn't intended. Was it really only just to put a sprite in a wall?

The problem was the maintenance overhead that the code created. I do believe this effect can still be done, but the code needs to be simplified and redone from scratch.

Next time, before you make a submission, have dpJudas or Blzut3 review it and critique it before Graf ever sees it, if they have time. They might give a few pointers (pun not intended) on how they would handle it to avoid problems like this in the future. Also - these things should be thoroughly tested before they reach the "pull request" phase - and not just with a simple lightning gun - because while Github may have intended that to be the review phase it's also just courtesy to make sure your code is as clean as possible and actually works.

I will not speak for Graf on this - but I do believe the reason why this code got removed was because it was not "release-ready" and he is getting ready to do a release soon. MC can still revert the commit that caused the removal in his own personal branch and continue working on this, until then.

For the next release, I suggest making models for the lightning gun and just sticking with that for now until you can get this working.

[Major Cooke]

Next time, before you make a submission, have dpJudas or Blzut3 review it and critique it before Graf ever sees it, if they have time. They might give a few pointers (pun not intended) on how they would handle it to avoid problems like this in the future. Also - these things should be thoroughly tested before they reach the "pull request" phase - and not just with a simple lightning gun - because while Github may have intended that to be the review phase it's also just courtesy to make sure your code is as clean as possible and actually works.

1. This was submitted an entire year before it was accepted. It took Graf that long to finally get around to it because he even admitted he forgot its existence. dpJudas wasn't even around that time, and it was accepted a few months ago.
2. I did have Blzut try and take a look at it but he said he had no idea what to think of it because it wasn't his area of expertise.
3. This was a culminative effect of fgsfds, marrub, Nash's and my own efforts to make this work. I admit I'm responsible for FLATSPRITES and DONTFLIP. I based it off of those rolling sprite to make it work.
4. If they don't feel obligated to do so regardless (to look into the code), then what?

[Rachael]

It's pointless to argue with me about it - I have no say over what Graf does. As to your points, most are just answered with this: Fork it. As far as dpJudas not being around then, he is around now, so there's that.

[Major Cooke]

I asked him for help but he had no idea either. And, I did, and I will continue to do so. But that means things like mac/linux users are in trouble.

[Major Cooke]

Also thank you for splitting this so it maintains notice.

Now... Graf, I don't mind if DONTFLIP is out for now and stuff. I suppose for now we'll just rely upon the September 3 build until something comes around from this. Will it be possible to perfectly replicate this EXACTLY as it was with the flatsprite behavior, including pitch tilting, once its been overhauled?

[Rachael]

I asked him for help but he had no idea either. And, I did, and I will continue to do so. But that means things like mac/linux users are in trouble.

Sorry, I don't know, then. There are other OpenGL programmers out there, though (or else OpenGL wouldn't be a thing) - it shouldn't be altogether hard to find one who can help you with it. Reach out to people on Facebook, Twitter, your work, your school - where ever you can, it doesn't matter, as long as they know enough about OpenGL that they can help you. Hell - you probably could've gone to Zandronum and sent a message to Torr Samaho. He's usually pretty helpful with things like this when he has the time.

Also thank you for splitting this so it maintains notice.

That wasn't the reason I split it, but you're welcome. Graf just doesn't like these discussions to carry on in the Bugs section.

[dpJudas]

Next time, before you make a submission, have dpJudas or Blzut3 review it and critique it before Graf ever sees it, if they have time.

I'm really a terrible reviewer - I sometimes even make my own hacks pass.

To be fair, MC did try ask me for help in private. But my knowledge of (g)zdoom highly concentrated in specific areas where I know a lot, and then other areas where I know basically nothing. When I was looking at the flatsprite code there were too many variables there that I wasn't 100% sure what purpose served. Even now with all this discussion I don't know if such sprites should be implemented with such flags or not. The only thing I know is that the effects, that they could theoretically do, look ace (from the youtube clips and such).

I think the real problem here is that this got merged into master prematurely. If it isn't 100% certain that the method being used is generally working and known to be sane, getting it into a release build will be really bad. So I support Graf in his decision to remove the feature from master until it works, but I also very well understand why Major Cooke wants this feature so badly.

You have to keep in mind that once something lands in master, it kind of becomes Graf's problem in the future should the original contributor go MIA. And modders will start using it in a way that could cause it to become something that has to be permanently supported.

[Major Cooke]

Right, and I based it off of code that even Nash said in his original one looked convoluted -- only I didn't learn about that until just recently.

Had I known that... I wouldn't have even bothered with FLATSPRITES until Graf came up with an alternative place to make them work. I had no idea I was basing it off of a hack.

The only thing I know is that the effects, that they could theoretically do, look ace (from the youtube clips and such).

Thanks!

[Rachael]

Well - Torr is still around. I've learned a thing or two from him, too. If you have trouble reaching out to him, I can shoot him an email, but he is usually reachable on the Zandronum forum. He's the one who is responsible for GZDoom's model and texture resizing code. (AFAIK)

I know where you guys are coming from. The lightning really does look awesome. But I also know what Graf and dpJudas are talking about with release plans. I may not have ever done it with C++ code, but I have managed a release schedule before. If it's not ready, it's not ready - it's as simple as that. As for whether this feature will make a comeback - that's entirely up to Graf. This is his port - not mine. Nowhere did Graf imply he wasn't ever going to consider it again, though - so that probably means this is only out the window for the next release.

[Major Cooke]

Right. Well, as long as it can go back to its originally intended behavior regardless of code, I don't mind it being postponed at all. I've waited patiently for a whole year for the submission to be accepted, and I can continue to wait for it to be properly redone.

So long as it's not permanently out the window, things are peachy.

We will rely on September 3rd's DRD build for now.

[Graf Zahl]

The reason I ditched this is because I want to do it RIGHT!
But if a release gets out with this mess in a later fix is no longer doable. And I do not consider this critical enough to postpone the release until I have suffiently free time which may be a few weeks off.
The code as it was was unsalvageable, it had to go no matter what.

My main problem with reviewing this is that of course the demos I got were tailored to the implementation and looked ok. It was just after I was doing some more explicit tests to see how the rotations stack when I noticed that some things did not work as intended. I'm sorry this passed the review but the convoluted state of the code was a major contributor there.

What needs to be done is to do the initial coordinates already in flat space and then rotate from there, not as this did, by starting with a wall sprite and rotate it around until something useful-looking comes out - and then make sure that the rotations work as intended.

The good thing is, the wall sprites are fully working as intended, everything absolutely behaves in a sane fashion.

[Major Cooke]

About the release, I understand.

Just to make sure we're on the same page, that's assuming flat sprites will be developed with the same sort of functionality, correct? That is, the flat sprites can still be out and about in the air, rolling and changing pitch? That is what my lightning gun effect is relying upon, and I can give you the demo if you need something to test it with when you get around to it.

And, well, I'm glad at least wall sprites work. And so does the rolling sprites too I take it?

[Graf Zahl]

The new implementation should support rotation along all three axes. What I cannot guarantee is that you may have to make adjustments.

With one sprite I tested the z-position was all wrong and rotations did not end up where they should, that's what prompted me to remove the code.