moolicc / wallop

Extensible, living/animated wallpaper engine built in C# using Silk.NET's OpenGL wrapper at its core.

As you can see, I'm by no means a graphics designer.

But I like coffee and I can code, so I must be a programmer.

What's this place about?

This little corner of the internet is where you'll find the quantified results of too much caffine intake. I use my github for both personal endeavours as well as school projects, so if you dig around too much you might need to take some time off to recuperate.

Interests

So here are listed some of the technologies / frameworks / stacks / things that you may or may not encounter here.

wallop's Issues

DSL for layouts

Write a DSL for layout creation. Could this replace wapp files entirely?

Refactor: redo the Engine's service locator.

Engine should load scene configurations

The Engine should be able to parse and load scenes from configuration files.
Note that any consequent saving may or may not happen to the same configuration files.
This permits multiple instances of the engine.

The UI needs to be present in the system tray

Error handling

It'd be ideal if the Engine as well as Layer Scripts could propagate warnings and errors up to the app for user interaction.

WappWriter needs to be implemented

Write the new Controller

The new Controller needs to be written still.
Basic functionality is in the project's readme.

Write the new Engine

The new Engine needs to be written.

It should be a .net standard 2.1 project.

More details in the project's readme.

Write the new Presenter

The new Presenter needs to be written.

It should utilize the Engine for everything except actual presentation.
It should use mongame, and .net core 3.

More details in the project's readme.

EnginePlugins

It'd be neat if we could allow engine plugins to extend engine functionality.

Some of the things we could do with this includes:

• Different scripting environments
  • This will require modifications to primarily the Engine itself
  • Modifications to the wapp reader/writers
  • And modifications to the necessary Layer Creation UI components
• Utility/Framework addons for scripts
  • We might want to provide a nicer API for simply getting some 2D stuff on-screen for example to avoid all the Textrure2D loading boilerplate

Included in the manifest would be information on dependencies to Engine Plugins so that the app can resolve them when necessary.

Implement support for Directors

We need to implement directors and director execution into the Engine.
They should be able to access the Ecs root for the current layout, as well as switch active layouts entirely.

Package definition file implemented as DSL?

Evaluate the pros/cons to writing a small dsl to handle the definitions of packages and their modules.

Add in intro/outro layer animations

Cog needs to resolve setting bindings independently from a base type

Currently, for Cog to load concrete instances of classes containing properties pertaining to a grouping of settings, that class's type must inherit Cog.Settings.
Remove this requirement altogether.

Implement Engine module execution

The Engine should be able to execute modules which will ultimately be in charge of handling a single axiom (instance of a module).

No Longer Works

Unfortunately, a Windows update has broken this nifty little thing.

Engine scripts

Add in engine scripts to the app that can dynamically adjust not only the layers within any given layout, but also hot-swap entire layouts themselves.
Thinking lua for this.

PluginPantry should be able to resolve endpoint parameters from fields in the endpoint type

EditMode controls need to be added

• The ability to lock/unlock layers
• The ability to snap to specific increments of x/y
• Perhaps support smaller, more incremental x/y location/size changes via keybindings
• Might need to allow right-clicking to allow the user to select a layer in the event they get too close for the user to pick the one they want

PluginPantry should auto resolve endpoints

PluginPantry should be able to resolve endpoints without the plugin explicitly declaring them

Common script execution functionality

We need a shared project to facilitate script execution.

The Engine will use this to execute Modules.
The Presenter will use this to manipulate the Engine.

Logging

We need to add some sort of logging to make this easier to debug in the wild.

Implement support for Components

• Modules need to be able to interact with components in the ECS.
  Implemented via "BindableTypes", exposed in DSLExtension.Scripting. It permits the binding of a value in an IScriptContext to a property in inheriting types.
• Actors and Directors both need to support adding / removing components.
• Actors and Directors both need to be able to create component bindings.
• Directors need to support querying for actors based on components.
• Create query language to support this (moved to #62)
• The user needs to be able to add these in when they define the scene.

PluginPantry shouldn't need a concrete class for the EntryPointContext

Currently, the entry point plugin is kind of a hassle and ugly. Refactor it.

Rewrite IPC

Revamp scripting

Decide and stick to a single language for module scripts.
This way, scripting will be much more concise as the API can be tailored to a single language.

Implement Engine logging and Exceptions

Probably use nlog for this.

• Implement quick and easy abstraction to get NLog loggers.
• Swap existing logging to using NLog logger.
• Implement logging in additional subsystems.

Explore the possibility of making (or at least refactoring in preperation of) both the Engine and App crossplatform

Write the composer

The new composer should be built, along with both support for Light and Dark themes.

It should use avalonia this time, and .net core.

More details in the project's readme.

More module types

We should have some additional module

• Component
  An actor's component

Implement Veldrid

Implement Veldrid for our rendering backend.

This should include pulling down the nuget package, and getting a window created with something rendering to it.

Implement Windows desktop renderer

We now must implement the plugin or rendering the veldrid contents to the desktop.
This implementation should work on at least Windows 10 and 11.

Further refactor

Let's go ahead and refactor this way further than initially planned.
The goal of this is to increase how modular the program is as well as increase extensibility.

New structure

The new project structure can be grouped into two sides.
The client side being what users directly interact with.
The runtime side being what the client-side interacts with.

Client

• Composer
  The UX part. UI to control the controller.
• Controller
  Command-line client to connect to and direct the operations of multiple Engines.

Runtime

• Engine
  The brains behind the presenter. Basically provides an API for presenters to implement.
• Presenter
  Puts what the engine tells it to on screen.

Shared projects

• IPC
  Inter-process-communication to allow everything to talk together. Should support either local or remote talking.
• Types
  Common data that both the client and runtime sides will need to communicate with each other.
• IO
  Common IO tasks between both the client and runtime sides. This will be the home of things like relative/absolute conversion for module scripts as well as wapp file IO.

TODO: Find somewhere to put client AND runtime extension types.

Implement Engine plugin loading

The Engine should allow certain things to be extended via plugins, with fall-backs to concrete implementations.

Variables in package xml format

This could reduce repetitive xml

GUI needs to allow the user to create components from setting values

The GUI should allow the user to setup components from various setting values regardless of the script doing so.
This allows the users to make actors compatible with directors they may not be entirely designed for.

Implement custom DSL

A custom language for writing modules in might be handy.

Preview box for edit mode when the user moves/resizes a layer.

When a user attempts to resize or move a layer in EditMode, the engine just needs to display a preview box to show where the layer will end up. This will prevent the associated controller's rendertarget from being re-created with every single mouse-movement.

Module execution error handling

If an error occurs during module execution, we should propagate that error up and handle it gracefully.

• Handle uncaught exceptions.
  What does it mean to handle this?
• Provide functionality to scripts to panic.
• Provide functionality to scripts to warn.
• Provide logging capabilities.

Separate the UI from the engine

The UI should be separate from the actual engine and use some form of IPC to communicate between the two.
This will be quite the undertaking.

Module invocation plugins

Add a plugin endpoint for before actor/director update/draw, after actor/director update/draw, etc.

Common settings serializing/deserializing

We need a common project to manage the saving and loading of various settings.
The consuming code should be able to setup default values with ease.

Engine should implement common Settings handler

Expose more globals to modules

Expose more useful globals to modules

• Expose logging capabilities
• Expose settings capabilities (solved as part of #56)
• [] NOW TRACKED IN #83
• Ability to add tracked values through scripts
  • Ability to create a local variable if no tracked state exists, or return the tracked variable if it exists. (solved via fc5a504)

Cleanup build script

Extend module settings

We should allow plugins to extend available ModuleSettings types.
Bear in mind the ramifications for the future GUI to this. The plugin, or another type of plugin, should be able to extend the GUI to properly allow control over the setting type.

Common plugin loading mechanism

We need a common project shared between the engine and presenter that can facilitate loading plugins.

Wallop.DSLExtension should support loading compiled scripts

Move appropriate components to their own independent projects

Certain core functionality in the engine can and may need to be exposed and shared to other proejcts within the wallopsphere.

Implement Veldrid backend

When I git gud at Graphics Programming, it might be of benefit to change the graphics backend from silk.net to Veldrid.

Update
Re-evaluate the necessity of this. It might be handy to permit the user select a preferred backend, but opengl via silk.net should suffice for the foreseeable future.
The only gotcha is opengl's lack of multithreading (or my lack of knowledge thereof)

We do in fact need to leverage Veldrid or at the very least, vulkan directly for multithreading capabilities. See: #70