FFP Software Rendered Graphics Engine

[TGStudiosDE]

Oh Okay I will try the method with ASCII but are there any tutorials or Introductions for the BSP trees ?

[Archive]

Oh Okay I will try the method with ASCII but are there any tutorials or Introductions for the BSP trees ?

Yeah there are plenty, but the good ones are in the corners of the internet.

http://www.luki.webzdarma.cz/eng_06_en.htm
This one is in java v
http://www.theparticle.com/applets/geometry/BSPSlidingCollisionFlightBox/index.html

[TGStudiosDE]

I tried out your Engine with the ffpVertex3f Calls so the Immidiate Mode and its very slow and I have low FPS.I have some Questions to your Engine:
1. How can I load OBJ Models ?
2. How can I use OpenGL 3 Functions like glDrawArrays or something ?

But the Engine is very easy to use and when I work longer with it, I think it would be good so build some Games

Games published by our own members! Check 'em out!

[Coldstream24]

You could probably roll your own .obj loader I have also seen libraries available that do that as well, but interoperability with FFP might not be there.
From memory, @Archive implements OGL 1.1 spec so there wouldn't be many (if any at all) OGL 3+ functions? Correct me if I'm wrong

Also @Archive, it looks like it's going really well. Keep up the good work!

[TGStudiosDE]

Okay then I must try to roll my own OBJ Loader and with the not available OpenGL 3.3, I dont know that

[Archive]

@TGStudiosDE, The engine is not a hardware accelerated engine. It's an emulation, for the most part, of OpenGL completely on the CPU, so you shouldn't expect speeds anywhere near hardware accelerated graphics. I think this is a good thing because it forces you to write good, efficient code. Also, I recommend using resolutions of 640x480 or under if you want speed. This sounds like a low resolution already but understand that modern games only NEED high resolutions because the detail in their games require that much resolution. In low detail games, the graphics look perfectly fine in resolutions as low as 640x480 or even 512x384.

As for the OBJ loader. I do have one for this engine
This is what I currently use, a bit stripped down though.
http://www.mediafire.com/file/9fk3meayy7vb24l/obj.zip

and yes, @Coldstream24, this is OGL 1.1, there are no vertex arrays and I didn't even implement display lists because the speed wouldn't be too different since this is a software implementation. And thanks!

[TGStudiosDE]

Oh okay thanks I will try this OBJ Loader and try to build some Scenes with the Engine and also try to draw some Text out and some other things

[Coldstream24]

I feel like a good project to undertake with this engine would be to port Doom to it.
Seems like a suitable rite of passage

[Archive]

I feel like a good project to undertake with this engine would be to port Doom to it.
Seems like a suitable rite of passage

Nah doom doesn't take advantage of a 3D engine. Quake is more fitting. And that's similar to what im doing with my game already

[Ecumene]

Id love to dig into the code, but its probably better to ask here..
If this operates similar to a graphics pipeline like OpenGL's Fixed Function how hard would it be to turn it into a LibGDX backend? Maybe simulate VBOs with actual arrays, FBOs with images..
I'm not sure how shaders would work, but It would be really cool to have any libgdx game run absolutely anywhere.

Games published by our own members! Check 'em out!

[Archive]

Id love to dig into the code, but its probably better to ask here..
If this operates similar to a graphics pipeline like OpenGL's Fixed Function how hard would it be to turn it into a LibGDX backend? Maybe simulate VBOs with actual arrays, FBOs with images..
I'm not sure how shaders would work, but It would be really cool to have any libgdx game run absolutely anywhere.

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 :p

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.

[Ecumene]

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.

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)

[Archive]

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.

...

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?

[Ecumene]

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?

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:
https://github.com/libgdx/libgdx/tree/master/backends

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!

[Archive]

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

[Ecumene]

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.

[Archive]

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