[Danukem]

I used the spriteshadow command on a tree tile, and this was the result:



Is there any way to make those shadows not suck? I'm willing to manipulate them by using the tsprite array or whatever it takes, but I don't know how to go about it.

[XThX2]

How are the shadows on models casted ? I just had the idea of having the sprite modelled (good enough to use as a simpe shadow) and stretch it to the surface. It could work on slopes too.

[Danukem]

We are not using models in this TC, so that would be of no use to me.

[XThX2]

No, I didn't mean you should replace the sprite as a model, I meant, a simple skin or something like that which would act as it's shadow, so it could be stretched to the surface; at the same time fitting your needs. (Sort of)

[Danukem]

I guess I wasn't being clear. I want to manipulate the hardcoded shadow sprites that are already in the game to make them look better. I'm making some progress on that already. The main problem I have is that you can see them hanging out into mid-air, when the sprite casting the shadow is near a cliff.

[Plagman]

I don't know how much you've already figured out, but look for tsprites with the same tilenum, translucency, 8 limes less yrepeat (but never less than 4) and pal 4. I guess we could flag them with a special cstat for easier identification like we do when models are enabled. Judging by your screenshot the hard-coded yrepeat limit might just be the issue as the tile is very big. I'm interested in the results you'll get.

[Danukem]

Plagman, on Sep 11 2009, 10:51 AM, said:

I don't know how much you've already figured out, but look for tsprites with the same tilenum, translucency, 8 limes less yrepeat (but never less than 4) and pal 4. I guess we could flag them with a special cstat for easier identification like we do when models are enabled. Judging by your screenshot the hard-coded yrepeat limit might just be the issue as the tile is very big. I'm interested in the results you'll get.

What I've done for the trees is make the shadows half-submerged (adding 128 to the shadow cstat). This looks a lot better and it is good enough for now.

I'm having another problem, though. There is a ghost enemy that should not cast a shadow, but I can't prevent it. I tried removing the spriteflag for casting shadows from them and it has no effect. I've also tried making the shadow tsprites invisible and making them 0 xrepeat, 0 yrepeat, but again it has no effect.

[XThX2]

Quote

I'm having another problem, though. There is a ghost enemy that should not cast a shadow, but I can't prevent it. I tried removing the spriteflag for casting shadows from them and it has no effect. I've also tried making the shadow tsprites invisible and making them 0 xrepeat, 0 yrepeat, but again it has no effect.

I have the same issue as well. It might be a bug in eduke32.

[Jimmy]

I'm not sure if there is a better way, but you could change it from "useractor enemy" to "useractor notenemy".

[Fox]

Changing enemy to notenemy causes too much differences, better not try.

I suppose that tsprcstat 32768 may work. But I am not sure about how to diff beetween the shadow and the sprite itself.

[Danukem]

Ilovefoxes, on Sep 13 2009, 09:34 AM, said:

I suppose that tsprcstat 32768 may work. But I am not sure about how to diff beetween the shadow and the sprite itself.

It doesn't work. I already tried that, as I said in a post above. Also, Plagman explained in a post above how to tell the difference between the shadow and the sprite.

[Plagman]

DeeperThought, on Sep 11 2009, 08:22 PM, said:

I tried removing the spriteflag for casting shadows from them and it has no effect.

In what event are you trying to set the shadow size to 0 (or give it cstat 32768)? It's possible you're manipulating the tsprite after it's been drawn. Anyway, the source code will give a shadow to enemy sprites OR sprites that have the SPRITE_SHADOW set, so enemy actors will get the shadow no matter what. I suppose this part could be changed so that enemy sprites that don't have that flag don't end up with a shadow, but we'd need to be careful about giving them all the flag by default. Alternatively, the new cstat that's used to tell polymer not to draw dynamic shadows could be plugged in the old shadow system as well.