Hi I am TizzyT and I am trying my hand at making my first game. I don't know any graphics programming so I kind of cheated using WPF . The reason I used WPF is because I needed more memory than XNA could provide (being 32 bits, correct me if I'm wrong). I have gotten most issues sorted to the best of my ability (framerate, scaling, etc) but while I was addressing those issues I was only using single images or at most a single small/short animation for testing. My game will eventually be a fighting game at first (though the idea is to reuse most of this for future game projects). I went online to find some example fighting game sprites etc. I found skull girls sprite rips which I used for testing. After I got done with most of the issues it hit me. How would it handle the large number of images like skull girls. I rounded the number of images each character had upwards (so its ~1500) and then multiplied by 2 (for 2 players). So I proceeded to create a folder with 3000 images. I loaded them all up and it used about ~3GB if I remember correctly (Did test a while ago and have been trying to address it since). The next bit was to draw them to the screen (all 3000, one per frame). I noticed that there is some jerkiness to it. I went ahead and unloaded the 3000 except for the 13. Ran some tests and I concluded that the 13 image animation wasn't jerky because after the images are drawn once they are placed in video memory and so next time it doesn't have to fetch it from system memory. I then realized loading that much into video memory would be disasterous but I tried so anyways. Loaded the 3000 back up and still Jerky, even more so this time around I think. I believe this is due to the images being moved around to make room for the image trying to be drawn. Does anyone have any ideas as to how skull girls is able to do what they do considering their large number of sprites? or some alternate solutions?
Thanks.

Well, you're never going to get great perf from WPF, but that said, have you thought about using an atlas or sprite sheet instead?

How would it handle the large number of images like skull girls. I rounded the number of images each character had upwards (so its ~1500) and then multiplied by 2 (for 2 players). So I proceeded to create a folder with 3000 images. I loaded them all up and it used about ~3GB if I remember correctly

In professional games there is much more to having "images" than this.

There are many types of images used in games. They can be in different places in memory like living in main memory (rather slow) or living directly on the video card (extremely fast). There are different ways to draw them.

The type of images that tend to work well for the Internet -- formats like jpeg and png -- are pretty terrible for games. They are tightly compressed for transmission across the wire, but they must be decompressed which takes time and computing power and memory.

There are other formats of images, with format names like "dds" and "dxt5" and "pvrtc", that are excellent for games. They have a little less compression so the files are bigger, but they are designed to be loaded directly to the graphics card. Since these live directly on the video card they don't really consume your program's main memory address space when done well, only needing a few bytes per image so you know where they are at.

The next bit was to draw them to the screen (all 3000, one per frame). I noticed that there is some jerkiness to it.

Moving data around and making calls out to the graphics cards are both slow operations. Games do all kinds of amazing things in order to reduce those calls.

For comparison, somebody recently wrote up how GTA V graphics system generated a rather complex scene. They prepare a 3D reflection of the entire environment with about 30 calls. They draw the entire cityscape, mountains and trees and shrubs and vehicles and characters in under 2000 calls. Shadowing and fancy lighting takes another 1000 calls. Reflections, blurs, subsurface scattering on skin and other surfaces, fog, and clouds all get added. Map overlays get added.

You spent 3000 draw calls to draw your spites, for comparison, the blockbuster game GTA 5 used about 4000 draw calls to build this scene:

Does anyone have any ideas as to how skull girls is able to do what they do considering their large number of sprites? or some alternate solutions?

Graphics developers in games read a lot of highly technical research papers, read conference reports, read instructional sites, read papers produced by the hardware vendors, and then use every trick they can find to produce the amazing images you see.

You can use WPF and build your game that way, it will get a game built.

Just be aware that in order to get high performance out of a game engine's graphics you will need to invest far more effort than just drawing sprites one at a time.

Oh, also moving to For Beginners, I don't think this really fits in the current area.

Performance wise (disregarding the issue with the vast number of images loaded as a large/long animation) using only the 13 frames for animation, It is well within my needs. And have tested up to and beyond my expected draw count per frame (~400, though I have tested up to several thousand without issue or significant latency). So WPF while I know it is not as performant as other solutions it should be sufficient enough. The jerkiness happens when I get to a point where I am trying to draw an image that is not yet loaded into vram (i think). and so there is a jerkiness to it. In XNA I have tried using Texture2D but I can see that that too is kept on main system memory until needed. From my understanding (of your post), the problem is less about the moving of data and more about decompression of the images. If that is the case I should look into implementing DXT of sorts? I have had the idea of a sprite sheet but the images are so large that when I placed them in a sprite sheet it created an image that was ~21K in width. And when I tried to load such an image it didn't even appear on screen (not because it didn't fit but because I think it just refused to draw due to some limitation/restrictions/etc). So far the alternatives that I am trying to avoid is lowering the resolution of the sprites a great deal and lowering the potential image count for each character. I originally wanted the sprites to be high quality but seeing as memory would be an issue I already plan on resizing them. Going back to DXT, I have looked into DXT for WPF before and while I don't remember if I found a solution or not I believe I concluded that there wasn't a good way to do it in WPF (correct me if im wrong), But I will have another look around. The game is going to be a 2D game so nothing as complex as GTA V will be a goal lol but good info.

Thanks @ferrous and @frob