how does openbve work????

Hi all, I`m having issues with the frame rate on the latest part of the Midland Suburban Line...the problem is this...the new route file consist of a different departure point, the files collectively are less in size than the original route file, i.e. kentish town to Junction road Junction is larger than Gospel Oak to junction road juncton... hope this makes sense...
Heres the question... how does openbve actually call up the files..does it load all of the route and object/sound files at the start or does it load the files as the route progresses....or am i missing the plot altogether.....why having reduced the object file sizes, (deleting all face2 etc) does this make no difference....does the use of .dike,.form etc give a better frame rate than using .freeobj..

Not sure if all files, or if not how many files, are loaded at the outset.
As far as .dike over .freeobj goes, it's tidier and easier for the builder to code an object which repeats a number of times at 25m intervals as a .dike or .wall - you can use either term for the object, remember each rail can have only one dike object plus one wall object. How these are made, however, gives the builder a LOT of flexibility. Remember also that there is a Left and Right object referenced to each .wall / .dike item in the structure namespace.

I have found that if I put a VeryLargeObject in a route file then framerates can suffer, but it seems only to affect the part where the object is about to arrive within the viewing distance. So I imagine its a renderer thing, it isn't being "chewed" until it's about to appear - that's when the indigestion happens. If framerates are low throughout the journey I imagine there has to be a common factor causing it.

Hi,

Yeah if you route is curvy and your forward vision is restricted you can set you distance to a lower value say 600m. Gray is right, the hit to frame rate will occur when then large object is loaded as it is comes within your viewing distance.

Also the .dike and .wall commands have a left and right version available to you but there is nothing stopping you making them both appear on the same side as they're user defined. So you get three variant from each command, L, both and R to be used as you see fit. Saves a lot of coding as you only define a start and an end, otherwise it is a .freeobj every 25m.

When you removed all .face2 and replaced them with a .face, 0,1,2,3 and a .face, 3,2,1,0 for example, this would make little difference. If you removed the face you didn't see then it will improve the frame rate.

So I lean towards Gray's summation that there is a common problem that is to blame for the reduction in your frame rate. A little use of the semicolon to remove commands being seen / executed by BVE and slowing working through your coding may be the only way you nut out what is causing the blow to your frame rates.

I wish you all the best with your fault finding.

Bye for now,

Stephen.

Headache pills at the ready

Here goes at my understanding of things.

At loading the route file is parsed, I believe that all objects are are loaded, however by default textures are not loaded until needed this behaviour can be changed. I believe that sounds operate in a similar manor, I'm not sure if this can be changed or not.

As regards drawing of objects by the renderer, I believe although I've not really looked in depth in to this. That all objects falling within the viewing distance (default 600m) are then drawn, this would be when their textures are loaded, if they are not already loaded. This is what causes small pauses/dips in frame rate every so often as textures that need to be loaded are actually loaded, if a large amount of textures and/or textures large in size need to be loaded this could be quite noticeable.

As for differences between objects of differing types at the level of loading the objects, it doesn't make a difference as openBVE loads objects as either static(not animated) and animated objects. The different types of objects are applied during parsing of the route file, not when parsing the objects themselves.

Or at least that's my understanding of how things work.

graymac wrote:I have found that if I put a VeryLargeObject in a route file then framerates can suffer, but it seems only to affect the part where the object is about to arrive within the viewing distance.

This is the main point... and It 's worse if many heavy objects are placed at the same progressive. This causes a sudden drop in frame rate.

Common cases seen by me are:
- trains fitted with the interior, rotating wheels, opening doors (in other words trains designed for external views) positioned along the line as freeobj
- station buildings built as an unique heavy object and/or a lot of smaller objects (like track objects) placed at the same or very near position.

There are not, in my opinion, precise rules, but it's better to try to "dilute" objects at differents positions (with 25 meters steps); objects whose visual position may be shifted backward in the code of the object itself, so to look like they are at the same position of others also if not in the track code.

Thanks all, labratandy, can you possbly expand on the texture loading side of things, especially how the texture loading point can be changed, i think your answer may be the key to my ongoing problem, by the way i have managed to increase the frame rate from 25 to roughly 31/32 fps, which is still no where near the 40+ from the old route file...I tend not to use .dike,.form etc very much, relying on .wall and .freeobj`s..
Tof63, Your right i have been playing with the object coding to see what difference it makes to the frame rate. The large object problem is something that is being experienced already with the modelling of St Pancras stn, because of the length of the object, it doesnt look good appearing before your eyes, so to speak, however thats for later this year..

I pass on this message sent me on this subject from a respected colleague not registered with this forum:

Hi Gray,

I noticed in the forum some are asking about how many files OBVE loads

"Not sure if all files, or if not how many files, are loaded at the
outset."

That depends upon how you set it.

Somewhere there is a file called options.cfg which in Linux sits in

.config/OpenBve/

part of which contains:

[display]
mode = window
vsync = true
windowWidth = 1024
windowHeight = 768
fullscreenWidth = 1280
fullscreenHeight = 1024
fullscreenBits = 32
mainmenuWidth = 808
mainmenuHeight = 611
disableDisplayLists = false
loadInAdvance = false
noTextureResize = false

So, if you set loadinadvance to true, all textures are loaded before
the game starts, otherwise they load at whatever distance setting you
use.

This is worth knowing.

That is really great to know! Suddenly I'm able to run Genova Brignole - Genova Nervi nearly smoothly, while on less demanding routes I also have improvements, not in the topic of FPS, which stayed rather constant, but in the virtually complete lack of stuttering before greater objects (i.e. stations, loops, trains etc).

Personally I don't think it will make a difference to the FPS a route runs at, but the stuttering will be less. Given that most modern PCs have multi gigabytes of ram, I don't see why it couldn't be set to on by default(would need this change made in openBVE it's self).

I think FPS performance is down to size and complexity of objects and also size of textures used. As the graphics card has far less memory available to it and moving the textures from system to graphics memory to be displayed all takes time. The larger the textures used the fewer that can be held in graphics card memory and the more times things need to be moved all taking time, reducing the FPS rate.

Hi all, having spent a few days reducing the size of the .PNG files and generally getting rid of unnecessary files, I have come to the conclusion that it doesn't make a lot of difference to the frame rate. I think my problem lies in the start of the route file...I substituted the first part of the route file with the first part of the Kentish town route file, the frame rate went straight up to 40+ fps..I am now in the process of deleting each .freeobj and.wall to try to find where the problem is...watch this space