Progress with a GNU/OpenGL version of Openrails
#1
Posted 05 February 2021 - 01:59 AM
As a covid project I’ve been working on a GNU/OpenGL version of OpenRails, initially for linux but in principal it can also be used with other operating systems. It has reached the stage where, with some exceptions, land, buildings, rail tracks, engines and wagons are displayed but nothing moves. The code is available from github (https://github.com/djw-zr/ZR) where the top level README file gives more details.
Regards,
David Webb.
Regards,
David Webb.
#2
Posted 05 February 2021 - 05:39 AM
David Webb, on 05 February 2021 - 01:59 AM, said:
As a covid project I’ve been working on a GNU/OpenGL version of OpenRails, initially for linux but in principal it can also be used with other operating systems. It has reached the stage where, with some exceptions, land, buildings, rail tracks, engines and wagons are displayed but nothing moves. The code is available from github (https://github.com/djw-zr/ZR) where the top level README file gives more details.
Regards,
David Webb.
Regards,
David Webb.
NICE!
I await these developments with eagerness.
#3
Posted 05 February 2021 - 11:05 AM
Hi David,
It looks as though you've completed a terrific amount of work - well done. You clearly have a good understanding of the graphics system.
Through the website, I get occasional requests for Open Rails on Linux and Mac, but these mostly come from non-programmers. I will pass on your URL to Miguel Gameiro who enquired and might have some skills.
David Webb, on 05 February 2021 - 01:59 AM, said:
As a covid project I’ve been working on a GNU/OpenGL version of OpenRails, initially for linux but in principal it can also be used with other operating systems.
It looks as though you've completed a terrific amount of work - well done. You clearly have a good understanding of the graphics system.
Through the website, I get occasional requests for Open Rails on Linux and Mac, but these mostly come from non-programmers. I will pass on your URL to Miguel Gameiro who enquired and might have some skills.
#5
Posted 23 August 2021 - 01:54 PM
I decided to upload my personal train simulator to github so that others could use it or look at the code. It also currently only runs on Linux. It is available at https://github.com/dajones42/rmsim.
Doug
Doug
#6
Posted 24 August 2021 - 12:25 AM
Doug,
I had a quick look at your code - you seem to have been using it for a long time - and include ships so I assume you live near the coast. I was also surprised how little code you need compared say with OpenRails but maybe OSG is doing a lot of the file reading and conversion.
There is another port of MSTS/OpenRails reported here.
I'll use this list to report further progress with my own system. I now have multiple trains and have the wheels turning (using the matrices). I'll upload this to github when I next have time to clean up the code a bit. After that he next job is to use the shape file animation data for signals, crossing etc and the engine running gear but although the program reads the data, I have not worked out how to use it. I'd welcome any clues.
David.
I had a quick look at your code - you seem to have been using it for a long time - and include ships so I assume you live near the coast. I was also surprised how little code you need compared say with OpenRails but maybe OSG is doing a lot of the file reading and conversion.
There is another port of MSTS/OpenRails reported here.
I'll use this list to report further progress with my own system. I now have multiple trains and have the wheels turning (using the matrices). I'll upload this to github when I next have time to clean up the code a bit. After that he next job is to use the shape file animation data for signals, crossing etc and the engine running gear but although the program reads the data, I have not worked out how to use it. I'd welcome any clues.
David.
#7
Posted 29 September 2021 - 06:32 AM
For any prospective developer of a OpenRails port for macOS: please note OpenGL is deprecated from version 10.14 onwards, and can be removed at any time by Apple. I guess it will happen sometime when all Mac models have an Apple Silicon variant, so in about a year and a half.
There are middleware libraries that can translate OpenGL to Metal (MoltenGL), but this will inherently incur a performance penalty.
There are middleware libraries that can translate OpenGL to Metal (MoltenGL), but this will inherently incur a performance penalty.
#8
Posted 29 September 2021 - 12:05 PM
I get your point, but I suspect that the graphics interface requirement will always be a minor problem, compared with data input and all the logic concerned with train dynamics and track logic.
At the moment my ZR program has about 18000 lines of code of which only around 800 involve OpenGL calls and even that includes a lot of repetition and, with thought, could be reduced - maybe by a factor of four, maybe more if I removed all the (inefficient?) display lists. All 3D plotting systems have a similar need to deal with triangular meshes, textures, lighting, distance etc. etc - and although the calls may be different the logic is always likely to be similar.
A few hundred lines of OpenGL code should not take long to convert to the most efficient Apple graphics system. It should also be possible to switch between OpenGL calls and Apple whatever at the pre-processor stage using #ifdefs.
The other problem with different operating systems are the differences in the interface to the system, i.e. the handling of keyboards and sound. For this packages like OSG (Open Scene Graph) may be the way forward.
As far as Apple is concerned they will almost certainly always support C, will probably always have OSG support but, almost certainly, will never support C#.
Regards,
David.
At the moment my ZR program has about 18000 lines of code of which only around 800 involve OpenGL calls and even that includes a lot of repetition and, with thought, could be reduced - maybe by a factor of four, maybe more if I removed all the (inefficient?) display lists. All 3D plotting systems have a similar need to deal with triangular meshes, textures, lighting, distance etc. etc - and although the calls may be different the logic is always likely to be similar.
A few hundred lines of OpenGL code should not take long to convert to the most efficient Apple graphics system. It should also be possible to switch between OpenGL calls and Apple whatever at the pre-processor stage using #ifdefs.
The other problem with different operating systems are the differences in the interface to the system, i.e. the handling of keyboards and sound. For this packages like OSG (Open Scene Graph) may be the way forward.
As far as Apple is concerned they will almost certainly always support C, will probably always have OSG support but, almost certainly, will never support C#.
Regards,
David.
#9
Posted 21 October 2021 - 03:05 AM
Version 0.3.0 of ZR is now available from github "https://github.com/djw-zr/ZR".
The code now supports multiple trains, each consisting of one or more engines and/or wagons. Improvements also include wheel rotation, steam engine running gear, and wagon loads.
The code now supports multiple trains, each consisting of one or more engines and/or wagons. Improvements also include wheel rotation, steam engine running gear, and wagon loads.
#10
Posted 01 April 2022 - 03:58 AM
Version 0.5.0 of ZR is now available from github "https://github.com/djw-zr/ZR".
The program now works with the seven standard MSTS routes as well as the Australian "au_great_zig_zag" route. It can be compiled on 64-bit Windows computers using the MinGW64 package and run using SDL2.
The program now works with the seven standard MSTS routes as well as the Australian "au_great_zig_zag" route. It can be compiled on 64-bit Windows computers using the MinGW64 package and run using SDL2.