Bitwise or operator versus logical or operator

I've recently being doing some profiling of openBVE to try speed up the loading of routes. When I noticed that one of the heavily called functions  vertex equality operator was using a bitwise (|) or operator to check equality (see code segment)

Code:

public static bool operator ==(Vertex A, Vertex B) {
if (A.Coordinates.X != B.Coordinates.X | A.Coordinates.Y != B.Coordinates.Y | A.Coordinates.Z != B.Coordinates.Z) return false;
if (A.TextureCoordinates.X != B.TextureCoordinates.X | A.TextureCoordinates.Y != B.TextureCoordinates.Y) return false;
return true;
}

However, should this be the logical(||) or operator? As this would not speed up the process very slightly? As logical(||) or does "short circuiting" where by the first compareson is done should it be true then the rest need not be done. Also given that logically if any one of the values is not equal then the vertex cannot be the same.  I don't really see why it is being used in this case or am I missing something here?

Interesting question.

I suspect this will depend heavily on how the C# runtime is optimised internally; In C/ C++ bitwise operations are very marginally faster (Something to do with hardware registers on the CPU, not sure exactly what mind ), and this may well translate to C# speed.
http://blog.typps.com/2007/10/bitwise-operators-in-c-or-xor-and-not.html

Loading speed IMHO isn't the issue, but rather framerates. I've looked into this, but unfortunately the only real way to solve this is to rewrite the whole renderer and parts of the game engine from scratch, and that's nowhere near my level. A brief technical analysis:
At the minute, the whole game, including the renderer is run inside the single MainLoop thread.

This was the result of my last set of profiling on the mainloop:
(Plymouth Route + Dinmore Manor- Complex plugin running various animations and a steam engine simulation, a relatively minimal set of animated world objects, primarily signals and a few large conglomerate objects):
OpenGL system calls (Rendering faces): ~20%
JIT Object loading ~20%
3D exterior calculations ~10%
Updating world animated objects ~5%


The OpenGL implementation is where there is most room for improvement-
Each time a face is rendered (In general terms, this is a single [MeshBuilder] statement, within an object, although the sim will combine wherever possible), the RenderFace function is called, which starts off an entirely new GlBegin/ GlEnd chain.
Faces without transparencies or lighting are wrapped within OpenGL Call Lists wherever possible, but otherwise are plain OpenGL statements. (Wrapping everything else in Call Lists increases the framerate a little, but causes visual issues)

It really wants rewriting with VBOs, which would probably speed it up by an order of magnitude.


FWIW, I've actually got a version I've been playing with, which replaces Tao with OpenTK, which is marginally faster, but nothing really useful.

Cheers

Chris Lees

http://www.bvecornwall.co.uk

I guess the "easiest" (and still very hard) way to increase performance would be to switch to using an external 3D engine. The dev team of LokSim3D e.g. is aiming for this in the long run, but it still is much work.

It's not so much the 3D engine, as the game engine itself as a whole; They're very much intertwined.

Find yourself a copy of a very basic route (BVE2 era), and run it with a GPU load monitor program active.
You'll find that this will quite happily max out the GPU if you max out the AA/ AF setttings.

Now load a complex route, and look at the GPU load again.
You'll notice that even with the AA/ AF settings maxed out, you're only sitting at ~30% GPU load.

Why is this?
Using a single loop thread to run *everything* means that if one function is slow, it effectively blocks the next from updating until it's finished.
Graphics card usage is lower the more complex the scene is because it's actually spending more time opening and closing the graphics card and waiting for the renderer to finish calculating the next frame- Modern graphics cards are capable of throwing around huge amounts of data, but opening and closing them takes a significant chunk of time

Cheers

Chris Lees

http://www.bvecornwall.co.uk

I'm not sure I'm getting all the technical detail, but over all, I think I get the problem. Thanks for clearing that up.

Does this mean a major performance boost would be possible by splitting that main loop thread into a "graphics loop" thread and an "everything else loop" thread?

At least a little bit, and not "an everything-else thread" but many threads, and using ThreadPool or sth similar that makes threads be re-usable, afaik.

Such difference may also be seen on a quite famous bus simulating game, OMSI. You'll see the FPS drops quite much when enabling "less threads mdoe".

Well, my guess was that in OpenBVE graphics are the most challenging stuff and thus separating the rest wouldn't do much good (besides probably higher physics FPS, but imho that's not as critical with a railway simulation, even as low as 20 still works neatly, space shooters are something different of course), but that's just wild guessing by someone with little knowledge in the matter.

Chris, I know that loading time is not really a massive issue per say, it was just that I noticed that on my new albeit very modest laptop, loading times compared my old (11 year old) were almost the same regardless of the increase in computing power. Although I get this might just be down to delay in reading from a hard drive?
Yes I understand that openBVE doesn't really use modern 3d rendering techniques, although I did think the opitimseobject function tried to implement basic vertex buffer arrays though quadstrips and trianglestrips(I might be wrong though I'm no expert on 3d graphics rendering).
I would however agree slightly with you Quork that using 3d engine like Ogre3D might make more sense than continuing to use or rewrite a renderer from scrach.
I also can see how using more than 1 thread could speed up the game loop using a simulation update loop and a rendering loop, however the interaction between the loops would need to be closely managed.