The "both" option for the movie display obscures the song jacket during gameplay about dtxmanianx HOT 6 OPEN

The code is very messy, partly because you have x/y coordinates hardcoded everywhere.
A full component (e.g. the score, graph, movie, game itself, status panel etc.. ) should be fully encapsulated in their CAct class, and shouldn't care about where it is located. All drawing code should be relative to the component position.

I still think that the location of each component should be part of the Skin.
Let me take a few examples:

• DTXMania in DTXViewer mode. Currently the display is very different from DTXV.exe because all components are hardcoded to a fixed location which works well when you play, but not for writing DTX files. We could have a DTXViewer skin which would be much simpler, have the lanes on the left side and minimal information on the right side. In the future we could also have drums, guitar and bass at the same time as in DTXV.exe
• The new small graph. It is thinner than the original, but it is at the same location. First reaction from players on Discord was: with XXX skin which has square angles, could the graph be closer to the lanes? It would be possible if the component location was part of the Skin.
• I'm working on a new feature which will include 2 new UI elements on the Song Selection screen. One of them should be just above the BPM box, but the BPM box was directly drawn on the background on Exchain and Nextage skins, and doesn't take the same space. The other one should be on the top, but the top 'header' text is much larger on Nextage, so my new UI element should be more right.
  This is why I first had this idea of setting the component location directly in the skin.

Moving the component location to the Skin would make DTXMania clode cleaner (each component cares about their own business, which is what's inside the component), and would make it possible to make better skins.
We are shipping the skins with DTXManiaNX anyway so we could easily add this XML file (at least when a custom location for a component is wished). XML file would be optional anyway so we keep compatibility with skins coming from other sources.

from dtxmanianx.

The movie display is currently located (lower-right corner) where it was during the XG-era (pre-GITADORA) of the game and has not been modified to relocate it to the top-right corner

from dtxmanianx.

We'll probably not fix it because we will either have to shrink the movie window or shrink and shift the song jacket somewhere else.

from dtxmanianx.

@limyz I think in recent Gitadora it's the jacket which was moved from lower-right corner to top-right corner.
That leaves space for the movie to show in the middle of the right side.

So ideally we should do the same, but I'm not too much in favour of doing adhoc changes to follow a specific Drummania/Gitadora version.
I think it would be cleaner to just make the movie position and the jacket position configurable in the Skin, so that we can have a difference gaming experience when we play with Gitdora Skin, Tri-boost skin, Exchain skin etc.
I was already thinking of adding an optional XML file with the skin to configure the position of a new UI element, we could progressively add existing UI elements (like jacket or movie) too.
If this XML file is missing in the skin, elements would just go to default/hardcoded position.

from dtxmanianx.

Since drawing of UI elements is decided by us, we can add an configurable option to allow this to happen. Adding more files already complicate the distribution of dtx files and restricts that particular xml to our usage. We can try to work with the latest before backporting to older versions.

from dtxmanianx.

Sorry to necro an old thread, just wanted to throw some thoughts out as to me this is an area that needs attention before more radical interface changes can be made.

Changing activities to have a local coordinate space is certainly a move in the right direction, but I feel that it could be taken much further than this. Currently activities copy-paste a lot of code for common tasks which is very messy, such as simple things like bNotActivated checks before performing any methods (is there event a reason for there to be an option to continue lifetime without being activated?) Acts themselves generally feel very outdated, things such as manually performing draw calls, manually handling child lifetimes, update and draw being grouped, the manual handling of animation counters, and managing unmanaged resources are all things that should be a lot more encapsulated.

I'm partial to changing activities to be more of a scene graph. They already are scene graphs-lite in a way, but the separation of drawing and the graph is unneccesary. In my opinion activities should not contain any draw code, instead delegating this task to children within the graph (for example a Sprite node would allow drawing of a texture). This immediately leans into a much better basis for encapsulation, as components are entirely independent objects within the graph that can exist anywhere. They should almost always be unaware of their parent, instead providing basic interfaces for accessing their functionality (for example a Jacket node would contain a Song property that sets the source). This also opens the door for many further improvements later down the line, such as propagating events like input or state changes down the hierarchy, allowing further independence of components and the screens they are within.

This system can be slowly phased in, initially providing a compatibility activity that contains its own graph. Slowly over time individual components can be moved to this system until the whole program can exist in one graph. Or well that's the end goal anyways, haha. This is obviously a lofty proposition. I've implemented a basic working sample of this just to test it out, and I think it could be very beneficial for improving the program in the future. I'm curious on other people's thoughts on this, so please do give your input if you have any.

And just my 2 cents on skinning, providing an INI/XML file for further customization works as a stopgap, but in my opinion a more fleshed out and feature-rich system could be implemented with Lua skins like in StepMania and unnamed-sdvx-clone. Perhaps this new scene graph system could be provided as an API? Not too sure, I haven't put much thought into it, but DTXMania skins feel pretty outdated and limited, and providing a ton of customizable parameters is bleh.

from dtxmanianx.