➟ Go back to November 2008.
➟ Proceed to January 2009.
| In these blog entries, you will find information on the things that I am currently working on. Whatever you read in recent entries does not necessarily describe things that are available for public download. The sole purpose of this blog is to inform you about the progress on development which will eventually - that is, in the future - result in an actual release of those features. Do not mistake this blog for a changelog. |
I have been trying to get forward/backward shaking due to acceleration to work, but it seems that I am unable to get this right. As such, I am dropping that feature for now, thus you will not get any shaking when coming to a complete hold, or accelerate abruptly. I will try working on this again in the future, though.
ObjectViewer and RouteViewer have been given the most recent versions of the object and route parsers to fix a few problems that had been resolved in the openBVE main program. RouteViewer is now also capable of showing animated objects, albeit with some restrictions regarding current time and trains if referenced by any of the associated functions.
Given the progress on the animated objects, there is a good chance that they will already be an official feature for version 1.0. As such, I have started writing a formula parser for infix notation. The parser first converts an infix notation (e.g. a+b) into a functional notation (e.g. plus[a,b]), and then into the postfix notation (RPN) (e.g. a b +) as required by the underlying stack-based processing engine for the function scripts. This approach has certain advantages, especially when mixing functional notation with infix notation and when dealing with longer formulas. The parser is basically finished, but not yet integrated into openBVE.
The infix notation formula parser has been integrated into openBVE now. The Track.AnimatedObj command, which resembled Track.FreeObj in syntax so far, has been added an additional Section parameter, which works similar to Track.SigF in that either the current or any of the following sections can be referenced. Via an additional variable available to the functions, any animated object can now query the state of the associated section and thus work as a signal, allowing semaphores, blinking signals, and the like. I have added blinking signals to my version of DemoRoute1 for testing purposes, and the feature work quite fine. I will release samples tomorrow.
I have supplemented the infix notation parser with operators for comparisons and logical combinations. A semaphore signal has also been added to DemoRoute1. For demonstration, RouteViewer, ObjectViewer, openBVE itself (v0.9.1.15) and DemoRoute1 are now updated and made available.
I have ditched the old implementation of the buffer and chain coupler and have written a new one instead. The old algorithm had one particular design problem: It worked by comparing the distance between a car and its up to two adjacent cars to minimum and maximum thresholds. If the thresholds were exceeded, the car would be repositioned according to its own mass and the mass of the respective adjacent car. A problem arose when a collision happened both with the front and the rear car in that both their respective maximum or minimum thresholds were exceeded. By design, the algorithm did not guarantee that the distance between the cars would be within the thresholds in this case, which became noticeable when using a locomotive and lots of unpowered trailer cars.
The new algorithm works as follows: First of all, the center of mass in the train is calculated, leading to either of two cases: 1) The center of a certain car is closest to the mass center (usually happens when the number of cars is odd), or 2) The coupler in-between two cars is closest to the mass center (mostly when the number of cars is even). In the first case, the respective car is left where it is, while the group of cars in front of it and the group of cars behind it are handled separately. The algorithm basically works in an in-to-out fashion in that it successively corrects the position of the cars closest to the center-of-mass car, then the cars following these, and so on, until the end-of-the-train cars are reached. This way, the algorithm ensures that after a correction is performed, the distances between the cars are always within the thresholds. The speeds of the cars are also corrected by averaging the speeds of all those consecutive cars that have collided. The new algorithm seems not to create further problems.
When testing collisions with buffer stops, I noticed a problem which could made the first or last car jump to the other end of the train. This is corrected now.
I have started implementing jerk regulation for the motor power, which works, also effecting the motor sound accordingly.
During the last days, I was hoping to finally find the cause of the sound bug that has been plaguing openBVE for months. The problem most oftenly manifests itself by having the flange sound at the same pitch as the motor sound, although less frequently, other sounds are effected, too. One of the biggest difficulties in analyzing the problem is its inherent random nature of occurence. I have audited all parts of the source code regarding motor sound, flange sound, and sound in general, and have also written code to detect anomalities in the sound subsystem, but without success. Due to code that I recently modified regarding jerk and acceleration, the problem seems to occur less often, which is some sort of an indication that openBVE's code is at fault, and not necessarily OpenAL.
Today, I have completed implementing jerk regulation for the motor power and motor brake. There are now four values available regarding jerk that can be adjusted, but which are currently left at the default value of 1 m/s³.
The extensions.cfg has been given additional options to allow to set up lengths for individual cars, to position the axles manually and to define the distances between the cars. I had made such proposals back in July, and it was probably about time to finally implement them. I am still uncertain though whether or not to include coupler objects.
Shaking the train forward and backward due to changes in acceleration is something that I still find difficult to implement. But contrary to my failed previous attempts to get this effect believable, the implementation I made today seems to be the first usable one. While I anticipated underdamped oscillation, this implementation uses rather some sort of an overdamped one. Nonetheless, I will keep this implementation until I can come up with something better.
When boarding at stations, shaking due to entering and leaving passengers has been implemented, too, now.
Unfortunately, there was still a remaining problem with the panel2.cfg parser, which inverted the yaw angle obtained via the difference between the x-origin and the x-center values. This is now corrected, and the center and origin values correctly correspond to the center-of-the-screen pixel in the bitmap and the pixel corresponding to the vanishing point at the horizon, respectively.
Upon investigating why static and animated objects where aligned differently on gradients and when yaw, pitch or roll was explicitly assigned, I needed to notice that the geometric transforms in the route parser actually never really worked in the lifetime of openBVE as I intended them to. As such, I have rewritten large parts of the object manager and have also simplified the code that does the transformations, resulting in slightly shorter loading times due to fewer trigonometric function calls.
I prepared the release of the 0.9.2 series and also finally started on redesigning the homepage to exclusively make use of the homepage generating software that I wrote quite a while ago.
The Jam parameter in Track.Sta now not only affects the amount of shaking at stations, but also how sensitive the passengers are during driving regarding discomfort.
I noticed that some signals did not load correctly and found that the order of precedence for object file extensions was inadequate. When no extension is indicated, openBVE would first look for B3D files, then CSV and finally X. I have reversed this order now so that signals will first try to load X files, which is what is commonly the case.
The cause of the major sound bug that has been plaguing openBVE for months has finally been found and corrected. In previous versions, some sounds would play with a seemingly random pitch or gain occasionally and usually non-reproducably. The problem resulted from the fact that the sound manager could stop sounds and free their handles if the respective sounds were too far away from the listener or too many sounds were playing at the same time, but the train manager still had a handle to that sound and was trying to modify its pitch or gain, resulting in a change of another sound which had been assigned the just freed handle.
In previous versions, some sounds were modified in volume by a quadratic formula which only worked in the range from 0 to 1. As openBVE uses some sort of high dynamic range volume, occasionally volumes higher than 1 are encountered and incorrectly modified, forcing such high-volume sounds to become essentially mute instead. This has been resolved by not making use of such quadratic formulas any longer.
The Track.Rail command for a certain rail index is handled differenly now when occuring multiple times on the same track position. Previously, the first command took effect while subsequent ones were ignored, while now, the first one acts just like Track.RailEnd in that it creates a disconnected piece of rail, while subsequent commands mark the start of a new rail. This behavior is required for compatibility, for example with the Tanigumi line.
Previously, on a change of background images, the newer background image would instantly replace the older one. This has been changed now so that the new image smoothly fades in.
➟ Go back to November 2008.
➟ Proceed to January 2009.
|
|
