Pull to refresh

Comments 13

Неплохо пишите :)
Радует, что хна стала аткуальнее
Спасибо)

Да, с развитием Xamarin реинкарнация xna в виде Monogame действительно становится актуальной.
Чувствуется, что Monogame слизан с Flash. При том криво.

А приведенный в статье способ масштабирования меня просто убил. Это же просто растяжение под размеры экрана, которое не учитывает пропорции.
На мой взгляд, лучшим способом масштабирования является использование единого глобального коэффициента, вычисляемого как отношение максимального размера к текущему
Я думаю нет единого лучшего способа маштабирования все зависит от задач, но растягивания/сжатия по двум осям конечно лучше избегать.
А приведенный в статье способ масштабирования меня просто убил. Это же просто растяжение под размеры экрана, которое не учитывает пропорции.

Прошу прощения, но где вы в статье такое увидели?

На мой взгляд, лучшим способом масштабирования является использование единого глобального коэффициента, вычисляемого как отношение максимального размера к текущему

Фактически, как раз указанный вами способ и используется. Определяется единый коэффициент, который, в данном примере, равен отношению ширины экрана к ширине картинке. Затем текстуры масштабируются согласно полученному значению как по Х, так и по Y, сохраняя, тем самым, пропорции.
При этом, если пропорции экрана и пропорции текстур не совпадают, то по бокам экрана остаются черные полосы (либо любой другой заданный цвет).

Чувствуется, что Monogame слизан с Flash. При том криво.

Не совсем понял, в чем, по вашему, это проявляется?
Да, правда ваша — пропорции сохраняются.

Архитектура и подходы Monogame (показанные) аналогичны Flash
В vs 2015 легкими движения руки можно скачать темплейт с репозитория MonoGame…
case по состоянию сцены для меня выглядит странно. Почему был выбран именно этот подход, в чём недостаток работы с абстрактным предком сцены?
Поясните, пожалуйста, что вы подразумеваете под работой с абстрактным предком сцены?
Ну, я так пишу обычно
public abstract class AbstractScene
{
    public abstract void Draw();

    public abstract void Update();
}

public class StringScene : AbstractScene
{
    public StringScene(string text)
    {
        this.Text = text;
    }

    public string Text { get; set; }

    public override void Draw()
    {
        //...
    }

    public override void Update()
    {
        //...
    }
}

public class IntScene : AbstractScene
{
    public IntScene(int number)
    {
        this.Number = number;
    }

    public int Number { get; set; }

    public override void Draw()
    {
        //...
    }

    public override void Update()
    {
        //...
    }
}

//...

public class Game1 : Game
{
    private AbstractScene scene;

    protected override void Initialize()
    {
        this.scene = new StringScene("Ima scene"); // инициализировать логично сценой меню или загрузки.

        base.Initialize();
    }

    protected override void Update(GameTime gameTime)
    {
        this.ReadKey(); // операции ввода и апдейт мира - две независимые операции. Интересно, кстати,
        this.scene.Update(); // почему они не разделены на уровне движка?

        base.Update(gameTime);
    }

    protected override void Draw(GameTime gameTime)
    {
        this.scene.Draw();

        base.Draw(gameTime);
    }

    private void ReadKey()
    {
        if (Keyboard.GetState().IsKeyDown(Keys.S))
        {
            scene = new StringScene("Ima scene");
        }

        if (Keyboard.GetState().IsKeyDown(Keys.I))
        {
            scene = new IntScene(1);
        }
    }
}



Плюс такого подхода в том, что сцена инкапсулирует своё поведение, не давая свои поля на изменение в обход механизмов сцены. В большинстве случаев, такое поведение будет максимально корректным.

Основной минус подхода, предложенного в статье — это то упущение, что ничто — кроме голоса совести — не мешает мне поменять местами в свичах вызовы методов.
Спасибо большое за ответ! Интересный подход, попробую в текущем проекте как раз :)

При написании статьи остановился на рассмотренном способе в виду того, что в небольшом проекте такой подход, на мой взгляд, удобен своей наглядностью.

Основной минус подхода, предложенного в статье — это то упущение, что ничто — кроме голоса совести — не мешает мне поменять местами в свичах вызовы методов.

А с этим полностью согласен.

Вот здесь тоже интересный пример реализации смены сцен с использованием классов.
Sign up to leave a comment.

Articles