Welcome to the LnLP Forums and Resource Area

We have updated our forums to the latest version. If you had an account you should be able to log in and use it as before. If not please create an account and we look forward to having you as a member.

Why is zoom in CO2 not like zoom everywhere else?

Joined
Jun 5, 2022
Messages
34
Points
8
Age
54
Location
England
I've seen a lot of discussion about having more zoom levels, but not much, if anything, about why the zoom is in 'levels' at all. What I mean is, if you think of it like your phone, you can pinch and 'zoom' the screen display to any magnification, whereas with CO2 you can only zoom to a very few set 'levels' of zoom. My question is, why can't we have a zoom function that mimics the zoom we're all used to. I only mention smartphones because it's difficult to describe the type of zoom I'm thinking of, so smartphones pinch-zoom function may be the best way to explain what I have in mind.

The reason this came to mind at all is because I was trying to screenshot my game today and with the current limited 'levels' of zoom, I can't get the full map to display in a screenshot at a reasonable size on my laptop's screen. It's either way too small, or too large to fit the whole map in the screenshot. A smartphone style zoom would solve all these problems.
 
Joined
Oct 20, 2014
Messages
1,182
Points
63
Age
76
Location
Livonia, MI (Detroit-area suburb)
I've seen a lot of discussion about having more zoom levels, but not much, if anything, about why the zoom is in 'levels' at all. What I mean is, if you think of it like your phone, you can pinch and 'zoom' the screen display to any magnification, whereas with CO2 you can only zoom to a very few set 'levels' of zoom. My question is, why can't we have a zoom function that mimics the zoom we're all used to. I only mention smartphones because it's difficult to describe the type of zoom I'm thinking of, so smartphones pinch-zoom function may be the best way to explain what I have in mind.

The reason this came to mind at all is because I was trying to screenshot my game today and with the current limited 'levels' of zoom, I can't get the full map to display in a screenshot at a reasonable size on my laptop's screen. It's either way too small, or too large to fit the whole map in the screenshot. A smartphone style zoom would solve all these problems.
How much game playing function are you willing to sacrifice for a more refined zoom function?

There's a limited amount of programming that can be stored in memory for the real time calculations the game makes as you play. It is cyclically accounting for all of the movement, line of sight, movement, and combat resolution you see as the game runs -- recalculating each bit of information multiple times per second in some instances (such as hit probability and damage). That information is reflected in the graphic display.

The zoom as it is structured now continues to display that information in real time after calculating what is best portrayed on the screen to facilitate game play at that level. Four levels of zoom for that display were the best balance of both realtime game calculation and graphic display for the program language selected to develop the game. Using that same language to change that display convention to an infinite number of zoom levels would drive a need for more graphical programming at the expense of the real time status calculations, possibly turning the feedback to the person conducting combat to a crawl.

Your cell phone can do that because the zoom it offers only deals with a graphical file as opposed to a graphical file which is showing what goes on in the background on the phone.

In this case, there's a lot going on in the background that you can't necessarily "see" but is critical to the smooth operation of the game as it runs.
 

Johannes82

Member
Joined
Jan 22, 2015
Messages
4
Points
1
Age
42
Location
Germany
How much game playing function are you willing to sacrifice for a more refined zoom function?

There's a limited amount of programming that can be stored in memory for the real time calculations the game makes as you play. It is cyclically accounting for all of the movement, line of sight, movement, and combat resolution you see as the game runs -- recalculating each bit of information multiple times per second in some instances (such as hit probability and damage). That information is reflected in the graphic display.

The zoom as it is structured now continues to display that information in real time after calculating what is best portrayed on the screen to facilitate game play at that level. Four levels of zoom for that display were the best balance of both realtime game calculation and graphic display for the program language selected to develop the game. Using that same language to change that display convention to an infinite number of zoom levels would drive a need for more graphical programming at the expense of the real time status calculations, possibly turning the feedback to the person conducting combat to a crawl.

Your cell phone can do that because the zoom it offers only deals with a graphical file as opposed to a graphical file which is showing what goes on in the background on the phone.

In this case, there's a lot going on in the background that you can't necessarily "see" but is critical to the smooth operation of the game as it runs.
I'm sorry, but that's complete nonsense. Of course it is possible to achieve both. Stepless zoom and game logic calculations. Even if this were not possible at the same time, you could simply pause the calculation of the game logic during the zoom process. So this statement is simply an excuse. The real problem is the architecture and implementation of the graphics presentation layer of CO2 which was certainly not a top priority and also not state of the art when it was first released. As a software engineer with 20 years of professional experience, I am qualified enough to comment on this.

Best regards,
Johannes
 
Joined
Oct 20, 2014
Messages
1,182
Points
63
Age
76
Location
Livonia, MI (Detroit-area suburb)
I'm sorry, but that's complete nonsense. Of course it is possible to achieve both. Stepless zoom and game logic calculations. Even if this were not possible at the same time, you could simply pause the calculation of the game logic during the zoom process. So this statement is simply an excuse. The real problem is the architecture and implementation of the graphics presentation layer of CO2 which was certainly not a top priority and also not state of the art when it was first released. As a software engineer with 20 years of professional experience, I am qualified enough to comment on this.

Best regards,
Johannes
Well, if you're so brilliant and accomplished in your profession, perhaps you could volunteer to solve this GUI problem.


In the 20 0r so years I have worked on the Command OPs planning and development team, the discussion of improved GUI revolved around the amount of calculating power the game absorbed to work out the real time mechanics of sighting / visibility, movenent, terrain effects, combat and individual units interacting with them, the conflict is between absorbing miore calculating power to offer a smoother graphical portrayal of the action at the expense of real time unit activity.

There are two programmers - one part time -- managing the software development. There is a significant number of advisors, testers and data managers working with them, but all the improvements they, and users suggest, have to be funnelled through them for resolutiion.

Your concern has a priority in the planning, but it's not at the front of the line until issues with unit behavior and artificial intelligence "staff" functions for friendly and enemy sides

You may know the solution but you know nothing about the size and organization of the team charged with implementing them.

This comes from someone with more than 20 years experience in project management. who, among other tasks, had the job of keeping software engineers on focus and within schedules of the projects I managed.
 
Top