Jump to content
Eternal Lands Official Forums
Roja

Skybox discussion

Recommended Posts

Remember too that these maps were made with the before-huge-perspective got turned on. I can play the game with a lower perspective and not have this problem.
Oh, I know, just saying that the introduction of perspective settings is what caused the problem in the first place, extra zoom would just make an existing problem a bit worse. :)
Although I'm not 100% certain, I'm almost sure that the extended cam enabled the "over-the-shoulder" view that I had in Emajekral's client(that's why the camera got raised, it moved "over your shoulder" instead of at your waist...I think). Please make it do that, it was REALLY fun to play with that camera view :P
Yes, my vote would be to make the higher camera focus the default. I think it's only the middle-click vs middle-grab that's worth being configurable.
Not sure how hard it would be to limit the camera view, but _this_ can in theory be done, either by counting clusters while loading the map, or by extending the map format with a "cluster number" field which is stored when saving the map.
It can be done without needing a change to the map format, by just growing a 2D bounding-box (several boxes or a polygon would work better, to be able to cover non-rectangular map-sections, see maps like vermor castle for why a single box would include separate rooms, but that's more complex) per contiguous region as you check the height-map for where you can walk to when loading the map.

One thing on this, the lighting will change in some cases. A light a long way down the hallway would then be used instead of the light close-by in another room (not directly connected). Probably a good thing, but it may cause some areas to become unlit until someone fixed them.

This would, however, make creation of custom tabmaps harder, as you don't see more when you zoom out (and consequently it would also need a special case when the EL rendering engine is used in map creation; but since you don't have an actor position that would happen anyway).

ed: As for the camera, I assume that someone properly versed in the use of the bbox trees could apply the appropriate culling without too much work (say, that should also make performance inside a lot better).

Edited by ttlanhil

Share this post


Link to post
Share on other sites

It can be done without needing a change to the map format, by just growing a 2D bounding-box (several boxes or a polygon would work better, to be able to cover non-rectangular map-sections, see maps like vermor castle for why a single box would include separate rooms, but that's more complex) per contiguous region as you check the height-map for where you can walk to when loading the map.

Yes, the only reason why one would possibly want to store it in the map itself is the fact that map loading is already quite slow, and I'm not sure how much extra time is needed to compute the extra bboxes on load.

One thing on this, the lighting will change in some cases. A light a long way down the hallway would then be used instead of the light close-by in another room (not directly connected). Probably a good thing, but it may cause some areas to become unlit until someone fixed them.

In fact, that _would_ be a good thing, but indeed for compatibility the old behaviour would possibly need to be retained.

This would, however, make creation of custom tabmaps harder,

I don't think we should be overly concerned about that...

as you don't see more when you zoom out (and consequently it would also need a special case when the EL rendering engine is used in map creation; but since you don't have an actor position that would happen anyway).

...but this is something we should preferably take into account right away.

Share this post


