[Sobek]

Hey everyone,

Rather straightforward question here. I'm wondering if it's possible to alter the way in which sprites rotate in respect to the player's view. The way Duke3d does it is that a sprite set to rotate based on the movement of the player's viewpoint (billboard sprite, right?), however I feel a much more elegant way is to have the sprite rotate in relation to the physical direction of the player's 'body' (Axis aligned I believe).

Most modern shooters seem to do it this way when dealing with sprites, and if you've played Left 4 Dead (for example), you will probably know what I mean. It's so much more realistic when things like shrubs and plants rotate only with the physical movement of the player, as opposed to their view as you can be moving in one direction but looking in another, and it doesn't make the sprites rotate as you do unless you also shift your position at the same time. This video shows it off reasonably well (need to view it in 720p to make out any decent detail);

http://www.youtube.c...h?v=ofgSlHniLXU

You can see how all of the little ferns and plants on the ground don't rotate as the player looks around, but only as they MOVE around, so they always appear to be facing the player but don't show any obvious signs of rotation. I think it does wonders for immersion compared to the standard billboard type.

So that's what I was wondering. Can this be done by changes to something 'simple' like CON code? Or is the method by which the rotation of sprites occurs something that's hardcoded? Is this something that could perhaps be tackled in Polymer? I just think it's a much more visually appealing method of handling sprite rotation.

http://forums2.duke4...tyle_emoticons/default/smile.gif

*edit* Why did I say 'faceme' in the title? Man I'm tired today.

[Danukem]

Are you working on an 8-bit project now? Why can't you just use models and wall-aligned sprites?

[Sobek]

Still 32bit. The reason for this is that some detail sprites don't look good when using the normal view-aligned mode (lots and lots of obvious and unsightly rotation going on, especially in the far corners of your screen), and wall-aligned sprites tend to only look good on certain angles (speaking of details like shrubs and such here) like the front and back, where from a side angle it all but disappears. I've used a few wall-aligned props for certain grass details and such but in order to keep it looking reasonably realistic, I have to end up doing an X-shaped type of object, so basically just 2 flat planes slapped together so that it shows a fairly complete image from most angles. I'm trying to cut back on unnecessary poly's and object counts etc, so it's not always best solution to do this though, and using something like a 3d bush or shrub or whatever would just drag framerates down further.

I'm not demanding some major changes to how sprite rendering is handled or anything, I'm just checking to see if it's something that can already be done with relative ease, or if it's something that's been planned for... Granted, models and wall aligned sprites do a pretty good job as it is, but there's just so much room for improvement this way - less poly's, less overall objects needed, etc.

I don't think this is necessarily something specific to MY needs - I feel everyone could benefit from this style of sprite alignment. It definitely looks better in almost all cases, that much I believe.

[Plagman]

It's trivial with CON code, you just have to make all such sprites "wall aligned" and change their angle depending on the player position.

[Sobek]

That's good to know. I've been experimenting a lot with CON code recently... More or less reverse-engineering things I've seen elsewhere, learning how it all comes together as I go. So I think I might give this a try because I'm pretty sure from glancing over the Eduke32 wiki that I can come up with something myself http://forums2.duke4...tyle_emoticons/default/smile.gif

/optimism

[Danukem]

Sobek, on Jan 20 2011, 11:37 PM, said:

That's good to know. I've been experimenting a lot with CON code recently... More or less reverse-engineering things I've seen elsewhere, learning how it all comes together as I go. So I think I might give this a try because I'm pretty sure from glancing over the Eduke32 wiki that I can come up with something myself http://forums2.duke4...tyle_emoticons/default/smile.gif

/optimism

Just use cstator 16 on the sprites to make them flat like a wall, then make them face the player.

Example:

move FACEDUKE

useractor notenemy MYSPRITEPROP 0
ifmove 0
{
  cstat 257 // solid and shootable
  cstator 16 // flat
  move FACEDUKE faceplayer
}
enda

This is actually not a bad idea for certain sprites and I might use it next time I update the code in WGR2.

[Sobek]

*edit* Never mind. Got it working perfectly...

