Post by Major Pain on Sept 18, 2015 17:33:57 GMT 1
The discussion that has brought this topic back to life focuses on what happens outside of the first 32 x 32 ranges on a larger map.
The author is correct that the game does not process the actual coordinates that you wish to move a tank, or to fire a gun into, Most of the time you may get some kind of "Out of Script Area" or "VIL Error" or other similar type error before the game shuts down, which also can force a soft reset on your computer.
The issue is not quite as amplified on maps that are not square, but rectangular. That is only because the total over-all map coordinates has not reached the break over point... so it is clear that the game can find coordinates on a 15x64 map.
But in order to truly exploit the larger map sizes, a change is also required in the range/coordinate tables. VILs have been capped to not exceed a hard coded value. I can't recall that value at the moment but from memory I think it is the equivalent of a 48 height or 48 width. This would be derived by 32 plus 50%, or 150% of 32= 48. You always want to build your game tables with a 50% safety margin, but I have seen many later game engines in the 110% range.
Think of this for a second. We design an engine and drive train for a new car. In the United States, we have a few areas that drivers are allowed to drive 80 miles per hour. Most Interstate Highways are 70 or 75 miles per hour. Many State highways are 65 Mile per hour. And many local roads might be 45 to 55 miles per hour.
We know that drivers might be tempted to drive as fast as they can get away with. So in the US, 100 mph is not out of the question. Question: Should we build the engine/drive train for speeds of 100 mph. No, we better make sure the damn thing can reliably hold together at 150 mph. We just will not advertise this. Through the design of the engine that can perform at 2200-2400 rpm with very high gears in the differential (Say around 275 to 290), we can accomplish the goal. The lower the value of the differential gears allows higher speeds to be achieved.
I once had a Trans Am that had 292 Highway gears that could top out around 160 mph. Same car with 410 gears could run a 11 second 1/4 mile with a top speed of 125 mph. The engine was a 455-HD Bored 60 over, 12 to 1 compression, pop-up pistons, with a full race cam on a 4 speed slapstick Fairbanks-400 Transmission. The typical Pony Car of the Day, similar to the Chevy Camaro, Ford Mustang, Dodge Challenger, Oldsmobile 442... etc...
So why would we build our computers and game engines to max out very near the top of their limits. The answer should be 'we don't'. I want my hard drives to be 150% of what I expect to use, sometimes 200%. This is not hard to achieve today, so users more than ever are adding external or 2nd internal drives to their systems. They also add flash/thumb drives to make their projects mobile between systems.
I want my clock speed to be well over 1.5 GHz, with the option to be turned up around 1.8 GHz. So this means the top end should be at least 2.25 to 2.4 GHz. But Computers can process much more stuff than in years past so the GHz is not a good example in this discussion.... but it does have a light bearing.
The point is we do not build anything at the maximum operational level, we must add in a reasonable limit over and above what we expect our WIDGET to run at. And it is the same for the Blitzkrieg Enigma Game Engine. For those of you that have Blitzkrieg II, you are actually using the very same game engine, which has been throttled up with some new tools like zoom and rotate. So it become clear that the game engine was built beyond the normal operational levels. But this is not what limits the map size.
The map size and all of the required calculations are part of the game table and thresholds. In other words, these have been defined and hard coded where the normal user cannot exploit the data.. But as I mentioned, GEN II will address this in some fashion, but the limits or sizes have not been defined at this writing. There must be a lot of testing to see where the thing begins to degredate, or break down.
Just like we have not yet maxed out the Graphics capabilities of the game, the same is true for almost every other aspect. We can continue to push through the hard coded elements and I am sure we will begin to see the break-over points soon after. But when you think about just far past the graphical detail we have moved without finding a break-over, should we not also expect similar results in just about everything? We will see how it plays out.
In a nut shell, I think 64x64 maps are going to be quite possible in GEN II. But I must again pose the question: How many guys are going to want to work on a map that is 400% larger than what we have now? I just don't know the answer to that, so the argument may not matter and the option may not have much value behind it. Will it push the Computer or the game Engine past its limits? I don't think so, but it will push most mappers past their own limits.
At the time that the developers were defining what Blitzkrieg would be, they did pay attention to a scale in terms of metric. They did consider distances and ranges,. This is very obvious. What no one has discovered yet is how they defined the actual 'ratio' of true scale to get the values we use today. If we knew that, or soon discover it, that single ratio could change just about everything else in the game.... just by changing only that ratio value. I have not looked for it before now, but I suppose it should be located and defined.
The same can be considered as to speed. But speed has some other factors that I have not been able to quantify. Vehicles that should move at about the same speed as others, don't, with some of the speeds well out of a logical limits. So this is interesting because I do not know how they reached Speed values. They like distances are scaled. Before we do too much overthinking on this, we might want to first set a new scale ourselves and stick to it. This seems to be about the only place I can find fault in the game design, if you throw out water vessels and a tight airspace.
I'm sure more will be discussed in the future on this topic.
The author is correct that the game does not process the actual coordinates that you wish to move a tank, or to fire a gun into, Most of the time you may get some kind of "Out of Script Area" or "VIL Error" or other similar type error before the game shuts down, which also can force a soft reset on your computer.
The issue is not quite as amplified on maps that are not square, but rectangular. That is only because the total over-all map coordinates has not reached the break over point... so it is clear that the game can find coordinates on a 15x64 map.
But in order to truly exploit the larger map sizes, a change is also required in the range/coordinate tables. VILs have been capped to not exceed a hard coded value. I can't recall that value at the moment but from memory I think it is the equivalent of a 48 height or 48 width. This would be derived by 32 plus 50%, or 150% of 32= 48. You always want to build your game tables with a 50% safety margin, but I have seen many later game engines in the 110% range.
Think of this for a second. We design an engine and drive train for a new car. In the United States, we have a few areas that drivers are allowed to drive 80 miles per hour. Most Interstate Highways are 70 or 75 miles per hour. Many State highways are 65 Mile per hour. And many local roads might be 45 to 55 miles per hour.
We know that drivers might be tempted to drive as fast as they can get away with. So in the US, 100 mph is not out of the question. Question: Should we build the engine/drive train for speeds of 100 mph. No, we better make sure the damn thing can reliably hold together at 150 mph. We just will not advertise this. Through the design of the engine that can perform at 2200-2400 rpm with very high gears in the differential (Say around 275 to 290), we can accomplish the goal. The lower the value of the differential gears allows higher speeds to be achieved.
I once had a Trans Am that had 292 Highway gears that could top out around 160 mph. Same car with 410 gears could run a 11 second 1/4 mile with a top speed of 125 mph. The engine was a 455-HD Bored 60 over, 12 to 1 compression, pop-up pistons, with a full race cam on a 4 speed slapstick Fairbanks-400 Transmission. The typical Pony Car of the Day, similar to the Chevy Camaro, Ford Mustang, Dodge Challenger, Oldsmobile 442... etc...
So why would we build our computers and game engines to max out very near the top of their limits. The answer should be 'we don't'. I want my hard drives to be 150% of what I expect to use, sometimes 200%. This is not hard to achieve today, so users more than ever are adding external or 2nd internal drives to their systems. They also add flash/thumb drives to make their projects mobile between systems.
I want my clock speed to be well over 1.5 GHz, with the option to be turned up around 1.8 GHz. So this means the top end should be at least 2.25 to 2.4 GHz. But Computers can process much more stuff than in years past so the GHz is not a good example in this discussion.... but it does have a light bearing.
The point is we do not build anything at the maximum operational level, we must add in a reasonable limit over and above what we expect our WIDGET to run at. And it is the same for the Blitzkrieg Enigma Game Engine. For those of you that have Blitzkrieg II, you are actually using the very same game engine, which has been throttled up with some new tools like zoom and rotate. So it become clear that the game engine was built beyond the normal operational levels. But this is not what limits the map size.
The map size and all of the required calculations are part of the game table and thresholds. In other words, these have been defined and hard coded where the normal user cannot exploit the data.. But as I mentioned, GEN II will address this in some fashion, but the limits or sizes have not been defined at this writing. There must be a lot of testing to see where the thing begins to degredate, or break down.
Just like we have not yet maxed out the Graphics capabilities of the game, the same is true for almost every other aspect. We can continue to push through the hard coded elements and I am sure we will begin to see the break-over points soon after. But when you think about just far past the graphical detail we have moved without finding a break-over, should we not also expect similar results in just about everything? We will see how it plays out.
In a nut shell, I think 64x64 maps are going to be quite possible in GEN II. But I must again pose the question: How many guys are going to want to work on a map that is 400% larger than what we have now? I just don't know the answer to that, so the argument may not matter and the option may not have much value behind it. Will it push the Computer or the game Engine past its limits? I don't think so, but it will push most mappers past their own limits.
At the time that the developers were defining what Blitzkrieg would be, they did pay attention to a scale in terms of metric. They did consider distances and ranges,. This is very obvious. What no one has discovered yet is how they defined the actual 'ratio' of true scale to get the values we use today. If we knew that, or soon discover it, that single ratio could change just about everything else in the game.... just by changing only that ratio value. I have not looked for it before now, but I suppose it should be located and defined.
The same can be considered as to speed. But speed has some other factors that I have not been able to quantify. Vehicles that should move at about the same speed as others, don't, with some of the speeds well out of a logical limits. So this is interesting because I do not know how they reached Speed values. They like distances are scaled. Before we do too much overthinking on this, we might want to first set a new scale ourselves and stick to it. This seems to be about the only place I can find fault in the game design, if you throw out water vessels and a tight airspace.
I'm sure more will be discussed in the future on this topic.