Restore Old Custom Camera Glancing

What do you want to see in Armagetron soon? Any new feature ideas? Let's ponder these ground breaking ideas...
User avatar
dlh
Formerly That OS X Guy
Posts: 2035
Joined: Fri Jan 02, 2004 12:05 am
Contact:

Restore Old Custom Camera Glancing

Post by dlh »

Here is a patch to restore the old custom camera glancing for trunk. This should bring it back to the camera glancing and options in branch 0.2.8.

/me might “accidentally” apply this ;)

FROM THE FUTURE:

Patch still applied pretty cleanly. Available at https://code.launchpad.net/~armagetrona ... d-glancing
Attachments
restore_old_custom_camera.patch.not.zip
Not Zipped! It is just a patch file.
(43.69 KiB) Downloaded 316 times
Last edited by dlh on Fri Jan 30, 2009 5:40 pm, edited 4 times in total.
k
Random Identifier & Project Developer
Posts: 345
Joined: Wed Feb 25, 2004 12:54 am
Location: Northern California, USA

Re: Restore Old Custom Camera Glancing

Post by k »

nemostultae wrote:/me might “accidently” apply this ;)
/me looks the other way :wink:
Luke-Jr
Dr Z Level
Posts: 2246
Joined: Sun Mar 20, 2005 4:03 pm
Location: IM: [email protected]

Post by Luke-Jr »

Where's the accident in applying a bugfix? ;)
User avatar
Lucifer
Project Developer
Posts: 8640
Joined: Sun Aug 15, 2004 3:32 pm
Location: Republic of Texas
Contact:

Post by Lucifer »

Ummm, you know, instead of getting into a little revert war, why don't we try to straighten out the camera to allow both types?

I'd like to see the camera become a resource, and you'd pick some group of cameras you want to have available. So we'd have three types of cameras, each with their own config options that are set in the resource file, and then we'll ship a variety of camera resource files for folks to choose from.

You know, instead of getting into a revert war. You wouldn't want someone to "accidentally" revert your commit because they like meriton's camera better.....

(and let meriton hate the idea all he wants)
Image

Be the devil's own, Lucifer's my name.
- Iron Maiden
User avatar
dlh
Formerly That OS X Guy
Posts: 2035
Joined: Fri Jan 02, 2004 12:05 am
Contact:

Post by dlh »

Lucifer wrote:You know, instead of getting into a revert war. You wouldn't want someone to "accidentally" revert your commit because they like meriton's camera better.....
I guess you missed the smiley at the end.

I'm all for having both.
User avatar
Lucifer
Project Developer
Posts: 8640
Joined: Sun Aug 15, 2004 3:32 pm
Location: Republic of Texas
Contact:

Post by Lucifer »

nemostultae wrote:
Lucifer wrote:You know, instead of getting into a revert war. You wouldn't want someone to "accidentally" revert your commit because they like meriton's camera better.....
I guess you missed the smiley at the end.
Heh, no, I caught the smiley and smiled myself. Then I read two posts of "encouragement" and got a little worried, then decided to push my own agenda. :)

Here's what I've got in mind, anyway, if anybody wants to do it.

We take the existing camera options and turn them into slots. So, we'd have an incam slot, smartcam, external, etc. Custom would be removed because it gets obsoleted by the system, but we should consider having each camera type expose properties that can be changed and put in the config file. Or I'm wrong and custom gets a slot.

Then we make a base camera object (which we already have) that takes input and acts on it. The camera types would inherit that object, and we'd immediately factor existing code into an incam, zcam, mericam, and customcam.

Each of these camera objects reads and parses its own resource file. Actually, the mechanism I have in mind is only half-baked, and I've learned the hard way that if I post half-baked ideas people will just rip them apart instead of baking them some more, so I won't go into it.

So what you wind up with is some config options in the existing config system that specify a resource file to load for a given slot, and we anchor the slots. So the incam slot will only load an incam resource file, smartcam only loads a smartcam resource file, and so forth.

Existing camera config options become tags in the resource file, or attributes with tags, or whatever the person who writes the dtd decides is best.

Then we don't just have a mercam, what we have is a mercam type, and we put together a few resource files for folks to choose from that configure a different mercam. Glance behavior would be configured in the resource file and would be implemented by the camera, so mercam implements mercam's glance, zcam implements the old glance, etc. That's where the inheritance thing kicks in. The base camera class has virtual methods that handle input, but the subclass has to implement them to handle input its way, and it may or may not expose configuration through the resource file.

