Game Development Stack Exchange is a question and answer site for professional and independent game developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I know there is Unity, and XNA that both use C#, but I am don't know what else I could use.

The reason I say C# is that the syntax and style is similar to AS3, which I am familiar with, and I want to choose the correct framework to start learning with.

What should I use to be able to do the most possible bit-blit(direct pixel copy) objects per frame.

EDIT: I should not need to add this, but I am looking for the most possible amount of objects per frame because I am making a few Bullet-Hell SHMUPS. I need thousands and thousands of bullets, particles, and hundreds of enemies on the screen at once. I am looking for a solution to do as many bit-blit operations per frame, I am not looking for a general purpose engine.

EDIT2: I want bit-blitting because I do not want to exclude people who have lower end video cards but a fast processor from playing my games.

share|improve this question

closed as off-topic by Byte56 May 1 '14 at 14:25

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions about "how to get started," "what to learn next," or "which technology to use" are discussion-oriented questions which involve answers that are either based on opinion, or which are all equally valid. Those kinds of questions are outside the scope of this site. Visit our help center for more information." – Byte56
If this question can be reworded to fit the rules in the help center, please edit the question.

You can also use SlimDX in C#, which is (AFAIK) a managed language wrapper around DirectX. – The Communist Duck Dec 7 '10 at 20:36
XNA (on the PC) should be more than sufficient for most if not all needs. – Nate Dec 7 '10 at 20:59
If you really care about performance, you should be using hardware acceleration and not blitting in the first place. – user744 Dec 7 '10 at 21:20
@Joe Wreschnig, I do not want to exclude people who have low end graphics cards from playing my game. – AttackingHobo Dec 7 '10 at 21:27
General purpose computer graphics cards so low-end they don't even support OpenGL 1.2 are going to be attached to CPUs and buses so slow you can't blit over them. They also won't be able to run C#. – user744 Dec 7 '10 at 21:29
up vote 9 down vote accepted

Quake 2 is recognized as one of the first games to really ask gamers for hardware accelerated video cards. It came out in 1997. A processor from that time would be a Pentium 2, 233-300 MHz or so. If you're targeting video cards that old, you're targeting CPUs at least that old. I'm not even sure anyone bothered to make an AGP card that doesn't support OpenGL 1.

No one has fast CPUs and "slow", in the sense you mean, GPUs. Generally speaking, since 1997, you can rely on people to have fast enough GPUs to run nearly anything 2D, especially if you state-sort cleverly. You cannot rely on them to have a fast clock or enough cache or shallow pipelines, which are what make CPUs fast enough to support languages like C# today. You're more likely to find an early NetBurst chipset with a useless amount of cache and only 512MB RAM than an unaccelerated GPU in the wild.

Some modern GPUs are slow, relatively, like the integrated Intel chipsets. Some are feature poor, like the integrated Intel chipsets. Those still have an OpenGL 1 fixed function pipeline, and it's still orders of magnitude faster than building up a scene pixel by pixel on the CPU in RAM in C.

Trying to blit with a managed language, on modern computers, is insanity.

share|improve this answer
Many laptops and desktops have midrange cards that are absolutely horrible for video accelerated games, but they generally have dual to quad core CPUs that are definitely not slow. I want to create something that is fast and will run on all modern systems, not just modern systems with high end video cards. – AttackingHobo Dec 7 '10 at 21:49
Low- and mid-range cards today are still more adept at hardware accelerated 2D via OpenGL than blitting. Maybe you had a bad experience with a bad engine, or maybe you tried something that made heavy use of vertex shaders with a software fallback, or I don't know. But the cheapest netbooks you can buy today have no problem pumping thousands of sprites at 60FPS with fixed-function hardware acceleration. – user744 Dec 7 '10 at 21:52
"Those still have an OpenGL 1 fixed function pipeline, and it's still orders of magnitude faster than building up a scene pixel by pixel on the CPU in RAM in C." Any kind of game that uses the GPU acceleration on my laptop runs really slow, even games with just 2d graphics if there are a lot of sprites, while in AS3 I have a stress test with a ship shooting bullet sprites at 1,800 sprites per second running at just under 60FPS – AttackingHobo Dec 7 '10 at 21:55
I suggested a common reason that might be happening. It's not an inherent property of the card. I don't know what else to tell you. – user744 Dec 7 '10 at 22:04