Thanks so much DT, as always. Got a whole lot of levels that are going to benefit from this! I'm always in awe of what you can accomplish with some 'simple' CON code

[Scott_AW]

Sobek, on Jan 24 2011, 08:32 PM, said:

*edit* Never mind. Got it working perfectly...

Thanks so much DT, as always. Got a whole lot of levels that are going to benefit from this! I'm always in awe of what you can accomplish with some 'simple' CON code

So whats it look like in the end?

[Sobek]

Scott_AW, on Jan 25 2011, 03:45 PM, said:

So whats it look like in the end?

Really good?

I've only done a little test so far - just a little outdoorsy area with some grass and a shrub sprites in a few spots on the ground. Walking around with those down feels entirely 'natural', because you just don't see the bleedingly obvious sprite rotation happening any more. It really is fantastic...

Might do a video a bit later.

*edit* I just tried to record one on my work PC here but it's just simply too shitty a PC to record it fast enough. I'll do it later when I get home

[Danukem]

It's a good idea and I'm glad you brought up the issue. The code must only be used on sprites, or else models would be turning to face the player. That means it can't be used on anything that has an HRP. But for any sprite only mod it should be useful, or in your case if there are specific sprites with no models.

[Scott_AW]

Sobek, on Jan 24 2011, 09:50 PM, said:

Really good?

I've only done a little test so far - just a little outdoorsy area with some grass and a shrub sprites in a few spots on the ground. Walking around with those down feels entirely 'natural', because you just don't see the bleedingly obvious sprite rotation happening any more. It really is fantastic...

Might do a video a bit later.

*edit* I just tried to record one on my work PC here but it's just simply too shitty a PC to record it fast enough. I'll do it later when I get home

I like the idea of grass, maybe I should try that out instead of masked walls, or at least see how it works out.

What recorder do you use?

[Sobek]

I'm just using FRAPS to record. Actually, it started running much better for no real reason... Dodgy old thing. It's just a quick run around, but it shows the effect off perfectly I would say. The sprites for the grass and shrub are just things I whipped together a little earlier, so they're not designed for that environment and they're pretty low quality, but they do the job. It just gives you a good idea;

http://www.youtube.c...uD15DBNM&fmt=18

Youtube's raped the quality but you can more or less make out all the shrub & grass sprites on the ground. With the right sprites and lighting, this should do wonders. I'm already testing it out on some rather large sprites that I'm using as background objects in a map, and already I can see it looks infinitely better than any wall-aligned or normally rotating sprite, so I'm pretty excited to start changing all the detail sprites I use over to this method

Hey DT, one other quick question - is it possible to 'bulk define' this code for a group of sprites/tiles? Like at the moment you have "useractor notenemy MYSPRITEPROP 0" for instance, but is there some way to define more than just that one 'MYSPRITEPROP'? Or will I need to add in a whole new bit of code for each one I use? I don't have too many, but if there's a way to cut back on the overall amount of code used, that'd be nice.

[Stabs]

Well done indeed, models and sprites can live in harmony now

BUT

how do spotlights affect sprites like that?

[Danukem]

I can still see some questionable rotation, especially that plant near the middle of the screen for the last few seconds. Overall it looks nice, though.

With very small sprites, such as blades of grass or small patches, I see no reason not to use flat wall aligned sprites and just let them be without facing the player.

[Sobek]

I just checked... It doesn't appear to affect them at all really. They still cast a shadow same as always (the shadow gets thinner as the sprite rotates side on with the spotlight, but by then you can't see it anyway). Obviously you can just setup the tag or con code or whatnot to disable the ability of the sprite to cast a shadow, if you don't want it to.

Seems to work just great!

[Danukem]

When I add this feature to WGR2, it will be more sophisticated version, and I'll go ahead and write that code now and post it here for you.

There are several problems with the simple version:
1. The sprites actually are flat instead of just looking flat. This could affect gameplay if the sprites are blocking.
2. The sprites face the player instead of facing the camera. Not a problem in a single player game in 1st person mode, but it will be obvious if you use F7 or if there is more than one player (they will face the closest player).
3. The actor code is only processed 30 times per second, whereas the frame rate is probably much higher. This will cause lag; you will be able to see them turning towards you (though not as much as with the vanilla system that you started the thread about).

