IMO sticking with SFML for now would be the best, but we could always
write the code in a way that allows for changing it later on.
On Sun, Oct 15, 2017 at 3:43 PM, Chris Jacobsen <cjj_009(a)yahoo.com> wrote:
> with the programming language topic sorted out, on to the next
> the base dependencies. I have originally thought about using raw OpenGL
> (v3+), but have -- correctly -- been met with opposition from
> kirbyfan. I would really like to have some OpenGL experience, but I have
> meanwhile come to the conclusion that TSC is not the correct place for
> that if it ought to go anywhere anytime soon. Given my limited amount of
> time available, doing everything from that far down is
> problematic. Thanks to kirbyfan for putting me back on track. I will
> practise elsewhere.
A possible compromise is to go ahead and do SFML for now and look at
rewriting the renderer in modern OpenGL with shaders later.
There is nothing inherently wrong in wanting to use a project to gain
more experience with a technology. I also like the idea of using TSC to
implement modern OpenGL, eventually.
However, we do need to get something running for now, given the large
amount of code that needs to be rewritten. If we think we will replace
the SFML code eventually, we just should not spend excessive time over
architecting our solution with it.
Super Tux Kart eventually forked their own renderer in order to meet
their needs. I'm sure we can find interesting uses cases in a custom
rendering system. Some of the code SFML provides for rendering is
pretty boiler plate, but, again, there's nothing wrong in wanting to
implement it ourselves, eventually.
Yoko Shimomura, ryo (supercell/EGOIST), Hiroyuki Sawano >> everyone else