[Metro4001]

You know you're doing great when people gripe over snow flakes. Immersion breaking lol. On 2001 graphics. Immersion breaking lmao.

[edwardk]

How does this look now? After researching the basics of triangles and index buffers, I finally found out how to convert the index buffer to 32 bit. I increased the ceiling height as well as the size around the player locomotive so that when you switch to the rear of the train, you will still see the consistent snow fall. Keep in mind, this also includes rain. There would still be the issue of overall performance. The other part is that we are only uploading bug fixes so this would only be uploaded once V1 is released.

Edward K.

Attached thumbnail(s)

• 

[James Ross]

edwardk, on 23 April 2015 - 01:38 PM, said:

There would still be the issue of overall performance. The other part is that we are only uploading bug fixes so this would only be uploaded once V1 is released.

The main issue is not performance but the 16bit limitation on some graphics cards so you need to have conditioned the code to use the right one (and the right limits) depending on the user's hardware.

Edit: Note how that bug got reported 5 times in the one month before it was fixed.

Edit: Also, you may want to see what the box size and height were before that bug to see what I'd set up prior to being constrained by the 16bit indexes.

[Genma Saotome]

A question: If someone is dissatisfied with the appearance of either the falling snowflake or falling raindrop isn't there a .png file for each that could be replaced by the end user?

[Kazareh]

edwardk, on 23 April 2015 - 01:38 PM, said:

How does this look now? After researching the basics of triangles and index buffers, I finally found out how to convert the index buffer to 32 bit. I increased the ceiling height as well as the size around the player locomotive so that when you switch to the rear of the train, you will still see the consistent snow fall. Keep in mind, this also includes rain. There would still be the issue of overall performance. The other part is that we are only uploading bug fixes so this would only be uploaded once V1 is released.

Edward K.

That, looks FANTASTIC! Not going to lie, my jaw hit the floor seeing that shot.

As for the bit abotu 16b GFX cards, and again I am just saying this as an -idea-. I cannot really code due to my dyslexia, however. Would it be possible for OR to 'scan' the Graphics Card's bit-rate, and go off of that? Or maybe use a checkbox for toggling between 16b, 32b, and/or 64b snow/rainfall rates or somethin'?

Genma Saotome, on 23 April 2015 - 03:03 PM, said:

A question: If someone is dissatisfied with the appearance of either the falling snowflake or falling raindrop isn't there a .png file for each that could be replaced by the end user?

As far as I know Genma, no, there is not. I've looked all over my OR directory and it's as present as the fabled 'Addons' folder for the overheadwire.ace texture...

[edwardk]

James Ross, on 23 April 2015 - 01:55 PM, said:

The main issue is not performance but the 16bit limitation on some graphics cards so you need to have conditioned the code to use the right one (and the right limits) depending on the user's hardware.

Edit: Note how that bug got reported 5 times in the one month before it was fixed.

Edit: Also, you may want to see what the box size and height were before that bug to see what I'd set up prior to being constrained by the 16bit indexes.

James,

I had no idea that you set this up as 16 bit because of computers not being able to handle 32 bit. The hard part getting to this point was trying to find enough of the right information on line. There is just not enough tutorials/examples on line. Even looking for examples of using 2 index buffers was impossible. Either way, there must a common ground solution. With what you had set up as 16 bit was pushing the limit. About 64,000 vertices out of 65,535 being the limit. No room for change or expansion. I will try to find information on hardware detection. Do you have any experience in this area?

Edit: OK, so what I thought was a good idea was actually done before X2270. Before the fix, the box size was 1024x1024x100

Edit: You indicated in one of your edits to note that the original issue was reported 5 times before it was fixed. This just tells me that the people on the team do not have the right knowledge/experience to feel comfortable enough to tackle the issue. In my case, I really have no knowledge in this area, but I am willing to try.

Edit: Kazareh indicated in one of his posts of having an option to choose either 16 bit or 32 bit. I would not know how you would view this option, but as last resort, I see it as a viable option.

