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

Add OpenGL ES 1.1 support to opengl1 renderer #375

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

zturtleman
Copy link

@zturtleman zturtleman commented Jul 10, 2018

I added support for OpenGL ES 1.1 to the opengl1 renderer. This is loosely based on the OpenPandora port by ptitSeb from PR #14. Using OpenGL ES API is chosen at run-time based on SDL default GL context type or forced with r_useOpenGLES cvar. There is a single renderer_opengl1 dll.

I've made opengl1 be compatible with OpenGL ES when possible or check if ( qglesMajorVersion >= 1 ) or use wrapper functions for incompatible OpenGL ES functions (glOrtho(double) vs glOrthof(float)). This is my preferred method and how I'd like OpenGL ES 2 added to the opengl2 renderer.

Is this an acceptable way to add support? Or is it preferable to use a separate renderer_opengles1 dll with GLES ifdefs or separate copy of code/renderergl1 altogether?


Tested and works on Raspberry Pi 3b running Rasbian Stretch. Build and install SDL2 from source, compile ioq3 using make, run using ./build/release-linux-arm/ioquake3.arm +set cl_renderer opengl1.

@zturtleman zturtleman force-pushed the opengles1 branch 3 times, most recently from 45de4bc to b1943b8 Compare July 24, 2018 04:25
@BidyBiddle
Copy link

What are the cons of adding the ES support the way you suggest it? It seems a lot easier than needing an extra dll with users then needing to tweak their renderer preferences then.

@zturtleman
Copy link
Author

I think the cons are mainly related to maintenance and diverging farther from the original renderer.

It kind of depends what purpose opengl1 serves now that the opengl2 renderer is the default. If it's just suppose to be a reference implementation for accurate rendering and simplest rendering code for reference when creating new renderers then it may not be a good idea to add additional complexity of OpenGL ES 1 and possibly introduce behavior changes.

Other quake3 engine projects (iortcw, ET:Legacy, ...) seem to use separate renderers dlls. Ensiform has voiced opinion against combined ES1 renderer in ioq3 (#14). The main reason I was in favor of combined gl1/es1 is that I didn't want to maintain three (or four if ES2 is separate) renderers x2 (ioq3 + Spearmint). (That point is somewhat void as I intend to stop maintaining ioquake3.)

Related: Unfinished ES2 support for the opengl2 renderer. It works but slow on Pi 3b with Raspbian Stretch so may have some big issues. master...zturtleman:opengl-dev

This is loosely based on the OpenPandora OpenGL ES port by ptitSeb.
Some of the changes were backported from the opengl2 renderer.

It runs faster, at least on modern hardware, and is requires for
OpenGL ES support.

r_primatives cvar values 1 and 3 still use glBegin as they have to use
it by definition.
This requires my previous commit to use vertex arrays instead of
glBegin() (loosey based on ptitSeb OpenPandora port).

There isn't software gamma correction so overbright may not work (as is
already the case for windowed mode on GNU/Linux).

Enabling unsupported cvar settings (see README) automatically displays
a warning and disables the cvar.

r_useOpenGLES cvar controls whether OpenGL or OpenGL ES API is used (see
README). It's not achived to avoid it being saved in mods, as there is
no way to have a global cvar.
@zturtleman
Copy link
Author

Rebased, fixed conflicts, and updated README and default context for re-adding support for OpenGL 1.1 ( 350b8f9).

Converting RGBA image to 2x2 RGB had wrong row alignment. Add image row
padding support for 2x2 RGB and non-power of two images (not used by
opengl1 renderer).
@tomkidd
Copy link
Member

tomkidd commented Dec 19, 2020

What was the last word on this?

I've used the changes from this branch in my iOS/tvOS port of Quake 3 and it works great. I've been getting the macOS Xcode project for ioquake3 up to speed (less important than the Makefile but still neat to have) so I thought it would be cool to add iOS and tvOS targets in there too for official mobile support, so one workspace can build all three but for this to work they'll need to support GLES as well.

Perhaps, for the goal of making sure the original code is in there for reference purposes, we could use something like a preprocessor directive to allow both versions of the code to coexist in the like 10% of code where things differ.

@zturtleman
Copy link
Author

It stalled due to lack of feedback. I thought about wrapping this in #ifdef GLES_COMPAT recently when considering merging this into some other projects. Partially because it's not in ioq3 —it may help with merge conflicts and may be easier to upsteam modified version later— but I'm not really opposed to it in general. Though I haven't looked through how much of a nuisance/ugly it will be to #ifdef the new and original code.

Base automatically changed from master to main February 10, 2021 09:26
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.

3 participants