To fix all this, we manipulate only the tsprites of the actors instead of the sprites in the game world, and we make them face the camera instead of the nearest player, and we do it in a rendering event so it is synced to frame rate.

Note: You have been using DukePlus as a base, so I assume you already have move INIT defined and the variable "temp", etc. Otherwise you would have to declare the needed variables.

// put this with other variable declarations
gamevar flatface 0 2


// example actor
useractor notenemy MYSPRITEPROP 0
ifmove 0
{
   move INIT
   getactor[THISACTOR].mdflags temp
   orvar temp 16
   setactor[THISACTOR].mdflags temp  // what this does is tell the game to process the tsprite of the actor in EVENT_ANIMATESPRITES
   setvar flatface YES // The special processing will be used only if this variable is set
}
// rest of code for breaking object or whatever if needed can go down here
enda

The following event code would be somewhat redundant in DukePlus, since the event already has code in HUDPLUS.CON
But if you can't figure out how to integrate this into the existing event, I think it would still work as a separate event declaration

onevent EVENT_ANIMATESPRITES

gettspr[THISACTOR].tsprowner spriteid
ifvare actorvar[spriteid].flatface YES
{
  gettspr[THISACTOR].tsprcstat temp
  orvar temp 16
  settspr[THISACTOR].tsprcstat temp
  setvarvar mx camerax
  setvarvar my cameray
  subvarvar mx sprite[spriteid].x
  subvarvar my sprite[spriteid].y
  getangle angvar mx my
  settspr[THISACTOR].tsprang angvar
}
endevent

The code should work, although I just typed it here and have not tested it. The one thing I worry about is the effect of changing the cstat of the tsprite. Sometimes I have had problems where it doesn't work like changing the cstat of the actual sprite.

EDIT: I'm testing a variation on this code and it doesn't seem to be working. I'm not sure what the problem is but it seems like the event code is not doing anything.
EDIT2: Nevermind, I was using my own code wrong. It works fine.

[Scott_AW]

I'll play around with that myself.

Thats a nice scene you have going on in the video, altough the shadows are a little weird. The light rays are nicely done.

You should check out Camstudio, it has a nice lossless codec and has proven to be very versatile in recording on various systems of various strengths.

[Danukem]

Here's a little video I made which directly compares the standard way of displaying sprites with the improved method:

http://www.youtube.c...h?v=HwSaEL8vRfQ

It would be nice if I could add this feature to DukePlus, but I have a problem. There is no way to tell, in CON code, whether a sprite has a model. If a sprite has a model (i.e. if the player is using the HRP), then the effect should be off. I don't want to make it an optional feature because players will turn it on, then use the HRP and start making bug reports about how models turn towards them in DukePlus.

[Sobek]

That's a real shame. I was just typing up my thoughts on the matter but I realize what you're saying... there isn't even any way for the CON code to 'talk' to the DEF code to determine what tiles have models assigned, is there?

And from what I can see the only alternative is to manually define each and every tile that you want to change over to this new method via CON code - a time consuming and clearly unreliably fiddly way of doing it.

Bugger. But who knows, maybe there is some kind of workaround to the issue... I just have no idea what it could be.

[Plagman]

No, but it would be pretty easy to eg. have the engine set a flag into mdflags when there's a model, or something similar. Then you'd be able to read that from CON and act accordingly, right?

[Hendricks266]

Seems easy enough, though I wonder if you would want to add flags for every type. Voxel, texture, skybox, model. (Tilefromtexture doesn't count.)

[Danukem]

Plagman, on Jan 31 2011, 09:00 PM, said:

No, but it would be pretty easy to eg. have the engine set a flag into mdflags when there's a model, or something similar. Then you'd be able to read that from CON and act accordingly, right?

Yes, I have wanted that for a long time, and not just for this little feature. Sometimes you need to know whether the friggin thing is a model.