This is just my opinion, but performance-wise, it shouldn't matter. Pick the framework most comfortable to you. It will save you a lot of pain in the long run. Not only that, but any decent framework should be performant enough for your needs. If you try one framework and it can't reach 60 fps, then either your code is terrible, or the framework is. If it's you (more likely) then no framework will fix it for you. If it's the framework, then it's junk and shouldn't have been on your list anyway.

If you actually are in a situation where performance is critical, for example you are doing far more operations than normal, then you probably shouldn't be looking at C# as a language anyway (unless you've already mastered the garbage collector.)

share|improve this answer
-1. I asked about performance explicitly, and you say it doesn't matter.... I shouldn't have to explain what I am doing, I should have to just say that I definitely need the performance, but I posted more information anyways. And yes I am already pretty good at not causing the garbage collector to run in as3, so I think some of the coding styles can carry over. – AttackingHobo Dec 7 '10 at 20:52
@AttackingHobo Well, with that information I won't argue with your need, but in general you should have to explain. No offense, but should everyone take your word for it that you know what you're doing and need the performance? Plenty of people ask "how do I do X" when really what they want is "how do I solve this problem", and the resulting comments ask for explanation so they don't mistakenly head down the wrong path. – Tesserex Dec 7 '10 at 21:21
You should have to explain when you say you need the fastest version of a low-level software rendering technique but want it in a high-level language with plenty of hardware acceleration support. – user744 Dec 7 '10 at 21:21

I'm quite sure that this is not framework problem and you can choose any of them. But what matter is hw accelaration. And there is no reason for ignoring it. Even the cheapest gpu has built in support for blending. Cpu solution will be very slow and cannot be compared with gpu (even the slowest one)

share|improve this answer
Oh there appeared similar answer while i was writing – Notabene Dec 7 '10 at 22:08
If you guys keep saying this, please find me a sample application with a lot of sprites that are HW accelerated, and I will compare it to my flash engine I that have been working on. – AttackingHobo Dec 7 '10 at 22:13
The demo in can draw (and animate) 6000+ sprites at 60fps for me, on an Intel GMA X3100, which is a four year old low-end integrated laptop card. It maxes out the CPU long before the GPU, and can get 10000+ at 60fps with fewer animations. – user744 Dec 7 '10 at 22:22
I cannot get the installer to run, I installed python 2.7 but its saying it cannot find 2.6, is there a stand-alone version I can test without figuring out how to get this stuff to run? – AttackingHobo Dec 7 '10 at 22:55

SDL is a popular software renderer, and has a C#/.NET binding: But like Joe and others have said, worrying about super fast rendering is silly if you want to use C#/Mono/.NET. You'll already get a lot of performance out of using something other than Flash.

On my modest laptop I loaded up 25,000 animating sprites and still ran at 60fps. Add in background rendering, game logic and physics, and input, and maybe it could only handle 15,000. The trick to getting XNA to run fast is discouraging the garbage collector from running. Avoid heap allocations in your update loop(use structs), don't release references until the main gameplay sequence has a break, and watch your iterators.

If you want to be really fast, go use C++ with SFML. But again, make sure you're actually going to have issues with performance.

share|improve this answer
-1 because you don't talk about the difference between software and hardware rendering. C# is faster than Flash at normal execution, but Flash does have one of the fastest software renderers. If you naively port a program from Flash to another language and keep software rendering it's probably going to be slower. It's also just totally not relevant on today's (or yesterday's) computers. – user744 Dec 8 '10 at 10:04

Why do you want bit-blit in C# XNA?

Your problem seems to be to render a lot of objects on screen. XNA is more than capable to handle this, but you don't need to go low-level for this.

You might wanna take a look how the SpriteBatch class renders Texture2D. SpriteBatch doesn't immediately send draw request to the graphics card, but puts them into a list. If the next draw call is for a different Texture2D or SpriteBatch.End() is called all draw requests from the list are sent at once to the graphics card and the image is only copied once to the graphics card memory but rendered for each request in the list.

So you can either put all images your game needs into one big image and tell the sprite batch which parts of it it needs to render or sort your sprites to draw after drawing depth and texture.

That way you can draw a few thousands images without any performance problems.

A complete explanation with sample code:

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.