DRD Team

This is mainly directed to Torr as I understand Graf has his focus on DoomScript.

The main reason why I made a public thread (instead of PM'ing) is so that other people can participate in the discussion.

I propose the +UNANCHORED flag and not a global unanchored sprite setting because there are situations where unanchored (or billboard, whatever you'd like to call them) sprites are a must:

1) Particle effects (smoke, fire, blood, light coronas, etc)
2) Sprites that are not scenery-related (like objective indicators, text indicators floating above a sprite, etc)

I have been working to finish an official MODELDEF that is compatible with the jDoom resource pack, and one problem I ran into is that the torches don't use models, but particles.

One could easily duplicate this effect using DECORATE, but the flame particles will never look right if they're anchored.

Indeed, true. It would help for particles and light effects.
I noticed when I played KDiZD sometime ago again, the coronas in software mode look much more like... coronas than in OpenGL mode. Also, projectiles (fireballs, etc.) will easily look better with it.

Or short:
Seconded ;P

The UNANCHORED flag idea is nice, but as long my x/y axis billboard code doesn't work with horizontal sprite splitting, Graf won't add it to GZDoom, making the flag pointless .

But this doesn't mean I can't add such a flag to Skulltag, especially since I want to use the torch models. I'll think about it.

If I should add such a flag, would you spawn the particles with A_SpawnItemEx and the client side flag?

Well yes, definitely it has to be spawned with the client-only flag to make it online-friendly.

That would also mean having to provide a DECORATE actor replacement for the torches... would that be a problem?

Flag is ready . To be consistent with the ZDoomGL naming scheme it's called +FORCEXYBILLBOARD. I also added a +FORCEYBILLBOARD to enforce drawing anchored to the floor. The torch sprites for example look really bad when drawn unanchored.

Nash wrote:That would also mean having to provide a DECORATE actor replacement for the torches... would that be a problem?

Perhaps I need to make a few changes to properly allow client side replacements, shouldn't be too problematic.

Oh, you mean the DECORATE keyword "replaces" doesn't work too well?

Thanks a lot for the flag. I have plenty to work with now (just signed up as an ST tester, yay!)

Nash wrote:Oh, you mean the DECORATE keyword "replaces" doesn't work too well?

It's the server that "decides" what is spawned where (with the exception of client-side spawning for A_SpawnItemEx flag 128). So right now, if your client has some eye-candy mod which replaces decoration without any incidence on the gameplay, but the server doesn't load this mod; then it's just as if you didn't have the mod as well.

In single-player, or when the server has the same list of mods as you, there's no problem.

I take it this will work in the next version of GZDoom?

Using the latest internal beta of Skulltag, I've tested billboarded sprites with a WAD that uses lots of 3-d floors and there doesn't seem to be any problems...

EDIT: I also tested with a variety of actors using both anchored and unanchored flags, all displayed at the same time on 3-d floors. No problems. Torr, you're amazing.

Problems with 3D floors will arise if a sprite intersects a 3D floor. As long as you are using only solid 3D floors, you most likely won't notice problems. If you want to see what kind of problems can occur, use a ExtraFloor_LightOnly to partially light a sprite.

... and unfortunately I don't have a decent solution for this.

Doing the rotation before the splitting shouldn't be too difficult. One just has to calculate the transformations by hand once instead of letting OpenGL do them, I can do so when I find time.

Does anybody know how exactly the matrix generated by the command OpenGL command Rotatef(a, b, 0, c) looks like? I'm too lazy to construct the matrix by hand .

But I think this alone won't solve the problem: From briefly looking at the sprite splitting code, I'd say that this only works for anchored sprites and needs some adjustments to handle the unanchored ones.

Wouldn't it be this?

1st row: c cos a, c sin a, 0, 0
2nd row: b cos a * -c sin a, b cos a * c cos a, b sin a, 0
3rd row: -b sin a * -c sin a, -b sin a * c cos a, b cos a, 0
4th row: 0, 0, 0, 1

Assuming OpenGL rotates around the x-axis first. That's how I would construct the matrix but I don't know OpenGL enough to know which order it does rotations.

EDIT: Made a mistake reading the stock rotation matricies from my notes on the subject. Will re-edit when fixed

EDIT 2: Done correcting. Amazing how different the results are when you multiply backwards.

KeksDose wrote:Indeed, true. It would help for particles and light effects.
I noticed when I played KDiZD sometime ago again, the coronas in software mode look much more like... coronas than in OpenGL mode. Also, projectiles (fireballs, etc.) will easily look better with it.

Or short:
Seconded ;P

A alternative .....
In UT engine, you have some procedural textures .. in special Fire Textures that looks damn well. It's was very usual when any a guy like to create a fire source like a torch, creating a "X" double sided polygons and put these procedural texture there which a alpha channel. They looks really good and need lees computer power that particles to create a good fire.

To do this here in a MD2/3 model, you need :
-More of one skin per model
-Procedural textures that can be assigned to a skin of a model