LÖVE

hdon wrote:I'm saying this is a flaw in LOVE. I do get it.

LOVE is a 2D graphics engine. Not being able to do 3D is a feature. You don't get it. This thread is not about doing 3D in LOVE, it's about doing image distortions so that they can be used for faking 3D for example. One would want to do this when he doesn't want to use OpenGL. You however are suggesting that 2D engines should not exist and that one should use OpenGL?

qubodup wrote:

hdon wrote:I'm saying this is a flaw in LOVE. I do get it.

LOVE is a 2D graphics engine. Not being able to do 3D is a feature. You don't get it. This thread is not about doing 3D in LOVE, it's about doing image distortions so that they can be used for faking 3D for example. One would want to do this when he doesn't want to use OpenGL. You however are suggesting that 2D engines should not exist and that one should use OpenGL?

If you are trying to construe my post as a suggestion to supplant LOVE's emphasis on 2D graphics with OpenGL bindings, think again! There is absolutely no reason not to offer direct OpenGL bindings alongside LOVE's 2D graphics APIs.

As it has been put in another thread

Mike wrote:As we worked on it the focus shifted from providing everything but the kitchen sink to more of making a good system for letting people provide their own features. We were going to have a built-in GUI system (see another thread somewhere on this forum), but people started making their own libraries so it quickly became apparent that building a good TOOL for people to base their work around was better than making it all ourselves (takes less time too).

LOVE's 2D graphics API is currently built on top of OpenGL. Were the OpenGL API exposed to LOVE applications directly, LOVE's 2D graphics API could still be built on top of OpenGL, and it would be easier to modify and extend for one's own apps. So in fact, if OpenGL APIs were exposed to LOVE programmers, LOVE developers could have been doing image deformations already, and there would probably already be a third-party LOVE image deformation API.

Please stop PMing me accusations of "trolling" I'm not doing anything wrong on this forum.

It seems like all you want is a lua binding for OpenGL, but as already stated above, that's not what LÖVE is. (all I have to say, really, I could write a complete essay about this fact, but I'll skip that)

hdon wrote:Please stop PMing me accusations of "trolling" I'm not doing anything wrong on this forum.

I never stop being amused by this forum

hdon wrote:If you are trying to construe my post as a suggestion to supplant LOVE's emphasis on 2D graphics with OpenGL bindings, think again! There is absolutely no reason not to offer direct OpenGL bindings alongside LOVE's 2D graphics APIs.

LOVE's 2D graphics API is currently built on top of OpenGL. Were the OpenGL API exposed to LOVE applications directly, LOVE's 2D graphics API could still be built on top of OpenGL, and it would be easier to modify and extend for one's own apps. So in fact, if OpenGL APIs were exposed to LOVE programmers, LOVE developers could have been doing image deformations already, and there would probably already be a third-party LOVE image deformation API.

This all sounds so right. And one would not even have to do the bindings.

BUT I don't know anything about OpenGL so I'll just shut myself

hdon wrote:Please stop PMing me accusations of "trolling" I'm not doing anything wrong on this forum.

Oh dang, I had 20 more hate-mails waiting in my "drafts" folder. Oh well..

bartbes wrote:It seems like all you want is a lua binding for OpenGL, but as already stated above, that's not what LÖVE is. (all I have to say, really, I could write a complete essay about this fact, but I'll skip that)

Well, as I said, this isn't how FOSS tends to operate. Be prepared for forking...

EDIT I just thought of a good reason not to expose OpenGL APIs. I can't say for whom this is a good enough reason and for whom it isn't. I'm not even sure how I feel about it, but here it is anyway: I thought I read someone wishing for a LÖVE port for Nintendo DS, a platform without an OpenGL implementation. If LÖVE plans on running on such platforms, using some other graphics abstraction, then, would be quite prudent.

Whoa, whoa, WHOA.

If you want to use 3D in LÖVE, you are not using the right tool for the job. It is unlikely that I will devote my time to do "fake" 3D in LÖVE; I consider the fact that people attempt to use 3D on top of LÖVE ironic and amusing, but nothing more. (Sidenote: as far as I can tell, those who've made full 3D apps on top of LÖVE have done so just to gain understanding in how 3D works.)

This is a 2D engine/framework/library, and it will stay that way. I understand that people want to do 2.5D games in LÖVE (and I do not oppose it!), but I don't want the engine focus to shift in that direction.

The GTA effect OP is trying to achieve requires (unless I'm mistaken) perspective transformations to be done properly, i.e. "full" 3D. Generally, if it requires perspective transformations, then you should use another engine/framework/library.

Why not expose OpenGL fully? Abstraction. Learning curve. API size.

Motto proposal: Orthogonal or GTFO.

rude wrote:Why not expose OpenGL fully? Abstraction. Learning curve. API size.

You can provide more than one programming abstraction. OpenGL is deliberately designed to be very compatible with combining multiple programming abstractions. Citing learning curve is a false argument for a similar reason. API size? Uh.. well.. would you also argue that you shouldn't add a file I/O API because the graphics API is already too large? I don't understand how completely orthogonal APIs can be counted together in any way.

Honestly I think Love could easily include the 3D layer, but it's a pain in the ass and the neck to code and I wouldn't wish it upon rude. I want him to WANT to update love, not look upon it as some Herculean task. There are plenty of 3D applications out there that seamlessly blend 2D and 3D easily enough. Let them be the ones you use. I like Love because it's just a 2D engine. I don't have to worry about dark and draconian calls to OpenGL or SDL. It Just Works.

My personal motto is K.I.S.S.: Keep It Simple Shithead / Stupid / Silly

Whatever your choice.

Don't forget that whatever I say immediately becomes a fundamental truth in the Universe.

For starters: 2 + 2 = 5

I am for exposing more low-level stuff in OpenGL, but it needs to happen selectively, and it must be properly abstracted, wrapped and polished. Vertex buffers are coming in the next version, for instance.

hdon wrote:OpenGL is deliberately designed to be very compatible with combining multiple programming abstractions.

The point is abstraction of the entire graphics subsystem; right now we're using just OpenGL, but Windows will probably use Direct3D in the future. The more details we expose from one API, the harder it will be to create a backend using the other. This is why components must be kept at pretty high level (for now), and also why we can't just do a 1:1 wrapping of the entire OpenGL interface.

If love should run (one day) on mobile devices, you also have to think of OpenGL ES.