InsideQC Forums

I'm looking for an engine fork with a "clean" GL implementation. By clean, i mean without old GL hacks and platform specific-stuff. FitzSDL? QuakeSpasm?

Fitzquake Mark V ? It has a lot of fixes for hacks and some cool features.

frag.machine wrote:Fitzquake Mark V ? It has a lot of fixes for hacks and some cool features.

I was looking for something very minimalist, so it can be used as a starting point for a OpenGL ES 2 port. I tried with vanilla sdlquake, but there's too many ugly stuff to fix/rewrite.

both FTE and DP already have opengles 2 ports.

if you want to make your own port, MarkV is as good a choice as any. enough features for it to still be somewhat usable, and a base that most people trust. As far as I'm aware, the gl changes are optimisations more so than added features, and thus there shouldn't be too much extra code in there that isn't already expected by the average user.

gles2 requires that you gut all the glBegin stuff that glquake uses. that means an almost complete rewrite of any and all code that generates mesh data (2d images, mesh interpolation, etc), this also includes static stuff like surfaces.
however, people targetting gles are generally targetting some awkward system like android or ios where there's a load of system expectations where the single-main-function doesn't really work very well. this can be a problem even with sdl2.



I'd like to think that FTE's renderer is clean in that the backend sees just trisoup and shaders, with texture, video, etc, management also abstracted away.
For instance, fte's software renderer (which is really quite poo) has an entry in fte's 'rendererinfo' array so that the setrenderer command may use it, with almost all of the rest of the code being self contained within the software-specific files. While there is an enum value assigned for it, its pretty much only used to silence warnings about a case value not being specified, and is followed by a break statement in all but one location, although admittedly this means that it does not support realtime lighting.
FTE's D3D11 renderer does include a few extra twiddles in a few places in order for the shader code to use hlsl correctly, as well as rtlights. Sadly such things are quite specific to the backend which will be using it, and isn't particuarly easy to abstract.
Of course, one man's definition of 'clean' can often be different from another man's - I suspect your definition of clean is better expressed with the word 'small'. FTE's GL renderer is far from small, despite the interface the rest of the engine uses to access it. That said, be careful of 'too small' (aka: unusable) - MarkV is probably of a suitable size.

I can't speak for DP, but these are the console commands required to get the win32 or sdl2 port of FTE to attempt to use GLES2 (the glx port does not support these at this time). Whether your graphics drivers/sdl library support gles2 contexts or not is a different matter.
vid_gl_context_es 1
vid_gl_context_version 2.0
vid_restart

Thank you very much, Spike. That information is priceless!

Just complementing what Spike said: since I suspect you're aiming for a minimalist engine, one positive thing about Mark V is that most of (if not all) non-standard stuff can be turned off with an #undef. And even the non-standard features are actually long time requested things like skyboxes, loading external textures, fences, envmap, etc.

Hi all,

I'm looking around for a good starting point for a minimalist engine. I've been trying to get a hand on Tomaz's cleansrc, but my google-fu seems to be failing me. All I'm getting are old quakesrc.org links.

Does anyone have a working link? Or failing that, would anyone recommend a simple engine that can be used as a starting point?

Fitz is pretty much the new standard since it's cleaner and also implements TEH MISSING QUAKE FEATURES glquake never came with. It's proven to be minimalist enough to even be ported to the PSP, and it has mapper features that are the expected supported standard. It's kind of like what Boom is to Doom.

Cleansrc was just GLQuake with the software renderer totally excised. That's not to say it doesn't serve a purpose, it's just that it's not caught up for general usage, and especially not appropriate for the original post since it still has the 97-era graphics pipeline.


I would've also suggested the QIP Engine which is a decent 'bugfix' engine to start a new port with, but then you'd have to deal with all these additional comments which can get in the way of source readability. Not exactly 'clean' by doing that.

What about QuakeSpasm?

Based on Fitzquake i think ?.