Monogame XNA niedrige Bildrate von wenigen Draw() -Aufrufen

Question

Ich habe ein Scrolling-Shooter-Spiel portiert, das ich in XNA über Linux mit MonoGame erstellt habe. Fast alles ist reibungslos gelaufen, aber ich habe ein Problem an einem bestimmten Ort mit SpriteBatch.Draw() Aufruf der Framerate. Der Großteil des Spiels läuft gut ohne Schluckauf. Es zieht eine große Anzahl von Gegnern und eine große Anzahl von Kugeln auf einmal ohne jegliche Verlangsamung. Der Teil, der die ausgelassenen Rahmen verursacht, ist jedoch ein mehrschichtiger Bildlaufhintergrund. Die relevanten Abschnitte des Codes sind hier.

Level.cs:

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

Die "scrollingBackground" oben ist eine Liste von ScrollingBackgroundLayers, die entsprechenden Abschnitte davon sind:

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); 
    } 
} 

Alle von Die Framerate-Probleme gehen weg, sobald ich den Aufruf von ScrollingBackgroundLayer.Draw() auskommentiere, so dass dies ein ziemlich großer Hinweis zu sein scheint, dass das Problem von S kommt Der Versuch von priteBatch, die Scroll-Ebenen zu zeichnen. Offensichtlich möchte ich herausfinden, warum das passiert. Ich habe ein paar andere Probleme mit SpriteBatches untersucht und die häufigste Sache, die auf eine Antwort hinweist, ist die Tatsache, dass ein neuer SpriteBatch immer dann erstellt wird, wenn die Textur geändert wird, aber selbst wenn der SpriteSortMode auf Textur gesetzt wurde, gab es keine Verbesserungen.

Die Framerate-Abnahme erfolgt auf einer Bühne des Spiels, die 7 verschiedene ScollingBackgroundLayers hat, von denen jede eine separate Textur zeichnet, die etwa 700 Pixel breit und 900 hoch ist (jeder Layer sollte dies nicht mehr als 2 Mal tun) der Scroll-Effekt). Ich habe das Gefühl, dass ich etwas Offensichtliches vermissen muss, weil das Spiel manchmal bis zu 2-300 Kugeln mit exakt der gleichen Überlast rendert, also sollten weitere 14 Aufrufe ein Tropfen auf den heißen Stein sein. Ist das einfach ein Problem beim Versuch, Texturen zu zeichnen, die zu groß sind, um von SpriteBatch effektiv gehandhabt werden zu können? Das ist kein Problem in der Windows-Version, also frage ich mich, ob es keine plattformspezifische Problemumgehung gibt oder ob MonoGames Implementierung von Draw nur ineffizient ist. Jede Rückmeldung wäre willkommen.

Volle Quelle für Interessenten:

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

Edit: Ich habe versucht, mit ihm ein bisschen mehr bastelt. Ich änderte den Aufruf von Draw(), um sicherzustellen, dass das Zielrechteck dem ausklappbaren Bereich des Bildschirms entsprach, aber es gab keine merkliche Änderung. Ich habe die Textur gegen eine sehr kleine getauscht und das hat die Verzögerung beseitigt, also denke ich, dass es etwas mit der Größe der Textur zu tun hat.

Edit 2: Okay, ich landete nur bei der Kugel und zerschnitt die Transparenzschichten, die ich benutzte (wie eine Art nicht fauler Typ). Es hat das Problem gelöst, vermutlich weil es nicht mehr viele nutzlose Pixel rendern muss, aber ich frage mich immer noch, warum das nur ein Problem unter Linux ist. Auch wenn ich mein Problem vorläufig gelöst habe, werde ich das für eine Weile offen lassen, für den Fall, dass irgendjemand etwas darüber weiß, was den drastischen Leistungsunterschied verursachen könnte.

Answer 1

In dieser Situation würde ich vorschlagen, dass Sie stattdessen einen Shader verwenden, um dies zu erreichen. Sie werden sehen, dass Ihre Leistung dadurch explodiert.Werfen Sie einen Blick auf die folgenden:

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

es auf diese Weise tun, wird eine Menge CPU-Auslastung verringern, und machen Sie Ihre GPU tun den Großteil der Arbeit.

Sie können auch Ihre Texturen in Potenzen von 2 statt 700x900 speichern. (Mach etwas wie 512x512). Ihre Grafikpipeline hat einen Leistungsschub in Bezug auf Texturen mit einer Zweierpotenz.