Link to post
Share on other sites
It can be done without needing a change to the map format, by just growing a 2D bounding-box (several boxes or a polygon would work better, to be able to cover non-rectangular map-sections, see maps like vermor castle for why a single box would include separate rooms, but that's more complex) per contiguous region as you check the height-map for where you can walk to when loading the map.
Yes, the only reason why one would possibly want to store it in the map itself is the fact that map loading is already quite slow, and I'm not sure how much extra time is needed to compute the extra bboxes on load.
Well, I was thinking about extra data structures to hold a list of 2D boxes, but adjustments to how the bboxes work should be good too. Yes, loading the maps faster would be a good thing, however it's the need to change the format I was looking at (then again, you can probably whip up a script that can update all existing maps as well as updating the map editor anyway :P )
In fact, that _would_ be a good thing, but indeed for compatibility the old behaviour would possibly need to be retained.
No, I don't think so, it should just mean that all maps need to be checked with the new behaviour before being released. However, the FPV option already means that minor mapbugs are a lot more visible, so the maps will probably have to be closely investigated anyway (hence why I stuck it in CVS when there are still all these known bugs)
as you don't see more when you zoom out (and consequently it would also need a special case when the EL rendering engine is used in map creation; but since you don't have an actor position that would happen anyway).
...but this is something we should preferably take into account right away.
Right. However I don't see why it would be too hard to do, just disable the check for the local area, since you can't without an actor (to indicate which map you're in) anyway.

Actually, there's a thought. This could cause issues with certain mapbugs, like if there's a single walkable tile several steps away from the cave-proper; or where there is no valid data (I don't know how nomap.elm is set up, for example, if everything or nothing is walkable). Of course, we want to be rid of all bugs anyway, but they could cause a problem.

Which then gives me another thought... Where TPTR or teleplatforms are currently used to jump (disconnected) sections. The platform in Tarsengaard's mage school, for example... It's probably close enough to other walkables to be okay, but it serves as an example (the rest of the map also serves as an example of being able to see other rooms and all :) )

Share this post


Link to post
Share on other sites

Which then gives me another thought... Where TPTR or teleplatforms are currently used to jump (disconnected) sections. The platform in Tarsengaard's mage school, for example... It's probably close enough to other walkables to be okay, but it serves as an example (the rest of the map also serves as an example of being able to see other rooms and all :P )

Well, but they're usually not separated by blank tiles, are they? You could check for those instead of checking the height map for walkability.

 

EDIT: maybe not, walkable areas can also have NULL ground tiles.

Edited by Grum

Share this post


Link to post
Share on other sites
Although I'm not 100% certain, I'm almost sure that the extended cam enabled the "over-the-shoulder" view that I had in Emajekral's client(that's why the camera got raised, it moved "over your shoulder" instead of at your waist...I think). Please make it do that, it was REALLY fun to play with that camera view :bow_arrow:
Yes, my vote would be to make the higher camera focus the default. I think it's only the middle-click vs middle-grab that's worth being configurable.

 

Huh? You're confusing me a bit there :P

The default camera should be centered on the player(exactly as it is now). The EXTENDED camera should be "over-the-shoulder" with extended camera rotation like the screenshots I posted. Basically the Extended cam should be the same as most modern day RPG's, where you see your character, but you can move the cam around and look at the sky, etc.

Share this post


Link to post
Share on other sites
Well, but they're usually not separated by blank tiles, are they? You could check for those instead of checking the height map for walkability.
So we'd have to look into the map to see if the tiles there are water or rock or whatever as well? That gets complicated.

