[c#] Afbeeldingen over elkaar heen weergeven.

[Onbekend]

Ik ben bezig om een spelletje te maken. Dit is bijna af, alleen grafisch neemt het nogal veel processortijd in beslag. Ik wil dit grafische gedeelte per sé door de cpu af laten handelen en niet door de gpu.

Nu heb ik om te testen een vergelijkbare situatie in c# (windows) gemaakt zodat ik gemakkelijk het e.e.a kan aanpassen en finetunen. Op dit moment test ik met een resolutie van 500x500 pixels, maar met deze resolutie is 1 core van 2,5GHz al aan het rekenen waarmee ik nét aan 1fps haal.
Mijn doelstelling is om minimaal 10fps te halen.

Grafisch is het spel te vergelijken met een platform spel zoals Mario Bros, en gebruik daarvoor 3 afbeeldingen.
1. De afbeelding van de achtergrond.
2. Het spel zelf met daarop speler en items in het spel.
3. De voorgrond wat dus over afbeelding 2 en 1 wordt weergegeven.

Als optimalisatie gebruik ik al geen bitmaps, maar een eigen class die ik "CustomImage" heb genoemd. De afbeelding is dan gewoon opgeslagen in een byte-array waarmee ik dus sneller toegang heb dan een normale bitmap. De single byte-array heeft gewoon voor elke pixel 4 bytes (B, G ,R ,A), en is dus voor mijn afbeeldingen maar 500x500x4 = 1MB groot.

Alle afbeeldingen die ik in het spel nodig heb, laadt ik vooraf in in deze CustomImage.
Tijdens het spel verbouw ik de 3 afbeeldingen (ook van het type CustomImage) en houd ik bij binnen welke rechthoeken ik de afbeelding heb aangepast.
Nadat dit is verwerkt ga ik elke gewijzigde rechthoek af en update deze in een eindafbeelding (ook van het type CustomImage).
Aangezien ik transparantie gebruik, moet ik dus steeds laag voor laag de afbeelding opbouwen, en vergelijk ik dus of de kleuren transparant zijn.


Alhoewel ik dit al flink heb geoptimaliseerd, blijft het vergelijken en pixels kopiëren het langzaamste gedeelte van mijn code.

Zit ik met deze oplossing wel in de goede hoek, of is deze methode totaal verkeerd om afbeeldingen over elkaar heen te laten weergeven?

[Caelorum]

Onbekend schreef op maandag 25 augustus 2014 @ 20:24:
[...] Aangezien ik transparantie gebruik, moet ik dus steeds laag voor laag de afbeelding opbouwen, en vergelijk ik dus of de kleuren transparant zijn.[...]

Afgezien van de gebruikte methodiek, waarom vergelijken? Gewoon simpel additief samenvoegen en die vergelijking achterwege laten. Dat zou al een bult moeten schelen toch?

[RobIII]

Onbekend schreef op maandag 25 augustus 2014 @ 20:24:
Zit ik met deze oplossing wel in de goede hoek, of is deze methode totaal verkeerd om afbeeldingen over elkaar heen te laten weergeven?

Behalve dat ik me afvraag waarom je dit "per sé door de cpu af" wil "laten handelen" en niet gewoon XNA (deprecated/obsolete, maar toch...), DirectX, SDL of een dergelijk framework of ander alternatief gebruikt: je kunt ook directe toegang tot de byte array krijgen op een bitmap met de LockBits() method. Verder vraag ik me af of je double buffering gebruikt, hoe je precies je canvas/world tekent en hoe efficiënt je bewerkingen/algoritmes zijn als je maar 1fps haalt. Maar daar valt weinig zinnigs over te zeggen want daar vertel je niet veel over.

[R4gnax]

Onbekend schreef op maandag 25 augustus 2014 @ 20:24:
Alhoewel ik dit al flink heb geoptimaliseerd, blijft het vergelijken en pixels kopiëren het langzaamste gedeelte van mijn code.

Tja, dat vergelijken en kopiëren blijft langzaam heh? Eigenlijk zou je dat parallel willen kunnen doen en dan flink opschalen. Dat zou heel wat schelen. Als je dan ook nog eens hardware hebt die speciaal op dat type berekeningen ingericht is, dan zou het helemaal snel gaan en dan tik je die 60 FPS echt wel aan...

[Onbekend]

Caelorum schreef op maandag 25 augustus 2014 @ 20:31:
[...]

Afgezien van de gebruikte methodiek, waarom vergelijken? Gewoon simpel additief samenvoegen en die vergelijking achterwege laten. Dat zou al een bult moeten schelen toch?

Hiermee ga je toch ook elke pixel langs of mis ik iets? En dit vermenigvuldigen lijkt langer te duren dan vergelijken of iets transparant is of niet.

RobIII schreef op maandag 25 augustus 2014 @ 20:36:
Behalve dat ik me afvraag waarom je dit "per sé door de cpu af" wil "laten handelen" en niet gewoon XNA (deprecated/obsolete, maar toch...), DirectX, SDL of een dergelijk framework of ander alternatief gebruikt: je kunt ook directe toegang tot de byte array krijgen op een bitmap met de LockBits() method.

LockBits gebruik ik inderdaad bij het inlezen van de bron-afbeelding. Maar de GetPixel en SetPixel duren dan nog steeds lang, vandaar dat ik een eigen array gebruik die ik zelf beheer.

Verder vraag ik me af of je double buffering gebruikt, hoe je precies je canvas/world tekent en hoe efficiënt je bewerkingen/algoritmes zijn als je maar 1fps haalt. Maar daar valt weinig zinnigs over te zeggen want daar vertel je niet veel over.

Ik zie dat het tekenen naar canvas vrij snel gaat, in ieder geval in verhouding tot de voorbewerking. Dus ik vond het niet relevant om verder over het canvas te hebben. Double buffering wil ik later gaan toepassen (threads e.d.), maar eerst wil ik die afbeeldingbewerking sneller hebben.

[Gleighton]

Heb je al gebenchmarked / profiled waar echt de cost in zit? Ik heb wel eens vergelijkbare dingen gedaan met afbeeldingen, maar liet het samenvoegen van de afbeeldingen door OpenGL. Daarbij had ik het vermoeden dat het samenvoegen van de afbeelding redelijk duur was, maar uiteindelijk bleek dat het genereren van de overlay een stuk duurder was. Het is heel makkelijk om iets te vermoeden, maar als je het nog niet gemeten hebt blijft het maar een vermoeden ;-)

