Monogame XNA niska liczba klatek na sekundę z kilku wywołań funkcji Draw()

Question

Przesyłałem przewijaną grę strzelanki, którą zrobiłem w XNA, do Linuksa, używając MonoGame. Prawie wszystko poszło gładko, ale mam problem w określonym miejscu z wywołaniami do SpriteBatch.Draw() paraliżującego framerate. Większość gier działa dobrze bez żadnych problemów. Przyciąga dużą liczbę wrogów i dużą liczbę pocisków naraz bez spowolnienia. Częścią, która powoduje upuszczenie klatek, jest jednak przewijane warstwowo tło. Odpowiednie sekcje kodu znajdują się tutaj.

Level.cs:

public void Draw(SpriteBatch spriteBatch) 
{ 
    foreach (ScrollingBackgroundLayer sbl in scrollingBackground) 
    { 
     sbl.Draw(spriteBatch); 
    } 
} 

W "scrollingBackground" Powyżej znajduje się lista ScrollingBackgroundLayers, odpowiednie sekcje, które są:

ScrollingBackgroundLayers.cs:

Vector2[] scrollingBackgroundImages; 
public float DrawLayer; 

public ScrollingBackgroundLayer(GameScene newScene, Texture2D texture, float scrollSpeed, Color color) 
{ 
    layerColor = color; 
    layerSpeed = scrollSpeed; 
    layerTexture = texture; 
    thisScene = newScene; 

    Initialize(); 
} 

public void Initialize() 
{ 
    scrollingBackgroundImages = new Vector2[2]; 

    for (int i = 0; i < 2; i++) 
    { 
     scrollingBackgroundImages[i] = new Vector2(0, thisScene.ScreenArea.Height - (layerTexture.Height * i)); 
    } 
} 


public void Update(GameTime gameTime) 
{ 
    for (int i = 0; i < scrollingBackgroundImages.Length; i++) 
    { 
     scrollingBackgroundImages[i].Y += (float)gameTime.ElapsedGameTime.TotalSeconds * layerSpeed; 

     if (layerSpeed > 0 && scrollingBackgroundImages[i].Y >= thisScene.ScreenArea.Height) 
     { 
      scrollingBackgroundImages[i] = new Vector2(scrollingBackgroundImages[i].X, (scrollingBackgroundImages[i].Y - layerTexture.Height * 2)); 
     } 
     else if (layerSpeed < 0 && scrollingBackgroundImages[i].Y + layerTexture.Height <= 0) 
     { 
      scrollingBackgroundImages[i] = new Vector2(scrollingBackgroundImages[i].X, (scrollingBackgroundImages[i].Y + layerTexture.Height * 2)); 
     } 
    } 
} 

public void Draw(SpriteBatch spriteBatch) 
{ 
    foreach (Vector2 sb in scrollingBackgroundImages) 
    { 
     spriteBatch.Draw(layerTexture, sb, null, layerColor, 0f, Vector2.Zero, 1f, SpriteEffects.None, DrawLayer); 
    } 
} 

Wszystkie z problemy z framerate znikną, gdy tylko skomentuję wywołanie ScrollingBackgroundLayer.Draw(), więc wydaje się to być dość dużą wskazówką, że problem pochodzi z S priteBatch próbuje narysować przewijane warstwy. Oczywiście, chcę dowiedzieć się, dlaczego tak się dzieje. Przejrzałem kilka innych problemów z SpriteBatches, a najczęstszą rzeczą, jaką znalazłem, która mogłaby wskazywać na odpowiedź, jest fakt, że nowa opcja SpriteBatch jest tworzona za każdym razem, gdy zmienia się teksturę, ale nawet ustawienie SpriteSortMode na Texture nie dało żadnych ulepszeń.

Zmniejszenie liczby klatek na sekundę występuje na scenie gry, która ma 7 różnych arkuszy ScollingBackground, z których każda rysuje oddzielną teksturę o szerokości około 700 pikseli i wysokości 900 (każda warstwa powinna to zrobić nie więcej niż 2 razy, aby uwzględnić efekt przewijania). Czuję, że muszę przegapić coś oczywistego, ponieważ gra czasami renderuje aż 2-300 pocisków przy użyciu tego samego przeciążenia, więc kolejne 14 wywołań powinno być kroplą w wiadrze. Czy jest to po prostu problem z próbami narysowania zbyt dużych tekstur, aby SpriteBatch mógł skutecznie działać? To nie jest problem w wersji dla systemu Windows, więc zastanawiam się, czy nie ma jakiegoś rozwiązania tego typu związanego z platformą, lub czy implementacja Draw w MonoGame jest po prostu nieefektywna. Wszelkie opinie będą mile widziane.

Pełna źródło dla zainteresowanych:

Linux - https://github.com/cmark89/AsteroidRebuttal-Linux
Windows - https://github.com/cmark89/AsteroidRebuttal

Edit: Próbowałem majstrować przy nim nieco więcej. Zmieniłem wywołanie funkcji Draw(), aby upewnić się, że docelowy prostokąt jest równy obszarowi do rysowania na ekranie, ale nie było zauważalnej zmiany. Zamieniłem teksturę na bardzo małą i to wyeliminowało opóźnienie, więc myślę, że ma to coś wspólnego z rozmiarem tekstury.

Edycja 2: W porządku, skończyłem właśnie gryząc pocisk i przecinając warstwy przezroczystości, których używałem (jak jakiś nie-leniwy facet). Rozwiązał problem, prawdopodobnie dlatego, że nie musi już renderować ogromnej liczby bezużytecznych pikseli, ale wciąż zastanawia mnie, dlaczego jest to problem tylko w Linuksie. Chociaż na razie rozwiązałem mój problem, zamierzam zostawić to otwarte na chwilę, na wypadek gdyby ktoś miał wgląd w to, co może powodować drastyczną różnicę w wydajności.

Answer 1

W tej sytuacji proponuję użyć zamiast tego shadera, aby to osiągnąć. W ten sposób zauważysz gwałtowny wzrost wydajności.Spójrz, co następuje:

http://www.david-gouveia.com/scrolling-textures-with-zoom-and-rotation/

Robi to w ten sposób, będzie łagodzić wiele użycie CPU, GPU i dokonać wykonać większość pracy.

Możesz również chcieć przechowywać tekstury w potęgach 2, zamiast 700x900. (zrób coś w stylu 512x512). Rurka graficzna ma zwiększoną wydajność w odniesieniu do tekstur o potędze dwóch.