Sign in to follow this  

[.net] Blazing fast 2D graphics and disabling .NET in VS C++ 2008 Express

This topic is 3490 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

A couple of question for my first post. First, I want to compile a normal executable on Visual Studio C++ 2008 Express without any .NET element. How do I do this? This way I don't need other computers to have .NET installed (nor need to distribute the files in the VS "dist" folder). Second, using .NET, what is the best way to have fast 2D graphics updated in the UI window? I'm guessing .NET allows this, but any help page where I can see quick code or tutorials etc.? I want to create a slider which as you adjust it, the image preview updates in realtime (say, gets darker or lighter according to the position of the slider). I want it blazing fast and realtime though (50 fps preferred) :) Preferably, I want to create my own code for this, so everything will be done pixel by pixel in the window. Is .NET up for the job? [Edited by - TwinbeeUK on May 27, 2008 2:23:00 PM]

Share this post


Link to post
Share on other sites
Quote:

First, I want to compile a normal executable on Visual Studio 2008 Express without any .NET element. How do I do this?

Don't use C# or VB. Use only C++ (no C++/CLI).

Quote:

Second, using .NET, what is the best way to have fast 2D graphics updated in the UI window? I'm guessing .NET allows this, but any help page where I can see quick code or tutorials etc.? I want to create a slider which as you adjust it, the image preview updates in realtime (say, gets darker or lighter according to the position of the slider). I want it blazing fast and realtime though (50 fps preferred) :) Preferably, I want to create my own code for this, so everything will be done pixel by pixel in the window.

Doing things manually pixel-by-pixel is inherently slow. You can get reasonable framerate out of GDI, but you can get even better out of, say, Direct3D.

Quote:

Is .NET up for the job?

Seeing as requirement #1 is that you don't want to use .NET, then no.

Share this post


Link to post
Share on other sites
Sorry I left "C++" out of "Visual Studio C++ 2008 Express". I already have it installed and am getting to grips with it.

So how do I go about disabling the compilation of .NET style exes?

Quote:
Seeing as requirement #1 is that you don't want to use .NET, then no.


That's only a requirement for some programs I will be creating. I will still be using .NET for others.

GDI eh? Never heard of it before. I've thought about using SDL, but am not sure how well that compares to GDI.

So GDI could work in a pixel by pixel basis? Does it already come with Visual studio c++ express 2008. Is there code I can type out right now to draw a pixel or 2 on a window?

Not sure if you're familiar with the picture viewer Irfanview or other image processsing tools. Would they want to use SDL, GDI, DirectX/3D or "other" for the typical image preview you get in such programs?

Oh and finally, using Direct3D, would I have exact control over the colour of every pixel in the picture? I like speed, but I need flexibility too.

Thanks for helping out here - just need a direction to research into really.

Share this post


Link to post
Share on other sites
Quote:

Sorry I left "C++" out of "Visual Studio C++ 2008 Express". I already have it installed and am getting to grips with it.

So how do I go about disabling the compilation of .NET style exes?

.NET is a CLR implementation. It's only for managed code. Native C++ doesn't use it at all. Just create a C++ (not CLI) project, and you'll be fine.

GDI is the Win32 basic graphics interface -- what all your windows and controls are rendered with. It comes with the Windows SDK, which you should already have. Look on MSDN for documentation.

You can do per-pixel access with it, but it's not efficient. Like I said, per-pixel rendering is slow regardless of which API you employ. That's why as you move towards APIs that take advantage of hardware acceleration, like Direct3D, per-pixel access remains possible (after a fashion), but difficult.

Share this post


Link to post
Share on other sites
Thanks, both of you got me on the right track.

I still received the error "The application has failed to start because the application configuration is incorrect." on the other computer.

It turns out /clr was already off, so that wasn't the problem. Also, the project was a simple printing of hello world to the command prompt, so that was fine too.

However, I started experimenting with the compiler options, and noticed the "Use of MFC" option. If I change it from "Use Standard Windows Libraries" to "Use MFC in a Static Library", it works!! (the resulting exe bloats from 7k to 52k mind).

Now this is where it gets weird. If I change it back to "Use Standard Windows Libraries", it still works (and the exe is still 52k), despite previously the same option resulting in the old 7k (and not working) exe. Is this a bug with Visual Express, or is it appropriate behaviour?

Very briefly, what does MFC have to do with any of this?

Quote:
That's why as you move towards APIs that take advantage of hardware acceleration, like Direct3D, per-pixel access remains possible (after a fashion), but difficult.


But surely you would get wrappers to help make things easy again? In the same way that something like OpenGL is made easier by SDL/GLUT, which itself is made even easier by something like "QuickCG". Can you recommend a Direct3D wrapper which would ultimately allow me to more or less straight away code up "Plot x,y,r,g,b"?

Share this post


Link to post
Share on other sites
Quote:
Original post by TwinbeeUK
Now this is where it gets weird. If I change it back to "Use Standard Windows Libraries", it still works (and the exe is still 52k), despite previously the same option resulting in the old 7k (and not working) exe. Is this a bug with Visual Express, or is it appropriate behaviour?

I'd say it's a 'feature' ;)
If you delete all of the intermediate files used by the compiler (.obj, etc), and recompile, it will probably go back to the old 7k version.

