Since a while I work on making Simutrans prettier. So far I've tried to make two pleasant UI themes, a light one, called Silver and a dark one, called Purple night. I've renovated the old pak48.Excentrique to higher res graphics, now 144 pixels.
And since my mind is restless and the pak64 seemed to deserve some love as well, I've started a pak64 makeover, by the name of pak72.Elegance.
But there still was the core, the game itself. I had not been doing any C++ coding for years, but I decided to give it a try. Along with my work on themes, not only station, town and factory labels became part of a theme, but also window title bars.
Today I finally found a way to work on something that I wanted since a long time. Better text display in Simutrans. Right now it's an ugly hack, has performance issues, eats memory and only works with the vector type fonts, but here it is - and with it, the official announcement of my Simutrans Prettification Project.
smooth_ttf_fonts.png
Step by step I want to go over all the dialogs, see if I can change them to make them more pleasant to look at, easier to use, and if possible, work better together (at least not get in the way so often). Code and demo releases will appear here:
https://github.com/Varkalandar/simutrans_ts
The TS is not particularly meaningful. I had a Simutrans repository already, forked from aburch/simutrans, so I needed to chose another name for this one, now forked from simutrans/simutrans. If you want, think of tomato and salad, a Simutrans fork with some goodies added. Or traffic starter, if you want something more transport related.
Wow, this is really magnificent!. 8) 8) 8)
I wonder if something can be done to improve the load bar?.
Captura desde 2023-01-31 19-39-36.png
Quote from: Yona-TYT on January 31, 2023, 11:39:55 PMWow, this is really magnificent!. 8) 8) 8)
I wonder if something can be done to improve the load bar?.
Thanks! And certainly. What exactly do you have in mind?
It's been tough to create a demo release, and convince the build pipeline to use the new TTF font and my updated translations in the archive. I have tested this with Linux and Windows, and it seems both packages work as expected.
https://github.com/Varkalandar/simutrans_ts/releases/tag/v0.03-alpha
There are still a lot of problems. In particular, the code does not handle font baselines properly, so some fonts (if you chose other than the Liberation Sans, with which I have tested) show too high or too low in the dialogs.
There is also a problem with the kerning (some characters are too far apart), but Simutrans font display routines don't know about kerning yet, and I have to implement that. Same for ascend and descend values (the reasons why some fonts are aligned too high or low). Also something for me to look into.
Compared to the screenshot yesterday I had to change the "weight" of the font slightly. The lines are now thicker, stronger. I have tested some settings and some fonts and think this is a good compromise which works with many fonts.
Furthermore I had to disable some checks in the language choice. At the moment all languages are enabled, even if the font does not support the characters. This is a workaround so you can at least try and see if some translation works with the chosen font.
So, what else is in there? If you chose the "Silver (large)" or "Purple Night (large)" themes, you will get theme defined window title bars, station, town, factory and marker labels. They all are not final, just to show that the code actually works.
Furthermore there is a slightly changed pak selector, with a (I think) better layout.
pak_selector.png
And I've started to change the depot windows slightly. Instead of having an empty space at the bottom to show vehicle details, the details are now shown in an overlay over some of the controls. It only appears if the mouse is over a vehicle, so will disappear if you move the mouse elsewhere, so you can use the controls.
Also, I tried to get the values into a more tabular order. There are some problems there still, sometimes texts are cut off with ellipses "..." even if there is enough space. I must look into that, apparently the calculation of the text length got broken in some cases due to my changes on the font routines.
Quote from: _Hajo_ on February 01, 2023, 08:02:19 PMThanks! And certainly. What exactly do you have in mind?
Mainly the shape of the bar, for example making the edges rounded, as seen in the new styles of the station labels.
And customizable background would also be nice.
Currently only two colors can be changed on this bar.
I think the theme is already loaded at the point, also the preview/title image from the pak. Should be doable to use either source to define the loading bar looks. But maybe we should discuss the details in another thread.
I will say this once and only once: If anyone uses this for Comic Sans, I WILL reach through the internet and slap you AND ban your account from this forum. ;-)
edit: Same goes for Papyrus...
Quote from: Isaac Eiland-Hall on February 01, 2023, 10:06:52 PMI will say this once and only once: If anyone uses this for Comic Sans, I WILL reach through the internet and slap you AND ban your account from this forum. ;-)
edit: Same goes for Papyrus...
Just a moment ! And why so much hate towards those fonts in particular?. :police: ^-^
Nice that you are working on the fonts code (to move away from fixed size bitmaps).
Quote from: _Hajo_ on February 01, 2023, 08:02:19 PMThere are some problems there still, sometimes texts are cut off with ellipses "..." even if there is enough space. I must look into that, apparently the calculation of the text length got broken in some cases due to my changes on the font routines.
This happens if the string changes after the assignment of the element sizes is done. Not sure what a proper fix would look like. I solved this by calling ``resize(scr_size(0,0));'' whenever some string label changed. see eg at the end of depot_frame_t::update_data() or within some of these draw(...) methods, another example is in convoi_info_t::update_labels()
Quote from: Dwachs on February 02, 2023, 12:41:45 PMNice that you are working on the fonts code (to move away from fixed size bitmaps).
Thank you. The real thanks must go to the person though, who implemented the FreeType support. Without that previous work, it wouldn't have been possible.
Also thanks for the hint with the ellipses and the label sizes. I had been looking into it, but couldn't figure out the real problem :o
I made the spaces of the new fonts a little smaller, and tidied up the display of data in the depot dialogs some more.
simscr41.png
Demo versions for testing can be found here:
https://github.com/Varkalandar/simutrans_ts/releases/tag/v0.04-alpha
Quote from: Isaac Eiland-Hall on February 01, 2023, 10:06:52 PMI will say this once and only once: If anyone uses this for Comic Sans, I WILL reach through the internet and slap you AND ban your account from this forum. ;-)
edit: Same goes for Papyrus...
you do realize that that'll be the font pak192.comic will ship with? That's a lot of traveling you should be looking forward for here!
----
@Hajo finally proper fonts! Do you intend to make them part of the theme? Or be changed separately?
Quote from: Flemmbrav on February 02, 2023, 07:40:53 PMyou do realize that that'll be the font pak192.comic will ship with? That's a lot of traveling you should be looking forward for here!
----
@Hajo finally proper fonts! Do you intend to make them part of the theme? Or be changed separately?
Your questions and statements reawaken a concern I have.
As for whether we will have default themes in the paksets, I even did a little experiment last year -> https://forum.simutrans.com/index.php/topic,22162.0.html
Quote from: Flemmbrav on February 02, 2023, 07:40:53 PMyou do realize that that'll be the font pak192.comic will ship with? That's a lot of traveling you should be looking forward for here!
He doesn't need to, I'll personally slap you with a stinky fish if you attempt that! P192C already has a font - Komika Axis of the Komika-Bundle by Larry Yerkes. (Though that doesn't support lower case, so probably one of the Komika Text variants... [Idea for Hajo: Allow for "Title" and "Body" fonts to be chosen])
Quote from: _Hajo_ on January 31, 2023, 08:20:59 PMStep by step I want to go over all the dialogs, see if I can change them to make them more pleasant to look at, easier to use, and if possible, work better together (at least not get in the way so often).
Very nice!
Here is a general idea for you that might impact all kinds of dialogs: Expanding tooltip functionality.
A) Allow tooltips to be more than one line of text, but rather, a formatted, multi-line block of text that may include icons.
B) Allow tooltips to be "pinned" - a way to make them stay open even if the mouse moves away, and to choose where it's positioned. (But also be closed if the dialog it belongs to is closed)
With A, existing tooltips can be prettier (eg. Name, cost, capacity of a station icon in separate lines) and more information might be possible due to better structure. But also, each vehicle could have it's stats as the tooltip instead of the current 'special' treatment in the depot to show it's stats. That same tooltip could also be shown in the convoi list and convoi details - wherever the vehicle appears in a dialog.
With B, it becomes much easier to compare things with each other. This is true for tracks and stations but even more so for vehicles. I also believe that one could incorporate most help texts in tooltips. Eg. in the finance dialog, the help describes each button individually. This could be done as tooltip for those buttons instead, but only if they can display more information and can be pinned to allow them to be studied.
Quote from: Flemmbrav on February 02, 2023, 07:40:53 PM@Hajo finally proper fonts! Do you intend to make them part of the theme? Or be changed separately?
Thank you. I had not thought about this yet, but I agree with the idea that a pak set should be able to define a preferred theme and also a font to offer a consistent user experience.
In the UI we can offer an option so users can override the pak defaults, so everyone should be happy.
Quote from: Leartin on February 03, 2023, 11:06:41 AM[Idea for Hajo: Allow for "Title" and "Body" fonts to be chosen])
Very nice!
Here is a general idea for you that might impact all kinds of dialogs: Expanding tooltip functionality.
A) Allow tooltips to be more than one line of text, but rather, a formatted, multi-line block of text that may include icons.
B) Allow tooltips to be "pinned" - a way to make them stay open even if the mouse moves away, and to choose where it's positioned. (But also be closed if the dialog it belongs to is closed)
Thanks to you as well. And yes, I am already looking into options to have more than one font size. Technically it's easy, the question is how to implement it properly, I mean the interface to chose different sizes. I think I have an idea, but I need more time to weigh the pros and cons.
In regard to A) - Multi line tool tips should be easy, there are already routines to display multi-line text, fitted into a box. I need to think about the icons some, how to address an icon from a piece of text. Maybe with some html-like syntax like <img src="identifier"> and have the name of the icon there as identifier (the name from a pak file). Again, I need more time to think about this and come up with a good idea. Also, a point that puzzled me, buttons can have tool tips, combo boxes apparently can not ... something to investigate as well.
For B) - I'll say this is beyond my current skills. Maybe once I know the code better.
Thanks for all the feedback!
Quote from: _Hajo_ on February 03, 2023, 12:56:09 PMMaybe with some html-like syntax like <img src="identifier">
If you use html syntax (an image tag), that would benefit me a lot with scripting scenarios!. ;D
Years ago I tried here: https://forum.simutrans.com/index.php/topic,15049.0.html
So, next steps ... I want to make a graphical pak selector. I found a way to load "symbol.BigLogo.pak" from all installed pak sets and display them. Due to size reasons I only display the upper half right now. I think I could also show a middle band without too much hassle. (and sorry for the placeholders ... I just noticed pak72.Elegance and pak144.Excentrique had no big logos yet, so I had to quickly make up something). Using theme-defined background will also come soon.
It's not very pretty at the moment and the code is quiet some hack. But it actually works ;D
preview_1.png
Needs checkboxes or stuff to load with and without addons ... and maybe some hint about the installation folder, like the old pak selector showed? Pak sets might show just twice right now, without hint why.
Code: https://github.com/Varkalandar/simutrans_ts/tree/feature/graphical_pak_selector
Demo (with luck, if the scripts work): https://github.com/Varkalandar/simutrans_ts/releases/tag/Nightly
But first. Weekend!
Been working on it some more. It's now a proper dialog, but that came at the price of leaving a margin for the toolbar, because dialogs are not allowed to overlap the toolbar space (even that there are no icons in it at this time).
To keep it symmetric, I apply the same margin on all 4 sides.
There are scrollbars now, so if you have many sets installed, you can scroll through them. There still is an omission. I need to calculate the actual height of the scrolled panel. So right now there is a fixed limit, but it will be dynamic soon.
The pak installer button works, but refresh of the icons does not. So after installing a new pak, one of the icons will be used twice. I'll look into that, how to refresh the icons list.
preview_2.png
IMHO only showing half of the big logo doesn't make that much sense.
I'd much more prefer to either show the whole big logo (and maybe make Simutrans start as a screen wide window to gain some space here),
or to have an extra image to be shown in the pakset chooser.
I agree. It's mostly been for testing if it works at all. Until there are special logos/icons made for the pak selector, I'll display the whole "big logo".
I think I have fixed everything meanwhile, but I've removed the option to chose with/without addons. Pak sets are always loaded with addons in this version.
I've attached two previews with the "Modern (Large)" theme and the "Silver (Large)" theme.
Quote from: Flemmbrav on February 06, 2023, 07:55:39 PM(and maybe make Simutrans start as a screen wide window to gain some space here)
I can't do that (I think). The staring window size is given in one of the simuconf.tabs
For those interested to try, demo versions should appear here in the next minutes (Android build is out of order though):
https://github.com/Varkalandar/simutrans_ts/releases/tag/Nightly
Code needs more cleanup. I will do that once there is an agreement on the final pak selector.
https://github.com/Varkalandar/simutrans_ts/tree/feature/graphical_pak_selector
Working on presentation is nice. Especially in the depot which is too large and cluttered.
However, does this work with a touchscreen? I mean there are no mouseover with a touchscreen. We had made quite an effort to use simutrans with a touchscreen ... so it would be great if the depot can work with touchscreen as well. For this the info probably need to stay after the first click.
And all the logos had assumed a black background. Can the background of the logo display be black as well?
My bad, I didn't think about touchscreen. So no, the new depot dialog doesn't work well with a touchscreen.
Meanwhile I had changed the background of the logos to theme_gui_t::gui_shadow_color
I'll change this to black.
Thank you for the info, Prissi!
Quote from: prissi on February 08, 2023, 07:46:43 AM...
However, does this work with a touchscreen? I mean there are no mouseover with a touchscreen. We had made quite an effort to use simutrans with a touchscreen ... so it would be great if the depot can work with touchscreen as well. F...
A completely different UI is needed for a touchscreen.
For the depot it would make more sense to use a vehicle list (picture on the left, data on the right) that can be scrolled.
Currently, vehicle data cannot be displayed with touch without buying the vehicle. At least that's how it has been in my testing so far.
During pak development I am using the factory list often, so see if Simutrans sets up the chains like I'd like it to.
So, I've started to work on the factory list as well. I've aligned the data in columns, gave the scrolled area a border and introduced background colors for odd and even rows. Also the rows are bigger now, because I don't think this is a space critical dialog.
I think if you start with one list, maybe it would be good to base it on this patch here:
https://forum.simutrans.com/index.php/topic,22171.msg202753.html#msg202753
That would also add extra functionality.
Also, since the list code has been recently unified, I think a more uniform display would be then better for all single line lists.
Quote from: prissi on February 09, 2023, 11:59:57 PMAlso, since the list code has been recently unified, I think a more uniform display would be then better for all single line lists.
I'm working on that. Sadly the appearance of lines is defined in the "draw" method of the *stats types and not the list, so one has to change each *stat type for the stripes. But the goal is just that, make all the lists appear with the same looks. It just takes time.
A second list is done in the new style, the city list.
Likely I'll not have time to work on more lists before next week.
Work in progress, just a preview.
- There are two font sizes now. "Normal" and "large", which is 120% of the normal size.
- Both can be drawn in bold style.
- I've aligned and unified sizes of input fields in the new world dialog.
Also, it showcases the larger font in the "Settings for a New Game" label, and the bold normal size font in the title bar.
I have no demo of this out yet.
More striped lists. I've also changed the station list to have indicator boxes like the factory list had, instead of shadow-colored vehicle names.
Demo versions are available here (including the updated new world and pak selector dialogs):
https://github.com/Varkalandar/simutrans_ts/releases/tag/v0.07
The Windows GDI build is broken. That is my fault, I had forgotten to test it during development, so I didn't notice till the release. There is also a problem with the android build, it also failed to build. Still, Windows, Linux and Mac builds are available.
Also, only the Silver and Purple Night themes are properly configured for the striped lists. Other themes will have striped lists, but likely in badly matching colors. I need to update them all.
Great, no doubt now it will be easier to look at those lists :D 8)
The new lists look nice. Definitely an improvement compared to now imo. :)
If it is possible, maybe the convoys on the right hand side in the vehicle list should be vertically aligned? Not sure if this has performance implications when there are 30k+ convoys on the map, however.
I think the striped list should go into the main code as soon as the themes can support his.
Same for the additional labels.
The depot needs more thought on how to handle touch. The current state is also not too good, but at least on can see stats.
Thanks for the feedback. I've not been feeling well recently but I hope to continue the work once I feel better again.
Long break, but that is my life. First, feeling down, burned out, then interested in other stuff, working on other game projects.
But eventually an idea itched me. I tried to resist, knowing how unlikely it is to actually complete it. And others tried it before.
Then, 4 days ago, I actually started. Started to work on an OpenGl backend for Simutrans. It was done before, I know, but I could not find anything related, so I started from scratch. Now 4 days later and countless mistakes that ate my time and sleep, I hate C++ again and also know why, but well, it works ... somewhat. It can load legacy pak files, draw lines and boxes. There is a mistake though in decoding partial transparent pixels from legacy pak files. I'll fix that some day, once I understand how they are actually encoded.
So why another OpenGL backend if the old one failed? In other game projects of mine I grew rather fond of blending textures, for simulated light effects, or just to make things pretty. This is very hard with the traditional backend of Simutrans, even if that one is very performant.
Pros:
- Full 32 bit graphics from pak files to screen (needs a new Makepak and recompiled paks)
- All OpenGL blending fancy, colors, full and partial transparency (at like no extra cost)
- I might bite the sour apple and actually replace terrain rendering with real polygon texture mapping instead of that abomination of synthesizing myriads of tiles in memory that currently is in Simutrans. Downside is just the size and integration of this abomination. Very hard to understand and replace with something equivalent, but off loaded to the graphics hardware.
Cons:
- OpenGL does not allow multithreaded rendering. So likely the turbo charged multithreaded backend will be more performant.
- The day/night cycle trickery is hard. I'll not support it.
- Player colors are also hard with OpenGL. I'll likely not support it. Maybe I'll try something with shaders ... maybe.
What do I have now? An OpenGL backend in its infancy. Problem is now psychology ... actually I have achieved most of what I wanted, even if looks very incomplete to other people. I can load old paks, convert them and display them, and all the basic drawing functions are there. Usually this is the point where I lean back and say to myself, "I have proven that it can be made. I'm done here. Lets look for a new challenge"
It is hard for me to go further, and complete it. I'll try though, cause there is one thing not achieved yet - actual 32 bit graphics, a new Makepak and showcasing the transparency and light effects with some pak set.
Missing is 98% of the event handling. This is why I can only show the pak selector screen with a clipping bug and not even click a button to actually load a pak. Plus there are myriads of lurking bugs to erase and shortcuts which I put into this proof of concept.
PS: Why no Vulcan instead of OpenGL? Simple answer, my PC is so old, the graphics driver does not know about Vulcan and I cannot use it.
Question is: if going OpenGL, why don't just render 3D and forget all the tile mess. All front-back ordering, artifacts, etc. would be handled by OpenGL itself.
There can be a default train, bus, plane 3D model that would appear if no 3D model exists in the pakset.
I think Ters tried that in his approach.
https://forum.simutrans.com/index.php/topic,11796.0.html
I am a 2d guy. I'll not try to lift Simutrans to full 3D. But see. If I could do it ion 4 days, anyone can, right? So anyone can to the 3D thing in only a little time.
I have no good answer. All my experience is with isometric games and using OpenGL with that. I am also not good for really big projects anymore, I have lost all endurance. So I'll keep the Simutrans rendering with 2D tiles and expand the quality of the rendering with colors, lights and transparency.
Also I am old now. You do not teach an old horse new tricks. Sorry.
PS: I think that most artifacts can be solved in 2D. No need to go full 3d for that unless you also want to make 3D models for all buildings and vehicles.
This is impressive stuff, so is it possible to overcome the limitations that were encountered when this was tried before?.
Edit.
I remember someone once tried it and after hard work discovered that their project was a failure, it was very discouraging I'm afraid.
Since then I don't think anyone has come this far.
I've seen the messages in Ters thread and indeed I am seeing similar problems. The performance of the first version was very bad, 200ms for a screen redraw, sometimes worse.
I can't measure exactly how much Simutrans simulation engine needs and how much the OpenGL backend needs, but on this netbook (Intel Celeron N3350, 4 GB RAM, Intel on board graphics HD500) I now get stable 25 FPS at a window size of 1000x750 pixels with pak64. There might be room for improvement, but I have taken care of the basic tricks like combining many tile images into one big texture so my code does not need to switch textures that often. I must see what I can do to make it better.
Loading the paks and converting the graphics is really slow with my current code though, so that will be my next thing to investigate. I clearly don't use the optimal method there.
Right now it's looking just the same as before, well, kinda, you see which parts I have not implemented yet. But with OpenGL it will be easier to add nice graphics gimmicks later.
I dunno, it looks very dirty to me. ;-)
I'm glad to see this! I hope it remains interesting to work on - that's most important, imho.
@Hajo, If you manage to achieve good performance with OpenGL, then you would be achieving the holy grail of simutrans. 8)
In my opinion, one of the big problems with graphical processing is the immense amount of vehicles moving everywhere on extremely large maps, which results in something very slow for hardware processing, so...
What about the graphical interface (GUI)?, In theory it should be possible to process this independently, or not?.
Quote from: Isaac Eiland-Hall on December 11, 2023, 04:05:17 AMI dunno, it looks very dirty to me. ;-)
I'm glad to see this! I hope it remains interesting to work on - that's most important, imho.
It's the first time I use OpenGl and C++ together, definitely very challenging for me (and I make a lot of mistakes). But I think it's good get more practise with C++ again. And yes, quite a lot is missing, there are like a dozen of specialized methods to draw tiles, and I have only completed the most common ones yet (and I think there is still a mistake in my handling of semi transparent pixels from the current pak files which have a very tricky encoding). It will start to look better the more complete the code is and the more bugs I can fix.
Quote from: Yona-TYT on December 11, 2023, 08:25:45 AM@Hajo, If you manage to achieve good performance with OpenGL, then you would be achieving the holy grail of simutrans. 8)
In my opinion, one of the big problems with graphical processing is the immense amount of vehicles moving everywhere on extremely large maps, which results in something very slow for hardware processing, so...
What about the graphical interface (GUI)?, In theory it should be possible to process this independently, or not?.
I think it's too early to give definite answers here. Last evening I was working on a fix for a clipping problem and suddenly frame times went up from 40ms to over 200 ... I think I found the problem now and can get display back to the mentioned 25 FPS on the netbook, but until I have a more complete version it's really very hard to predict performance.
The GUI is fairly easy for OpenGL though, that's the part that I'm least concerned about, in terms of performance.
Overall I can only tell, in other game projects OpenGL performs very well, so I think it must be possible for Simurans too. Might require additional changes in the higher level display routines though, which break down the landscape data into tile drawing commands. Must see. E.g. the landscape itself changes only rarely and could be kept as a VBO which is very fast to display.
Objects that are out of sight won't go into the OpenGL routines, so they do not bother the drawing. And from what I saw in the code they are processed by a different thread and therefore should be quite indentant from OpenGL performance as long as the CPU has 2 cores or at least supports hyperthreading for 2 threads. But indeed, updating so much data in near real time is a problem (not a new one though).
So far performance is neither very good not very bad. I keep hoping I can make it good enough even on older systems. In a week or so, it will be easier to tell if I can do it.
This is great! I really can't wait to see the results, let's hope for something big! :)
Quote from: _Hajo_ on December 11, 2023, 02:43:02 PMIt will start to look better
Just wanted to say that my stupid joke was just based on the visual ature of much of the ground in the screenshot. :)
Just a quick update before I get some much needed sleep. Tested on my netbook (specs see above) with pak 64. There are still some issues in loading the image data from current paks. These will go away once I have a new makeobj to encode true 32 bit colors, but I also want to have compatibility with pak sets that cannot so easily be recompiled, e.g. lack of sources.
The performance stats look normal to me, the CPU even is a bit idle, 4 simloops per second are good and it runs at 25 FPS. Of course this was an empty game, but there is hope to have better graphics and special effects support without big penalty in performance. And on computers with real graphics cards, the numbers should be much better.
Now I must add support for pak sizes other than 64 (should work already, but doesn't) and fix the remaining glitches (quite a lot).
Gives me a miniature all white window titled "Simutrans GL" for a split second then crashes. Not much debugging info, presumably somewhere off in the NVidia driver:
Simutrans version 123.0.2 Nightly from Dec 11 2023 r
Warning: loadsave_t::rd_open: File 'settings.xml' does not exist or is not accessible
Message: simu_main(): Parsing r:\simutrans_ts-simutrans_gl\simutrans\config\simuconf.tab
Message: simu_main(): Version: 123.0.2 Nightly Date: Dec 11 2023
Message: simu_main(): Debuglevel: 4
Message: simu_main(): base_dir: r:\simutrans_ts-simutrans_gl\simutrans\
Message: simu_main(): install_dir: r:\simutrans_ts-simutrans_gl\simutrans\
Message: simu_main(): user_dir: r:\simutrans_ts-simutrans_gl\simutrans\
Message: simu_main(): locale: en
Message: simu_main(): simgraph_init disp_width=640, disp_height=480, fullscreen=0
Message: simgraph_init(): GLFW 640,480 -> window: 0000015de05e06a0
Message: simgraph_init(): GLFW max texture size is 32768
Message: simu_main(): .. results in disp_width=640, disp_height=480
Message: simu_main(): Loading colours from r:\simutrans_ts-simutrans_gl\simutrans\config/simuconf.tab
Message: font_t::load_from_freetype: trying to load 'C:\Windows\Fonts\segoeui.ttf' in size 14
Message: font_t::load_from_freetype: Loaded 65534 glyphs
Message: font_t::load_from_freetype: 3926 glyphs have actual bitmaps
Message: create_texture(): id=1 error=0
Message: font_t::load_from_freetype: trying to load 'C:\Windows\Fonts\segoeui.ttf' in size 16
Message: font_t::load_from_freetype: Loaded 65534 glyphs
Message: font_t::load_from_freetype: 3926 glyphs have actual bitmaps
Message: create_texture(): id=2 error=0
Message: pakset_manager_t::load_pak_file: filename='modern.pak'
Message: pakset_manager_t::load_pak_file: Read 1 blocks, file version is 3eb
Message: register_image(): Currently at 1 images, converting 4x4 pixels
Message: register_image(): Starting texture sheet #0
Message: create_texture(): id=3 error=0
Thread 13 received signal SIGSEGV, Segmentation fault.
[Switching to Thread 11104.0x1998]
0x00007ffd1fd9035f in nvoglv64!DrvPresentBuffers () from /c/Windows/System32/DriverStore/FileRepository/nv_dispig.inf_amd64_1fea8972dc2f0a69/nvoglv64.dll
(gdb) bt
#0 0x00007ffd1fd9035f in nvoglv64!DrvPresentBuffers ()
from /c/Windows/System32/DriverStore/FileRepository/nv_dispig.inf_amd64_1fea8972dc2f0a69/nvoglv64.dll
#1 0x00007ffd1fd8ff7e in nvoglv64!DrvPresentBuffers ()
from /c/Windows/System32/DriverStore/FileRepository/nv_dispig.inf_amd64_1fea8972dc2f0a69/nvoglv64.dll
#2 0x00007ffd1fca5c32 in nvoglv64!DrvPresentBuffers ()
from /c/Windows/System32/DriverStore/FileRepository/nv_dispig.inf_amd64_1fea8972dc2f0a69/nvoglv64.dll
#3 0x00007ffd1fca54d4 in nvoglv64!DrvPresentBuffers ()
from /c/Windows/System32/DriverStore/FileRepository/nv_dispig.inf_amd64_1fea8972dc2f0a69/nvoglv64.dll
#4 0x00007ffd1fca579f in nvoglv64!DrvPresentBuffers ()
from /c/Windows/System32/DriverStore/FileRepository/nv_dispig.inf_amd64_1fea8972dc2f0a69/nvoglv64.dll
#5 0x00007ffd1fcbdbeb in nvoglv64!DrvPresentBuffers ()
from /c/Windows/System32/DriverStore/FileRepository/nv_dispig.inf_amd64_1fea8972dc2f0a69/nvoglv64.dll
#6 0x00007ffd1fcbdd7d in nvoglv64!DrvPresentBuffers ()
from /c/Windows/System32/DriverStore/FileRepository/nv_dispig.inf_amd64_1fea8972dc2f0a69/nvoglv64.dll
#7 0x00007ffd1fd6a987 in nvoglv64!DrvPresentBuffers ()
from /c/Windows/System32/DriverStore/FileRepository/nv_dispig.inf_amd64_1fea8972dc2f0a69/nvoglv64.dll
#8 0x00007ffd1fd6ace0 in nvoglv64!DrvPresentBuffers ()
from /c/Windows/System32/DriverStore/FileRepository/nv_dispig.inf_amd64_1fea8972dc2f0a69/nvoglv64.dll
#9 0x00007ffd1f8667b2 in ?? ()
from /c/Windows/System32/DriverStore/FileRepository/nv_dispig.inf_amd64_1fea8972dc2f0a69/nvoglv64.dll
#10 0x00007ffd1f99212a in ?? ()
from /c/Windows/System32/DriverStore/FileRepository/nv_dispig.inf_amd64_1fea8972dc2f0a69/nvoglv64.dll
#11 0x00007ffd1f996715 in ?? ()
from /c/Windows/System32/DriverStore/FileRepository/nv_dispig.inf_amd64_1fea8972dc2f0a69/nvoglv64.dll
#12 0x00007ffd1f99750a in ?? ()
from /c/Windows/System32/DriverStore/FileRepository/nv_dispig.inf_amd64_1fea8972dc2f0a69/nvoglv64.dll
#13 0x00007ffd1f9a38b0 in ?? ()
from /c/Windows/System32/DriverStore/FileRepository/nv_dispig.inf_amd64_1fea8972dc2f0a69/nvoglv64.dll
#14 0x00007ffd1f7ed313 in ?? ()
from /c/Windows/System32/DriverStore/FileRepository/nv_dispig.inf_amd64_1fea8972dc2f0a69/nvoglv64.dll
#15 0x00007ffd1f9bfcc3 in ?? ()
from /c/Windows/System32/DriverStore/FileRepository/nv_dispig.inf_amd64_1fea8972dc2f0a69/nvoglv64.dll
#16 0x00007ffd1f9bf847 in ?? ()
from /c/Windows/System32/DriverStore/FileRepository/nv_dispig.inf_amd64_1fea8972dc2f0a69/nvoglv64.dll
#17 0x00007ffd1fc38ba8 in nvoglv64!DrvValidateVersion ()
from /c/Windows/System32/DriverStore/FileRepository/nv_dispig.inf_amd64_1fea8972dc2f0a69/nvoglv64.dll
#18 0x00007ffd8bd47344 in KERNEL32!BaseThreadInitThunk () from /c/Windows/System32/KERNEL32.DLL
#19 0x00007ffd8d0226b1 in ntdll!RtlUserThreadStart () from /c/Windows/SYSTEM32/ntdll.dll
#20 0x0000000000000000 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
Edit: tried on an ancient Intel IGPU only laptop - game loads and runs, but display is really only the status bar.
Quote from: _Hajo_ on December 09, 2023, 01:23:48 AMI think Ters tried that in his approach.
https://forum.simutrans.com/index.php/topic,11796.0.html
[...]
PS: I think that most artifacts can be solved in 2D. No need to go full 3d for that unless you also want to make 3D models for all buildings and vehicles.
Not exactly. I didn't remember, but I also participated in that thread and my idea remains the same. In both cases OpenGL is used to represent a 3D world in 2D based on a complex system of tile rendering full of artifacts and complex algorithms and having thus very few camera positions (four rotations in fact) that also need to change the position and offsets of the objects to match.
But OpenGL wasn't design for that in the first place. If worked from scratch, the landscape can be painted in 3D with appropriate textures and the camera could be moved freely and OpenGL would do the magic for nearly no cost.
The problem stated by Ters (and by you) was that no graphics would be reusable since real 3D models for buildings and vehicles must be designed. Sure, but one can design a "generic" train 3D model, generic building, etc. and use them where 3d models aren't provided in the pak set. Or other temporary tricks... For instance, a train could be temporarily represented by four wheels and a "sheet of paper" on them with the picture of the 2D model of the train... Not good, but those gaps could be filled by 3D pak authors once the engine works.
The big, big reward of going full 3D is that once you have the data of the vehicles and landscape, nothing has to be done apart from telling OpenGL to draw it. Problem certainly is that 2D rendering may be deep inside ST code and may be impossible to factor that out.
By the way, have you tried performance with Mesa software drivers?
Many objects created since around 2008 have been created as 3D models and then rendered as 2D. Which models are still available is another question.
As far as I know, pak128.german has many 3D created objects.
But first you have to determine which 3D model is used. And then you have to check which of the 3D formats can be converted into the appropriate 3D model.
Quote from: TurfIt on December 11, 2023, 10:36:35 PMGives me a miniature all white window titled "Simutrans GL" for a split second then crashes. Not much debugging info, presumably somewhere off in the NVidia driver:
Thanks for testing, even if it probably was too early. I have this white screen on my other laptop too. Please give me some more time. I'm positive I can get it working on a wider range of systems. I'm still fixing problems with color conversion and also memory management of the tiles.
In regard of the 3D models and 3D display questions, I just want to say, I'll not even try to do it. That is a big endevour, too big for me. I only want better rendering quality with 2D graphics (which typically have 24/32 bit sources already) and more fancy features like transparency, color and light effects.
PS: White screen was totally my fault. A buffer overflow in texture loading. Thanks for reporting!
I'd have ignored it otherwise in favor of other fixes. Fix will be pushed with some more fixes to image conversion later the day.
Until the window is resizeable, you can set the size with the -screensize <width>x<height> command line option. I use -screensize 1000x750 in my tests.
And now with support for tile sizes other than 64! And I think I am getting closer to loading transparent pixels from current pak files.
PS: Now! Had the alpha values inverted, this is now correct.
Is it possible to compile on Linux?.
Yes, I'm working with Linux Mint, which is mostly the same as Ubuntu, so that should work.
https://github.com/Varkalandar/simutrans_ts/tree/simutrans_gl
But be warned, everything is quite crude and rudimentary, keyboard input is completely missing, mouse input is incomplete. Maybe rather wait a few more days till there is a version which has been tested more and got more complete code. But I have pushed the fix for the blank screen problem that Turfit has reported and also a fix for handling the transparent pixels as shown in the last screenshot. Now I am trying to get the build actions on github to work with my changes.
Regarding performance - I did some experiments on this a while back, and found that the fastest way to do this is using buffer textures, and to batch draws as much as possible. I managed to make the code work with current trunk, but it is unfinished and has lots of bugs. Hopefully this is useful. :)
The attached patch can draw the yoshi pak64 test map at at minimum zoom factor (~600k quads) in under 2 ms using a (desktop) GTX 1080. Special colour replacement is implemented, but nothing else; I believe especially clipping and the display_*_alpha routines would decrease performance if they were implemented.
Thank you @ceeac, this is very interesting!
I've not implemented any sprite batching yet, and I'm pretty sure it will help to improve performance a lot.
I'll study your code. It is definitely more advanced than my approach and I think I can learn a lot from it.
Thank you for sharing the patch :D
Noticed something that might explain the one crash that Turfit had. If the default font is missing, Simutrans GL logs an error message but continues, and will crash the next time some text is displayed. This and the fact that it uses a font that is not part of a Simutrans standard installation might explain some crashes. I've attached an archive with the missing font. Unpack it into you "<home>/simutrans" directory, so there is a "<home>/simutrans/font" directory (along "<home>/simutrans/paksets" and some more.
Nightly build from your branch works?, I tried to compile in fedora 39 but not even the main branch has worked for me (dependency problems I think).
"Work" might be too much said, but I've tested the Linux Nightly with Mint 21.2 and the Windows build with Windows 10. There is still a lot left to do until these are really playable versions.
https://github.com/Varkalandar/simutrans_ts/releases/tag/Nightly
It is highly recommended to start these versions from Windows CLI/Linux shell because the window is not resizable yet and one must set the desired size on the command line. Also the window close button doesn't work and the game must be stopped with the "quit" button in the settings dialog.
For Linux, start with
Quotecd <installation_dir>
./simutrans -debug 3 -screensize 1000x750
For Windows start with
Quotecd <installation_dir>
simutrans -debug 3 -screensize 1000x750
PS: On Linux you might need to install a package called
glfw (maybe called
glfw3 on some systems). This is a helper for OpenGL to handle events and window functions.
Quote from: _Hajo_ on December 14, 2023, 10:22:28 AMglfw
Simutrans version 123.0.2 Nightly from Dec 13 2023 r1 hash 0x96330b4
Message: simu_main(): Parsing /home/casa/Descargas/simulinux-x64-nightly(2)/simutrans/config/simuconf.tab
Message: simu_main(): Version: 123.0.2 Nightly Date: Dec 13 2023
Message: simu_main(): Debuglevel: 3
Message: simu_main(): base_dir: /home/casa/Descargas/simulinux-x64-nightly(2)/simutrans/
Message: simu_main(): install_dir: /home/casa/simutrans/paksets/
Message: simu_main(): user_dir: /home/casa/simutrans/
Message: simu_main(): locale: es
Message: dr_os_init(): GLFW init: 1
Message: simu_main(): simgraph_init disp_width=1000, disp_height=750, fullscreen=0
Message: GLFW Error: Error 65543: GLX: Failed to create context: GLXBadFBConfig
Message: simgraph_init(): GLFW 1000,750 -> window: (nil)
ERROR: simu_main(): Failed to initialize graphics system.
For help with this error or to file a bug report please see the Simutrans forum:
https://forum.simutrans.com
This error appears when trying to start.
Thanks for the report. I'll look up the error message and number and try to find out what went wrong there.
A quick search gave this and similar results.
https://www.reddit.com/r/linux_gaming/comments/mfw36e/x_error_of_failed_request_glxbadfbconfig_after/?rdt=57244
https://github.com/archlinux/archinstall/issues/1104
The recommendation is to set an environment variable before starting the game:
export MESA_GL_VERSION_OVERRIDE=4.6
in other places it was suggested to set it to 4.5
export MESA_GL_VERSION_OVERRIDE=4.5
Since it runs for me I cannot test if these settings actually fix the problem. I'll investigate this further. Likely there is something that I can do in the GL/GLFW setup code to get more compatibility. Seems to be an error thought that happens if graphics drivers and mesa libraries do not work together properly.
Quote from: _Hajo_ on December 14, 2023, 01:14:49 PMexport MESA_GL_VERSION_OVERRIDE=4.6
Thank you very much, this works for me.
For some reason the fonts do not appear, I suspect libfreetype offered by fedora 39
Captura desde 2023-12-14 12-18-09.png
I found a bug when opening windows from the start menu.
After that simutrans now fails on startup:
gdb:
Thread 1 "simutrans" received signal SIGFPE, Arithmetic exception.
0x00005555556e1796 in banner_text_t::draw(scr_coord) ()
(gdb) where
#0 0x00005555556e1796 in banner_text_t::draw(scr_coord) ()
#1 0x0000555555702a82 in gui_container_t::draw(scr_coord) ()
#2 0x0000555555780d88 in gui_frame_t::draw(scr_coord, scr_size) ()
#3 0x0000555555810fa0 in display_all_win() ()
#4 0x00005555558134f6 in win_display_flush(double) ()
#5 0x0000555555994425 in intr_refresh_display(bool) ()
#6 0x0000555555a21d07 in karte_t::display(unsigned int) ()
#7 0x00005555558148e2 in modal_dialogue(gui_frame_t*, long, karte_t*, bool (*)()) ()
#8 0x000055555599ded5 in simu_main(int, char**) ()
#9 0x00005555559a4d69 in sysmain(int, char**) ()
#10 0x00007ffff776514a in __libc_start_call_main (main=main@entry=0x555555638ca0 <main>, argc=argc@entry=1, argv=argv@entry=0x7fffffffdf18)
at ../sysdeps/nptl/libc_start_call_main.h:58
#11 0x00007ffff776520b in __libc_start_main_impl (main=0x555555638ca0 <main>, argc=1, argv=0x7fffffffdf18, init=<optimized out>, fini=<optimized out>,
rtld_fini=<optimized out>, stack_end=0x7fffffffdf08) at ../csu/libc-start.c:360
#12 0x0000555555638d0e in _start ()
Capture:
Captura desde 2023-12-14 12-30-43.png
Thanks for all the testing, and sorry for all the bugs!
The font problem might be my fault, I was confused where Simutrans by default looks for fonts and might have made mistakes in coding. The arithmetic exception I know, had it too. The start menu tries to center some text, but without a font, the text width is zero and then a divide by zero happens.
In my case it helped to put the font in a directory like this one.
font_folder.png
In your home directory there should be a "simutrans" directory which is also home to installed pak sets. Take the attached font.7z and unpack it there to get a font folder like the one in my screenshot and inside this folder there should then be a "LiberationSans-Regular.ttf" file.
If my guess about the cause of the problem is right, this might help.
Quote from: _Hajo_ on December 14, 2023, 07:44:05 PMIn your home directory there should be a "simutrans" directory which is also home to installed pak sets. Take the attached font.7z and unpack it there to get a font folder like the one in my screenshot and inside this folder there should then be a "LiberationSans-Regular.ttf" file.
The fonts directory is in place, but the texts still do not appear.
Edit.
I have solved it as follows:
Open the official version of simutrans, copy the font to the underlying directory, configure that font from the GUI, close simutrans so that the config will be saved.
Now when you open its branch the text appears since I have previously selected the font file.
So far performance looks very good.
The tool menus are in black for some reason.
Also the mouse wheel events are not working, it would be nice to have them as it would not show how performance is going when zooming in/out.Captura desde 2023-12-14 16-29-11.png
Quote from: _Hajo_ on December 14, 2023, 10:22:28 AMand the game must be stopped with the "quit" button in the settings dialog.
I bet End Task works, though. ;-)
Quote from: Isaac Eiland-Hall on December 15, 2023, 04:18:49 AMI bet End Task works, though. ;-)
The X to exit is already working, don't be cruel to the processes! killing is bad!... ;D
Quote from: Yona-TYT on December 14, 2023, 08:08:08 PMI have solved it as follows:
Open the official version of simutrans, copy the font to the underlying directory, configure that font from the GUI, close simutrans so that the config will be saved.
Now when you open its branch the text appears since I have previously selected the font file.
Good to know there is a solution :D
I'll look into the font loading code again and make sure there is safe fallback in case the previously chosen font cannot be loaded.
The black tool icons are my fault. I've tried a small performance optimization to set color not for every single image newly but once for a batch of subsequent drawing operations. Seems I missed to give these a proper color, and now the last previously set color is black, so they are drawn in black too. I'll fix that.
Zoom isn't implemented yet, and it will take a little longer because with OpenGL a different zooming strategy is needed compared to the old rendering code. I plan to render the tiles to a so called off-screen render target and zoom that in one step before display. That is fairly efficient with OpenGL and promises pretty high quality zoom.
At this point I'm happy to see that it works on someone elses computer too, even if the start was a bit rough. Also that performance is acceptable, this gives hope. There are options to optimize it further, e.g. with sprite batching as ceeac mentioned. First I'll try to complete the functionality though and fix all the bugs and problems.
The next step on my list is to bring the minimap back, I have code that works good as in display and real time updates of the map, but is very unresponsive to the scroll bars of the minimap window. I'll need some time to solve that. Good news though is that the performance penalty while the minimap is open is small and the new map supports 16 million colors, instead of 32000 as before - but that probably does not matter that much, it's just a side effect that I've switched everything to 8 bits per color component.
@Isaac, yep, had to resort to killing the task during early tests when I could not close the window and had no in-game UI either ... but just yesterday I made the window close button work 8)
Icons are back in their real colors. But I wanted to showcase a first new feature with openGL. It is easy now to darken or tint non-top windows and transparent window bodies come at no extra cost anymore. This is just a showcase a the moment though.
PS: Sound is currently missing. I plan to use a library called OpenAL for sound, which is often used in combination with OpenGL. But step after step ... it will take time to implement it all.
Quote from: _Hajo_ on December 15, 2023, 01:19:46 PMPS: Sound is currently missing. I plan to use a library called OpenAL for sound, which is often used in combination with OpenGL. But step after step ... it will take time to implement it all.
Sound is not really a priority.
Something that is is the behavior of the mouse and the reactions to the clicks.
I have noticed that when clicking to drag and move around the map sometimes it does not respond correctly and you have to make several more clicks for the event to react.
Something similar happens to me when I try to close a window, I have to click several times for it to work.
Quote from: _Hajo_ on December 15, 2023, 01:19:46 PMIcons are back in their real colors. But I wanted to showcase a first new feature with openGL. It is easy now to darken or tint non-top windows and transparent window bodies come at no extra cost anymore. This is just a showcase a the moment though.
PS: Sound is currently missing. I plan to use a library called OpenAL for sound, which is often used in combination with OpenGL. But step after step ... it will take time to implement it all.
Impressive, now I will have to publish this again on social networks to show those beautiful windows. 8)
Thank you :)
And I agree, the event handling needs improvement. There is a lot left to do.
Test under Windows 10 with pak64.german
utf-8 fonts don't work
screen size
# display (screen/window) width
# also see readme.txt, -screensize option
display_width = 1600
# display (screen/window) height
# also see readme.txt, -screensize option
display_height = 960
Quote from: Andarix on December 15, 2023, 03:27:48 PMTest under Windows 10 with pak64.german
utf-8 fonts don't work
screen size
# display (screen/window) width
# also see readme.txt, -screensize option
display_width = 1600
# display (screen/window) height
# also see readme.txt, -screensize option
display_height = 960
Are there fps drops on your PC?.
a bug
message window background change to black by add message
EDIT This is apparently the case with all windows that have changing output.
Screenshot 2023-12-15 165139.png
small demo map (192x192) from pak64.german on start
Screenshot 2023-12-15 165325.png
PS
relief map not show map
Script AI plays
The black backgrounds on changing displays are bad.
There also seems to be an error with the player color. The player color is blue and green is displayed in the depot.
In the depot, the mouse is above the third car from the left.
ogl_windows_black_bug.jpg
Well, some fonts display rather nicely though, I'm happy to see that. I'll try to find out why the one font was only black boxes. Seems the creation of glyph bitmaps failed. Basically there should be support for utf-8 fonts, the liberation sans that I use has more than 2500 glyphs.
Also good to know the windows version is working ... ok well, let me rephrase that, at least it's starting and doing something 8)
Player color is currently completely unsupported by the code, it should usually be the default blue. It will take a while to get fixed, I want to take care of other things first.
And yes, the minimap was gone altogether for a while. I have today tried to fix it, the code that is pushed now (and should end up as a new "nightly" in a few minutes) has some basic support for the mini map, at least in non-isometric view. Still one of the many open construction sites. The old approach of drawing the map was unsuitable with OpenGL, I had to create something new and it took a while.
The black windows and some more random color changes are likely a side effect of the earlier mentioned optimisation attempt of mine to minimize calls to set the color for OpenGL. I'll fix these as I become aware of the problems. Compared to other problems these are easy and quick fixes.
Overall I am rather amazed of how much works already. It's been not even two weeks since I started. But now weekend is coming and I'll probably not be programming till Monday.
Have a nice weekend everyone!
I have a small request for you regarding the minimap.
When zooming in/out on the minimap the most appropriate behavior would be to follow the position of the mouse pointer, as does the game in general which maintains the position of the magnifying glass.
It is strange that the same behavior was never implemented on the minimap, which in my opinion is more intuitive and practical.
If this project continues at a good pace, then no one will want to use any backend other than OpenGL. 8)
simutrans ogl 10932 windows
I'm not sure if the transparent background of the windows is good in the long term. It strains the eyes with so little contrast.
imressions.jpg Screenshot 2023-12-16 094320.png
With the minimap, the map itself is not adjusted.
Screenshot 2023-12-16 091633.png
Quote from: Andarix on December 16, 2023, 08:20:00 AMI'm not sure if the transparent background of the windows is good in the long term. It strains the eyes with so little contrast.
This must be some experiment, I suppose that later this would be a configurable parameter from the theme.
Quote from: Andarix on December 16, 2023, 08:20:00 AMWith the minimap, the map itself is not adjusted.
The minimap is a work in progress, currently it's completely broken for me.
The minimap is still under construction. I need more time for that. It shows the map in normal mode now, but no overlays and no zoom.
Improvements since my last message:
FIX: loadingscreen shows the pak set logo again during loading.
FIX: Themed labels are now shown in proper colors.
FIX: Themed title bars are shown in proper colors.
FIX: Vehicle info popup in depot window got proper color again.
FIX: Vehicles in the depot are now displayed in their natural color.
CHG: Window background now only 20% transparent, to make text easier to read.
FIX: Event queuing also on low system event level to prevent loss of input events.
The window background will become configurable. As Yona-TYT assumed, I'm just testing performance and options here.
- Text input works again. At least the basics.
- The last used font is now loaded in the graphics initialisation phase, and if not found, the default fon is loaded. This should fix the font problems.
- Restoration of the minimap continues. The normal view works mostly I think, except for zooming out (zooming in is ok). Isometric view can display the map initially, but neither zooms nor scrolls. Needs more work.
- I've added line drawing functions to the OpenGL backend. Mostly for the minimap repairs, but I suspect they fix issues with the charts. Didn't test the charts yet.
Some problems I have noticed:
- Dropdown menus (filters) appear in black.
- Dragging the map with the secondary click is not working.
- When a tool is selected in the menu bar, the icon does not stay selected/shaded.
- Maximizing the window (without using the console) still does not work.
- Factory Builder window shows a black background.
- Some texts are not being displayed with the theme color.
These are minor details, so you should not take them as something of extreme priority.
Thank you for these reports! Some should be easy to fix, some will take a little longer.
I'll start a list of all reported problems and try to fix them as I have time.
I could fix some of the problems and offer a new feature:
FIX: Combo box dropdowns got proper colors again.
FIX: Right and middle mouse buttons work again.
FIX: Selected tools are marked with an orange overlay.
NEW: Front window color/tint and back window shade/tint can be configured in themes now.
This means, themes not only can give windows a transparency but also a tint to separate front from background windows. In the attached example I have the front window a yellow tint and the background windows a blue shade. Plus, all have some transparency. The default is no transparency, no tint and no shading.
QuoteFIX: Selected tools are marked with an orange overlay.
Can that orange color be changed by theme parameter?.
simutrans opengl 10947 windows
When selecting pakset, you may want to avoid displaying the path.
Or show the path as a mouseover.
The resize corner (bottom right) is displayed correctly in some windows and is black in other windows.
Quote from: Yona-TYT on December 19, 2023, 06:40:50 PMCan that orange color be changed by theme parameter?.
Not yet, but should be easy to do. What color should I chose as default if the theme doesn't set it?
Quote from: Andarix on December 19, 2023, 07:29:31 PMsimutrans opengl 10947 windows
When selecting pakset, you may want to avoid displaying the path.
Or show the path as a mouseover.
The resize corner (bottom right) is displayed correctly in some windows and is black in other windows.
Thank you for the example screens. Some of these problems are surprising, but I'll try to find out why it happens and fix it. At least the black dragging corners should be easy to repair.
QuoteNot yet, but should be easy to do. What color should I chose as default if the theme doesn't set it?
I would have to try to see which ones look better, something close to black perhaps.
Is it possible that you can make the pakset selection available as a patch so that it can be adopted into Simutrans standard if necessary?
There is a bug when using network filters on the minimap.
Edit.
It actually happens when an AI player is activated
This is what gdb says:
Thread 1 "simutrans" received signal SIGSEGV, Segmentation fault.
0x0000555555876e30 in ai_passenger_t::step() ()
(gdb) where
#0 0x0000555555876e30 in ai_passenger_t::step() ()
#1 0x0000555555a34c0f in karte_t::step() ()
#2 0x0000555555a370be in karte_t::interactive(unsigned int) ()
#3 0x00005555559a0934 in simu_main(int, char**) ()
#4 0x00005555559a8979 in sysmain(int, char**) ()
#5 0x00007ffff776514a in __libc_start_call_main (
main=main@entry=0x55555563b140 <main>, argc=argc@entry=1,
argv=argv@entry=0x7fffffffe0f8) at ../sysdeps/nptl/libc_start_call_main.h:58
#6 0x00007ffff776520b in __libc_start_main_impl (main=0x55555563b140 <main>, argc=1,
argv=0x7fffffffe0f8, init=<optimized out>, fini=<optimized out>,
--Type <RET> for more, q to quit, c to continue without paging--
I think I could fix the problem with the passenger AI, but there is something wrong with my event handling, so that needs more work.
CHG: Standard size silver theme now has themed window title bars and station labels too.
FIX: Tool pointers show in their natural colors now.
FIX: The OpenGl program window is resizable now.
FIX: Main toolbar no longer randomly changes to miscolored background.
FIX: Window dragger corners are now always shown in proper colors.
Furthermore I worked some on the minimap. The isometric view can be scrolled now, but there are still problems with isometric map and zoom. Zooming out with the normal view now shows the map correctly, but mouse clicks select wrong locations of the main map.
https://github.com/Varkalandar/simutrans_ts/releases/tag/Nightly
QuoteFurthermore I worked some on the minimap...
Wow, I didn't imagine that the algorithms for zooming would be so complicated.
I guess the in-world zoom will also be difficult to implement.
@Hajo
What are the biggest challenges that still remain to be faced?.
Quote from: Yona-TYT on December 20, 2023, 10:42:11 PMWow, I didn't imagine that the algorithms for zooming would be so complicated.
I guess the in-world zoom will also be difficult to implement.
@Hajo
What are the biggest challenges that still remain to be faced?.
The minimap is complicated because it combines three functions or more. Display the map (fairly easy) handle overlays like connections of factories, then support dynamic updates from the big map changes like moving vehicles, and link backwards mouse positions over the minimap to factories and such in the big map. And each in two versions, plain and isometric, plus scrolling which changes the origin of the map and zooming which changes coordinates.
I hope the zoom functions for the actual game will be easier. At least they only have to zoom, nothing else.
Remaining challenges:
- Full support for input events in combination with control and shift keys.
- Zoom of the main map.
- Bring player colors back, at least to some degree.
- Fix display glitches for the main map. This will be a big one.
- Implement a makeobj to create pak files with 32 bit graphics data.
- Try to offer a new night mode with extra light features. This will likely require new paks with light data for vehicles.
Things I want to do:
- Improve display performance.
- Keep everything so that I can merge improvements from standard. This will be hard, too. I kinda ploughed through the code forth and back for the open gl support. The differences are big already.
- Implement a feature to load PNG files with graphics to display for further prettification of the user interface, also something like a big graphical title screen.
- Showcase all new features with themes and pak sets.
I likely forgot some. At times it's good not to remember all the challenges ahead, but just go on and solve things step by step as they show up.
Well, once more I wish my head was better at math. Even that zooming is just multiplication and offsets are some additions, I find so many ways to do it wrong. Plus, OpenGL has some oddities that kept tripping me up today. But I think I have everything in place now and zoom works. It's been a pretty big change once more, which touched both the OpenGL code and higher level of Simutrans map display, so likely there are some mistakes left in it right now. One that I know is that town labels (probably all labels) are misplaced in zoom. I'll fix that once I have time.
Ah right, some symbols of the status bar "fly off" when zooming. Must find out why that happens ... so the next releases will likely focus on fixes for broken stuff and stabilize the features that are in Simutrans GL so far.
Edit: Downloads with the new zooming code are named "*_zoom.zip"
I hope both Linux and Windows versions work. Had to link yet another OpenGL helper library because of the framebuffer extension that I use for the zooming. If the Linux version whines about a missing dependency, install "glew" (GL extension wrangler) with your favorite pak manager.
https://github.com/Varkalandar/simutrans_ts/releases/tag/Nightly
simutrans ogl windows 10959
Quote from: _Hajo_ on December 20, 2023, 05:40:51 PM...
FIX: Main toolbar no longer randomly changes to miscolored background.
...
mmh, pak72.Elegance yes, pak64.german (background is black) no
The icons do not seem to be placed in the status line separately from the map.
zoom_in.jpg
With the Zoom version, an existing game will not load correctly.
load_savegame_zoom.jpg
The multiple repeated displays in the zoom are a limitation of the frame buffer approach. The frame buffer is max 4096x4096 pixels and if the displayed map area before zoom is bigger than that, the buffer is wrapped in x and y direction.
Not much that I can do about it right now, except to try to allocate a larger buffer. But on some systems a larger buffer will fail. Maybe i can solve it later with different map drawing code.
The lose icons from the status bar are something I can and will fix. I just need some time to identify why they are not drawn with the UI.
Also I'll try to fix any black icons or black spots on the map. I must admit though the black spots on the map are a mystery to me. It will need some time to find out what causes them.
Thanks for testing!
Edit: The missing objects on the loaded map are strange. I assume they are still there in the map data but not displayed. I'm sorry for this one, shouldn't happen. I'll look into this tomorrow.
Vehicle icons do not appear on the pak128, Also the calendar icon is in a bad place :o .
Captura desde 2023-12-21 22-46-32.png
The preview box is broken, this must be zoom related effects.
Captura desde 2023-12-21 22-52-24.png
I could fix some of the problems. The status bar icons now stay on the status bar, and the vehicles in the depot show again. The main menu background is now grey instead of black (as it used to be) if there is no background icon set.
I could also fix the missing objects on the map, and make town, station and factory labels stay near their origin objects during zoom.
https://github.com/Varkalandar/simutrans_ts/releases/tag/Nightly
FIX: Fixed the problem in clipping management that caused map objects to disappear with the new zoom code.
FIX: Town/station/factory labels now stay over their places during zoom.
FIX: Vehicles in depot window are displayed again.
FIX: Former day/night light colors are now properly converted to RGB too.
I wish everyone a merry Christmas, or just a good time even if you do not celebrate. I'll be back for more development and bug fixes some day next week. Have a good time everyone :)
At first quick view it looks good.
Only the desert texture (used for the coast) is transparent.
Interesting. No idea really, why this worked before the zoom and fails now, but I'll look into it. I'm confident I can fix this too. But I must ask for some patience, I'll be away for some days. Thanks for the report, though!
Try to start the zoom version, but it fails with pak128
gdb:
The debuginfo package for this file is probably broken.
[New Thread 0x7fffdffff6c0 (LWP 639003)]
[New Thread 0x7fffdf7fe6c0 (LWP 639004)]
[New Thread 0x7fffcfd876c0 (LWP 639037)]
[New Thread 0x7fffcf5866c0 (LWP 639038)]
[New Thread 0x7fffced856c0 (LWP 639039)]
Thread 1 "simutrans" received signal SIGSEGV, Segmentation fault.
0x00007ffff76bd3d1 in arena_for_chunk (
ptr=0x5555556dcbed <grund_t::display_overlay(short, short)+45>)
at /usr/src/debug/glibc-2.38-14.fc39.x86_64/malloc/arena.c:152
Downloading source file /usr/src/debug/glibc-2.38-14.fc39.x86_64/malloc/arena.c
152 return chunk_main_arena (ptr) ? &main_arena : heap_for_ptr (ptr)->ar_ptr;
(gdb) where
#0 0x00007ffff76bd3d1 in arena_for_chunk (
ptr=0x5555556dcbed <grund_t::display_overlay(short, short)+45>)
at /usr/src/debug/glibc-2.38-14.fc39.x86_64/malloc/arena.c:152
#1 arena_for_chunk (
--Type <RET> for more, q to quit, c to continue without paging--
capture:
Captura desde 2023-12-22 17-12-17.png
pak128.german:
gdb:
The debuginfo package for this file is probably broken.
[New Thread 0x7fffdffff6c0 (LWP 639456)]
[New Thread 0x7fffdf7fe6c0 (LWP 639457)]
[New Thread 0x7fffcffff6c0 (LWP 639515)]
[New Thread 0x7fffcf7fe6c0 (LWP 639525)]
[New Thread 0x7fffceffd6c0 (LWP 639526)]
[New Thread 0x7fffce7fc6c0 (LWP 639527)]
[Thread 0x7fffcffff6c0 (LWP 639515) exited]
Thread 1 "simutrans" received signal SIGSEGV, Segmentation fault.
0x00007ffff76bd3d1 in arena_for_chunk (
ptr=0x5555556dcbed <grund_t::display_overlay(short, short)+45>)
at /usr/src/debug/glibc-2.38-14.fc39.x86_64/malloc/arena.c:152
152 return chunk_main_arena (ptr) ? &main_arena : heap_for_ptr (ptr)->ar_ptr;
(gdb) where
#0 0x00007ffff76bd3d1 in arena_for_chunk (
ptr=0x5555556dcbed <grund_t::display_overlay(short, short)+45>)
at /usr/src/debug/glibc-2.38-14.fc39.x86_64/malloc/arena.c:152
#1 arena_for_chunk (
ptr=0x5555556dcbed <grund_t::display_overlay(short, short)+45>)
at /usr/src/debug/glibc-2.38-14.fc39.x86_64/malloc/arena.c:150
#2 __GI___libc_free (
mem=0x5555556dcbfd <grund_t::display_overlay(short, short)+61>)
at malloc.c:3390
#3 0x0000555555635978 in sysgl_window_close_callback(GLFWwindow*) [clone .cold] ()
#4 0x0009000000000000 in ?? ()
#5 0x000000000000000b in ?? ()
#6 0x0000003b0000fffb in ?? ()
#7 0x0000ff600000000f in ?? ()
#8 0x000002da0000007f in ?? ()
#9 0x0000002000000200 in ?? ()
#10 0x0000000900000026 in ?? ()
#11 0x00005555bac6fa80 in ?? ()
#12 0x0000004000000040 in ?? ()
#13 0x00007fffffffae40 in ?? ()
#14 0x00007fff00000040 in ?? ()
#15 0x0000002000000080 in ?? ()
--Type <RET> for more, q to quit, c to continue without paging--
capture:
Captura desde 2023-12-22 17-19-18.png
@Hajo 2 minor things I found:
- get_zoom_fraction does not return a value even though the signature says it does.
- there is a buffer overrun in get_color_rgb for special light colours (indices 224..238 inclusive). You can use this to fix this temporarily:
rgb888_t get_color_rgb(uint8 idx)
{
- return special_pal[idx];
+ return idx < SPECIAL_COLOR_COUNT ? special_pal[idx] : rgb888_t{0,0,0};
}
@Yona-TYT
I'll look into this. Probably I missed something there. I didn't test the 128 paks.
@ceeac
Thank you. I worked too fast and these are typical mistakes of mine from that. I'll fix these. Thanks for letting me know!
Quote from: _Hajo_ on December 23, 2023, 04:43:50 PM@Yona-TYT
I'll look into this. Probably I missed something there. I didn't test the 128 paks.
...
Maybe it's because of the double heights.
I don't think so, it seems like no pakset works for me now.
gdb:
Thread 1 "simutrans" received signal SIGSEGV, Segmentation fault.
0x00007ffff76bd3d1 in arena_for_chunk (
ptr=0x5555556dcbed <grund_t::display_overlay(short, short)+45>)
at /usr/src/debug/glibc-2.38-14.fc39.x86_64/malloc/arena.c:152
152 return chunk_main_arena (ptr) ? &main_arena : heap_for_ptr (ptr)->ar_ptr;
(gdb)
Captura desde 2023-12-23 14-11-13.png
Edit.
It seems that in Nightly build r10965 something was broken since the error does not occur in the first version of zoom.
Quote from: Yona-TYT on December 23, 2023, 06:11:33 PMIt seems that in Nightly build r10965 something was broken since the error does not occur in the first version of zoom.
This is a useful information, because the method in which the crash occurs indeed was changed. In the first zoom version town/station/factory labels were not zoomed with the map and used to wander off if you zoomed in or out. I then changed this method to fix the positioning. So there is a causal relation.
Sadly I could neither reproduce the problem yet nor find the cause of the problem by inspecting the code. The suspicious method is a bit lengthy and I could not make out any obvious mistake there yet.
I've tested with pak127.german, pak64.german, pak64 and my own paks. I've also tested with valgrind, a memory debugger. It helped me to find and fix two problems, but in different places of the code (bevel borders for scroll panes and loading of the language files). So right now I am clueless what to do about it.
I've also downloaded the exact version to test, instead of building my own from the sources. The downloaded version works on my system.
For Andarix I have better news. I could bring the missing shorelines back. Sadly, all climate transitions are gone as well, that was just not so obvious. At the moment there is no simple fix to bring those back, they use pixel trickery that is not possible with OpenGL. I need to implement a different approach, which probably means to render the landscape with real 3D polygons and overlay partly transparent climate textures on transition tiles. This will work and probably even look nice, but means to write quite a bit of new code. So, it will need some time till done.
Another thing I could at least partially fix are player colors for themed window title bars and all the types of labels. Probably only the "Silver" theme is supporting such yet. I'll still provide a screenshot how it looks right now.
as far as Yona's problem is concerned
Back when I started the repos for Linux, I had the problem that the program created under Xubuntu (based on Ubuntu) crashed under Mageia (based on Fedora) with a memory access error.
Fortunately it already works again in Nightly build r10973, would it be a corrupt file?. It seems strange that it was fixed without touching anything related. ¿? :o :o :o
- The gadget that resizes windows is not displayed in the correct place.
Captura desde 2023-12-25 16-22-32.png
- Station labels and previewing objects in windows only work well at a specific zoom level.
- Object previews in windows appear too dark in some cases.
Look and compare the two images below:
Captura desde 2023-12-25 16-44-06.png
Captura desde 2023-12-25 16-44-12.png
Oops, something went very wrong with the labels there. I hope it wont be too hard to fix.
The resizing corner should be an easy catch, though. Luckily the zoom was the last big feature to add, now things should slowly stabilize.
And the preview windows. I had seen that they are too dark, but forgot to look into the problem. Definitely linked to the changes that I made to zoom the landscape. At least this way I won't get bored the next days ;D
The world views in the info windows should now have the right colors and work even if the main view is zoomed in or out. Also I could fix the labels so the parts stay together when the map is zoomed.
Furthermore the window size change gadget should stay in the bottom right corner during zoom. And eventually, I've changed the label shape for town labels in the silver theme to make them more distinct from station labels.
https://github.com/Varkalandar/simutrans_ts/releases/tag/Nightly
- Minimap has some black buttons.
- Regarding zooming in the minimap, wouldn't it be better if the screen maintained the position of the cursor/mouse, like Google Maps does?.
Captura desde 2023-12-26 12-19-16.png
Edit.
- Maybe it's a mistake in the pakset, but there are some black lines on the slopes that detract from the elegance of the pak72.Elegance.
- There is a strange cutout in the station coverge.
Captura desde 2023-12-26 19-08-25.png
Quote from: Yona-TYT on December 26, 2023, 04:21:38 PM- Minimap has some black buttons.
- Regarding zooming in the minimap, wouldn't it be better if the screen maintained the position of the cursor/mouse, like Google Maps does?.
I can't reproduce the black buttons, on my system they show in colors. Does it happen always on your system or just with certain settings?
I agree on the zoom being centered on the mouse if one zooms by mouse. Unfortunately there quite some more problems in the minimap, which I want to fix first.
Quote from: Yona-TYT on December 26, 2023, 04:21:38 PM- Maybe it's a mistake in the pakset, but there are some black lines on the slopes that detract from the elegance of the pak72.Elegance.
- There is a strange cutout in the station coverge.
The black lines come from rounding errors and that 72 pixels are a somewhat unusual raster size, so the code was not made for that. Right now I see no easy fix for this, I'll do it once I start to fix all the display glitches that the current code has.
Also, no idea about the cutout, but I think that's something I can fix.
Quote from: _Hajo_ on December 27, 2023, 02:34:45 PMI can't reproduce the black buttons, on my system they show in colors. Does it happen always on your system or just with certain settings?
...
The problem also exists on Windows. You can see it in a screenshot of mine above.
Quote from: _Hajo_ on December 27, 2023, 02:34:45 PMI can't reproduce the black buttons, on my system they show in colors. Does it happen always on your system or just with certain settings?
It always happens and apparently it has been there from the beginning.
Quote from: Andarix on December 27, 2023, 03:20:57 PMThe problem also exists on Windows. You can see it in a screenshot of mine above.
Yes I saw it. I couldn't reproduce it back then either, so I chose to ignore it.
Edit: That's how it look on my system.
Edit 2: The white buttons give a hint though. There is actually a difference how these get their color and how the others get their color. So I have a clue for a fix.
Can you test it with another theme?
My guess is that when the buttons are changed by the theme, it turns black. Just like it was with the other windows.
Works with any theme for me. But I see a difference how the white and how the colored buttons are initialized in the code. So I have a hint what to change.
It's the github build process. The versions I compiled locally work, the one I downloaded from github does not. Must see what I do different locally.
Edit: Thanks Yona and Andarix, mystery solved! I can now go and fix this.
Quote from: _Hajo_ on December 27, 2023, 02:34:45 PMAlso, no idea about the cutout, but I think that's something I can fix.
I think this is related to the zoom out issue, as the crops match exactly the screen divisions shown in the image below:
Captura desde 2023-12-27 14-21-31.png
Edit.
Vehicle markings are drawn outside the minimap when the window is resized with zoom in.
Captura desde 2023-12-27 14-31-21.png
simutrans ogl windows 10987
Minimap buttons work
The tab icons are not displayed in the lists or are transparent. The icons on the pak64.german are in gray color.
Good to know the colored buttons work now.
I could fix the missing icons for the tabbed panels meanwhile. The vehicle display in the minimap will take longer, can't finish it today. Same for the cutout in the station coverage display.
Thanks, Yona and Andarix, for testing so busily! Alone I'd never find the mistakes so quickly.
QuoteThanks, Yona and Andarix, for testing so busily! Alone I'd never find the mistakes so quickly.
Always collaborating. ;)
Edit.
@Hajo, I suspect that the changes in gl are breaking things in the other backends, so I think we should start testing in the normal builds as well.
Can you publish the executables on Github?.
I'm afraid it is not possible to build both versions from the same code base because each place that sets a color uses a color structure with 4 floats (red, green, blue, alpha) in Simutrans GL, while in Standard all these places use 16 bit integers, many of which were indices into a mapping table.
Maybe you can abstract a "Color" class and define its properties and methods depending on which version is compiled... On modern C++ a lot of tricks can even be done at compile time (for instance, calculate the float values from the integer ones after looking at the mapping table if that's static)... But it all depends on what compilers you're targeting.
windows ogl 10993
The light went out again in the minimap 8)
10993.jpg
Quote from: isidoro on December 29, 2023, 12:51:15 AMMaybe you can abstract a "Color" class and define its properties and methods depending on which version is compiled...
Yes, that's a option. Still needs all these places to be changed from a simple type to a class. But it's doable.
Quote from: Andarix on December 29, 2023, 01:42:52 PMThe light went out again in the minimap 8)
Help! The darkness is consuming my work!
No idea what I did wrong this time. But I'll try to fix it. Of course my self compiled version does not show this problem, so it's a bit tricky again to find the cause. Thanks for reporting!
Maybe it's due to differences in implementations.
https://learnopengl.com/Getting-started/OpenGL (https://learnopengl.com/Getting-started/OpenGL)
windows ogl 10997
Light was turned back on. Thanks
The vehicle graphics are still missing from the lists.
Screenshot 2023-12-29 191505.png
When I was working in my OpenGL project, I used apitrace to debug OpenGL. I remember it to be very useful. It's capable to "see" even textures, buffers, etc. Just in case it's useful, since some implementations of OpenGL are more lenient to errors.
Quote from: Andarix on December 29, 2023, 01:42:52 PMThe light went out again in the minimap
Are you playing at night?
Quote from: Andarix on December 29, 2023, 06:17:53 PMLight was turned back on.
Good morning! :)
Quote from: isidoro on December 29, 2023, 11:45:12 PMWhen I was working in my OpenGL project, I used apitrace to debug OpenGL. I remember it to be very useful. It's capable to "see" even textures, buffers, etc. Just in case it's useful, since some implementations of OpenGL are more lenient to errors.
There's also RenderDoc (https://github.com/baldurk/renderdoc/), but it does not work with fixed-function OpenGL.
Found a bug when zooming out with pak192.comic.
gdb:
[Thread 0x7fff211266c0 (LWP 411062) exited]
Thread 3 "simutran:gdrv0" received signal SIGABRT, Aborted.
[Switching to Thread 0x7fffdf7fe6c0 (LWP 410816)]
__pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
Downloading source file /usr/src/debug/glibc-2.38-14.fc39.x86_64/nptl/pthread_kill.c
44 return INTERNAL_SYSCALL_ERROR_P (ret) ? INTERNAL_SYSCALL_ERRNO (ret) : 0;
(gdb) where
#0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0)
at pthread_kill.c:44
#1 0x00007ffff76ae8a3 in __pthread_kill_internal (signo=6, threadid=<optimized out>) at pthread_kill.c:78
#2 0x00007ffff765c8ee in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
#3 0x00007ffff76448ff in __GI_abort () at abort.c:79
#4 0x00007fffe76fc717 in _crocus_batch_flush (batch=batch@entry=0x555555d96138,
file=file@entry=0x7fffe96166a0 "../src/gallium/drivers/crocus/crocus_batch.h", line=line@entry=323)
at ../src/gallium/drivers/crocus/crocus_batch.c:1022
#5 0x00007fffe8d65ca4 in crocus_require_statebuffer_space (size=2400, batch=0x555555d96138)
--Type <RET> for more, q to quit, c to continue without paging--
Capture:
Captura desde 2023-12-30 15-08-39.png
Edit.
Test 2
gdb:
(gdb) run
Starting program: /home/casa/Descargas/simulinux_gl-x64(1)/simutrans/simutrans
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
warning: the debug information found in "/home/casa/Descargas/simulinux_gl-x64(1)/simutrans/lib/libXau.so.6.0.0" does not match "/home/casa/Descargas/simulinux_gl-x64(1)/simutrans/lib/libXau.so.6" (CRC mismatch).
[New Thread 0x7fffdffff6c0 (LWP 412280)]
[New Thread 0x7fffdf7fe6c0 (LWP 412281)]
[New Thread 0x7fff2112e6c0 (LWP 412405)]
[New Thread 0x7fff2082d6c0 (LWP 412407)]
[New Thread 0x7fff03ff56c0 (LWP 412408)]
[New Thread 0x7fff037f46c0 (LWP 412409)]
[Thread 0x7fff2112e6c0 (LWP 412405) exited]
Thread 3 "simutran:gdrv0" received signal SIGABRT, Aborted.
[Switching to Thread 0x7fffdf7fe6c0 (LWP 412281)]
__pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
44 return INTERNAL_SYSCALL_ERROR_P (ret) ? INTERNAL_SYSCALL_ERRNO (ret) : 0;
(gdb) where
#0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0)
at pthread_kill.c:44
#1 0x00007ffff76ae8a3 in __pthread_kill_internal (signo=6, threadid=<optimized out>) at pthread_kill.c:78
#2 0x00007ffff765c8ee in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
#3 0x00007ffff76448ff in __GI_abort () at abort.c:79
#4 0x00007fffe76fc717 in _crocus_batch_flush (batch=0x555555d95ce8,
file=file@entry=0x7fffe96163a0 "../src/gallium/drivers/crocus/crocus_batch.c", line=line@entry=597)
at ../src/gallium/drivers/crocus/crocus_batch.c:1022
#5 0x00007fffe8c7d9e5 in crocus_batch_maybe_flush (batch=<optimized out>, estimate=<optimized out>)
--Type <RET> for more, q to quit, c to continue without paging--
Test 3
gdb:
(gdb) where
#0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0)
at pthread_kill.c:44
#1 0x00007ffff76ae8a3 in __pthread_kill_internal (signo=6, threadid=<optimized out>) at pthread_kill.c:78
#2 0x00007ffff765c8ee in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
#3 0x00007ffff76448ff in __GI_abort () at abort.c:79
#4 0x00007fffe76fc717 in _crocus_batch_flush (batch=0x555555d95948,
file=file@entry=0x7fffe96163a0 "../src/gallium/drivers/crocus/crocus_batch.c", line=line@entry=597)
at ../src/gallium/drivers/crocus/crocus_batch.c:1022
#5 0x00007fffe8c7d9e5 in crocus_batch_maybe_flush (batch=<optimized out>, estimate=<optimized out>)
at ../src/gallium/drivers/crocus/crocus_batch.c:597
#6 0x00007fffe8d657e4 in crocus_simple_draw_vbo (sc=0x7fffdf7fcea0, indirect=0x0, drawid_offset=0, draw=0x7fffe9b88b18,
ice=0x555555d953d0) at ../src/gallium/drivers/crocus/crocus_draw.c:325
--Type <RET> for more, q to quit, c to continue without paging--c
#7 crocus_draw_vbo (ctx=0x555555d953d0, info=<optimized out>, drawid_offset=0, indirect=0x0, draws=<optimized out>,
num_draws=<optimized out>) at ../src/gallium/drivers/crocus/crocus_draw.c:438
#8 0x00007fffe7ce4791 in tc_call_draw_single (pipe=<optimized out>, call=0x7fffe9b88b10, last_ptr=<optimized out>)
at ../src/gallium/auxiliary/util/u_threaded_context.c:3732
#9 0x00007fffe7cde979 in batch_execute (parsing=false, last=0x7fffe9b8a110, pipe=0x555555d953d0, batch=0x7fffe9b87100)
at ../src/gallium/auxiliary/util/u_threaded_context.c:394
#10 tc_batch_execute (job=job@entry=0x7fffe9b87100, gdata=gdata@entry=0x0, thread_index=thread_index@entry=0)
at ../src/gallium/auxiliary/util/u_threaded_context.c:445
#11 0x00007fffe774d4a1 in util_queue_thread_func (input=input@entry=0x555555d02e70) at ../src/util/u_queue.c:309
#12 0x00007fffe776e48c in impl_thrd_routine (p=<optimized out>) at ../src/c11/impl/threads_posix.c:67
#13 0x00007ffff76ac897 in start_thread (arg=<optimized out>) at pthread_create.c:444
#14 0x00007ffff77336fc in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78
(gdb)
- Pakset loading image is not displayed correctly.
Captura desde 2023-12-30 15-38-52.png
The minimap does not seem to completely cover the window area:
Captura desde 2023-12-30 15-59-47.png
More strange effects related to zoom (the magic numbers appear in the wrong place):
Captura desde 2023-12-30 15-58-59.png
- The positions of the income/expenditure numbers should be correct now.
- The vehicles in the lists should be visible again.
- The "new map" got the map preview back.
- Likewise the city info windows got their map previews back.
- I've added a simple day/night mode, but there are no working lights at night yet.
- Alternating colored lists should show with an even right border now.
Plus some minor improvements to layout in some dialogs. I have neither investigated the crash with pak192.comic yet, nor could I fix the overdraw problem in the minimap so far. Needs more time.
I've been working on a first test with light by night, but doesn't look good, so I disabled that in the code again, till I have better graphics and better code.
Also, I've been able to merge all changes from Simutrans Standard which were pushed to github recently. That was something I was very worried about, if the code bases are still similar enough to make merges easy.
QuoteAlso, I've been able to merge all changes from Simutrans Standard which were pushed to github recently. That was something I was very worried about, if the code bases are still similar enough to make merges easy.
That's great !. 8)
A title screen inches closer. I can now load and display PNG images as part of dialogs. Still have to see how to integrate that properly with themes and such. As example, the pak selector with the old Simutrans logo in the background.
- The transparency of the trees is not working as in normal simutrans. Is this the expected behavior?.
Captura desde 2024-01-03 06-22-46.png
- Activating the isometric view of the minimap no longer allows you to return to the normal view.
Captura desde 2024-01-03 06-17-33.png
Simutrans GL now got a title screen. The logo was designed by Seth C. Triggs long ago.
simutrans_gl_v003.png
Quote from: Yona-TYT on January 03, 2024, 05:15:28 AM- The transparency of the trees is not working as in normal simutrans. Is this the expected behavior?.
- Activating the isometric view of the minimap no longer allows you to return to the normal view.
The tree transparency is not implemented yet. It was not a priority for me so far.
I'll try to fix the minimap soon.
Edit: In the latest nightly the logo isn't truncated anymore (some pixels are missing from the top in the screenshot)
If I could wish for something, the start screen as a patch for standard.
Simutrans code keeps puzzling me. I have made a new makeobj to store 32 bit "truecolor" graphics in the pak files, including 8bit transparency, and also changed the reading code, but now some road and railroad tiles don't show anymore :o
I surely did not do anything special to scare these tiles away, all graphics are fed through the same routines. Another mystery ...
But anyways, here it is. The first screenshot with 32bit graphics. Doesn't look very special, because the input are the same old pak set sources, yet now another door is opened to make better use of slightly transparent images.
Since these are the crossings, it is reasonable to suspect that it has something to do with the switches for rails, which do not exist on roads.
Wiki - Switches for tracks (https://simutrans-germany.com/wiki/wiki/en_WayDef#Switches_for_tracks)
windows ogl 11019 - v0.03
Windows version crashes immediately upon startup.
Quote from: Andarix on January 04, 2024, 12:58:44 PMIf I could wish for something, the start screen as a patch for standard.
It wont be easy to do this, because it depends on my open gl related extensions to Simutrans. But it's not impossible.
Quote from: Andarix on January 04, 2024, 04:23:48 PMSince these are the crossings, it is reasonable to suspect that it has something to do with the switches for rails, which do not exist on roads.
It works though with the old pak files with 16 bit graphics, but not with the new ones with 32 bit graphics. So something went wrong there either in my new makeobj, or in the way I load images from the new pak files. Technically Simutrans thinks the crossing are there, I can open an info window for them, just nothing is display on screen. I'll play Sherlock Holmes for a few hours and look for the missing images. Or Indiana Hajo, the quest of the lost road.
Quote from: Andarix on January 04, 2024, 05:19:03 PMWindows version crashes immediately upon startup.
Confirmed. It's because the new backdrop and logo image for the title screen was not included in the download and it fails when trying to load it. Obviously my build scripts need an update. I'll fix that, shouldn't take long.
Edit: I fixed the build script. Windows nightly r11021 worked in my test.
Edit 2: Crossing and switches are back. It was a mistake in my new Makeobj.
Do themes also need customization?
The pak64.german theme causes a crash (windows and linux). Since it was selected before the update, starting it also causes a crash.
The start only works after deleting the settings files *.xml.
I'm now and then testing with the "modern" theme, that used to work. It is my intention to maintain compatibility with both, existing pak sets and themes.
So I consider this a bug. Where can I get the pak64.German theme? I want to test it and fix the problem.
I did some fixes last evening, related to loading the images from pak files (16 bpp and 32 bpp, I had changed some stuff there for the new 32bpp pak files), and could fix one or two illegal memory accesses. Being used to Java which has automatic memory management and automated access checking, also nothing like malloc and free, I'm notoriously bad with manual memory management in C++, sorry for that. Valgrind helps though.
I've tested the latest nightly for Linux (r11023) and it works with the theme.
Only small updates this time:
- The minimap got a forced refresh now after the map window was resized.
This change might also avoid the weird updates in black areas, but I'm not 100% sure about that.
- The minimap got a different, Minecraft-map inspired color scheme.
To me it looks more friendly, opinions are welcome.
- The "transparent trees" display option works again.
Latest nightly with fresh bugs and yet unseen crashes,
https://github.com/Varkalandar/simutrans_ts/releases/tag/Simutrans_GL_Nightly
Some small improvements again:
- CHG: Improved initial size calculation for display options dialog.
- FIX: Transparent building display option works again.
- FIX: Refresh minimap only once after map window resize.
- CHG: Silver is now standard theme.
- CHG: Normal text color for pak selector texts.
https://github.com/Varkalandar/simutrans_ts/releases/tag/Simutrans_GL_Nightly
Forgot to push a change. There is one more. I've tried to improve the info window for city houses, clean up the info, highlight the numbers.
Build is running, update should be available in a few minutes.
I've merged the recent changes from Simutrans Standard. There were some conflicts in the domain of making a new map, loading/saving games, the banner and the options window. I've tried to solve them, but there might be problems that I did not catch in my tests.
So, the state before the merge is now here:
https://github.com/Varkalandar/simutrans_ts/releases/tag/GL_v0.03
And the state after the merge can be downloaded here:
https://github.com/Varkalandar/simutrans_ts/releases/tag/Simutrans_GL_Nightly
Besides fixes and new functions that came from Standard, no changes were made from my side.
Would it be better to have the numbers right aligned?
They look good to me . ;)
Good, so I'll keep this version :thumbsup:
Wouldn't it be $1000 instead of 1000$?
Quote from: _Hajo_ on January 07, 2024, 06:28:46 PMOnly small updates this time:
....
- The minimap got a different, Minecraft-map inspired color scheme.
To me it looks more friendly, opinions are welcome.
....
I like! I'd also love to set the minimap colours from the Pakset-side, so it'll better fit the climates .
Quote from: Flemmbrav on January 11, 2024, 11:39:20 PMI like! I'd also love to set the minimap colours from the Pakset-side, so it'll better fit the climates .
The minimap is a heightmap, not a climate map. Fitting the minimap to climates would work best with the minimap actually showing climates, an Extension Request.
But I agree that minimap colors could be set by pakset. Especially paksets outside the norm (like the new bitlit, the old handdrawn, and even excentrique) would benefit.
Quote from: isidoro on January 11, 2024, 11:21:51 PMWouldn't it be $1000 instead of 1000$?
Didn't really think about that, it's the same code in Standard. But it will look better with the leading currency sign, indeed.
Quote from: Flemmbrav on January 11, 2024, 11:39:20 PMI like! I'd also love to set the minimap colours from the Pakset-side, so it'll better fit the climates .
That's possible. Technically it's just a table of numbers, which can easily be read from a file too.
Quote from: Leartin on January 12, 2024, 09:32:00 AMFitting the minimap to climates would work best with the minimap actually showing climates, an Extension Request.
I think that option already exists. If I remember right, one if the many buttons sets the map to show climates.
Last coding job before the weekend - I have tried to restore the shore transitions in Simutrans GL. There is a minor difference to Simutrans Standard though. Simutrans GL uses the water texture from the ground textures, Simutrans Standard uses a synthesized texture from the water tiles. I think for most pak sets it should work fine but if needed I can try to adapt to the synthesized texture approach from Standard now that I have figured out the rest of the code.
I think this can be further improved, at the moment I'm happy that I finally figured out how to emulate the alpha mapping of the shore map with the tiles in Open GL.
Good news, I think I can use a similar approach to bring the climate transitions back. They use the same trickery as the shore transitions.
Have a nice weekend everyone!
Quote from: _Hajo_ on January 12, 2024, 10:10:07 AMI think that option already exists. If I remember right, one if the many buttons sets the map to show climates.
There is an option to show climates
instead of heights. I was thinking of a hybrid, that uses different hues for the climates and brightness for height. Anyway, that's off topic.
So, finally I got the climate transitions back. My head and vector math surely are no friends. But it works.
There is currently a bug that causes the game to crash shortly after creating a new map. I have not fully figured out why that happens yet, just want to let you know it's on my list.
I've been working on an Open AL based sound player for Simutrans GL, but sadly a lot of time was lost due to hard-to-solve build problems, libraries and dependencies. Now I have build actions that produce binaries that run with sound on my Linux Mint 21 and Windows 10, but I have no good idea if they will run anywhere else.
Furthermore the sound player is very primitive and needs more work, e.g. it can currently only play one sound at a time.
https://github.com/Varkalandar/simutrans_ts/releases/tag/Simutrans_GL_Nightly
PS: IF there is no sound, check the sounds settings. It seems the former Simutrans GL versions saved settings with all sounds muted and you have to deselect the "Mute all sounds" box in the sound settings manually to get sounds back.
Good buttons say "click" now in Simutrans GL!
Most of them ... the pak selector is shown before the game has loaded any sounds, so right now I can'tlet the game play sounds at that time, but the usual in button in the game now make the click sound which is defined by the selected pak set. I hope I can some day change that to a theme defined click sound instead.
The sound player got cleaned up and can play up to 4 concurrent sounds now. Furthermore I could reduce the memory footprint of the Open AL sound player a little. Valgrind says I did not create any new memory errors.
https://github.com/Varkalandar/simutrans_ts/releases/tag/Simutrans_GL_Nightly
Besides the sound related changes, not much else happened. I have merged all changes from Standard, and it seems to work.
After making the UI more clicky, I remembered a suggestion of Andarix, to make depot windows show vehicles in the same size for all pak sets. Andarix suggested 96 pixel or 128 pixel size for that. I took 96 for my tests with Simutrans GL.
The zoomed images are of good quality for pak set sizes of 128 and more pixels, but get blurry if smaller images have to be scaled up. I've attached examples from 48 up to 144 pixel sets.
If someone wants to try, the new depots are in this version:
https://github.com/Varkalandar/simutrans_ts/releases/tag/Simutrans_GL_Nightly
Still trying to clean up the info windows. Just noticed that money values are formatted differently in different windows. I'll try to unify that.
I found a pretty bad bug in texture loading that could cause truncated, or partly transparent textures, where there should have been full colored textures shown.
This particularly affected pak sets with many objects and/or large graphics, cause it happened when a new texture atlas page was about to be used. Graphics were still loaded to the former page, at the very bottom and got truncated before the change was actually made.
Now the calculation of when to write to a new atlas page should be correct. So if you had strange filckering, truncated or just missing textures, please try version r11077:
https://github.com/Varkalandar/simutrans_ts/releases/tag/Simutrans_GL_Nightly
Took a while, but I found the cause of the random crashes after generating a new map. My code did not wait for the last simulation loop to finish, and occasionally created a new map while the loop was still running.
I think I got it right now. At least in my tests I had no more random crashes after creating a new map. The fix is in r11083, and I've also merged all recent changes from Simutrans Standard:
https://github.com/Varkalandar/simutrans_ts/releases/tag/Simutrans_GL_Nightly
Last night Github is not running on my Linux district, however I have tested the Windows executable using Wine and it works.
(gdb) run
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /home/casa/Descargas/simulinux_gl-x64(4)/simutrans/simutrans
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
warning: the debug information found in "/home/casa/Descargas/simulinux_gl-x64(4)/simutrans/lib/libXau.so.6.0.0" does not match "/home/casa/Descargas/simulinux_gl-x64(4)/simutrans/lib/libXau.so.6" (CRC mismatch).
[New Thread 0x7fffdfdff6c0 (LWP 12229)]
[New Thread 0x7fffdf5fe6c0 (LWP 12230)]
[New Thread 0x7fffd7fff6c0 (LWP 12232)]
[New Thread 0x7fffd77fe6c0 (LWP 12233)]
[New Thread 0x7fffd6ffd6c0 (LWP 12234)]
Thread 6 "pw-alsoft" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffd6ffd6c0 (LWP 12234)]
client_node_transport (data=0x5555569adc60, readfd=25, writefd=24, mem_id=0, offset=0, size=2312)
at ../pipewire-jack/src/pipewire-jack.c:1588
1588 c->socket_source = pw_loop_add_io(c->loop->loop,
(gdb) where
#0 client_node_transport (data=0x5555569adc60, readfd=25, writefd=24, mem_id=0, offset=0, size=2312)
at ../pipewire-jack/src/pipewire-jack.c:1588
#1 0x00007fffde0dce4a in client_node_demarshal_transport (data=<optimized out>, msg=<optimized out>)
at ../src/modules/module-client-node/protocol-native.c:380
#2 0x00007fffde1dc021 in process_remote (impl=impl@entry=0x5555569d6be0) at ../src/modules/module-protocol-native.c:1037
#3 0x00007fffde1dc808 in on_remote_data (data=0x5555569d6be0, fd=22, mask=1) at ../src/modules/module-protocol-native.c:1071
#4 0x00007fffded02f16 in loop_iterate (object=0x5555569ae378, timeout=<optimized out>) at ../spa/plugins/support/loop.c:496
#5 0x00007fffdedafdd7 in do_loop (user_data=0x5555569ae240) at ../src/pipewire/thread-loop.c:295
#6 0x00007ffff7688897 in start_thread (arg=<optimized out>) at pthread_create.c:444
#7 0x00007ffff770f6fc in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78
(gdb)
Edit.
At least in wine the zoom seems to work better, but that gray rectangle seems intriguing to me.
I'm not sure but I think that is (or should be) the custom image background in the paksets.
Your progress seems really interesting, i think your actions might in fact bring Ranran, the Extended GUI Department Pork, out of stasis. I'm sure he can help you with many things. Also, 128Britain has all its sprites rendered after 3D models, so maybe one day Simutrans goes 3D (not counting on prettiness considering the polycount, but realistic day/night with shadows and whatnot, just slap a pixel filter on).
Thank you! The gui renovation has turned out to be kinda scary, I want to do a better depot and also a new schedule window, but somehow I feel intimidated and don't actually start the work.
For the 3d part, I think a hybrid display is possible with bitmaps as we have them now and 3d models displyed in between. So a smooth transition seems possible, replacing the bitmaps with 3d models step by step.
Now spring is coming though, and with warmer weather my focus will shift towards gardening and outdoor activities. So progress will slow down some the next months.
Quote from: _Hajo_ on January 17, 2024, 07:46:59 PMAfter making the UI more clicky, I remembered a suggestion of Andarix, to make depot windows show vehicles in the same size for all pak sets. Andarix suggested 96 pixel or 128 pixel size for that. I took 96 for my tests with Simutrans GL.
The zoomed images are of good quality for pak set sizes of 128 and more pixels, but get blurry if smaller images have to be scaled up. I've attached examples from 48 up to 144 pixel sets.
If someone wants to try, the new depots are in this version:
https://github.com/Varkalandar/simutrans_ts/releases/tag/Simutrans_GL_Nightly
mmh, an alternative would be to add a customized depot graphic to the pak file.
So, I'm back for some more Simutrans development. The past months I've been learning Rust, which has some nice ideas, lots of safety checks by the compiler too, but at the cost of being quite restrictive in regard to what sort of code is "legal" to write. That is it has to be written in such a way that the compiler can check the code for correctness, e.g. not to have any race conditions or illegal memory accesses.
Also I've been learning some about more modern OpenGL. More modern than what I used in Simutrans GL so far. It will need some fairly deep changes, but with so called fragment shaders it should be fairly easy to get the player color feature for vehicles and player buildings back. I have no idea though right now about the performance impact, I expect it to be small though.
Not much has happened yet, Simutrans GL now resides in a repository actually named simutrans_gl, and I could merge all changes from Standard up to Monday this week.
https://github.com/Varkalandar/simutrans_gl
I also changed the name of the "nightly" builds to "development snapshots", because they are recreated each time the repository is updated, any time of the day or night.
https://github.com/Varkalandar/simutrans_gl/releases/tag/dev_snapshot
Little additions yet, just support of three font sizes now, the standard size, a larger and a smaller variant. The smaller is used in the minimap at the moment, but it seems hard to read, so maybe I'll revert that change again.
Next I'll do some playtesting and see what bothers me, and what I want to change.
I'm glad to see you back here.
Now that I have a modest AMD graphics card I'd like to run some performance tests. 8)
This development snapshot should be up to date with Simutrans 124.2.2
https://github.com/Varkalandar/simutrans_gl/releases/tag/dev_snapshot
Quote from: _Hajo_ on September 02, 2024, 08:53:23 AMThis development snapshot should be up to date with Simutrans 124.2.2
https://github.com/Varkalandar/simutrans_gl/releases/tag/dev_snapshot
I get a segmentation violation in linux
(gdb) where
#0 0x00007fffbee46753 in client_node_transport (data=0x5555561b0290,
readfd=24, writefd=23, mem_id=0, offset=0, size=2312)
at ../pipewire-jack/src/pipewire-jack.c:1588
#1 0x00007fffbc505532 in client_node_demarshal_transport (
data=<optimized out>, msg=<optimized out>)
at ../src/modules/module-client-node/protocol-native.c:380
#2 0x00007fffbc5ee01e in process_remote (impl=impl@entry=0x55555626f5d0)
at ../src/modules/module-protocol-native.c:1037
#3 0x00007fffbc5ee7f8 in on_remote_data (data=0x55555626f5d0, fd=21, mask=1)
at ../src/modules/module-protocol-native.c:1071
#4 0x00007fffdc017246 in loop_iterate (object=0x555556249918,
timeout=<optimized out>) at ../spa/plugins/support/loop.c:496
#5 0x00007fffbedfe4a7 in do_loop (user_data=0x5555561b0870)
at ../src/pipewire/thread-loop.c:295
#6 0x00007ffff75c26d7 in start_thread (arg=<optimized out>)
at pthread_create.c:447
#7 0x00007ffff764660c in clone3 ()
at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78
(gdb)
I must admit I am a bit clueless about this. I do not recognize any method/function name in this trace. Looks to me as if the location of the crash is in some library, not Simutrans code.
Which Linux version do you use? I could try to set up a VM with just that distro and see what happens there.
Quote from: _Hajo_ on September 02, 2024, 06:37:30 PMI must admit I am a bit clueless about this. I do not recognize any method/function name in this trace. Looks to me as if the location of the crash is in some library, not Simutrans code.
Which Linux version do you use? I could try to set up a VM with just that distro and see what happens there.
Wait, there are some additional libraries that must be used, right? I think the directory where the executable is doesn't have them.
CMake stores them in the "lib" folder and the created executable should load them from there. I suspect that some of these libraries again depend on other system libraries, and that there are differences between the Linux distributions. Simutrans GL needs a number of libraries that Simutrans Standard does not need (OpenGL and OpenAL and some support libraries like GLEW).
If you tell me which distro you are using, I'll try to set up a VM with just that, and see what I can find out about the problem.
I've compiled a new release, Simutrans GL v0.08, which is up to date in features with Simutrans 124.2.2.
https://github.com/Varkalandar/simutrans_gl/releases/tag/v0.08
In addition to the bug fixes and features merged from Simutrans Standard, there have been some Simutrans GL specific bug fixes:
- Fixed several accesses to uninitialized memory which occasionally could change scrollplane backgrounds to go black.
- Fixed the layouts of several list dialogs (factories, curiosities, vehicles ...)
- Fixed the city info window layout.
- Chat messages in the ticker line should have proper player color now.
There is still a leftover problem from merging changes from Standard. Currently there is no "Load Game" button in the new world dialog, but a "Back To Menu" button which just closes the new world dialog and does nothing else. To load a game in this situation, please open the options dialog from the top menu bar and select "Load Game" from there.
Quote from: _Hajo_ on September 03, 2024, 12:17:49 PMIf you tell me which distro you are using, I'll try to set up a VM with just that, and see what I can find out about the problem.
Im using fedora 40
Thank you. I'll set that up and see what I can do.
Quote from: Yona-TYT on September 03, 2024, 11:12:37 PMIm using fedora 40
So, there were some problems, but I think I have got it done. At least on my new Fedora Workstation 40 installation I could compile a version that runs. Now, the big question, will it run on your computer too? There are definitely some differences from Ubuntu because even with the same settings the Fedora build is 3 MB larger than the Ubuntu build.
Please follow the link and download the "simutrans_gl_v008-linux-fedora-x64.zip"
https://github.com/Varkalandar/simutrans_gl/releases/tag/v0.08
Let me know if this works.
Quote from: _Hajo_ on September 04, 2024, 02:30:09 PMSo, there were some problems, but I think I have got it done. At least on my new Fedora Workstation 40 installation I could compile a version that runs. Now, the big question, will it run on your computer too? There are definitely some differences from Ubuntu because even with the same settings the Fedora build is 3 MB larger than the Ubuntu build.
Please follow the link and download the "simutrans_gl_v008-linux-fedora-x64.zip"
https://github.com/Varkalandar/simutrans_gl/releases/tag/v0.08
Let me know if this works.
great!, Work well now :)
Captura desde 2024-09-04 13-02-44.png
Nice! So we now know its compatible with your card and drivers.
Quote from: _Hajo_ on September 04, 2024, 06:37:39 PMNice! So we now know its compatible with your card and drivers.
This card supports up to OpenGL 3, so it's a piece of junk.
I assume simutransgl is using OpenGL 2... although games already use gl 3 and above.
Yes, so far it's all very old style OpenGL.
I wanted to move to 3.2 though, to get access to the programmable pipeline with shaders. Seems I should wait some more with that.
There were some more problems left in v0.08 from the last merge with Simutrans Standard and also some older oversights which needed to be fixed. The list of changes is small, but some have bothered me and I felt a need to get a better version out. So here is the new and shiny v0.09!
Changes since v0.08:
- Fixed a crash when loading a theme without window title bar images
- Fixed a assertation failure when openening the mini map
- Station info icons (passengers, mail, freight, happy, unhappy, no route) are displayed again
- All list windows should have a common design again
- Tried to make the station info window more compact
- Tried to make the vehicle info window more compact
- "Back to menu" button in the new world window now opens the game options window (with option to load a saved game)
- There is a now an experimental build for fedora linux, because the ubuntu build did not work on fedora.
Downloads and sources:
https://github.com/Varkalandar/simutrans_gl/releases/tag/v0.09
The zoom out does not reach the same scale as in standard simultrans.
I also had some problems when trying to load an online game (not supported of course), the result was an infinite loop and I had to force quit.
The map thumbnail in the server loading window appears black.
Quote from: Yona-TYT on September 08, 2024, 03:54:15 PMThe zoom out does not reach the same scale as in standard simultrans.
A yes, I remember that problem. In Simutrans GL map is first rendered to a framebuffer which then is scaled. The size of the framebuffer limits the totally viewable area, I think it is 4096x4096 pixel currently.
I'll see if I can create a bigger framebuffer. At least in theory OpenGL should support up to 16000x16000 pixels, but in my one laptop anything bigger than 4096 failed, so I chose that as max size, but it surely would be good to use a bigger one on systems that allow bigger buffers.
The netork related things, I must admit I know very little about that part of Simutrans. I tried not to break anything, but chances are that something broke anyways. Problems there will need more time to be fixed. I want to focus on the basics first.
Update: The mentioned laptop has only 128mb graphics ram and simply runs out of graphics memory with a bigger framebuffer. I can detect the error code. This means I could try to get a bigger framebuffer on machines with enough graphics ram and fall back to the small buffer if creation fails with an out of memory error.
Quote from: Yona-TYT on September 08, 2024, 03:54:15 PMThe zoom out does not reach the same scale as in standard simultrans.
This version should offer one more level of zoom if you have at least 256MB of graphics ram.
https://github.com/Varkalandar/simutrans_gl/releases/tag/dev_snapshot
Been working on light effects again. Still not 100% convinced, but I think I found a fairly good place in the code now to put the display of the light effects. For objects like stations I can put the light-halo above or below the front image. In these examples the light is displayed above and illuminates the whole structure.
The tricky part is to keep the pak files compatible to Simutrans Standard and still feed the lighting data into Simutrans GL's display engine. A proper solution will definitely need more planning. This is just a proof of concept.
As a welcome side effect of these experiments, I could fix the climate transition display at night (they were glowing before). The fix has been applied in the current development snapshot on github.
Quote from: _Hajo_ on September 09, 2024, 05:19:47 PMThis version should offer one more level of zoom if you have at least 256MB of graphics ram.
https://github.com/Varkalandar/simutrans_gl/releases/tag/dev_snapshot
It works for me, although I get drops below 12 FPS with a 2432x2432 map.
I guess the GPU isn't being used very much.
(https://github.com/Yona-TYT/imgs/blob/f25423fdc813a96f162390abad4c6337cfd6a69d/Captura%20desde%202024-09-09%2019-15-35.png?raw=true)
Edit.
Minimap focus goes out of bounds.
Captura desde 2024-09-09 19-23-35.png
Dragging horizontally with the mouse should allow you to move the pakset panels, but they do not drag and when the click is released the focused pak is loaded when the click was pressed.
Captura desde 2024-09-09 19-24-40.png
Thank you for testing. The feedback is very valuable.
Yes the GPU is only used for texture stuff, all the position calculations still happen on the CPU. The many trees in the screenshot are the problem, each goes through all position calculations and currently all these happen on the same CPU core because OpenGL does not support being used from multiple threads. I'll need more time to understand the rendering logic of Simutrans better and see if I can bring multi threading back there on some level.
The minimap is sadly broken in many ways. It will need time to fix it. It's on my list, though.
And I didn't know that scrollpanes in Simutrans standard support dragging with the mouse. I'll see what I can do about it.
The pak selection scroll pane should support dragging by mouse in the new snapshot. I must have been way too tired when I coded that and the code to check for a mouse click was totally off; actually a surprise that it worked at all.
I've tried to fix the small cracks in the world display that occurred at certain zoom levels. This required a fairly deep rework of the zoom function and touched more than 10 source files, which means, I might accidentally have broken something or missed something.
The new zoom code is in the current development snapshot,
https://github.com/Varkalandar/simutrans_gl/releases/tag/dev_snapshot
Overall I like this version better, it's cleaner than the former and simpler. Performance should be about the same. This version saves two multiplications and additions per tile displayed, but that is way too little to be noticed.
Two problems related to zoom:
- As the zoom out scale increases, scrolling on the map becomes slower.
- Zoom in should maintain the position relative to the mouse cursor, but this does not happen correctly.
Quote from: Yona-TYT on September 12, 2024, 11:08:37 AM- As the zoom out scale increases, scrolling on the map becomes slower.
Is this worse than before or about the same? (It should be about the same, otherwise I broke something by accident. There always was some slowdown on zooming out because more objects must be displayed)
I'll look into the zoom center problem. That's something that my changes easily might have broken.
Yes, I have noticed an improvement. 8)
Improvement sounds good. I've merged the new zoom code into the main branch and tried to fix the zoom center problem. I could achieve an improvement there too, but it's still not quite right.
Then I went back to the lights, tried to set up interfaces and data structures to allow each object on the map to have a light inside (if it has front and back image) and a light above. Still missing are the configuration files, there are still hard coded values in the program for the display tests. But I think with another day or two I should have set it up, so one can compile pak files with sets of lights and assign these lights to other objects. Still left to do, head and tail light effects for vehicles to illuminate the road. That needs quite some lights per vehicle (8 directions each), but I want to at least show a proof of concept some day soon.
Here a combination of "lights inside" and "lights above". I think it can still be improved by better light textures and better placement. That will be part of the configuration though, once done.
Lighting is a very nice new feature, especially if it can also come with color.
Do you go by the OpenTTD route, with an 8 bit player map and additionally a fullcolor light map ...
I don't know how OpenTTD works on a graphics level. OpenGL allows to tint a texture with any color, and the lights in the different screenshots have slightly different colors. The feature to have colored lights is already in the code.
What's missing is to configure the lights on a pak set level. I'm working on that. Each light will have a color which also defines the brightness and a texture which defines the falloff from center to the border of the light. Also offsets where exactly the light texture has to be displayed relative to the lit object.
Simutrans GL doesn't support player colors yet, I'd need to use more advanced OpenGL features for that. Some day I'll bring back support for player colors, right now I'm experimenting to find out what I can do with the already existing code.
Quote from: _Hajo_ on September 14, 2024, 09:22:30 PMHere a combination of "lights inside" and "lights above". I think it can still be improved by better light textures and better placement. That will be part of the configuration though, once done.
Wow they look amazing!
Quote from: Yona-TYT on September 15, 2024, 12:28:17 PMWow they look amazing!
Thank you!
@Prissi, I've attached an example with different light colors and light textures for station and road lights. I'm still working on the configuration though, about 50% done.
Quote from: _Hajo_ on September 15, 2024, 03:17:25 PMThank you!
@Prissi, I've attached an example with different light colors and light textures for station and road lights. I'm still working on the configuration though, about 50% done.
I already posted it on X. ;)
I'm working on particle effects for buildings and other objects. Here a ground object, sort of a volcanic geyser. The code needs some more refinements, there are many hard coded values at the moment, which need to go into some configuration file.
Edit: I think I can let particles fade over time (make them more translucent), scale them (shrink or grow), and give them other paths, like the arcs that water drops in fountains traverse. They can even be stationary and just fade/shrink like sparks that pop up and fade again. Must see which of these options are actually useful and how much effort it is to support all of these ideas. I think fountains will be interesting and useful.
I hope animated gifs work in the forum:
output.gif
Can the particles change texture over time? Then they could replace current smoke objects directly.
You mention different paths. Do you have to hardcode paths, or could a formula be provided via dat? I enjoy using shorthand dat to animate frontimages with position calculations, but those are 'precalculated' in makeobj. If simple formulas with time and a random value were possible, supporting PEMDAS and some form of sinus, for x and y position, scale, opacity and texture, I think it would provide the most freedom.
Something to think about: It seems to me your advancements here could be used for weather overlays (rain and snow surely are particle effects, you can probably get ripple-effects via shaders for trees to make them look like leaves are shaking,...), and weather - especially wind - would affect most use-cases of particle effects. Might make sense to think about particle effects being influenced by world states?
At the moment paths are like pos(t) = pos_0 + v * t + 1/2 * a * t² (all 3d vectors) where you can define pos_0, v and a as part of the configuration (plus some randomization for each, there are ranges in the config, like minimum v and maximum v for each axis).
An interpreter for something like pos = f(t) with a user defined f(t) will be overkill I think. It's not impossible though, I have just recently written something like that as a Rust training project.
The textures can change over time. That's fairly easy to code. At the moment color and size changes will be linearly interpolated from start to end settings, textures can change over a sequence of given values by time.
If the particles and generators can replace the smokes, I have doubts. Compared to the traditional smoke objects the particle generators and particle data are fairly heavyweight. I'm worried that for large maps frequent use of these will be too demanding.
I definitely have plans though to use the particles this way. For factories and also for vehicles to show sparks for pantographs, exhaust smoke and the like. I'll post examples once I have results to show.
Weather effects - yes, and since OpenGL does full screen updates all the time anyways, it won't be as much of a problem as in Standard where display performance depends on how much of the screen changes between two frames. I'll look into that, but later. I was thinking about wind effects to move some of the particles, this will probably come first because it's directly linked to particle movement which I am working on anyways.
Give me some more weeks to finalize the configuration and publish examples for at least one pak set.
Thank you for the feedback! That helps me to move on, and keep a good direction.
Here a version with gravity configured to be greater than zero,
output.gif
Quote from: _Hajo_ on September 25, 2024, 02:09:03 PMpos_0 + v * t + 1/2 * a * t²
I see, that should allow any straight path or single curves by approximating sine with a quadratic, yes?. An additional parameter to enable oscillation might be nice (think leaves falling from trees, slowly swinging left and right on their way down), but that's already quite flexible as it is.
Straight motion and this sort of curve,
https://en.wikipedia.org/wiki/Projectile_motion
Test have shown I need to add some more options for the initial direction of the particles. I'll post examples once I have that done. Also attaching a particle generator to a factory building has turned out more complicated than expected. I'll need some more time for that too.
Now with extra sparkles! And attached to a factory. But map rotation screws it. I'll have to fix that before a release ... also need to make the particle size configurable, it's hard coded at the moment.
output.gif
Clouds make some pretty fat particles. Some day I'll try to animate the shower in the rainmaker too.
output.gif
Hajo, i hope you're still inclined to keep working on the OpenGL in Simutrans. Gotta remind you, Simutrans (especially Extended) is amongst the most mechanically advanced transport tycoon games out there, as far as i am aware. It's just it looks old and plays kinda old for modern times, and your OpenGL refreshment might bring perhaps dozens, if not hundreds of new players to community
I can't tell if you realize that Hajo is the original creator of Simutrans or not. lol.
But I do agree that I think having OpenGL in Simutrans might garner more interest in the project. :)
An OpenGL-related patch was recently discussed, you can find it here: https://forum.simutrans.com/index.php/topic,23493.0.html
Hajo, having exchanged messages with Ranran recently, he seemed very interested regarding your OpenGL project, and somewhat sad regarding you shifting development time towards other projects. No pressure, but believe that once you continue working on OGL in Simutrans, Ranran will be interested in trying to implement your developments in Extended, seriously spicing up the development of both Standard and Extended