FFP Software Rendered Graphics Engine

WIP games, tools & toy projects
#41

FFP operates in a fashion that’s very similar to OpenGL’s fixed function pipeline, in fact I named it FFP (fixed function pipeline) because of this. I’ve never used LibGDX so I’m not sure what it has and what it needs but I’m sure it can’t be hard. The engine already has FBOs essentially since you can point the engine to using a certain render target whenever you need. For VBOs, you can wrap the ffpVertex() function calls with the functionality of VBOs. Since this is a software renderer, there is little overhead for calling ffpVertex() and thus VBOs being integrated into the engine itself wouldn’t provide much of a performance boost.

I’ll definitely look into LibGDX, you’ve got me curious now :stuck_out_tongue:

About the shaders… I’m not sure how I could implement them, or if I would even want to implement them. I avoided shaders because I feel like they should remain as a hardware accelerated feature. The processing needed for a shader is not convenient for a software renderer and any features that need to be added using shaders are probably not going to run fast on the CPU anyways. The fixed function lighting in the engine is as realistic as I could make it and it’s as fast as I could make it.

#42

It would be a challenge, but you could probably replicate the shaders functions in java, the hard part is taking in inputs and outputs and probably compiling the shader to java.

Basically you’d have a simple shader wrapper class, that takes raw shader lines in a string array then just fill up a list of functions that operate over a given list of values (float, texture sampler, ect.) then companion classes per every shader function (ShaderFuncTexture2D, ShaderFuncMix, ShaderFuncSin…)

You’d do blending, depth testing and the clipping or whatever, but the possibilities of having a GLSL function on the CPU oh boy!

It’s a challenge but how awesome it would be to run any any libgdx game on the CPU and have it work 1:1 (or 1:crappy shader interpreter in this case)

#43

Right, but the software renderer is already struggling to keep up most of the time and adding shaders to it would make it run at awful frame rates. Do you understand what I mean?

#44

I understand, I guess you could go without shaders, and just set material properties similar to glColor and glLight… LibGDX’s “Environment” seems like a good place to derive that info

Also check out LibGDX’s backends on github, that might have all the info you need to port it:

EDIT: It looks like libgdx is completely open to any kind of backend, if your engine operates somewhat like OpenGL it shouldn’t be any trouble!

#45

They have interfaces for GL20 and GL30. I can’t find anything for < GL20

#46

Hmm, I’ve always assumed LibGDX’s GL20 interface contained the fixed function methods from OpenGL 1… But you can get away with porting most of the stuff from GL20 like VBOs and FBOs then filling in the stuff for the shaders and textures.

Idk if it’d be worth it, but libgdx has some great 2D/3D utils your engine could use.

#47

Updated main post. I created a website for the engine. Everything you want to know about it is there.
http://miremadi.com/code/wsite/index.html