Jump to content
Eternal Lands Official Forums
Umrion

Maybe Auto-cam Almost Usable

Recommended Posts

I started familiarizing myself with the code, and decided to fix the auto camera a bit. Presently it looks like this (actor_scripts.c):

if(auto_camera)
 if(actors_list[i]->actor_id==yourself)
 {
   camera_rotation_speed=rotation_angle/18;
   camera_rotation_frames=18;
 }

Which basically means that the speed of the rotation is directly proportional to the length the camera should rotate. It really doesn't look good, as many people undoubtely have noticed.

 

I changed it so that the auto camera rotates with the normal camera rotation speed instead:

if(auto_camera)
 if(actors_list[i]->actor_id==yourself)
 {
   camera_rotation_speed=normal_camera_rotation_speed/40;
   camera_rotation_frames=get_rotation_vector(rz,targeted_z_rot)/camera_rotation_speed;
   if(camera_rotation_frames<0) {
     camera_rotation_frames=-camera_rotation_frames;
     camera_rotation_speed=-camera_rotation_speed;
   }
 }

This is much nicer. I still don't know if I'll use the auto camera, but at least it's an improvement B)

 

 

I also noticed an interesting detail; whenever something else than the main game screen is viewed (i.e. we view the console or a map) the color buffer is cleared twice :D Doesn't matter much, since speed won't matter here, but anyway...

For example:

	if(!shadows_on || !have_stencil)glClear(GL_DEPTH_BUFFER_BIT|GL_COLOR_BUFFER_BIT);
else glClear(GL_DEPTH_BUFFER_BIT|GL_COLOR_BUFFER_BIT|GL_STENCIL_BUFFER_BIT);

if(interface_mode==interface_console)
 {
	 // are we actively drawing things?
	 if(SDL_GetAppState()&SDL_APPACTIVE)
   {
  	 Enter2DMode();
  	 glClear(GL_COLOR_BUFFER_BIT);

That last line is unnecessary. (The same thing happens for interface_opening and so on.) ^_^

Share this post


Link to post
Share on other sites

Good point about the double clearing.

Anyway, the auto camera code was there in the first client version, and it was never updated. As you can see, it was introduced as a hack, and left there...

Share this post


Link to post
Share on other sites
As you can see, it was introduced as a hack, and left there...

Yeah, I kind of figured that ^_^

 

I tried walking around a bit more with auto cam, and it actually works quite good. Try it! B)

What could be added to make it a good auto cam is make it try not to have any objects between itself and the character - i.e. the character should always be visible if possible. I'll have a look later to see if I can figure out a nice way to add that.

Share this post


Link to post
Share on other sites

No objects in the way :P ...that'll be hard, since you'll probably have to create a list of large objects which get in the way, so as you won't just calc whether there is something between us and the camera and turn (oh no, there is a small bush in the way) B)

 

Good luck, in any case!

Share this post


Link to post
Share on other sites

I was thinking one could cheat by using the height map. It won't account for things that don't hinder movement, but it might be good enough.

Of course, as you say, it will try to avoid having bushes between itself and the character, but I'll have to try to see how it works out :D

Share this post


Link to post
Share on other sites

I implemented it, and it actually works quite fine. It does get problems when there are lots of low unwalkable tiles - it just assumes all unwalkables are of height 25 (i.e. -2.2+25*0.2=2.8 m.)

Anyway, it works basically like this:

By "drawing" lines from eight possible eye positions (north, north-west etc.,) the program checks for intersections with the height map. For each direction a visibility score is calculated - basically, the more intersections that were found, the lower the score. (Actually, it might be better to calculate this based on how long a line we can draw without intersections, starting from the character and going towards the camera. Hmm....)

These scores are then weighted based on two things: The direction the character is facing (the camera wants to face the same way) and the current camera direction (the camera is a bit lazy.)

Then the direction with the highest score is chosen and rotation speed set accordingly.

 

Well, that's it. I put all this in update_camera, because this should be updated when we walk, not just when we start walking in a new direction.

 

I can post code later if anyone's interested in using/trying this (I want to clean it up a bit first.)

So is anyone actually interested in having a better auto cam? If not, at least I learnt a bit more about how EL works internally, which was kind-of the point. Perhaps now I can help out with coding stuff that is actually necessary :P

 

Edit: I just now noticed that I wrote "Maybe" instead of "Made" in the title of this topic. I was quite tired when I wrote that... :rolleyes:

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

×