In the end, the only camera config options that should be left in the game are the slots, all other camera config should be delegated to the resource files.

Now, we'd have to think about custom cam specifically. I don't think the resource files will be terribly complicated, and anyone who can currently grok the custom cam config should be able to handle the resource files. However, some may disagree and want to provide a way to customize the camera ingame. Maybe we could expose the properties of the camera to the user and dream up a way to serialize the properties into a config file? I don't know, but it does require some thought.

Then we set the default camera slot config in the development series to stuff to show off what the cameras can do. :) As we get closer to the next stable release, we start working on default config that does what default config in a stable release should do: the easiest and most sensible config for the most users so that most users are happy without customizing. At least, that's what I think default config should be. :) After that, the first step for a user to customize would be to set one or more of his slots to various camera resources that are available, either shipped with the game or downloaded from somewhere or whatever. If a user can't find happiness that way, then he makes his own camera resource file.
Image

Be the devil's own, Lucifer's my name.
- Iron Maiden
meriton
Round Winner
Posts: 256
Joined: Sun Nov 20, 2005 3:33 am

Post by meriton »

It would help if those who prefer the old camera stated why they prefer it. That way, I - and other working on the camera code - could improve it and keep the things you like. If we don't know what you like, the only way to make sure you stay happy would be to cease improving the camera, and it should be clear why that is not an option.

@Lucifer: I am not at all opposed to a configuration system, I am sorry if my arguing about details gave you the idea I dislike the idea as a whole. The design with putting camera control logic in a family of subclasses looks good to me. I'd like that design very much, in fact. The reason I did not offer to do this, and very probably the reason z-man didn't do this long ago are a combination of two things:

1. The camera code is very messy. We are talking half a dozen camera modes sharing the same datastructures and also sharing code without any discernable kind of organization. As a result, the code is very fragile, and changes - especially major changes such as a refactoring - are likely to affect camera behaviour.
2. People are very sensitive to the camera and complain loudly about every change, minor as it may seem to others. People refuse (or at least announce that they refuse) to upgrade to the new version because they don't like changes.

So we are deadlocked.

What I tried to express when you last mentioned this configuration idea was that how that camera should be configured by the ressource file seemed very fuzzy to me. What settings can be exposed? Is there enough flexibility be the settings we have now or do we need new ones? What could they look like? And how can they be supported in the code?
User avatar
Lucifer
Project Developer
Posts: 8640
Joined: Sun Aug 15, 2004 3:32 pm
Location: Republic of Texas
Contact:

Post by Lucifer »

Actually, I agree that we shouldn't go making a ton of config items in the regular configuration system for cameras. For pretty much all the reasons you gave. :)

Ok, I see and understand the deadlock, it's the same situation with rubber and even *gasp* lag (where people reject some changes the correct for lag because they're used to the lag but don't want to admit it, heh). As for the old tastes item, I think we can address that in a useful manner. As for the code refactoring problem, quite frankly I don't know where the camera lives in the renderer, it's entirely possible that serious work can't be done there until we get to the renderer itself, and that's a task that's quite honestly overwhelming when you try to wrap your head around it, and the amount of work that lies between here and there is enough to make my head spin.

So, with that going, to your last part. :) Each camera type would determine what's available in its resource file, so two resource files for different camera types don't have to look anything alike. Let's go with the idea that you're a miser about configuration because whether true or not, it shows what I'm saying. :)

Let's say you decide the only two configuration parameters that make sense are angular velocity to and from a glance. So you stick those in your resource file and that's all. It'll be a very small file.

Then someone else comes along and turns the custom cam into a camera type. They take all the existing CAMERA_CUSTOM config items and turn them into parameters in the resource file.

Does that make more sense? The idea is to separate the camera types so that they no longer depend on the same stuff and they can work completely differently, arbitrarily even. Ultimately we'd want to allow scripters to write new camera types.

