Pattern editing and rendering within OpenMPT

Started by FreezeFlame(Alchemy), February 17, 2020, 23:05:11

Previous topic - Next topic

FreezeFlame(Alchemy)

After playing around with several GUI libraries (GTK+, wxPython, Tkinter) and booting up OpenMPT after some fantastic (or stupid) new idea manifested, took a closer look at the pattern editor and started wondering, "How the hell did they made this work?!". Did some experiments to emulate that, and all of them failed.
Afterwards, i became fascinated by it and started to look at the C++ code. Noticed that i understood about 1/5 at best (might be since i haven't learned template metaprogramming in C++ yet), and not even the part i am curious about.

Developers of OpenMPT, would you be so kind to explain how you managed that feat?
And from what GUI widget is each cell of the pattern even made of? Are they custom or improvised labels, maybe even neither?
Blue Flames of the Night.

Was known as Alchemy before(with an Dialga picture).

Saga Musix

The pattern drawing code is very old (most of it is more or less untouched since the old MPT days), and it certainly doesn't use a lot of template metaprogramming, so I have no idea where you looked at to get the idea that it uses templates or other complex C++ magic. There are no GUI widgets involved. All the drawing code is in Draw_pat.cpp and it does little more than filling an off-screen bitmap with text, rectangles and copies of other bitmaps (pattern font and VU meters) and then copies that image on the screen. This is pretty much bog-standard WinAPI GDI code like you will see it in a lot of older Windows applications, so some familiarity with GDI (DCs, window handles, bitmaps, pens, brushes) would be helpful for understanding the code.
» No support, bug reports, feature requests via private messages - they will not be answered. Use the forums and the issue tracker so that everyone can benefit from your post.

FreezeFlame(Alchemy)

Thanks for the reply, Saga Musix.
QuoteThe pattern drawing code is very old (most of it is more or less untouched since the old MPT days), and it certainly doesn't use a lot of template metaprogramming, so I have no idea where you looked at to get the idea that it uses templates or other complex C++ magic
I was tired while checking it then. And i think i might have screwed up while looking.
But just to be sure, i read through Draw_pat.cpp and your right, almost no templates.
QuoteThere are no GUI widgets involved. All the drawing code is in Draw_pat.cpp and it does little more than filling an off-screen bitmap with text, rectangles and copies of other bitmaps (pattern font and VU meters) and then copies that image on the screen.
Very interesting. Read about GUI frameworks having such a option before, but never thought that OpenMPT did exactly this. Sounds like a PITA to implement.
QuoteThis is pretty much bog-standard WinAPI GDI code like you will see it in a lot of older Windows applications, so some familiarity with GDI (DCs, window handles, bitmaps, pens, brushes) would be helpful for understanding the code.
No wonder i understood almost nothing in regards to how it ended up being drawn. I am taking a look at this WinAPI GDI.
Blue Flames of the Night.

Was known as Alchemy before(with an Dialga picture).

Saga Musix

Quote from: FreezeFlame(Alchemy) on February 18, 2020, 12:04:21
Very interesting. Read about GUI frameworks having such a option before, but never thought that OpenMPT did exactly this. Sounds like a PITA to implement.
You have to understand that the UI framework OpenMPT uses, MFC, is only an extremely thin layer above the WinAPI. Basically anything is a PITA because there is almost no abstraction from the OS. Most cross-platform toolkits are (indeed, they must be) more high-level compared to MFC, but of course this also comes at a cost (which may be negligible these days).
However, I wouldn't necessarily say that implementing something like OpenMPT's pattern view using e.g. widgets in Qt would be any easier than what we do. In particular, such an implementation may end up many times slower than pure bitmap drawing (or accelerated drawing with OpenGL / DirectX), so might be easier to implement but in the end it could very well end up in an unusable result.
» No support, bug reports, feature requests via private messages - they will not be answered. Use the forums and the issue tracker so that everyone can benefit from your post.