Just informing

[Juris3D]

Oh, probably need to state visible somewhere at release - "Press F1 after starting particular config" City is working, with cars and yellow balls pedestrians :) I could list ones that does not start: Config Universe, River, Berkeley, Puget, Puget Sound, Grand Canyon, Grand Canyon Sound, Hetch, Config Soda, San Miquel, White Plane. He 3DWorld_2019-06-23.zip re I will attach some screens, please take a look, maybe something visual missing or wrong.

[fegennari]

I don't see anything wrong in the screenshots, they look fine to me. I see you found the wireframe mode key. Why don't the other scenes start? Do you get shader errors? Please send me text logs of some of the scenes that don't start.

[fegennari]

Berkeley, Puget Sound, Grand Canyon, and Hetch won't work because the load large heightmap image files that aren't in the git repo. Soda and San Miguel use 3D models that aren't in the repo, but should load with an empty scene. Universe, White Plane, and River should work. River is one of the simplest scenes. White Plane has a lot of reflective spheres and may not run on all GPUs.

[Lecrapouille]

@fegennari could be nice to add other resources but just an idea: could be interesting to separate data (textures, 3d objects ...) from the code source and move them into separate git repos (and probably use git lsb: large file storage, for example, 3DWorld and 3DWorld-data). This allows keeping light the git holding sources. In a GitHub project, I was started to add textures with sources until I realized that was a bad idea. Once the error is made you cannot get back to initial size by git removing the huge file: the history keeps holding it. You have to work on your commit trees. this is what https://rtyley.github.io/bfg-repo-cleaner/ does.

[fegennari]

Most of the files came from my import from svn to GitHub. I don't think I have time to split the source from the data. The large files are all scattered about in the git repo, with many hard-coded paths to everything. It would take many hours to get everything working again after that reorg. And then there's the task of keeping everything in sync between the two repos when I make changes. I did try to remove a large file awhile back, and it took about an hour for that one file! I'm worried that using something like repo-cleaner would break something.

Maybe I can look into it sometime in the future. This past month I spent too much time fixing all of those compiler warnings/errors and trying to get 3DWorld working on different OSes and hardware. I'm behind on my procedural city and monthly blog posts. I only have about an hour a day to work on this.

I'm also in the process of getting everything to work with Visual Studio 2019, which has a new set of compile errors and warnings.

[Lecrapouille]

I'm also in the process of getting everything to work with Visual Studio 2019, which has a new set of compile errors and warnings.

:goberserk: :grin:

[fegennari]

I fixed the memory allocator compile error and created a MSVS 2019 of jpeg.lib. Those are the two sets of errors I had. I also updated the project file to point to the libraries in dependencies/. I've likely broken building with older versions of MSVS, but it shouldn't be hard for a user to get them working again.

The warnings are harder to fix, in particular because there are so many and there are so many bugs. Build time is faster, so I don't want to revert back to MSVS 2017 though. I get a long list of warnings, fix most of them, but they still show up. When I restart Visual Studio and rebuild it lists a different set of warnings that I haven't seen yet. I fixed some of the new ones. The icon shows 12 warnings, when I click on it it expands to 48 warnings, then when I unexpand it shows 1 warning - what?!

In addition, some of the warnings are false, and I don't know how to suppress them. For example: struct cube_map_lix_t { int ixs[6]; // one per cube face, -1 is disabled cube_map_lix_t() {for (unsigned i = 0; i < 6; ++i) {ixs[i] = -1;}} }; Gets me: Warning C26495 Variable 'cube_map_lix_t::ixs' is uninitialized. Always initialize a member variable (type.6). What, it can't figure out a loop initialization? I can't wait to fix that one that's an array of 256 elements by initializing them all one-by-one!

Also this line: if (!objs[i].status) continue; Gets me this warning: Warning C6319 Use of the comma-operator in a tested expression causes the left argument to be ignored when it has no side-effects. WTF? There's no comma on that line, or on the lines around it!

So, yeah. See if I've fixed the errors, and try to ignore the warnings for now. Maybe Microsoft will eventually fix it. If you figure out some good workarounds for the warnings, be sure and let me know.

[fegennari]

I updated Visual Studio to a newer version and rebuilt. Now all the warnings are gone, even the ones I didn't fix. So maybe the warnings bugs got fixed? I don't know.

[Lecrapouille]

Yep grepping C26495 on google makes appear this kind of bug existed and fixed in 2018: https://developercommunity.visualstudio.com/content/problem/316065/false-positive-for-c26495.html So may had a beta version.

And I find boring this kind of warnings (including coverity scan) because you may not want to directly initialize member variables and affect a value later (like you may do for integers). Plus why preferring to initializing an integer to 0 instead of 1? 0 is neutral for addition; absorbing for multiplication, while the opposite for 1.

if (!objs[i].status) continue; Gets me this warning: Warning C6319 Use of the comma-operator in a tested expression causes the left argument to be ignored when it has no side-effects.

Funny :) maybe they did something like #define continue return , lol I'm kidding

So maybe the warnings bugs got fixed? I don't know.

Is there a way to show used compilation flags ? Also you do not compile with a g++ standard (like --std=c++11) so maybe it uses c++03

[fegennari]

I don't think C26495 is the issue I'm seeing. I don't get warnings when initializing member vars like that. I get warnings when initializing an array of values in a loop. It does seem like the recent update fixed it though. Or maybe it broke all warnings so that I never see them.

I don't think it matters what you initialize an integer to as long as you expect it to be written to before it's used. It's better than not initializing and have it be random, which leads to unreproducible failures. At work we like to initialize integers to int::const_max to make it more likely for something to fail if it's used uninitialized.

You can see the options specified to the Microsoft compiler listed in one of the Visual Studio tabs. I don't understand the flags though. I also don't know how to set the standard used, though I'm sure I could look that up.

[fegennari]

... And now the warnings are back. At least the 2019 UI makes it easier to hide them.

[fegennari]

I'm closing this issue for now.