Share this post


Link to post
Share on other sites
Hi

If you want to do manual pixel by pixel operation, you can use DirectX or OpenGL with .Net. "Simply" draw a full screen texture and update/upload texture content every frame.

But as others said, it wouldn't be the best way...

Share this post


Link to post
Share on other sites
Quote:
Original post by TwinbeeUK
Thanks, both of you got me on the right track.

I still received the error "The application has failed to start because the application configuration is incorrect." on the other computer.


That usually means the other computer didn't install the Visual C++ 2008 Runtime.

Escpecially, I think that would be the error message that appears when you try to copy MSVCR90.dll / MSVCP90.dll into the application folder. This no longer works, on Windows XP and above, the Visual C++ runtime has to be installed into the WinSxS folder.

If you don't want your friends to install the Visual C++ runtime, go to Project Settings -> C/C++ -> Code Generation and choose the "Multithreaded [debug]" runtime (debug only for the debug configuration of your project) instead of the DLL runtime.

Quote:
Original post by TwinbeeUKNow this is where it gets weird. If I change it back to "Use Standard Windows Libraries", it still works (and the exe is still 52k), despite previously the same option resulting in the old 7k (and not working) exe. Is this a bug with Visual Express, or is it appropriate behaviour?


It might have switched the option I described above (static MFC might require static runtime since it's a static library -- linking to static libraries compiled against a different runtime == bad)

Share this post


Link to post
Share on other sites
Quote:
That usually means the other computer didn't install the Visual C++ 2008 Runtime.


Yep.

Quote:
Escpecially, I think that would be the error message that appears when you try to copy MSVCR90.dll / MSVCP90.dll into the application folder. This no longer works, on Windows XP and above, the Visual C++ runtime has to be installed into the WinSxS folder.


Actually, including the files in redist (Microsoft.VC90.CRT.manifest, msvcm90.dll, msvcp90.dll, msvcr90.dll) makes it work on the other (WinXP) PC (which doesn't have .NET installed).


Quote:
If you don't want your friends to install the Visual C++ runtime, go to Project Settings -> C/C++ -> Code Generation and choose the "Multithreaded [debug]" runtime (debug only for the debug configuration of your project) instead of the DLL runtime.


You were practically spot on. That previous option does simultaneously affect the "Runtime Library" field. (If only Microsoft could structure the options better so you could see the changes properly.). "Multi-threaded" (without the debug part which bloats it from 50 to 150k) is basically what we're looking for.

I also wonder why one has to delve into the "Code Generation" options for what should have been done by more easily selecting "No Common Language Runtime support" in the main options. But I'm new to .NET and all that, so maybe there's something I'm missing, and I'm sure Microsft have their reasons.

One other question too. Why does it allow "Use MFC in a static library", when the Express version of Visual C++ Studio isn't meant to have the Microsoft Foundation Class library?


Quote:
If you want to do manual pixel by pixel operation, you can use DirectX or OpenGL with .Net. "Simply" draw a full screen texture and update/upload texture content every frame.

But as others said, it wouldn't be the best way...


Because it's tricky to use? Unless there's an easy to use wrapper.....

I might try GDI first just to see what kind of speeds I get from that anyway.

Share this post


Link to post
Share on other sites
I don't think you seem to be catching what people are saying about pixel by pixel plotting:
Quote:
If you want to do manual pixel by pixel operation, you can use DirectX or OpenGL with .Net. "Simply" draw a full screen texture and update/upload texture content every frame.

But as others said, it wouldn't be the best way...

Quote:
You can do per-pixel access with it, but it's not efficient. Like I said, per-pixel rendering is slow regardless of which API you employ. That's why as you move towards APIs that take advantage of hardware acceleration, like Direct3D, per-pixel access remains possible (after a fashion), but difficult.

Quote:
Doing things manually pixel-by-pixel is inherently slow. You can get reasonable framerate out of GDI, but you can get even better out of, say, Direct3D.


Pixel by pixel plotting is SLOW, because the CPU is involved in plotting every single point. Here on GameDev, we are mainly involved in game development - If you want people to tell you how to do graphics for something other than a game, give a few more details and people can give you more tailored advice. But, if you are making a game, do yourself a favour and learn some SDL, OpenGL or DirectX, and if you still feel the need to plot pixel by pixel, use the texture updating method that the first I quoted suggested, becuase then you only do a pixel by pixel rendering when you change the image and not every frame.

Share this post


Link to post
Share on other sites
Quote:
I don't think you seem to be catching what people are saying about pixel by pixel plotting:

Nope caught it all. When I said "Because it's tricky to use?", I meant if that was the reason iliak was saying "it wouldn't be the best way though" for using DirectX/3D for pixel by pixel plotting. Obviously, I knew that DirectX/3D *was* tricky to use. I was also just wondering if there was a simplifying 'wrapper' to make DirectX/3D (with the texture mapping method for pixel by pixel plotting) as easy to use as GDI or SDL.

Synopsis:
DirectX/OpenGL/Diret3D: Fast but tricky to use
GDI: Slow but easy to use

I would imagine that applies both to games and apps (though I'm interested in making just apps at the mo, the speed issue is something you guys will know a lot about).

Share this post


Link to post
Share on other sites

This topic is 3490 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this