News:

The Forum Rules and Guidelines
Our forum has Rules and Guidelines. Please, be kind and read them ;).

A Simutrans Prettification Project + Open GL dev

Started by _Hajo_, January 31, 2023, 08:20:59 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Yona-TYT

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.

_Hajo_

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.

Isaac Eiland-Hall

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.

Yona-TYT

@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?.

_Hajo_

#39
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.

Yona-TYT

This is great! I really can't wait to see the results, let's hope for something big! :)

Isaac Eiland-Hall

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. :)

_Hajo_

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).

TurfIt

#43
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.


isidoro

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?

Andarix

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.

_Hajo_

#46
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.

_Hajo_

#47
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.

Yona-TYT


_Hajo_

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.

ceeac

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.

_Hajo_

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

_Hajo_

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.

Yona-TYT

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).

_Hajo_

#54
"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.

Yona-TYT

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.

_Hajo_

Thanks for the report. I'll look up the error message and number and try to find out what went wrong there.

_Hajo_

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.

Yona-TYT

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

Yona-TYT



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

_Hajo_

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.

Yona-TYT

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.

Yona-TYT

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

Isaac Eiland-Hall

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. ;-)

Yona-TYT

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

_Hajo_

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)

_Hajo_

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.


Yona-TYT

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.

Yona-TYT

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)

_Hajo_

Thank you :)

And I agree, the event handling needs improvement. There is a lot left to do.