Increase FPS by removing sky background about netfox HOT 5 CLOSED

Same thoughts as here - I'm open for discussion, but why are we targeting 240+ fps?

Also the project config itself is limited to 240fps so the game doesn't overheat higher-end PCs that can produce 1000+ fps on the example game.

from netfox.

Since the visual result is the same if not better (by darkening the custom color a bit, they could look identical), while also being simpler and also giving high FPS why not?
Demo projects should have greater than 500 FPS imo. For example, when I tried some personal stresstest gridmap experiments, I didn't get below 500 FPS and that was a good sign to me. Obviously personal preference, but my point is, high FPS for a barebones scene creates confidence in new users who haven't looked into the code. They won't bother looking into the code if they see 200 FPS for this kind of scene. They would subconsciously consider other intense resource processes like Lighting and AI/Navigation, and think it's impossible because of "bad netcoding, must drain a lot of CPU"

so the game doesn't overheat higher-end PCs that can produce 1000+ fps on the example game.

No one will play forest brawl for more than a session, as the reason to play it is to examine the addon in a real project

from netfox.

Since the visual result is the same if not better

I would like to disagree with you on this one. I prefer to keep the subtle gradient in the sky.

why not?

I know this is just a very minor part of your comment, but I would like to mention that since this is an open-source project, I would like to implement things that have a strong reason to be implemented, rather than "why not". This is just in general though, you have provided the argument for solid color skies that I have reacted to above.

Demo projects should have greater than 500 FPS imo.

Sorry but hard disagree. This sounds like an arbitrary metric that does not consider the nature of the project itself in any way. And it's also very hard to actually measure - 500 fps where? To accurately uphold this, you would need a reference HW config ( i.e. min system requirements ) and measure against that regularly. This is currently not feasible for Forest Brawl. What I can deliver in this regard ( and have been delivering so far ) is to make sure it runs well on my current config* even with 4 instances open.

No one will play forest brawl for more than a session

I take it wasn't your intention but this is bordering on rude 🙂 Forest Brawl is an example game to demonstrate how to implement some common mechanics with netfox. And it is implemented strictly as a game, to show examples as close to "real life" as possible, i.e. what you'd normally do in a project you intend to publish as a stand-alone game. So it is meant to be played and it was played multiple times.

Even if it wasn't meant to be played, I don't see any reason to leave the fps uncapped and have people burn precious electricity on running Forest Brawl at 1000+ fps on their 60Hz displays.

To conclude, I thank you for this suggestion, but will not be implementing it as of now. The proposal is a minor change in performance and ( arguably ) in aesthetics, with the latter also being very subjective. Closing issue.

* - AMD Ryzen 5 3600, GeForce GTX 1050 Ti, 16 GB RAM on Linux Mint

from netfox.

I understand all of the above, except one thing which I would like to insist on:

I don't see any reason to leave the fps uncapped and have people burn precious electricity on running Forest Brawl at 1000+ fps on their 60Hz displays.

Literally everyone who would run this project via the Godot editor, would think the framerate being max 240 is because of something in the project being horribly performant. This was my case, where I get 1500+ FPS on empty scenes, 1000 FPS on scenes similar to this, and seeing so low framerate on this scene scared me enough to actually start cutting off basic parts (clouds, enviromental lighting) to figure out if the framerate is so low because of the netcoding or the scene setup.
Another dev would simply see the FPS and exit the editor and look for another addon or try his own version.

My point is, if you can increase the FPS, there is no reason to cap it on the editor, its just bad first impressions, which is an injustice to such netcoding. Cap it freely for non-editor instances, but for the editor its just weird, as forest brawl in the editor is the "selling point" for netfox, the proof of "yes, it CAN work in a real game"
Electricity isn't precious enough to cause misconceptions in developers

Anyway, low FPS for the main demo isn't so important, haven't found any problem with the netcoding (nor do I think I will find, just gotta trial&error for weeks)
I hope none of the above has come off as rude (I am not an english native speaker), I just feel bad to see such a great addon have so few users, and I'm sure the first impressions are related (no video guide, low FPS demo)

from netfox.

Literally everyone who would run this project via the Godot editor, would think the framerate being max 240 is because of something in the project being horribly performant.

Sorry but the "literally everyone" sounds very much like a projection of your own experience, i.e. "everyone thinks so because I think so". That aside, for now I do not plan to attract the kind of people who open a full game, see it "only" runs with 240 fps ( or even 120 ) and think "this is literally unusable, better look for something else".¹

In addition, my experience after multiple years of working on games as a hobby and working on software at work is, that if something is slow, you profile it. Sure you can take a guess at what's slow and what's not, but that's just that - a guess. I'm pretty sure this is a universal notion in most kinds of software development, including games. This is to reinforce my point, that I'd like to attract the kind of users who take a look at what's happening before deeming the addon as unusable. Pretty sure they're easier to support and more joyful to work with 🙂

My point is, if you can increase the FPS, there is no reason to cap it on the editor

It's capped in the project settings, not sure if that applies to the editor itself as well, never measured the FPS inside the editor. The game instances being run from the editor are capped as expected.

the proof of "yes, it CAN work in a real game"

Again, the game running at a ( capped ) 240fps is plenty of proof that the game, in fact, works and is playable.

I hope none of the above has come off as rude

No offense taken 🙂

and I'm sure the first impressions are related (no video guide, low FPS demo)

You may or may not be right, without data we can't know for sure. Although that "low FPS demo" point is really, really contentious to me, but I think we've established that through this convo 🙂 For now, my personal opinion on the usage count ( which I also have zero data on ) is that this is a niche addon with not an overwhelming amount of promotion. Compared to that, I think netfox is really doing well with ~160 starts 🙂 I also have an assumption that if netfox got too popular too fast, I may or may not be able to support it through that transition. So a slow but steady rise is very sustainable for now.

one thing which I would like to insist on

So to conclude, you are absolutely free to insist, which I accept. However, I cannot accomodate that in this project unfortunately. Hope this does not prevent you from building awesome games with netfox!

¹ - I want to be clear just to be safe and note that I do not consider you part of that group, as you are meaningfully engaging with the project, and that is very welcome

from netfox.