|
Overall I thought that was a dumb movie. But being a guitar player myself and having played in a couple local bands, I did really appreciate that scene.
"But these go to 11." 
|
|
|
|
|
|
Xpnctoc wrote: Is this the best I can expect from a .NET-encompassed application? Would switching back to an older technology like MFC or even plain old Win32 programming increase my framerate? I do have a good C++ background with pointers and all that stuff, so I'm not afraid to roll up my sleeves if that's what it takes.
The first question should be identifying the bottleneck. Look at your CPU usage, if you hit 100% of a core, you are usually CPU bound (or very near). The problem with graphics drawing is there are many ways to do things. Immediate mode is the worst. If you are using immeadiate mode you will not likely get 1/100th the value listed for your card.
However, think about your triangle count for a minute. 64fps at 10,000 triangles is 640,000 triangles a second. Just below a million. Not bad for someone who hasn't even started trying to tune for performance. There are lots of ways to speed this up. If groups of your triangles don't move, you can use compiled vertex arrays, display lists, or vertex buffer objects. Each have different advantages.
If you have triangles textured, this reduces performance, but moreso if you have a larger number of texture binds than usual.
You might start looking through these[^] presentations to see if anything applies. Although nothing is specific to .NET, it offers hints for finding out what the bottleneck is, as well as drawing techniques that are faster.
_________________________
Asu no koto o ieba, tenjo de nezumi ga warau.
Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
|
|
|
|
|
First, I got rid of the v-sync. Between that and getting rid of the timer and going for a more direct loop, I'm cranking out a better framerate -- to where I was expecting the rates to be.
But you have an excellent point that I have not begun optimizing. There certainly are places I could use display lists, and I could re-sequence some of my data-binding to reduce texture binding calls. It will be interesting to see what additional performance I get once I make those modifications.
|
|
|
|
|
Let me ask you this too: Right now my code is set up to render a bunch of objects from closest to farthest away -- which I read somewhere is good practice to take advantage of the depth buffer. I could re-sequence the objects to render by texture binding, but that might mean more "in front" objects to render. So which is more costly -- repeated data binding operations or rendering more objects from back to front?
|
|
|
|
|
Xpnctoc wrote: So which is more costly -- repeated data binding operations or rendering more objects from back to front?
both, neither, and it depends. I wish there was a hard answer I could give you. Texture binds are more expensive. But if you have a reverse case (worst case) of drawing back to front, then you are rasterizing more than you need. Sometimes this is desired, for instance with transparency. So the answer is almost always a balance. It is a careful set of decisions, where one answer isn't always true.
Personally I would bind by texture, then sort within that binding. Are you doing a partical system that you have that many binds? There are ways to speed both up. You can used VBO's for static objects which also speed your texture binds since the textures are on the card and a VBO tells the card to keep the vertex object local to the card too.
There is no absolute, this is the only way to go.
I do use a scene graph myself, which attempts to make these decisions for you, organizing groups of objects by textures and materals first, then by distance. But even then you sometimes want your own control on the node to tell it when to render for specific appearance or calculaton issues.
_________________________
Asu no koto o ieba, tenjo de nezumi ga warau.
Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
|
|
|
|
|
No, not a particle system. I'm attempting to write my own railroad simulator, akin to MSTS or Auran's "Trainz" -- partly because I have complaints on how those software operate and partly because I just want to see if I can do it.
So I'm thinking from many different perspectives. Right now, the terrain engine is the main focus. I know terrains are a giant topic by itself, and I'm not terribly interested in making a science of it. The terrain is supposed to be user-modelable at runtime, which in my mind negates some of the really fancy algorithms anyway, because you don't know ahead of time what texture will be required from one tile to the next. So I'm just trying to improve on the brute-force algorithm a little bit.
I abandoned the idea of straight-forward triangle strips in favor of a spiral algorithm working from the camera outward to take advantage of the depth buffer test, especially when the camera is facing a large hill. Why bother to rasterize everything behind the hill? I also have some code in there that flags each tile as "in view" or not every time the user moves the camera, so at any time I'm only drawing about 1/4 of the actual data grid.
If I sorted by texture type, that would reduce the number of texture binds GREATLY, but at the expense of more vertex calculations because there would be no guarantee of a linear block of tiles having the same texture.
|
|
|
|
|
Xpnctoc wrote: which in my mind negates some of the really fancy algorithms anyway,
not necessarily, it all depends on how you are doing the blending. You can also use a shader in which case you can bind up to 8 textures to all materials, and leave them bound, use a shader to look up the appropriate texture at run time and use it. This is how multi-texture blends work. You can do some REAL fancy footwork with dynamic terrain, I do so now and then. Right now I run quad-tree, I have one bound texture per quad, plus some global textures working off shaders that are blended via shading program. Check out vterrain.org. (not mine, though my project is mentioned as one of the 100's of projects on one small page out of the dozens).
_________________________
Asu no koto o ieba, tenjo de nezumi ga warau.
Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
|
|
|
|
|
Xpnctoc wrote: I am using a Timer control to trigger the rendering cycle. Since I want to draw as fast as possible, the timer interval is set to 1 ms.
There's one bottleneck most likely. I'm not a .NET person, but if it's anything like VBs timer control, it uses WM_TIMER. That 1ms resolution from WM_TIMER is a joke, you'll never get that. Instead, your rendering cycle should just be in a loop that will allow important messages to interrupt it and otherwise not care one bit about them.
|
|
|
|
|
Xpnctoc wrote: Is this the best I can expect from a .NET-encompassed application? Would switching back to an older technology like MFC or even plain old Win32 programming increase my framerate? I do have a good C++ background with pointers and all that stuff, so I'm not afraid to roll up my sleeves if that's what it takes.
Personally, and this is just my opinion, I'd never use .NET for a game. Most of your code .NET won't handle anyway. And, adding the extra layers of garbage for just dialogs when VC++ has a native dialog designer (ok, it sucks though) isn't worth it IMO.
|
|
|
|
|
I noticed in your first response you said you're not really a .NET guy. In general you are right that .NET does add layers of garbage. I sure wouldn't try writing something requiring high performance in VB.NET or C#.NET. There are a number of known areas where .NET lacks performance. For instance, a quick programming experiment easily shows that, the .NET List<> class implementation of a quick sort is easily outperformed by a natively-programmed quick sort.
HOWEVER, C++/CLI allows you to mix .NET code with native C++. They call it "IJW" code (It Just Works). These sections of code are build directly to machine language rather than MSIL/CLR. This allows you to pipe through native code for execution without incurring the overhead of .NET and runtime compilation or interpretation.
In fact I have been architecting my software to do just that. The whole app is containerized in the .NET framework because of the ease of the form designers, etc. BUT all of my core logic is written in native classes that get built directly to machine code rather than interpretable CLR.
My software is also more what I would classify a modeler/simulator rather than a "game". Without going into all the detail, suffice it to say a very large number of dialogs is required, such that in my mind the little extra effort to create a "mixed mode" program is more than worth the effort.
Since I have managed to ditch the timer and move to a continuous rendering loop, my framerates have increased to where I expected to see them. I also haven't yet optimized any of my OpenGL instructions (using display lists, sequencing rendering to reduce state changes, etc.), so even more is yet to be gained. I don't think at this point I'm losing any performance by using "mixed mode" programming and letting .NET make life a little easier where it can.
Current performance: 160-239 fps running the exe directly, and even 20-25 fps through the Visual Studio IDE with all the debugger garbage running in the background. That's much better than the 64/5 I was getting when I started this thread!
-- modified at 11:03 Wednesday 26th September, 2007
|
|
|
|
|
Xpnctoc wrote: My software is also more what I would classify a modeler/simulator rather than a "game".
 I normally joke that work pays me to play games all day. Nudge, nudge, wink, wink, know what I mean?
_________________________
Asu no koto o ieba, tenjo de nezumi ga warau.
Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
|
|
|
|
|
Ah, wink wink. Say no more, say no more
|
|
|
|
|
El Corazon wrote: Nudge, nudge, wink, wink, know what I mean?
No, no I don't... unfortunately. Unless making websites qualifies as a game.  ;)
|
|
|
|
|
Jeremy Falcon wrote: Unless making websites qualifies as a game
depends on what is playing on the website.... good high quality soft-body physics can really put the "bounce" in what you look at....
_________________________
Asu no koto o ieba, tenjo de nezumi ga warau.
Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
|
|
|
|
|
El Corazon wrote: good high quality soft-body physics can really put the "bounce" in what you look at....
 Good one.
|
|
|
|
|
hi,
in advance thanks to look my problem,
i am executing pushsource program which is in samples->multimedia->directshow->filters of platform sdk. i am getting some errors while linking. i dont know what to do i have already included strmbasd.lib in the project library and the path is also set.
can any one help me how to get rid of this errors.
the following errors i am getting.
Linking...
LINK : fatal error LNK1221: a subsystem can't be inferred and must be defined
PushSource - 1 error(s), 0 warning(s)
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
can any one help me how to solve it.
amiya kumar das
|
|
|
|
|
amiya das wrote: LNK1221
You could always try looking up the error.
Linker Tools Error LNK1221[^]
/SUBSYTEM:WINDOWS works well for a DS filter.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
![Java | [Coffee]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/coffee.gif)
|
|
|
|
|
Iam doing my graduation project and i need to do a project (Design simple dream home ..)which is build 2d home which the user draw( I use c# to program it )and then transfer it into 3D home and allow walk throw this virtual 3d home...
which is better to do this transfer and drawing this 3D home..DirectX Or Open GL ??( I don't no any thing about both.. but i want to learn the best for my project )..
Thanks..
|
|
|
|
|
sofy2008 wrote: what is better directX or openGL
short answer: both, neither, either... take your pick.
Long answer: DirectX is designed for Windows operations and is a closed system, if you are on windows only, and C# only, chances are you will want to use DirectX. OpenGL is designed to be cross platform, and open. There are some advantages of the open system. It is far easier to find your scenegraphs for OpenGL for instance because of the openness issue. OpenGL is defined by committee, where-as DirectX is defined by one Company: Microsoft. There are advantages and disadvantages to both. You know what they say about committees, "a camel is a horse designed by a committee." ATI's got to get their two cents in, so does nVidia, so does Sun, so does... etc. Once everyone has put their two cents in, you've got some odd things. But on the good side, you are generally graphics card agnostic, tests are uniform, and extensions are available to pull in the latest stuff from your favorite vendor. With DirectX there is one way, or the highway, you say nothing, you obey everything. Don't like it? tough cookies, go play elsewhere. The advantages with DirectX is that it is generally efficient, if not sometimes convoluted, both because Microsoft can do anything they want, and they really don't have to listen to anyone else unless they feel like it that day. And of course the big thing for you, DirectX plays well with C#. Not to say you can't do OpenGL with C#, but you will find it usually easier to do DirectX.
OpenGL is also designed to be language agnostic, you will find OpenGL for C/C++ mainly, but also for VB, Delphi, Fortran (yes, you heard that right), Perl, Python, Ruby, Scheme, D, C#, and many, many, many, many more.
You might as well ask which is better, Fuji Apples or Granny Smiths? You'll get lots of opinions, but the real question is what is right for you, and no one can answer that except you. Personally, I prefer Fuji Apples and OpenGL.  Plus I can plant the garden outside the house and make it wave in the breeze.
-- modified at 12:53 Wednesday 19th September, 2007
_________________________
Asu no koto o ieba, tenjo de nezumi ga warau.
Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
|
|
|
|
|
El Corazon wrote: OpenGL is defined by committee
And Microsoft was part of the original committee. Just shows you really need to be careful letting Microsoft near a standards effort.
El Corazon wrote: DirectX is that it is generally efficient, if not sometimes convoluted
Like a lot of Microsoft API's, it appears to be the outgrowth of someone's thesis project. A lot of theory but little thought on what is needed in practice.
Save an endangered species. The American Engineer.
|
|
|
|
|
DirectX
Pros:
- It's a complete engine that'll handle stuff like audio, input, etc.
- A lot of companies use it, so learning it may land you a job.
Cons:
- Uses COM, so it's inherently slower.
- Windows Only.
- The code required to get things going is bloated.
OpenGL
Pros:
- Cross platform, if you want your games to also work on Macs, Linux, etc.
- Fast and efficient.
- It runs about 10 FPS faster on nVidia cards in Windows (pre Vista that is).
Cons:
- It's just a rendering pipeline, you'll still need to handle things like input, audio, etc. with another library.
- DirectX dominates the Windows arena, and Windows dominates the desktop arena.
I prefer OpenGL personally because I believe Windows isn't the only OS in the world. But, as far as what's really better or not, it depends on your circumstances. If you'd like to get a job in the gaming industry, learning DX may be a good choice. If you want cross platform, OGL is the way. So on and so forth.
And remember, at the end of the day, making a good game has less to do with your choice of engine and more to do with the talent of your team.
|
|
|
|
|
Thank you for your wonderful analysis, I will choose to learn DX first
|
|
|
|
|
I think DX is better for you, you can modify the samples to match your needs
|
|
|
|
|
Is there anybody know how can I fetch resources from Uncharted Waters 4, published by KOEI.
I need the pictures in Uncharted Waters 4, thanks a lot!
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
![Beer | [beer]](https://www.codeproject.com/script/Forums/Images/beer.gif)
![Java | [Coffee]](https://www.codeproject.com/script/Forums/Images/coffee.gif)
