|
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++
|
|
|
|
|
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!
|
|
|
|
|
send in your resume/CV and application to KOEI to be an employee.
_________________________
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,
I swear I hear a little flamenco guitar every time I read gems like that
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Mark Salsbery wrote: I swear I hear a little flamenco guitar every time I read gems like that
hey, it is nothing but the truth. My work is not public access, but does generate public pictures once in a while. I am the only one who has them outside my work. If you want to get access to the goodies, join the team. It's the best way, and you earn a buck doing it too!
and I play native american flute, not guitar.
_________________________
Asu no koto o ieba, tenjo de nezumi ga warau.
Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
|
|
|
|
|
American humor? Is there any other solution? I'm serious, thank you.
|
|
|
|
|
The artwork in the application belongs to KOEI. They produce the game, and their license will be pretty tight, so we cannot help you to rip them off. Sorry, but we don't encourage this type of behaviour around here.
Deja View - the feeling that you've seen this post before.
|
|
|
|
|
Yeah, I think you are right, but I don't want to steal these from KOEI, I just want to know how to fetch them out, from the technical point of view. It's just my interesting, you know, if I use them in business products, KOEI will trouble me. ^_^
|
|
|
|
|