Perhaps it would be simpler to raytrace into the walls when inside. As soon as you hit a wall, don't draw anything further along. That allows places that don't have walls but are still unwalkable (such as rivers) to be seen past (for that matter, we're actually looking at the same requirements as archery would have... perhaps we could use the same formula as would be used for archery :bow_arrow: )

 

Huh? You're confusing me a bit there :P

The default camera should be centered on the player(exactly as it is now). The EXTENDED camera should be "over-the-shoulder" with extended camera rotation like the screenshots I posted. Basically the Extended cam should be the same as most modern day RPG's, where you see your character, but you can move the cam around and look at the sky, etc.

Hmm, okay, we can do that, I just don't see why we'd want a checkbox (and hence spend screenspace in ctrl+o ) to lift the camera a meter :P Edited by ttlanhil

Share this post


Link to post
Share on other sites
Huh? You're confusing me a bit there :P

The default camera should be centered on the player(exactly as it is now). The EXTENDED camera should be "over-the-shoulder" with extended camera rotation like the screenshots I posted. Basically the Extended cam should be the same as most modern day RPG's, where you see your character, but you can move the cam around and look at the sky, etc.

Hmm, okay, we can do that, I just don't see why we'd want a checkbox (and hence spend screenspace in ctrl+o ) to lift the camera a meter :P

 

Because it's not JUST lifting the camera a meter.

 

Default Camera = EXACTLY as it is in the client now

Extended Camera = camera with extended rotation where you can look up and see the sky, look down at your feet, rotate it all around, zoom in/out...as shown in the screenshots I posted, and like almost every other RPG, and tons of MMORPG's out there.

 

Well, but they're usually not separated by blank tiles, are they? You could check for those instead of checking the height map for walkability.
So we'd have to look into the map to see if the tiles there are water or rock or whatever as well? That gets complicated.

Perhaps it would be simpler to raytrace into the walls when inside. As soon as you hit a wall, don't draw anything further along. That allows places that don't have walls but are still unwalkable (such as rivers) to be seen past (for that matter, we're actually looking at the same requirements as archery would have... perhaps we could use the same formula as would be used for archery :bow_arrow: )

 

 

Or we can just Auto it to a "default inside view camera" where you're not going to see other house insides.

Share this post


Link to post
Share on other sites
Default Camera = EXACTLY as it is in the client now

Extended Camera = camera with extended rotation where you can look up and see the sky, look down at your feet, rotate it all around, zoom in/out...as shown in the screenshots I posted, and like almost every other RPG, and tons of MMORPG's out there.

*shrug* Okay, I just expect nearly everyone will change to extended camera reasonably quickly.
Or we can just Auto it to a "default inside view camera" where you're not going to see other house insides.
Yeah, house insides are easy to do, they tend to be roughly square and not give access to anything else through use of TPTR. Dungeons are another matter, such as people being able to jump rivers or walls. It will work okay if the obstruction is thin, but if it's more that the padding we expect, the other side of a river or whatever will no longer even be seen (although people may still be able to TPTR across).

Share this post


Link to post
Share on other sites

Well, we still have the option for using Isometric view, how many people are using that? Since it's still there, having a more useful "default perspective camera"(what we have now) available doesn't sound like a big deal. Plus it really is different, also the extended camera creates more of a strain on your system. People with poorer computers might not want that.

 

 

I don't see any problems with limiting the zoom range for insides. MOST of all caves are on their own maps, some will be an exception and be on _inside.elm maps. So if there is a list made, insted of using everything labeled as "dungeon", it should work pretty well. Also, TPTR does have it's limits as well, I believe it's something like 20 height map tiles.

Share this post


Link to post
Share on other sites

Okay, so, you move the mouse, and it moves and them jumps back? And eventually it doesn't move at all, and you have to middle-click again to release the mouse? Where does it finish at, top of allowable mouse range? Bottom? Middle (exactly)? Do you still have left/right when up/down doesn't work?

Sorry, can't reproduce it.

I had full freedom of view, then looking up/down stopped working, left/right got jittery, then left/right also got stuck and only flicked.

 

/EDIT:

Skybox broke shader reflections on water.

Edited by Florian

Share this post


Link to post
Share on other sites

Well, it's been a while, so time to update, I guess...

Default Camera = EXACTLY as it is in the client now

Extended Camera = camera with extended rotation where you can look up and see the sky, look down at your feet, rotate it all around, zoom in/out...as shown in the screenshots I posted, and like almost every other RPG, and tons of MMORPG's out there.

That's pretty much how it is in CVS now (zoom is the same with or without ext-cam, do you want that adjusted?), although it's likely the changes I made allow the non-ext-camera to move another degree up/down, etc... Ext-cam now allows you to go almost straight up/down (I don't like straight up/down, as that looks perculiar when you pan, but I can add another 5-10 degrees if needed)
Or we can just Auto it to a "default inside view camera" where you're not going to see other house insides.
Grum's done this :evilgrin:

 

I took a few screenies wandering around in VotD today... FPV isn't that great for playing, but it's good for looking around :laugh:http://s17.photobucket.com/albums/b62/ttlanhil/FPV/

 

Bugs/TODOs/related issues:

- ctrl+o descriptions

- the lightning is seen on clouds (at least in -DNEW_WEATHER, where the flash is more noticeable), which isn't really going to be correct.

- fix follow cam in FPV

- the shadow system in EL only works for a certain distance; after that the shadows look funky. The new view here will make players more likely to be looking long distances, so it is becoming more of a problem.

- actor animations, when viewed from a low angle (such as horizontal) seem a lot more robotic, no bounce, etc. Note: in FPV, head bobbing will be visible to the player as the screen moves, so while it would look okay to increase a little, it shouldn't be too much

- again with being able to see further, you can see when actors disappear. It might work okay if we alpha blend people in/out at a certain distance, because currently they just pop in/out on actor add/remove from the server.

 

- shaders don't seem to work

 

- clouds, stars & sun go from north to south when looking north or south; west to east when looking west or east. funky.

- skybox and shadows roll when panning camera.

- reflection of skybox is pass-through, not a proper reflection

disable reflect_sky, and only on high angles is anything shown (is the horizon misplaced?)

 

All 3 seem to indicate that something in the OpenGL code is wrong, a mis-translation or rotation or something... I just don't know what/where :D

Share this post


Link to post
Share on other sites

The FPV is looking nice. Really need that over-the-shoulder perspective though; it gives about the right information for a game, giving you a sense of peripheral vision.

 

With a far-field view, it looks odd that there are no actors in the distance, but they appear from no where at quite a short range. How much information would be needed to send a "distant actor" message vector?

 

On the clouds -- their appearance is okay overhead clouds, but not for clouds towards the horizon; it looks more like smoke/fog. Clouds occupy one or more plains with perspective, and do not appear homogeneous on the sky sphere.

Share this post


Link to post
Share on other sites

If we went just to FPV, then perhaps the server could send actor data for what is in front of the actor, instead of a (assumed) circular radius around the actors current position. ie. move that circle X units in front of the person. That would increase the forward view distance and reduce the vision to the rear (which is realistic), mimicking natural perspective. Just a thought, but it would require server side changes. The server already knows what direction the user is pointed so it should not be too difficult. Just a thought.

Share this post


Link to post
Share on other sites
The FPV is looking nice. Really need that over-the-shoulder perspective though; it gives about the right information for a game, giving you a sense of peripheral vision.
I tend to agree, but the minimap may supply that sense of knowing what's going on around you. *shrug*
With a far-field view, it looks odd that there are no actors in the distance, but they appear from no where at quite a short range. How much information would be needed to send a "distant actor" message vector?
This has been a problem ever since perspective was added to the client (before that it was only modded clients (or perhaps rare cases with height differences)). It's just a lot more obvious in FPV. The problem is that you can see a long way, perhaps as far across as Whitestone City is, before LOD cuts too much out... Now, some people's computers won't be able to handle many maps in FPV, but some will... The increase in bandwidth needed, on the other hand, will be significant, especially in populous (not just people, but also critters) areas. I don't know how much of a problem dial-up would be today, but if the view range for actors went up that much, it'd be a lot worse (plus, how do we deal with the perception-difference? just crank that up at the same scale? People will see each other from so far away anyone has time to check stats before fighting?). It seems like there's some serious design issues to be considered :(
On the clouds -- their appearance is okay overhead clouds, but not for clouds towards the horizon; it looks more like smoke/fog. Clouds occupy one or more plains with perspective, and do not appear homogeneous on the sky sphere.
Yeah, it seems like we have an uncorrected sphere instead of a corrected one or a skyplane... Unfortunately, I don't know if I have the technical ability to fix it (I could probably add another layer of clouds that'd be seen as higher, but adjusting what sort of sky rendering view is used is trickier). Plus the amount of time that would be needed... Between university, all the other things on my TODO list for EL, work on related projects like my bot or movie-server, time off when people in-game make me wonder why I bother putting in all this work, etc, I don't think I have time to do more than fix the bugs and adjust some of the less tricky things.

 

I'm hoping someone with OpenGL experience will be able to help out, but the two people I know who have experience also have their own projects taking up time :P

 

If we went just to FPV, then perhaps the server could send actor data for what is in front of the actor, instead of a (assumed) circular radius around the actors current position. ie. move that circle X units in front of the person. That would increase the forward view distance and reduce the vision to the rear (which is realistic), mimicking natural perspective. Just a thought, but it would require server side changes. The server already knows what direction the user is pointed so it should not be too difficult. Just a thought.
No, given how fast you can pan the camera (and although in mouse-grab mode the client auto-turns the character, it's still way too slow). You'd need at least 120 degrees to be able to deal with only minor turns of the head, and turning your head (IRL) side to side means you have a range of vision of something like 270 degrees within part of a second (certainly less than some people's ping time on EL). Plus calculating the different ranges and angles may be more CPU intensive than just a circle.

It's an interesting idea (and certainly, come up with more :wub: ) but I don't think it will work out as well as we need.

Share this post


Link to post
Share on other sites

In principle this could work, but

a) keeping track of the viewing direction as well as the position of the player is more work for the server (every rotation would require checking ehich actors come into view)

B) the server and the client still disagree on the the current orientation of an actor sometimes

c) quite frankly, at the moment, gameplay in FPV just plain sucks. It looks awesome, but the interaction with the world is a lot more difficult than in 3rd person.

 

EDIT: ttl beat me to it :)

Edited by Grum

Share this post


Link to post
Share on other sites
:P the server and the client still disagree on the the current orientation of an actor sometimes
Theoretically that's entirely a bug, and will get fixed (preferably before 1.5), and hence won't be a big issue. Heh, yeah.
c) quite frankly, at the moment, gameplay in FPV just plain sucks. It looks awesome, but the interaction with the world is a lot more difficult than in 3rd person.
I don't know if it will ever be good for playing. Perhaps if zoom/mouse-wheel became a height adjustment (so you can look from different heights as well as pitch/yaw with the mouse) it might be a bit more usable, but I don't think so. FPV is okay for distance work and for looking around. Not close-in playing like EL is designed for.

