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

Textscreen: support for forcing software rendering #1444

Open
wants to merge 6 commits into
base: master
Choose a base branch
from

Conversation

fsufitch
Copy link
Contributor

@fsufitch fsufitch commented Feb 13, 2022

Added a TXT_SetForceSoftwareRenderer function to set a global configuration flag for textscreen, plus support for a TXT_FORCE_SOFTWARE_RENDERER environment variable. Setting either of these has the same effect on how SDL_CreateRenderer is called as the force_software_renderer option in Choco's config does.

Additionally, Setup and Endoom call TXT_Init, call TXT_SetForceSoftwareRenderer as appropriate given the configurations they are operating under.


Motivation for this change: I am using Chocolate Doom on a Raspberry Pi 1A, and while SDL can initialize its regular OpenGL environment, it is excruciatingly slow (0.5-1 FPS) even for something as simple as Textscreen. Forcing it to use software rendering instead of pretending to be a GPU fixes this.

Thus, this change greatly improves support of very low spec hardware.

renderer = SDL_CreateRenderer(TXT_SDLWindow, -1, SDL_RENDERER_PRESENTVSYNC);

if (renderer == NULL)
if (txt_force_software_renderer || getenv("TXT_FORCE_SOFTWARE_RENDERER") != NULL) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This doesn't match coding style

@turol
Copy link
Member

turol commented May 7, 2022

Looks OK other than the code style. Do you want to rebase/squash this into one commit or should it be done when merging?

@fragglet
Copy link
Member

fragglet commented Jun 7, 2022

Is there any reason not to just always use a software renderer for textscreen? It doesn't have the same performance requirements that the main binary has after all. Might be a simpler solution.

@turol
Copy link
Member

turol commented Jun 8, 2022

There was a PR that made the textscreen and main game share the same renderer. How will that be affected by this change or always forcing software renderer for textscreen?

@fsufitch
Copy link
Contributor Author

Is there any reason not to just always use a software renderer for textscreen? It doesn't have the same performance requirements that the main binary has after all. Might be a simpler solution.

This makes a lot of sense. I cannot envision any circumstance where textscreen needs hardware accel.

Looks OK other than the code style.

Sorry, I am very much a Go / Python / Typescript dev, not C. I will fix whatever is going on, but I'm not sure what I got wrong. Hints?

@turol
Copy link
Member

turol commented Jun 23, 2022

Check HACKING.md for coding style documentation. If you rebase this on latest master there should now be a linting CI check that should comment on any style violations.

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.

None yet

3 participants