The idea with the slot system is to preserve the incam-only server, because those are cool servers. :) (not that you asked about it, but I thought I'd toss it in there)
Image

Be the devil's own, Lucifer's my name.
- Iron Maiden
User avatar
Jonathan
A Brave Victim
Posts: 3391
Joined: Thu Feb 03, 2005 12:50 am
Location: Not really lurking anymore

Post by Jonathan »

meriton: what I liked about the old custom cam was its responsiveness and that it could quickly be pointed anywhere (I don't have the current version; is that what got destroyed?). The overview without glancing was also great, but I don't think that changed. It could be used for rapidly scanning the entire grid, and it would always end up in a well-defined direction (at least it got close very quickly).

Lucifer: all the camera does is control the projection.
k
Random Identifier & Project Developer
Posts: 345
Joined: Wed Feb 25, 2004 12:54 am
Location: Northern California, USA

Post by k »

meriton wrote:It would help if those who prefer the old camera stated why they prefer it.
Sometime it's hard to teach a somewhat old dog new tricks. :D After playing for years with the old smart cam and old glancing it is deeply ingrained how it works and what to expect. Playing with the new camera/glancing just doesn't work well for me. Since it was a standard part of the game for so many years I think it should at least be an option.
meriton
Round Winner
Posts: 256
Joined: Sun Nov 20, 2005 3:33 am

Post by meriton »

@Lucifer:
I'm all for factoring out the settings in their own files. Once that is done I'd even welcome new config settings ;)

@Jonathan:
I did not change the camera mode itself, only the behavior when glancing. Unless someone else changed the camera itself, it should be as responsive as ever. "Quickly pointing anywhere" has become "quickly point in any axis direction" (for 4 axes; for more axes, the glance keys still do 90 degree turns). Does that restriction bother you?

@K:
After playing for years with the old smart cam and old glancing it is deeply ingrained how it works and what to expect. Playing with the new camera/glancing just doesn't work well for me.
Could you be more specific as to what irritates you? Is it the change of angle and camera height when you start glancing? Are you bothered about the limitation about stopping to glance when the camera is outside the grid? Or something else?
User avatar
Lackadaisical
Shutout Match Winner
Posts: 823
Joined: Sun Dec 21, 2003 4:58 pm
Location: Amsterdam, Netherlands
Contact:

Post by Lackadaisical »

The thing that bothered me when i first started using the cam is the fact that the view doesn't change when you move/turn your bike. For example, when i start making a def around the zone i tend to use the glance button towards the zone(left or right depending if i go counterclockwise or clockwise) so i can make my def go close around the zone. With the old behaviour i could just keep pressing the glancing button, but with the new behaviour i need to glance, turn, go back to 'normal view', and glance again.

Also, iirc the camera goes too slow to 'normal view' after you've glanced in smart cam. I'm using a custom cam now and it's fine there.
Luke-Jr
Dr Z Level
Posts: 2246
Joined: Sun Mar 20, 2005 4:03 pm
Location: IM: [email protected]

Post by Luke-Jr »

I prefer the old glance because the change is instant, and because it always shows the same angle to my vehicle.
I prefer the new glance because the change is smooth, and because it shows to the left/right of whatever I was currently looking at, and doesn't change when I turn.

If you make them into separate cameras, we can't use both. I'd suggest making them into simply "QuickGlance Left" or "Pivot Camera Left" keybinding options.
k
Random Identifier & Project Developer
Posts: 345
Joined: Wed Feb 25, 2004 12:54 am
Location: Northern California, USA

Post by k »

meriton wrote:@K: Could you be more specific? Is it the change of angle and camera height when you start glancing? Are you bothered about the limitation about stopping to glance when the camera is outside the grid? Or something else?
Here's what I like about the old camera. When glancing the camera angle and distance from the cycle stay fixed. When glancing backwards and releasing the glance key the view instantly switched to the front instead of slowly panning down and rotating over the cycle back to the front. Glancing to the side quickly panned back to the front when released. It's simple, quick, predictable, and efficient. With the new camera half the time I don't know what the camera is going to do when glancing while turning. The zooming out and slowly zooming and panning back in make it a lot easier to get motion sickness. It does a lot more than what I want in a camera/glance system.
User avatar
dlh
Formerly That OS X Guy
Posts: 2035
Joined: Fri Jan 02, 2004 12:05 am
Contact:

Post by dlh »

Patch still applied pretty cleanly. Available at https://code.launchpad.net/~dlh/armaget ... d-glancing
Post Reply