Skip to content

Instantly share code, notes, and snippets.

@dpogue
Last active August 29, 2015 14:04
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save dpogue/7b8e6b4ee002ddb60e19 to your computer and use it in GitHub Desktop.
Save dpogue/7b8e6b4ee002ddb60e19 to your computer and use it in GitHub Desktop.

plGLPipeline Status

Disclaimers

  • It only works in Linux, in X11, possibly only with mesa drivers
    I'm using EGL to get a OpenGL (non-ES) context, which is minimally supported. I don't think I'm using any non-ES stuff though, so switching it over to grab a GLES2 context should be fine if that makes it easier for people to work on. I am running nouveau drivers, since the proprietary nVidia ones don't support a GL context through EGL.

  • A good chunk of the codebase is disabled
    There's a MINIMAL_GL_BUILD macro that disables a lot of non-essential creatables. In particular, it causes SceneObjects to ignore modifiers, SceneNodes to ignore Generic Pool objects, and Materials to ignore layers (because plSDLLayerAnimation wanted to pull in ridiculous stuff).

  • The focus is solely on the renderer
    It's tempting to try to hook up modifiers and input core and cameras and audio and try to get to a point where it feels like a game again, but the focus right now is purely on being an accurate renderer for Plasma data. In the future, I'd like to be able to build in Blender and use some minimal version of this to accurately preview what it will look like in-game.

Code Structure

Originally:

hsKeyedObject ----> plPipeline ----> plDXPipeline

Now:

                                                 ,----> plGLPipeline
hsKeyedObject ----> plPipeline ----> pl3DPipeline
                                                 `----> plDXPipeline

pl3DPipeline is a semi-generic class that handles the majority of the data passing to/from data classes, helper classes, and pipeline internal helpers. The two subclasses provide a way to override default behaviour where needed.

pl3DPipeline has a fDevice member which is a pipeline-specific class that does most of the real work at getting stuff onto the screen. Note: There is no shared base for these device classes, but it is strongly recommended that the exposed API for both be consistent.

plGLPipeline is mostly empty stubs or very minimal implementations right now, although the very bottom of the file contains the code to render stuff to screen (which should really belong in the device, but it was 4am and I just wanted to see something on the screen).

plGLClient

plGLClient is a minimal hacky plClient clone for X11. It loads a hardcoded Age by name and positions a camera in the world (also hardcoded).

What works

Well... it draws geometry with vertex colours.

Next Steps

Phase 1 (Geometry)

  • Figure out why some geometry isn't showing up
  • Verify working vertex colours (including alpha)
  • Maybe hook up some wireframe overlay mode for debugging?

Phase 2 (Materials)

  • Load textures and render with the base layer's texture on the correct UVs
  • Get the vertex colours + layer colours + texture colours calculations figured out
  • Deal with multiple layers (with no complex blending)
  • Deal with the crazy shader stuff needed for complex blending
    (I was looking at Blender to see how they do their 3D View shaders, and it seems like a decent architecture for generating runtime shaders)

Phase 3

  • Real-time lighting
  • Fog
  • Particles
  • plShader-based stuff like wavesets

Phase 4

  • All the non-renderer stuff
  • Fancy new shader effects
  • vast landscape with hours of unique gameplay
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment