Not sure if it's better suited at a Game or Host level. Need to investigate.

glScissor is being called even when no change is made to the scissor area.

As the title suggests, both keyboard and mouse input have been taken in osu! even when another window had focus. This is occurring on Linux in case the issue is platform specific.

I was hoping we could get by with just binding to input events to retrieve the state, but there are certain cases where this doesn't suffice. One such example:

Parallax container needs an up-to-date mouse position. When a parallax container is temporarily made invisible, it will stop receiving input events, meaning after it is made visible it may "jump" to place due to the lack of up-to-date positional information.

Another case is the initial cursor position when starting the game, which currently does not reflect the mouse position because it can't.

Not sure on the best way to handle this one, opinions? @Tom94 @smoogipooo

About Desktop .NET Framework

Currently we are targeting .NET Framework 4.5. If choose a higher version, we will get:

Benifits

• Large object heap(LOH) explicit compression. Since .NET Framework 4.5.1 .
• Windows Forms dpi support improvement. (Although we don't use controls of it) Since .NET Framework 4.5.1 .
• HttpResponse improvement. Since .NET Framework 4.5.2 .
• RyuJIT. Since .NET Framework 4.6 .
  • RyuJIT has a better SIMD support for System.Numerics. This world be useful.
• Fundamental Class Library expanding. Some of them may be available via nuget to earlier frameworks, but some runtime-related are not. Since .NET Framework 4.6 .
  • TryStartNoGCRegion and EndNoGCRegion.
  • System.Security.Cryptography
  • DateTimeOffset.FromUnixTimeMilliseconds(). Currently we are implementing again.
  • Enhanced WININET, if running on Windows 10.
• Enhanced X509 cryptography support. Both in .NET Framework 4.6.1 and .NET Framework 4.6.2.
• Debugger improvement for NullReferenceException. Since .NET Framework 4.6.2.

Limitations

• System requirement
  • .NET Framework 4.5 supports down to Windows Vista SP2.
  • .NET Framework 4.6 supports the same OSs.
  • Since .NET Framework 4.6.1, Vista support are dropped. Now is supporting down to Windows 7 SP1.
  • Not sure for Mono implementation.
• Development environment
  • Since we are using C# 6, VS2015 or MSBuild2015 is required. Won't trouble.
  • Not sure for MonoDevelop and XamarinStudio. But if using cross-platform Roslyn for compile, C# 6 and latest .NET Framework should be supported.

About .NET Core

Benefits

• Original cross platform support.
  • Can be compiled to native executable of each OS.
• Supported by Visual Studio Code, which is crossed platform pretty well.

Limitations

• Very lack of GUI support.
  • Currently there are no GUI library in standard .NET Core libraries, and no plan for it.
  • OpenTK on .NET Core is not completed.
• Redistribution for dependencies.
  • Desktop .NET Framework installs the first party libraries into GAC, so it's guaranteed on every client , and a very small assembly can do many things.
  • .NET Core can distribute the runtime with application, instead of installing it and a whole SDK. But this causes that every dependency should be distributed together with the application. The standard library will be a large cost.
• Currently no stable toolchain
  • The current project model is temporary, just because different teams start work on it individually. For further plan, some project files will be combined. (Probably when releasing the next version of Visual Studio)

About .NET Standard

Introduce

.NET Standard is a concept to replace Portable Class Library, to let library support different targets. Detailed information can be find here.

Plans

• Our generic Framework and OsuGameBase can be on .NET Standard, then we can put runtime-specific and OS-specific content into Desktop and Core project.
  • This needs all dependencies to be compatible with both runtime.
• Or we can just let Framework and OsuGameBase project to be multi-target.
  • By targeting to desktop and core version that support same version of .NET Standard, there's totally no #ifdef needed.
  • This needs to wait for a stable toolchain. Currently things are terrible when mixing csproj and xproj.

Or even better: Containers which contain games at some point.

Alternatively: If only one Game should be allowed, then this game should be passed in not via the standard Drawable.Add interface which might mislead readers, and also requires a cast from Drawable to Game.

Contains low-level entities like GameHost and GameForm.

Open to suggestion.

Currently inline gl texture state changes are happening in TextureGLSingle which don't account for VBOs.

I think they may need to be applied to the AddTarget.

Example is MainMenu.cs Content.MoveTo

Needs further investigation.

We need to sort out some solution for rendering characters that aren't in our font pages. We could probably make a working texture page that dynamically renders and rasterizes characters on-demand.

Currently in a bad state.

is needed.

Right now they can potentially be shared between DrawNodeTrees, creating a point of contention.

Right now when double clicking then dragging, selection will completely ignore spaces (and only include them in selection when selecting the next word in the direction of the drag).

Instead, all non-words (special characters/symbols/spaces) should be individually added to the selection.

selectable ranges currently:

this is a sentence

corrected:

this is a sentence

Used to be cached, but was removed due to random bugs showing up. It's a regular access and is currently doing a tree traversal; fixing it should bring great performance benefits.

Number of batches per frame, etc.

There is a lot of potential for the user to forget to call base.X(). In places where things will fail if the base call is missed, we should instead move it to be a call outside the virtual method where possible.

todo: add examples if this isn't clear enough.

Brief:
If output audio devices are disabled, osu! crashes on launch.

osu! version:
ppy/osu@4fc681a

Steps to reproduce:

1. Disable audio devices.
   
2. Launch osu!.

Actual result:
Crash.
System.StackOverflowException in AudioTrackBass.CurrentTime (did not investigate in detail yet).

Expected result:

1. I can launch osu! even if my audio devices are disabled.
2. I can't enter PlayMode.

Additional info:
Current osu! stable client does not have this problem.

Hey,

I already mentioned it in dev chat.
I'm currently writing a proper Mac app for osu!
I found out that Xamarin.Mac has no WindowsForm implementation and using MonoMac isn't
recommended (also it needs to be installed by the user and doesn't ship with the app package).

I would suggest writing a WindowsForm for Mac (Cocoa UI).
Also maybe we can resolve the graphical glitches this way on Mac too.

Mac supported .Net assemblies
https://developer.xamarin.com/guides/cross-platform/advanced/available-assemblies/

We really need to standardise how drawables should be initialized in a way that makes sense and drives conformity. My current thoughts are:

class MyDrawable : Drawable
{
    ctor()
    {
        //initialise children using Add or Children = new [] { ... };
        //should be simple operations as to not incur a performance overhead.
        //drawables can be constructed on any thread and in a disconnected tree.

        //any defaults for size/relativity/etc should be set here such that the consumer can override in object initialiser.
    }

    override Load()
    {
        //we now have Game available for loading textures and other heavy resources.
        //this should only be called on the update thread.
        //this should be able to start async loading and use this to strive to not incur a performance overhead.

        //avoid setting any defaults here.
    }
}

On x86 this is not necessary, but on other platforms changes in one thread may only become visible at a later point on other threads.

Check whether there are ways that we can improve MagickImage performance or find a leaner alternative.

I am talking about public virtual Quad ScreenSpaceInputQuad => screenSpaceDrawQuadBacking.Value; in particular.

I believe we should re-think and constrain where and how invalidations happen, and how the rest of the Update code interacts with changes that happened within the very same frame.
One possible way to attack is to make changes be a transaction that is only applied after all Update code has been executed, and before DrawNodes are generated. This way all Update code would see one consistent state of the scene graph.

Not sure if framework or osu! level, but stuff doesn't resize correctly post-maximise.

I have tried to input text in Arabic, Syraic and Hebrew. None of the text actually renders. English and Latin letters are fine.

When trying to draw to any value casted to a string using ToString(), TextAwesome triggers the assert found in TextrureGLSub.cs

The error message:

Parameter '...' hides field '...' - we use this pattern a lot: public ...(Foobar foobar) { this.foobar = foobar }

Delegate subtraction has unpredictable result - I mean how else are you supposed to do it

Use collection initializer - before: https://sr.ht/AqF8.txt after: https://sr.ht/pw7R.txt (breaks the test, too)

Redundant case label

            switch (type)
            {
                default:
                case PerformanceCollectionType.Update:
                    return Color4.YellowGreen;
                case PerformanceCollectionType.Draw:
                    return Color4.BlueViolet;

Non-readonly field referenced in GetHashCode() in RectangleF merits some discussion. Fixing it involves changing a lot about how RectangleF works and causes breaking changes all over the codebase, but the linter rule is there for a good reason.

Lots of "Virtual member call in constructor" warnings also merit discussion, since I'm not really sure what the best approach is to solving them.

Every time we need to change a global shader property, a batch much be split up.

Right now we are incurring insane performance overheads from zero batching. This needs to be addressed as a priority, in my opinion.

with batching: 1480fps
without batching: 98fps

Avoid our custom form stack.

Things to note:

• We need to make sure we can still make angle work.
• We need to make sure we can get exclusive full-screen (GLControl likely needs to be derived from Form).
• Switch to OpenTK based input handlers and remove the form counterparts (these are already implemented but not used).
• Figure a way to handle input for things like TextBoxes.
• Figure out what we can do about IME.

Warnings

• Using obsolete methods in OpenTK.
• Hiding methods in base class not using keyword new or override.
• Redundant generic for nested types.
• A disposable should dispose its disposable members.
• Safer P/Invokes.

Refactoring

• As some of the code uses C# 6 feature, it won't break compatibility to move all the code to C# 6, for example:
  • The properties of osu.Framework.RuntimeInfo are init only, so we can remove their setters now.

In Drawable class you can find:
public Container Parent { get; set; }
internal void ChangeParent(Container parent){...}

It means that Drawable class knows about Container and depends on it. From my point of view, it is not ok.
It can't be fixed just by replacing "Container" => "Drawable" in Drawable.cs, so I decided to open this issue.

Initial draft spec of OML. It's changed a little bit since the last iteration in the transitional repository so you'd best go over this again and point out any inconsistencies/points of clarification or just general comments. Topic for the next pair programming session.

OML - osu! markup language

What is OML

OML is a markup language very similar to QML, oriented towards designing layouts for games that are built upon the osu!framework. The language is YAML-Validated and generates appropriate C# code upon compilation.

Basic syntax

The following is an object that represents a 100x100 red rectangle:

Rectangle:
  Width: 100
  Height: 100
  Colour: Color.Red

Width, Height and Colour are general properties of the Rectangle. These are applied when the object is constructed.

Special Properties

Objects have special properties:
Extends
States
Transitions
Events
Properties
Children

The Extends Property

Objects extend Drawable by default and inherit all of Drawable's properties. It is possible to change this behaviour where this is not intended by specifying the Extends property of the object:

Rectangle:
  Extends: Box  # Rectangle will now inherit all of Box's properties

The States Property

A state defines how an object looks at a point in time by modifying the value of the general properties of the object. This special property may be used to define named states which may be referred to by multiple places in further code.
The property named "Default" is optional but will be applied when the object is first constructed.

Rectangle:
  States:
    - Name: Hovered
      Colour: Color.Red
    - Name: Default       # Optional state to be applied when the object is first constructed
      Colour: Color.Blue

The Transitions Property

A transition defines how an object should transition towards a state. This special property may be used to define named transitions which may be referred to by multiple places in further code. These can be used to transition to either named or anonymous states.

Rectangle:
  States:
    - Name: Hovered
      Colour: Color.Red
  Transitions:
    - Name: HoveredTransition
      State: Hovered           # Named state
      Duration: 500
    - Name: ScaleTransition
      State:                   # Anonymous state
        Scale: 1.5

The Events Property

An event defines the transitions that should be applied to an object when the event is called. Events are exposed in the generated C# code. These can be used to apply either named or anonymous transitions.

Rectangle:
  States:
    - Name: Hovered
      Colour: Color.Red
  Transitions:
    - Name: HoveredTransition
      State: Hovered
      Duration: 500
    - Name: ScaleTransition
      State:
        Scale: 1.5
  Events:
    - Name: OnHover
      Transitions:
        - HoveredTransition        # Named transition
        - ScaleTransition          # Named transition
    - Name: MyTransition
      Transitions:
        -                          # Anonymous transition
          State:
            Alpha: 0.5
          Duration: 100
          Easing: EasingTypes.Out
        -                          # Anonymous transition
          State:
            Rotation: 90
          Duration: 100

Todo: Reserved events

The Properties Property

An object may define properties as private members for it to use.

Rectangle:
  Properties:
    - Name: FocusColour
      Type: Color
      Value: Color.Blue    # Default value is optional
    - Name: NormalColour
      Type: Color
      Value: Color.White
  States:
    - Name: Focused
      Colour: FocusColour
    - Name: Default
      Colour: NormalColour

The Children Property

An object may be composited by several children that are directly affected by the containing object. In this way it is possible to transition an object and all of its children together by applying the transition to the containing object.
Children may be either named - allowing them to be referenced as private members from generated code, or anonymous.

Rectangle:
  Width: 100
  Height: 100

  Children:
    - Type: Box                         # Specifies the type of the child
      SizeMode: InheritMode.XY          # Setting the child's property
      Colour: Color.Gray
      Depth: -1
    - Type: FlowContainer
      Direction: FlowDirection.Vertical
      Children:                          # Can define subchildren for children
        - Type: SpriteText
          Text: Hello World!
        - Type: SpriteText
          Name: SubText                  # This child can be referenced to by `SubText` in code

On Linux, running:
mono --debug SampleGame.exe 2> error.txt
, and pressing the Windows Key while SampleGame is focused, occasionally causes SampleGame to crash.

error.txt: http://pastebin.com/27te7BL8

The first few lines of error.txt:

at <0xffffffff>
at (wrapper managed-to-native) System.Windows.Forms.X11Keyboard.Xutf8LookupString (intptr,System.Windows.Forms.XEvent&,byte[],int,intptr&,System.Windows.Forms.XLookupStatus&) <IL 0x0001a, 0x000a4>
at System.Windows.Forms.X11Keyboard.LookupString

seem to suggest that this is an error with mono, as does this similar issue mentioned here:
https://sourceforge.net/p/keepass/bugs/1545/#1618

Need a way to do something like this:

    Texture : ILoadable
    AudioTrack : ILoadable

    ...

    class OsuLogo
    {
        override Load() {
            Texture t1, t2, t3;
            AudioTrack sfx1;
            Game.Async.Load(delegate
            {
                t1 = Game.Textures.Load(@"Menu/osu");
                t2 = Game.Textures.Load(@"Menu/osuRipple");
                t3 = Game.Textures.Load(@"Menu/osuOverlay");
                sfx = Game.Audio.Track.Load(@"Menu/heartbeat");
            }, delegate {
                //On load completion...
                OsuLogo.Texture = t1;
                OsuLogoRipple.Texture = t2;
                OsuLogoOverlay.Texture = t3;

                startBeat(sfx1);
                FadeIn(500);
            });
        }
    }

Open to feedback on the semantics in this sample.

This is best explained by an example scenario.

Drawable drawable;
Container container = new Container { Children = new[] { drawable = new Drawable(); } };
container.Invalidate(Invalidation.All);
DoStuff(drawable.ScreenSpaceDrawQuad);
container.Invalidate(Invalidation.Colour);

Now future invalidations of container will never propagate to drawable because everything within container is already invalidated, even though drawable.ScreenSpaceDrawQuad is still valid.

I fixed this particular scenario in fd135a3 by making Invalidation.Color invalidate both DrawInfo and ScreenSpaceDrawQuad but the fix is specific and does not address this class of problem in general.

• Fixes ppy/osu#7273.

We need to add padding around textures we put into atlases to avoid bleeding of nearby textures during interpolation.
This padding needs to double in size for every level of mipmapping we want to support.

Currently, there are ChildPosition, ChildOffset, etc. member variables in Drawable which are only used by PaddingContainer. It may make more sense to implement PaddingContainer without relying on such specialized member variables of the Drawable class. (Such as by nesting Containers.)

On Linux the window never closes and on Windows the window takes a rather long time to close.

Leaving this here so that it does not get forgotten.
See #64

To reproduce: Enter the checkbox test, toggle the "Resizing height test" checkbox twice.

Expected result (with StaticCached.AlwaysStale = true;):

Actual result:

Right now, we are generating texture atlases on-the-fly. While this works great in some cases (unicode fonts, for example, where we don't want to instantly load 2048x2048x18 pixels into video memory), we will likely want pre-processed atlases in the near future.

We are already using the BMFont format for fonts, but will likely want a slight variant of this format for arbitrary texture resources. These would likely be referred to by a string identifier rather than integer id.

Things to be done:

• GlyphStore should be subclassed so we can support loading non-font atlases.
• TextureAtlas needs more functionality so we can pre-populate it with data rather than adding textures one-by-one. May require moving current implementation to a subclass.
• A new store (providing Textures) should be made which handles the loading of the full sprite-sheet texture(s) into GL memory and keeps one or more TextureAtlas local to itself.

So for fonts, we will (or rather, already) have:

TextureStore store = new TextureStore(new GlyphStore(Game.Resources, Font));

Texture = store.Get(@"F");
//TextureStore will request the texture from GlyphStore as it hasn't already been cached to the TextureStore atlas.


Texture = store.Get(@"F");
//TextureStore will return the already cached (and dynamically atlased texture).

For arbitrary textures, we need something like this:

AtlasTextureStore store = new AtlasTextureStore(Game.Resources.Get(@"Textures/main"));
//will load Textures/main.layout Textures/main_0.png ... Textures/main_n.png into many TextureAtlases (and thus GL memory) at load time.

Texture = store.Get(@"menu-osu");
//return Texture with TextureGlSub from the assigned atlas.

Open for feedback or implementations.

Interested in hearing people's opinions on what level of documentation we should use when developing this framework. Full XMLDoc? Public methods/properties/classes only? Unnecessary altogether?