Open GL - Yes/No

[Jebbs]

Allowing the usage of OpenGL was debated before the first jam took place, but since we needed a definite decision for the final set of rules I ultimately decided that we should allow it. I know this was a little confusing for some and caused a bit of controversy, so sorry for that. I want to bring attention back to this topic and decide with a vote this time.

As a refresher, some reasons for OpenGL were that since OpenGL integration is an easy thing(there is even a tutorial for it) it should be allowed, plus my own reason was that I would hate to limit the jam to just 2D.

The big reason against its usage were that it isn't a part of SFML itself and thus it defeats the purpose of the jam being dedicated to SFML.

Feel free to continue the discussion if you have other reasons for/against, or if I missed any! I'm not sure how long to leave the poll open for, so for now it is open for the foreseeable future.

[Ixrec]

My meaningless two cents:

The idea of rejecting OpenGL entirely because it's not really part of SFML sounds as silly to me as rejecting the use of audio because OpenAL-Soft/libsndfile aren't really part of SFML, or rejecting the use of the image formats that libjpeg/stb_image/stb_image_write support, and so on.  So I'm definitely in favor of allowing it.

What would seem reasonable to me is rejecting any program that just creates a window with SFML, then does absolutely nothing else using SFML itself.  In that case the game could be effortlessly "ported" to SFML's competitors and probably would behave exactly the same (right?).

Since I saw open source in the requirements already, it should be pretty obvious if someone does that, and I can't imagine anyone would want to do it anyway since it's so easy to use SFML for handling user input and loading music/fonts/images as well as creating the window, even if the actual graphics are all OpenGL.

[Jebbs]

The idea of rejecting OpenGL entirely because it's not really part of SFML sounds as silly to me as rejecting the use of audio because OpenAL-Soft/libsndfile aren't really part of SFML, or rejecting the use of the image formats that libjpeg/stb_image/stb_image_write support, and so on.  So I'm definitely in favor of allowing it.

I don't know if that's the right way to look at it. While all of those are external libraries, they are still a part of SFML as a whole, and while the same could be said of OpenGL, drawing in an SFML window with raw OpenGL is not a part of SFML. That's where the debate comes into play.

[Ixrec]

Yeah, personally I don't see a meaningful difference there.  Maybe that's just me.

[Nexus]

Instead of continuing the old discussion, I'll just post the most important points against the use of OpenGL:

• It is called SFML Game Jam, there are tons of other game jams where OpenGL is allowed.
  
• We can push the library and demonstrate what is possible using SFML alone, including its Graphics module.
• By restricting to SFML, we have a clearly defined scope that matches the community. There is no confusion about OpenGL versions or extensions. Results are more comparable if the same technology is used.
• Users will learn to be creative with SFML, new techniques or best practices might emerge.

There are many libraries that provide access to OpenGL, SFML is in no way specific here. In order to push SFML, one should focus on the strenghts and the differences from other libraries. Among those is the Graphics package, which allows very efficient high-level and low-level access to graphics. It's probably the most often used module, and with its clean API it is the SFML flagship; not using it would be a missed opportunity.

[Grimshaw]

Just my 2 cents on the topic. I believe that if any kind of 3rd party unofficial code is used in the jam, OpenGL should be allowed to.

I mean, if no engines or libraries made by the user are allowed, the OpenGL should be constrained too. If the purpose of the jam is to exploit SFML capabilities to its fullest while getting creative, then using only the SFML API's is the only thing that makes sense. If you are allowed to expand on SFML with libraries and tools, it also makes sense to use OpenGL, even if as a means to achieve more kinds of drawables, a perfectly valid extension to what SFML already provides.

[Nexus]

I think it's different whether you expand SFML on a higher level (using Wiki codes or libraries like Thor) or on a lower level (using OpenGL), because the former are still purely based on SFML technology -- they provide only an abstraction layer that the user could as well build himself.

But this is another point that should be discussed; the rule "You only have 72 hours to create [...] the code [...] of your project" is not clear here. Forbidding higher-level libraries is not really a solution, since users can still copy their implementations and modify them slightly. Furthermore, it encourages reinventing the wheel, instead of focusing on unique art, style and gameplay.

[eXpl0it3r]

Instead of discussing about OpenGL directly, one might want to think about, what makes this jam The SFML Game Jam?
If we just say "you have to somehow use SFML", it would be enough to link against SFML System and somewhere use a sf::Vector2<T>, but is that really what we want the SFML Game Jam to be about? Don't we want to make people use the full power that comes with SFML?

With that said, it's kind of use less to let people use OpenGL in any way they want. Because it would be perfectly fine to link against the System and Window module, to create a window and handle some events, but leaving all the graphics to OpenGL, thus defeating the purpose of utilizing SFML to its full extend.

Given that OpenGL is some important addition to the rest of SFML I understand the argument of allowing OpenGL, but as listed my argument above, the usage must be restricted and defined (i.e. switching out sf::Window and sf::RenderWindow still doesn't make you "use" SFML's graphics module). Either that or disallow it completely.

I don't agree that if OpenGL should not be allowed all the other libraries shouldn't either. There's just a difference between having to write a JSON/XML parser and using SFML to draw a rectangle or OpenGL to draw a rectangle. For a parser you'll need a lot of time to implement it and are essentially just reinventing the wheel again, where as with the rectangle you'd explicitly opt for something SFML already provides functionality for. So maybe the use of libraries that replace SFML's functions should be disallowed.

