They do make a special port that can handle the demands of high speed graphics. Its called PCIX, its quite wide and they put it on very very short wires right next to the CPU and RAM, so they can get high speeds out of it.
A PC has the power to run playstation & xbox360 games, its more that its easier to write games for one set of hardware.
The USB powered games will be far far shittier. They will have terrible graphics compared to anythign else on the market.
Other people have tried to provide a "better game" if you buy the hardware. Ageia did this with physics accelerators. Hardly anyone bought them, so nobody really made games for them.
Seriously, I bought a 9600GT the other day for around AU$150. How cheap did you expect to make this for?
If u knew how to do it u wouldnt be posting in this forum
I come vastly closer to knowing how to do it than you apparently do. I also know what it would take to make it viable commercially which you're apparently totally unaware of. And if I chose to put the effort forth to make it happen, I live in Silicon Valley and all the needed assests are in my backyard.
u could be in ur private boat partying
How do you know I'm not? The San Francisco Bay is lovely this time of year.
Oh, by the way. No one appreciates the dumb assed text speak you're using. It just makes you look stupid.
Basically, I would look into this solution to be able to drive a 30" monitor from my laptop for software development.
As some other posters have replied, the bandwidth of the USB port is not capable of driving a high performance graphics card for current technology games at the rate the current cards are capable of processing. The bandwidth of the device referenced in the article is about 2.5 GBits/s, which ends up being close to the equivalent of the ancient AGP 1.0, about 1/8 of the AGP 8x standard which has been out the door for quite some time.
Also, it was described that you would be running a video card, through a usb connection, and connects to the bus of the machine. Normal video cards sit right on the bus and have direct contact with the CPU and hardware. With an external solution, they cannot be as efficient because you are introducing new layers into an existing system, and will have bandwidth restrictions.
my friend and i developed a code using VB.net 2005 for Generating a flowchart for a given source code and approximatly every thing is fine but there is problem with the Dynamic relations between the nodes; they disappered when we make minimize then maximize for the window. so if some body have any idea about this problem please help coz this is our graduation project.
You know, you provide so little information in your original question, it's impossible to know. The only thing that I can suggest is that, when you resize a window, the system sends a WM_PAINT message to your window. If you think of that as an event, you can write a handler method that will redraw those connecting lines (or whatever is necessary). I code in C++, so I won't include a code snippet, but, it is a trivial effort.
Thanks a lot for your answering my question, but you are saying that I didn't write enough info. About my problem so what info. Do you suggest on me to include for making my question clearer, beside I’ll be so grateful for you if you include a code snippet even if it had been written in C++, I can handle it. Thanks again for answering
you are saying that I didn't write enough info. About my problem so what info. Do you suggest on me to include for making my question clearer,
You didn't tell us anything about how you've structured your program or the data you want to display. You need to capture the data you want to display and keep it available to your program. Maybe the "Form" but I don't do VB, only C++, so I'm not sure of that terminology. The program has to be structured so the data can be displayed entirely from the data structure in response to a WM_PAINT message. I think in VB you have a paint handler function where you need to do this (OnPaint?). It sounds like you aren't accounting for drawing your "dynamic links" there. A common mistake is to let the user draw interactively on the window and not capture the data into a structure for redisplay. In your case, you get a WM_PAINT message, at least under the covers, when you restore the main window from being minimized.
Yes, the way Tim just stated the problem is correct. Even though we code in C++, the windows object model is the same (but, the syntax is very different). We have no idea if you are drawing to a form, as in NET Framework or a normal window (Win32). We have no idea how you did the previous drawing operation, or where you derived the data. It never hurts to provide lots of code, and describe your thinking as if we were from another planet.
Essentially, Tim is correct about preserving the data structures that your drawing code depends on. How is that done? What kind of a presentation are you ultimately trying to achieve?
Yeah, sorry, I just click the buttons without looking at the context.
Norxnor, I think you got the idea. Hell if you have written an application that displays the flow chart correctly, rewriting the the drawing method should be easy.
Have created a EMF file using corel / Illustrator software.
But this emf file does not have antialising effect applied on its image.
Just need some pointers on how the emf file records can be edited programmatically to include the antialising and other quality enhancing information.
Any links to source code are welcomed.
I wanted to show an animated gif on a Windows Form (C#). Using the ImageAnimator class I was able to animate the gif, but the every other frame is skipped. There are eight frames to the animation and only four are shown.
When the gif in previewed with another program every frame is displayed smoothly.
Has anyone here any experience working
with the MetaDraw component from Bennet-Tec.
I'm starting a new project and I'm looking
for a component that allows users to draw and later
to move shapes around - like in Visio but without every
user needing to purchase Visio ( required when using Visio ActiveX ).
MetaDraw seems to fit but I'd like to know if anyone
has experience using it. Also how is their support ?
Hi. I'm coding a C# application and I know nothing about GDI. I have a mdi parent form which has mdi child forms bigger than the screen. I overcome the form screen size limitation using the following code I've found on the net but now I have a problem: setting form.Location property doesn't work. Can you please tell me how to fix this?
Here's the code:
publicstaticexternint SetWindowPos(int hwnd, int hWndInsertAfter, int x, int y, int cx, int cy, int wFlags);<br />
protectedoverridevoid SetBoundsCore(int x, int y, int width, int height, BoundsSpecified specified)<br />
SetWindowPos((int)this.Handle, 0, 0, 0, width, height, 0);<br />
This is really a NET Framework question, rather than a GDI question, but,...
I'm just guessing here, but, when you set or get a value for Location in your NET Form class, the framework at some point probably interops to the underlying Win32 API to do the actual work (probably SetWindowPos). And, by importing the original function with the System.Runtime.InteropServices.DllImport("user32") attribute, (Check out: PInvoke, SetWindowPos[^]) you are just short-circuiting the NET class implementation, which probably maintains a complex Form instance data structure somewhere in garbage-collected memory, and has a conflict now because the data are NOT what it expects, or something similar. Almost all of the NET Framework still interops its function calls, and it can be confusing from a developers point of view to maintain a consistent implementation.
The simplest method would be to use Form.Location property in the first place to set and maintain the correct value for your form's display. The MSDN documentation Control.Location[^] doesn't really explain that, though.
You might find this interesting: NET Framework Interoperability[^]
The article advises: "Before you decide to call a flat API using either of these interop technologies, you should determine whether there is equivalent functionality available in the .NET Framework. It is suggested that, whenever possible, you use .NET Framework functionality instead of calling unmanaged APIs."