Edward K.

[James Ross]

Genma Saotome, on 23 April 2015 - 03:03 PM, said:

A question: If someone is dissatisfied with the appearance of either the falling snowflake or falling raindrop isn't there a .png file for each that could be replaced by the end user?

Yup, Content\Raindrop.png and Content\Snowflake.png. Obviously I'd prefer that people proposed new images to the project so everyone can benefit, but you should be able to experiment locally quite easily.

Kazareh, on 23 April 2015 - 09:47 PM, said:

As for the bit abotu 16b GFX cards, and again I am just saying this as an -idea-. I cannot really code due to my dyslexia, however. Would it be possible for OR to 'scan' the Graphics Card's bit-rate, and go off of that? Or maybe use a checkbox for toggling between 16b, 32b, and/or 64b snow/rainfall rates or somethin'?

You can detect this (which I implied here).

edwardk, on 24 April 2015 - 12:30 AM, said:

I had no idea that you set this up as 16 bit because of computers not being able to handle 32 bit.

I explained that earlier in this thread.

edwardk, on 24 April 2015 - 12:30 AM, said:

I will try to find information on hardware detection. Do you have any experience in this area?

I believe it can be detected through normal XNA APIs. I checked and you need to do this (here's some similar sample code):

var capabilities = GraphicsDevice.GraphicsDeviceCapabilities;
if (capabilities.MaxVertexIndex > 0xFFFF) {
    // 16bit and 32bit indices supported
} else {
    // Only 16bit indices supported
}

edwardk, on 24 April 2015 - 12:30 AM, said:

Edit: You indicated in one of your edits to note that the original issue was reported 5 times before it was fixed. This just tells me that the people on the team do not have the right knowledge/experience to feel comfortable enough to tackle the issue.

IMHE of other (much larger) projects, the duplicate count is often a clear indication of the scale of the problem, as is the speed at which they appeared. Launchpad turns this and other info in to a "heat" value, which is 52 for the 16bit buffer issue - that's high for Open Rails. In fact it's 3rd (almost 2nd) in the heat-rating for all the bugs since 0.9.

Bugs don't get (many) duplicates just because nobody fixes them - see some of our older bugs, for example. Even the few others we have with multiple duplicates, they were not typically reported close together. There has to be additional motivation to cause duplicates, including (but not limited to) widespread, or game-stopping. This was certainly the latter and I believe partly the former.

[edwardk]

I would like to thank James for the information. A test can now be performed to check for 16bit operation that will prevent the crashes that took place prior to X2270. As it stands, the weather process is still in its early stages. The snow looks great, but there must be a way to have rain look like rain. If you compare the rain in MSTS to OR, it appears that some adjustments can be made. There have been many improvements since X2270 and the improvements will continue ;)

Edward K.

[Genma Saotome]

edwardk, on 24 April 2015 - 01:23 PM, said:

If you compare the rain in MSTS to OR, it appears that some adjustments can be made. There have been many improvements since X2270 and the improvements will continue ;)

Edward K.

That's why I asked about graphics files. The OR raindrop is outlined in white, the MSTS raindrop is, IIRC a medium gray. Given the existence of the .png files it seems that a bit of experimentation in art could get us from A to B.

I looked at the .png files -- they're rather small. Is there some "rule" about the size of the art and the size of the raindrop or is it simple UV logic?

[edwardk]

Genma Saotome, on 24 April 2015 - 03:24 PM, said:

That's why I asked about graphics files. The OR raindrop is outlined in white, the MSTS raindrop is, IIRC a medium gray. Given the existence of the .png files it seems that a bit of experimentation in art could get us from A to B.

I looked at the .png files -- they're rather small. Is there some "rule" about the size of the art and the size of the raindrop or is it simple UV logic?

I was only commenting on the differences that I noticed between MSTS and OR. Regarding specifics such as format and size, this is definitely not my area. You did mention that OR's raindrop is outlined in white. This is evidently why it looks like sleet instead of rain( at least to me ).

Edward K.