This of course then puts libraries like Thor and SFGUI in question. For Thor I don't see any problems, because Thor builds directly on top of SFML's function (afaik), so you'd still be indirectly using SFML.
For SFGUI the question is a bit harder. They are also using parts of SFML, but also utilize OpenGL. Personally I'd allow to use of it, because SFGUI currently can't function without SFML and the functionality of creating a GUI is not included in SFML, so you won't be replacing anything from SFML.

So my conclusion would be:

• OpenGL can only be used as addition to SFML's rendering.
• Everything that can be done with SFML, should be done with SFML - no replacement libraries.

[AlexxanderX]

Me too I agree with using OpenGL but should pe a category of pointing in the SFML Jam wich will point how much you used SFML.

[binary1248]

I think the problem can be reduced to the problem of determining what the purpose of the SFML Game Jam is. If it is as some say to showcase the capabilities of SFML, then I would not allow OpenGL usage, since this would allow detours (shorter or longer) around SFML's graphics API. If part of the "capability" of SFML is it's interaction with OpenGL then this becomes a harder problem. In that case I wouldn't mind seeing people use OpenGL alongside SFML to get things done, as long as whatever can be done in SFML is done in SFML (no glBegin(GL_QUADS) etc.). This means that the fact that you are allowed to use OpenGL is there to not limit you in your creative freedom, nothing more, nothing less. The last thing we want is people lamenting how they were "limited" to using SFML only for their graphics, which might even detract people from even taking part.

A good analogy would be an artist's paintbrush. SFML takes the basic paintbrush and makes it much easier for children to use, while at the same time limiting it's usability to use cases that cover 99% of all children. If you were to make a commercial promoting this paintbrush, you wouldn't expect to see a famous artist using it to paint their masterpiece would you? That would not promote what it was meant for, and to be honest, the artist also wouldn't be crazy enough to limit themselves to something like that . On the other hand, if you watch an artist paint a masterpiece and notice this paintbrush in their collection as well, it also promotes the paintbrush albeit in a completely different way.

SFML is a multimedia library, you can promote its usage in many other ways than just its graphics API. If you ask me, using SFML for window, event and context management is enough to label something as an "SFML application". It is probably the only thing you can compare SFML to its competitors by anyway.

And on a side note: showcasing SFML's integration with OpenGL 4.3 features is more challenging than many people think, even more so than getting things done using pure SFML. Whoever can get an SFML application done that doesn't use deprecated functions and a lot of 4.3 functions within 72 hours will receive my utmost respect . Oh, and the tech demo might also open SFML up to a more "serious" audience... just saying...

[FRex]

Yes.
No one is probably going to use it anyway and you are having analysis paralysis over it.
GLUT and GLFW(and most libs) are competitors of SFML in the area of input, context and windowing, not 2D(like SDL).
Also GL is not 'other library', SFML needs it, you can't run SFML without it, just nope, and it's not made into implementation detail, it's exposed for you. Something like DirectX should be (obviously ) not allowed, even though it has D3D since this is jam for cross platform GL based library and DX has nothing to do with it. Also things like IrrKlang, Irrlicht, Ogre, Horde, etc. should not be allowed because they replace part or all of SFML functionality, but have nothing to do with it. Thor, TGUI, SFGUI, CEGUI etc. should be allowed, even if they use GL, because you are not 'rendering' something, they are not 'renderers', they get you something very very specific rendered to a context, you can't build a game on that kind of graphics(unlike  building a game on Irrlicht, which can render arbitrary things). Something like 'personal codebase 3D renderer' might in theory come up(probably won't) and that probably shouldn't be allowed because someone like Nikolaus Gebhardt could come here and mop the floor with us all using entire 'personal, written by him' Irrlicht with custom irr::IrrlichtDevice that uses sf::Window for window, context and events.
So: OpenGL - during jam - yes, in the codebase for use with jam - no(maybe, if you're paranoid.. that or some looser rule that you can't bring in entire custom renderers in).
Also:
If someone replicates 2D API they just screwed themselves majorly on time unless they are extremely good programmer.
If someone goes 3D they just screwed themselves on time or are very good artist/designer and programmer and will pull through with high quality or stylized assets and alright game(play).

So OpenGL goes one of two ways in both 2D and 3D:
- total suicide timewise, might as well give up on submitting
- super skilled competitor, good PR for SFML that they even used it

glBegin(GL_QUADS)

90s called and they wanted their immediate mode API back.

[zsbzsb]

Yes
It should be allowed, but within limits as stated above. Everything that can be done with SFML should be done with SFML and OpenGL specific code not covered by SFML should be allowed. Also in 3D games SFML should be used to draw something other than being just the window manager.

Anyone reading this scroll to page 2 for my latest thoughts

[Jebbs]

Well, I don't think we'll be getting much more feedback on the subject. It looks like it was pretty close though. Based on the voting and what some of the people have said I am proposing the following changes to the rules.

Rule 5 get's changed to: "External libraries are allowed, but not SFML's competitors, such as GLFW, SDL, Allegro, etc."

And we add a new rule after it stating: "Everything graphical that SFML is capable of must use SFML. OpenGL is only allowed for things that are outside the capabilities of SFML's graphics package."

Exact wording is subject to change.

[FRex]

"Everything graphical that SFML is capable of must use SFML. OpenGL is only allowed for things that are outside the capabilities of SFML's graphics package."

= Goodbye SFGUI cus of GL renderer?

[MorleyDev]

Honestly, I think people are making this into a bigger deal than it is. It's a Game Jam for making games and having fun, and it's the SFML Game Jam. People who join are, on whole, gonna be using SFML. To make games. In a jam.

Really, if you have to do something maintain a "spirit of the jam" clause and reserve the right to penalise games that are felt to have broken that spirit.