➟ Proceed to August 2008.
The EB acknowledgement key has not been working in a while, which has been fixed now. Also, the AI driver was previously not able to handle the EB, which it now can.
An ATS-P bug has been fixed where the security system did not allow the emergency brakes to be applied after passing a red signal when a brake release was acquired. Various modifications have been made to prepare the release of version 0.6, including a performance optimization in the renderer and the introduction of proper error handling in some parsers which did not have one. Overall, the current state of development seems to be stable enough and feature-complete for the version 0.6 release, so version 0.6.0.0 has been published today. A problem related to the EB device has been solved when the device did not correctly work together with ATS-P. Additionally, the train was previously able to receive the distance to the next red signal even when crossing an ATS-P immediate stop transponder, which is presumably unrealistic and led to a series of brake applications on routes not properly equipped with ATS-P origin transponders. Thus, the immediate stop transponder now only forces the train to stop when the immediate signal is red, not adding in calculating the brake curve when the immediate signal is not red (which is left solely to the pattern origin transponders).
I have started to create pole graphics for the compatibility objects as BVE uses default objects when the route does not specify its own. Additionally, I found two very serious problems with the lighting. First, the light source previously rotated along with the camera direction. Second, I incorrectly assumed that the Route.LightDirection command specified coordinates instead of angles simply because I did not read Mackoy's specification well enough. Both problems are fixed now, although BVE seems to have a bug when the Route.LightDirection is set to 180;0. The light should point to the back then, but in BVE, it comes from above. I do not intend in replicating this behavior. Previously, the background image was affected by lighting, too, which did not occur in BVE, so lighting for the background has been disabled now. As for the compatibility poles, the single (left-sided) pole has been created using mostly photo-realistic textures.
The compatibility poles are now used when no custom poles are specified, making the work on the poles complete. In BVE routes, the Track.Signal command can be used to create invisible yet functional signals. Although this has been being supported in openBVE, it previously affected the ATS-P system, the interface messages, the AI, and other train-related internals. Now, it only affects the signalling, but is completely shielded from the rest of the game, increasing the compatibility on some routes, prominently those which used invisible signals as a means of controlling the transition from ATS to ATC.
I spent the day figuring out why the calls to the other functions did not work so far, and it seems that I have problems with the calling convention, or the way it is being used by the proxy to dynamically load the DLLs. This requires some time-expensive investigation before development can continue normally. A slight change has been made to the route parser which will now only treat numbers inside the [railway] section as track positions for RW routes, which was not previously the case and could lead to a bunch of problems.
I finally made some progress in communicating with the ATS DLL plugins. I have only accessed the DLLs in a debugger so far, but it seems that the interaction is working normally. Work can now begin to incorporate the plugin functionality into the actual program.
The plugin functionality is currently being integrated into the game using direct calls from C# without a proxy as it caused memory corruption problems, but it will take a while to test if the plugins actually work correctly.
I have successfully ported the calls to GLFW into calls to SDL. This way, I can get rid of GLFW which caused problems on some systems due to the incompatibility of the glfw.dll on those systems. Additionally, as I want to incorporate joystick support in the future, SDL is the more promising framework anyway. Initially, I noticed a serious drop in frame rates, which was due to the fact that SDL by default displays a mouse cursor on top of the screen, but by disabling it, there is no visible difference in performance between SDL and GLFW. Furthermore, I have implemented a new keyboard management system which will allow for customizable keys in the future, although some keys are currently unavailable. All keys have been reimplemented and also, the additional keys used by the security system plugins have been added.
The sound interaction with the ATS DLL plugin has been implemented and seems to work correctly. The SetBrake command sent to the plugin now reflects the use of the emergency brake and my assumption of how the interaction with a train using the automatic air brake would work. However I cannot currently test the latter one due to the lack of suitable trains.
All commands, including the SetSignal and SetBeaconData, are now passed to the plugin. It seems that my poor understanding of the largely undocumented behavior of the DLL commands results in the plugins not working correctly. The most significant problems are that first the beacon and signal data is probably completely wrong due to my lack of understanding. The other problem is that the handles the plugin should normally able to set is not set in the lifetime of the plugin, making it pretty useless currently. Also, there are certain sound-related issues when sounds are instructed to be played in a loop even when I know they should not.
The handles the ATS DLL plugin requests are now sent to the train and thus, the plugin has control over the train, which seems to even work in most cases.
I have logged the changes the plugin makes to the sound array in order to find out why certain sounds are issued to be played in a loop at the beginning of the game, but so far, I could not find the answer to this question.
The delays for the power and brake notch have not been working anymore for quite some time. The problem has been fixed though and now the delays work again as they did once upon a time.
The SetBeaconData and SetSignal commands sent to the plugin have been modified to report a signal aspect of 255 when no explicit signal is available as done in BVE. I have made a preview release version 0.6.9.0 available for publicly testing the plugins. Previously, the pretrain could trigger route sounds like set up using the Route.Announce command, which were then not played anymore for the player. This has been corrected to only trigger those sounds for the player's train.
The power, brake and emergency brake handles have been completely overhauled in order to allow better interaction with the security systems. Now, they are stored in three ways each: the driver's setting, the security system's setting and the actual setting, which accounts for the delays. A bug with the kmphd0, kmphd1 and kmphd2 suspects in BVE 4 panels has been corrected which prevented digital speedometers from displaying correctly.
Some parts in the initialization procedure of the ATS DLL plugin has been changed to better reflect the behavior of BVE, however, it still does not match exactly. Some few bugs have been corrected concerning the previous train and the emergency brake.
Delays have been added to the automatic air brake handle and to the emergency brake. The ATS DLL plugins can now also use the automatic air brake, which was previously unavailable to them. The way BVE 4 glow images are loaded has been changed. Previously, increasing the contrast in the images could force yellow-golden glow to become orange-red. Now, the process is as follows: Replace pure black by pure white, invert the image, hue-shift the image by 180 degrees, multiply the image by its own lightness mask, box-blur the image with radius 2 and finally multiply the image by its own lightness mask once again. The result preserves the color while converting a disk-like corona-employing image into a smoothly rounded glow image suitable for additive blending.
A problem with the compatibility functions for Linux and Mac has been corrected which prevented files to be correctly found on those systems. As for the X parser, the Mesh command is available again with, this time in the new parsing engine, resulting in the shapes of objects to be visible again, but as previously, with pure white faces only. The MeshMaterialList and Material templates have been added to the X parser, incorporating face color and emissive color.
The MeshNormals template has been added, too. Additionally, a bug has been fixed which prevented normals to be correctly faced after an object had been rotated in the route parser. Support for the binary flavor of the X format has been added, to the necessary degree that is. I think it is safe to say that the X format is one of the most complex and stupid file formats I have ever encountered. Anyway, for the first time I was able to run Mackoy's Keisei Chiba Line in openBVE, although a minor amount of objects are compressed X files and thus not supported. Additionally, some textures seem to be missing on my computer and some faces are still pure white, maybe because of that, but maybe due to parsing incompatibilities. Still, this allows a lot of more BVE 4 routes to be used in openBVE now.
The timetable can now be roughly rendered and displayed in-game. Some layout adjustments and a little beautification are still required.
The default timetable has been completely implemented now. As a result, the Route.Timetable command in CSV (or RW) routes has been made available, too.
Custom BVE 4 timetables are now available as support for the Train.Timetable has been introduced, as well as the necessary addition to the Train.Sta command.
The validation checks employed by the route parser have been checked and improved in some cases. The error messages have also been made a little more precise for some errors. The Track.FreeObj command has been extended to employ Yaw, Pitch and Roll as parameters for rotation. The source code has been a little optimized along with this addition in order to replace all rotation functions using angles by those using solely precomputed cosines and sines. As angles are commonly shared within the route parser and train updates, recomputing those trigonometric functions for every rotation was simply unnecessary.
The blend modes and glow attenuation have been reworked. The available blend modes are now Normal and Additive, while glow can be applied to any of them separately. A custom glow application distance can be chosen as well as the underlying attenuation function. Other functions than those currently built-in could also be added in the future if necessary. Additionally, the default distance for BVE 4 signals has been changed to fade out more quickly than before.
The Options.BlockLength and Options.UnitOfLength commands have been added to the route parser. Furthermore, the Track.Announce command has been extended to allow for speed attenuation. The function which calculates the forward and backward viewing distance based on the camera direction has been finally reworked into a mathematically correct implementation, while previously, only an approximation was used, which could force objects to become invisible even when they were inside the viewing frustum. Scripted camera view points have been mostly made available via the new Track.PointOfInterest command. It is already possible to jump between adjacent points via the keyboard.
➟ Proceed to August 2008. |