However, once the rendering and actor distances, and all the other issues are fixed... We'd then be ready for more camera positions. Over-the-shoulder may work, we can add a string camera (when you move, it tends to go behind you, but doesn't move when you don't), we can allow for greater freedom of zoom/pan in the current camera, the FPV client has a follow-cam (which, if you adjust settings, isn't too jerky to be unusable, although I think it still needs a bit of tuning), and probably many other options.

EDIT: ttl beat me to it :wub:
Nyah nyah! :(

Share this post


Link to post
Share on other sites

Over-the-shoulder vs mini-map -- While both give you equivalent information, the former is much more natural, keeping as much information presented within the game-world/VR as possible.

 

Distant Actors -- Filtering/sorting is probably a bigger problem than bandwidth. Consider treat "distant actors" as separate type of objects from regular actors and enhanced actors, without any specific information (clothes, name, look-at information).

 

Whats the minimum information needed to put a low-polygon representation in the distance? Say:

{ uid, x, y, [ z?, ] facing-sitting, body-type }

Less than 8 bytes? Have a message as a vector of these. Body-type would map to a lower-polygon model, covering all entities -- basic form, size, and colouration. Body type could even be designed to degrade with distance (if lower bits give more detail, mask according to range).

 

The "distant actor" could also serve as an intermediate form between in-range and out-of-range, to stop people flicking in/out of view fully formed.

 

If each entity (creature, character, NPC) has a unique uid for its duration on a map, then the client could correlate a local and distance entity, and track it as it walks into the distance.

 

But filtering is the killer if you want to limit the amount of "distant actors" that get sent to a particular client based on LOS. Here some approximations/heuristics would be required.

Share this post


Link to post
Share on other sites
:wub: the server and the client still disagree on the the current orientation of an actor sometimes
Theoretically that's entirely a bug, and will get fixed (preferably before 1.5), and hence won't be a big issue. Heh, yeah.

Sure. except that bug's been in there for ... wild guess ... more than three years, I'd say. :(

 

I'm not terribly pessimistic about FPV, I think it can be made to work decently. However, at this point it still needs a lot of tuning to be able to play decently. For instance, what I'd really love to be able to do in FPV is to move my character using the keyboard. With the current EL protocol this is possible, but t3h g0d paying for the bandwidth is not going to like it if we implement it with the current turn/step commands. However, with server support we could implement something like "key up means move forward until we change direction" which would make it a lot less bandwidth intensive.

 

Anyway, we there's now over 4 years of experience with the current view, and simply changing it over night is not going to work. Besides, I wouldn't want to rip out the 3rd person view entirely, I'd love to be able to switch between them.

Share this post


Link to post
Share on other sites
I'm not terribly pessimistic about FPV, I think it can be made to work decently. However, at this point it still needs a lot of tuning to be able to play decently. For instance, what I'd really love to be able to do in FPV is to move my character using the keyboard. With the current EL protocol this is possible, but t3h g0d paying for the bandwidth is not going to like it if we implement it with the current turn/step commands. However, with server support we could implement something like "key up means move forward until we change direction" which would make it a lot less bandwidth intensive.

 

Anyway, we there's now over 4 years of experience with the current view, and simply changing it over night is not going to work. Besides, I wouldn't want to rip out the 3rd person view entirely, I'd love to be able to switch between them.

I stopped using FPV after I was sick of wanting to use the keyboard. Click movement is age-old as it is - it'd be really nice to have freeform movement using the keyboard instead of click-click-click-click, crap missed the rabbit, click-click-click...I won't go into that here though :(

 

What I did notice with 'Follow Cursor', is the need for it to have a 'snap back' option, that allows the player to move/rotate the camera without having to readjust the view to behind the character (as it'll automatically move back to the back-view). Otherwise, you end up clicking to move instead of rotating the camera because you don't want to have to keep readjusting the view to behind the char... (Well, at least I do...)

Edited by Placid

Share this post


Link to post
Share on other sites
Whats the minimum information needed to put a low-polygon representation in the distance? Say:

{ uid, x, y, [ z?, ] facing-sitting, body-type }

Less than 8 bytes? Have a message as a vector of these. Body-type would map to a lower-polygon model, covering all entities -- basic form, size, and colouration. Body type could even be designed to degrade with distance (if lower bits give more detail, mask according to range).

Only if you don't move them the same as normal (the further away they are, the larger the co-ords of movement could seem to be, but that'd get harder to implement). Otherwise, well, add_command_to_actor messages (pain, move_nw, attack1, and so forth) are a large part of the bandwidth EL uses. Even if you assume it's limited to sit/stand/walk commands at range, that could be a large increase... For most players it won't be that bad, but people on dial-up will probably suffer (plus it may as much as double traffic, which matters more for the server; nor only network costs, but I recall reading that interrupts to get network traffic were one of the slower things on the EL server)

 

 

I stopped using FPV after I was sick of wanting to use the keyboard. Click movement is age-old as it is - it'd be really nice to have freeform movement using the keyboard instead of click-click-click-click, crap missed the rabbit, click-click-click...I won't go into that here though :wub:
Thanks :(
What I did notice with 'Follow Cursor', is the need for it to have a 'snap back' option, that allows the player to move/rotate the camera without having to readjust the view to behind the character (as it'll automatically move back to the back-view). Otherwise, you end up clicking to move instead of rotating the camera because you don't want to have to keep readjusting the view to behind the char... (Well, at least I do...)
Uhm. Do you mean ctrl+o->sky&cam->follow camera? I know it needs tuning and you have to play with the numbers, but it generally works (when in follow cam mode, spinning camera adjusts the offset from forwards of your character, which may be unintuitive to players for a while, but is useful)

Share this post


Link to post
Share on other sites
Whats the minimum information needed to put a low-polygon representation in the distance? Say:

{ uid, x, y, [ z?, ] facing-sitting, body-type }

Less than 8 bytes?

Only if you don't move them the same as normal... Otherwise, well, add_command_to_actor messages (pain, move_nw, attack1, and so forth) ...

I wouldn't bother with anything other than those 8 bytes. No actor actions or separate movement, etc. If the entity changes state, resend the 8 bytes in the next (periodic?) update. If you are sending the full position each time, and the client isn't interacting with the distant actor, its even possible to update less frequently than the movement clock-tick; the client can interpolate between previous and new positions if it needs to animate the distant actor.

Share this post


Link to post
Share on other sites
What I did notice with 'Follow Cursor', is the need for it to have a 'snap back' option, that allows the player to move/rotate the camera without having to readjust the view to behind the character (as it'll automatically move back to the back-view). Otherwise, you end up clicking to move instead of rotating the camera because you don't want to have to keep readjusting the view to behind the char... (Well, at least I do...)
Uhm. Do you mean ctrl+o->sky&cam->follow camera? I know it needs tuning and you have to play with the numbers, but it generally works (when in follow cam mode, spinning camera adjusts the offset from forwards of your character, which may be unintuitive to players for a while, but is useful)

Sorry, I meant "Follow Camera".

 

As for the rest of what you said, please read me again. I was referring to a 'snap back' ability, that centres back behind the character after you've let go of the middle mouse button to rotate the camera. That way, you can see alternative views, and not have to worry about readjusting the camera to work with 'Follow Cam'.

Share this post


Link to post
Share on other sites

Ahh, right. Well, setting the camera to spin back once you release middle could work... Although I think if you want to look around, mouse-grab (middle-click when not using SDL cursors) will probably be more common, and won't work with that.

Share this post


Link to post
Share on other sites

Ahh, right. Well, setting the camera to spin back once you release middle could work... Although I think if you want to look around, mouse-grab (middle-click when not using SDL cursors) will probably be more common, and won't work with that.

If 'snap back' were configurable, it'd cater for those who want my previously described functionality (highly annoying to me). Mouse-grab is just being anal, this isn't Google Maps ;)

Share this post


Link to post
Share on other sites

Hi all. Glad to see this merged with CVS. It looks great considering how I just dumped it in ttlanhil's lap and all. I compiled it today and things look OK. Just a few things:

  • The FPV camera is too high now (with extended camera on. The height is correct when it's turned off.). The original height had it centered right behind the bridge of the nose: precisely where your eyes would be if you were your character. Now it looks like it's just above the top of the character's head. I know there was discussion about this... just my thoughts. One reason why the camera looks odd when its lower is that some of the objects in the game are oversized compared to the players.
  • I put the extended camera option in so that those that insisted on using the old UI could easily enable it.
  • Turning extended camera on without using FPV should be close to but not quite the same as the early client I sent Roja. I don't quite remember what values I used for that - I tweaked them so that you could grab the mouse and click just in front of the character. Probably changing the magic number in draw_scene.c:218 from -1.6f to -2.0f will make it match her memory - a little higher than the classic EL and a little lower than what I delivered. This screenshot is with -2.0f.
  • The sky in FPV in CVS right now is tilted 35 degrees... horizon fog is in the wrong place and shadows are all wrong. The offending line is draw_scene.c:270
    glRotatef(rx-(first_person?35:0), 1.0f, 0.0f, 0.0f);
    


    That line shouldn't be there at all. Removing it fixes the bug for me. Sorry. I don't generally use the trinary operator so I'm not sure how that got there.

  • When I checked the client out of CVS 3 hours ago sky.c needed to include SDL_active.h to compile.

Keep up the great work. I appreciate what you've done.

Edited by emajekral

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

×