[Caelorum]

Onbekend schreef op maandag 25 augustus 2014 @ 21:15:
[...]
Hiermee ga je toch ook elke pixel langs of mis ik iets? En dit vermenigvuldigen lijkt langer te duren dan vergelijken of iets transparant is of niet.[...]

Elke pixel zal je toch eens af moeten lopen, welke manier je ook gebruikt. Zelfs als je een software rasterizer (zoals deze tutorial in C# <- best cool btw.) maakt heb je op een gegeven moment een stap in het proces waarbij je alle pixels af moet lopen (als ik het me goed herinner. *edit* ok je raakt in ieder geval elke pixel, maar je hoeft het natuurlijk niet 1 voor 1 in serie af te lopen...). Overigens had ik het over simpel optellen, niet over vermenigvuldigen, maar ik vraag me ook af of dit soort zaken belangrijk zijn in C#. Een extra check zal te verwaarlozen zijn als je telkens over de grens van de VM heen gaat.

Oh, en nog even een algemene tip. Je wilt kijken naar frame time en niet fps als je optimalisaties gaat doorvoeren of wilt weten hoe groot de impact van een bepaalde wijziging is. Dit in verband met de non-lineariteit van fps. Zie ook bijv:

quote: http://infocenter.arm.com...oc.dui0555b/BEIGDEGC.html

For example, going from 100 FPS to 200 FPS involves a difference of 100 FPS or 5ms. However going from 20 FPS to 22.2 FPS is a difference of 2.2 FPS but this is also 5ms. The linear nature of frame time is easier to work with when you are measuring the impact of optimizations.
Table 3.1. Difference between frames per second and frame time

FPS change	FPS difference	Frame time difference
20 to 22.2	2.2	5ms
50 to 66.6	16.6	5ms
100 to 200	100	5ms

[ Voor 46% gewijzigd door Caelorum op 25-08-2014 22:26 ]

[epic007]

Ik neem aan dat je de fps berekent in Release mode en dat je je project start via "Start Without Debugging (Ctrl+F5)" ? Dit kan nogal wat schelen.

Ik weet niet of je nu al unsafe functies hebt gemaakt waar je a la c++ door je byte pointers heen loopt, maar dit zou je performance kunnen vergroten.

http://www.codeproject.co...mmies-with-C-and-GDI-Part