Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[rlgl] Added a way to get information about the amount of draw calls #4600

Closed
wants to merge 1 commit into from
Closed

Conversation

gk646
Copy link
Contributor

@gk646 gk646 commented Dec 14, 2024

Non invasive way to get information about the amount of draw calls made during each tick.
Its under the custom frame control features as its done automatically per default if no custom frame control is chosen.
Accessor exist so it can be adapted to custom frame control

its under the custom frame control features as its done automatically per default if no custom frame control is chosen
accessor exist so it can be adapted to custom frame control
@gk646
Copy link
Contributor Author

gk646 commented Dec 14, 2024

What would be the use case of this call (besides debugging)?

Also, I don't think this should be called by default on the standard frame control. It's non-essential and most use cases probably won't have an use for it.

Well its just information you should have access to if you want. Its good for checking how many draw calls are made in different setups (using atlas vs none, ...).
It just in the default so it can be accessed easily and works right out of the box.
Many things you dont usually need that are more expensive are done in there aswell (Automation events, gif recordings).
But it would be fine just to add it to rlgl.

@gk646
Copy link
Contributor Author

gk646 commented Dec 14, 2024

I just think that its information a rendering abstraction should expose in an official way.
Also were arguing over two integer assignments. It will just be inlined. Those are 2 cpu cycles.
If your modifying defines you most likely also know enough to remove the call if you want to.
As raylib is also aimed towards newcomers, most users will not change the default defines.
Also the impression I got from working with raylib is that it doesnt optimized single digit cpu cycles if you get a valid new feature.

@raysan5
Copy link
Owner

raysan5 commented Dec 15, 2024

@gk646 I'm afraid I agree with @asdqwe mentioned points, most users don't need this function and it implies adding more globals, new functions and calls on rcore module. Also, this function seems to only consider draw calls accumulated on batching system, models drawing issue independent calls and depending on user code there could be more variables involved (like forcing batching flush). Users requiring this data, would probably also require VRAM memory usage and probably way more.

At this point I prefer to avoid exposing it.

@raysan5 raysan5 closed this Dec 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants