FIFE forums

Please login or register.

Login with username, password and session length
Advanced search  

News:

FIFE 0.4.0 has been released on 15th of January, 2017!

Author Topic: Some renderer improvements  (Read 1455 times)

vdaras

  • Developer
  • Newbie
  • *
  • Posts: 3
    • View Profile
Some renderer improvements
« on: March 12, 2013, 10:39:42 am »

Hey guys, just wanted to share with you some ideas I came up with for improvements to FIFEs renderers.
  • Ability to render rotated and scaled images (SDL renderer could do that with sdl_gfx library with an increased overhead since transformations are done in the CPU)
  • Allow rendering of textures with shapes other than rectangle. Could be used to improve how librocket interfaces with the renderer and allow a CE::GUI custom renderer that doesn't use direct OpenGL calls.
  • Lighting effects. Could increase the engine's appeal by a vast amount.
  • Enable OpenGL renderer to use shaders. KILLER feature imho but the renderer would need an overhaul. Maybe we could leave the old renderer intact and create and OpenGL3 renderer (?).

Discuss :)
Logged

prock

  • Developer
  • Full Member
  • *
  • Posts: 236
    • View Profile
Re: Some renderer improvements
« Reply #1 on: March 13, 2013, 08:44:21 am »

Hi Vdaras,

I really like the idea to allow for rotated and scaled images (rotated especially).  Rotation unfortunately is a term we already use in FIFE (instance rotation for example).  This would have to be addressed before image rotation could be introduced however.  The coordinate systems are already confusing, I'd hate to introduce more confusion here.

Allowing for rendering other types of geometry would be a huge improvement over what we are doing now.  I'm guessing you are mainly hinting toward allowing for batch rendering of geometry with one call?  Triangle lists for example.

What sort of lighting effects do you have in mind?

Shaders are a must in this day and age.  We should probably consider implementing them after the renderers get re-worked and we are finished consolidating them.  This would probably mean we should think about adding more capabilities to the DeviceCaps module to allow for more detection of the cards OpenGL features (currently it only does SDL features).  I'd hate to force users to modify config file values for all these things, we should do more auto-detection!  Actually the device caps module doesn't sound like a bad starter GSoC project.  hmmmm...

That's all I have for now.
Logged

helios

  • Developer
  • Jr. Member
  • *
  • Posts: 60
    • View Profile
Re: Some renderer improvements
« Reply #2 on: March 13, 2013, 11:12:28 am »

Hey all,
you can already scale/resize images on runtime, with Opengl and SDL. It isn't very intuitive but works. The rotation thing is more complicated, as prock said, it could lead to confusions. I'm not sure if it's really worth the effort.

The batch rendering is able to work with different geometry tyes (point, line, triangle, quad,...), but textures use internally always a quad. You could create another version of addImageToArray() which internally uses triangle or triangle stripe. But in general, there should be more types, for example FIFE still missing the opportunity to render circles (filled/unfilled).

Well, lighting effects... FIFE have a LightRenderer which uses blending. You can add Images, Animations or create a light primitives (use renderbackend drawLightPrimitive()), also you can change the blending modes and add stencil buffer tests. The "downsides" are that the lights are additive and the z ordering is not right because it has its own renderer (is called after the InstanceRenderer). Rio de hola have a simple demonstration of global light and light primitives. (enable lighting in the settings and press 1/2 and 4/5)

I fully agree that shaders would be a great feature for FIFE. I had implemented a basic shader support a few years ago. But there were too many other problems so I stepped away from the idea. (those were the times in which we have used immediate rendering)

Quote
I'd hate to force users to modify config file values for all these things, we should do more auto-detection!
We do it with glee in the backends, the problem is more that (especially for ATI/AMD cards/drivers) the detection failed. The settings are meant as fallback for these cases. But of course it would make sense to query other things, such as maximum texture size, max color attachments and so on.
Logged