Internal Architecture Improvements

[alxs]

I don't see why all the panic?

First, the plugins will not be for "general dumb users". They will be developed by Love Development Team and by those, who really need some non-standard, fast functionality.

About being cross-platform. I don't get it. Do you mean that if we move code from "drivers" into EXE it will somehow automatically become cross-platform???

Someone still have to sit and port the code, or write the same code for the different platform. There is absolutely no difference, whether the code in question is inside or ouside EXE.

--
Plus most options will have reasonable defaults, so the end-user will not even need to know about drivers.
--

P.S. And I want to state one more time (I think I said it already) - this thread will not affect end users, so it is not for users. It is internal Love engine stuff.
For users there is the Feature Request thread.

[Merkoth]

First, the plugins will not be for "general dumb users". They will be developed by Love Development Team and by those, who really need some non-standard, fast functionality.

Hmm, so what?

About being cross-platform. I don't get it. Do you mean that if we move code from "drivers" into EXE it will somehow automatically become cross-platform???

(1)

Someone still have to sit and port the code, or write the same code for the different platform. There is absolutely no difference, whether the code in question is inside or ouside EXE.

The problem is not having the code in external libs, the problem is the kind of drivers you're proposing. So, instead of using, let's say, sdl_mixer to take care of sound, you write one audio driver per platform? The same can be said of input, for example. I do agree on the OpenGL/Direct3D separation, for obvious reasons (poor OpenGL support in most consumer-grade PCs).

P.S. And I want to state one more time (I think I said it already) - this thread will not affect end users, so it is not for users. It is internal Love engine stuff.
For users there is the Feature Request thread.

(2)

(1, 2): No wonder why people tells you to fuck off. Don't bother answering this post, I can't have a serious discussion who doesn't have any kind of respect. I'm outta here.

[alxs]

The problem is not having the code in external libs, the problem is the kind of drivers you're proposing. So, instead of using, let's say, sdl_mixer to take care of sound, you write one audio driver per platform?

I don't propose any kind of drivers. You want to write SDL - fine. You want to add DirectX for Windows platform - fine. That's the point.

No wonder why people tells you to fuck off. Don't bother answering this post, I can't have a serious discussion who doesn't have any kind of respect. I'm outta here.

Hm... Who's emo now?
As I understood you are talking from the end-user perspective and I answered that it shouldn't concern you as an end-user.
If you want to join this discussion as a developer - I don't mind at all.

--
One more thing about drivers - they allow independent development with multiple people, even those, who don't know anything about internal Love mechanics.

If we accept this new architecture we can start working independently - I can start coding DirectX drivers, someone can start converting the old Rude/Mike code as SDL/OpenGL drivers...
And we won't even need to merge the Love source to compile the whole program! Isn't it good?

[tido]

Correct me if I've misunderstood, but say you have access to all of these functionalities and you create a game that makes use of DirectX only, how do you expect that very same game to work on Linux without having to modify and distribute the .love file for each platform?

The whole point of doing everything in SDL, is so that the end users won't have to worry about the technicalities. No "hacking" the .love file, or downloading some missing .dll files in order to play a game. You should really only need LÖVE Mächine and the games. Kind of like Java, only not gay.

[alxs]

You should really only need LÖVE Mächine and the games. Kind of like Java, only not gay.

I agree. The drivers will expose the same set of functions (we will need to develop a standard interface), so from the point of view of the game nothing will change.

The same functionality must be implemented in each driver, be it SDL or DirectX. If a user wants to draw a line - he doesn't need anything except "line(x1, y1, x2, y2)".

But any driver can expose additional functionality that will only be available on certain platforms. That's normal.

[rude]

it's just because my mode of work is a “full-time, highly-productive” and it differs from most fan/forum/opensource projects with their lazy attitude and catastrophic lack of time

What is it that you do, exactly ? Most people have real lives, you know. OpenSource projects would not exist if it weren't for those people who create "a minor build every two years or so".

I (personally) like the way you're thinking with dynamically loaded modules; I've been playing with that thought myself, but for simplicitys sake I decided not go for it back in the days. Besides, Lua has this functionality built-in, of which you are problably well aware. I even considered implementing LOVE in this way at some point, so that LÖVE could be run by the standard Lua interpreter:

Code: Select all

loadlib("love") -- Looks for DLL on Windows, SO on Linux, etc

love.this()
love.that()

Code: Select all

$ lua main.lua

Again, I felt that this meant less control, especially with regards to .love files.

I disagree with your Lua syntax, but that's another discussion. (Which is not that open for discussion ). I Assume you're just using placeholder syntax for illustrative purposes.

love.lua is planned, but its original name was loveu.lua (LÖVE U ... get it?). "LOVE utilities", if you will. It will provide a special global table "loveu" with Lua-only functionality built around the core "love" functions.

Correct me if I've misunderstood, but say you have access to all of these functionalities and you create a game that makes use of DirectX only, how do you expect that very same game to work on Linux without having to modify and distribute the .love file for each platform?

The interface the user (game creator) "sees" will not be dependent on DirectX. The user (game creator) will only be able to access functions in love.graphics, without knowing how LÖVE realizes those functions.

But any driver can expose additional functionality that will only be available on certain platforms. That's normal.

Short answer: no.

Just so we're clear on one thing: alxs is not suggesting that game creators should make their own DLLs, he's suggesting that we (LOVE Dev Team) should use DLLs to make our lives easier. Problem list:

1) Even if it's not our intention, game creators may create extra DLLs that lock certain games to certain platforms and/or create other problems. This clearly conflicts with the "vision".
2) I'm not sure if it really will make our lives easier. It does not really matter if it's compiled statically or loaded dynamically when only we are supposed to mess with them anyway.

[alxs]

What is it that you do, exactly ? Most people have real lives, you know.

As a self-employed I can spend 100% of my working time on whatever project I want. You, guys, have universities, paperwork and stuff

I disagree with your Lua syntax, but that's another discussion. (Which is not that open for discussion ). I Assume you're just using placeholder syntax for illustrative purposes.

Sure, but you probably meant semantics, not syntax
There is not much syntax in video.setMode(800,600)

BTW, though it is indeed a stand-alone topic - don't create Lua API that is (contrary to your own concept) bound to device implementation.

Example:
drawLine(xpos, ypos, x1, y1, x2, y2)

WTF? Any novice user will get heart attack right here. Or brain damage, I don’t know, which comes first.
"drawLine" –> can you do anything else with a line, except to draw it? Come on, change it to “line”! Keep it simple!
Next, line() is a simple function that draws a line from point A to point B. That’s 4 arguments. Not 6

love.lua is planned, but its original name was loveu.lua (LÖVE U ... get it?). "LOVE utilities", if you will. It will provide a special global table "loveu" with Lua-only functionality built around the core "love" functions.

love.lua is shorter, more readable with the same meaning, but sounds not like a lame declaration of love, but like a simple fact that we love lua

Short answer: no.

My short answer: think more about it. This is a lengthy philosophical discussion, but I am sure I am right
My long answer: remember how Half-Life 1 used 3 different renderers – software, OpenGL and DirectX with quite different results? At some point abstraction breaks and you have to deal with the low-level stuff.

1) Even if it's not our intention, game creators may create extra DLLs that lock certain games to certain platforms and/or create other problems. This clearly conflicts with the "vision".

Well, if it’s an intent – that’s Ok. If I want to ship my game only for Windows, let me do it. If you disallow extension via DLL you will limit yourself to schoolboys' trash-games, somewhere on the level of some of the current love “demos” I’ve seen.

Each serious game have non standard things and if you don’t allow extension – game developers simply won’t use it. Again, think more about it. Think about some game idea (forget what is possible in Love) and then think – could you implement it “clean”, without any extension of functionality?

I will make it easy for you. Imagine you want to write a top-down auto racing game with mini-cars. You create a level background with the mask - where the road is and there it isn't. Now how do you plan to find whether your car is on the road or not? Load this huge picture into Lua somehow? This is trivial example, but you should get the idea.

If you are the one who will include all extensions into Love and all game developers will depend on you about what kind of games they can create – then this will suck.

2) I'm not sure if it really will make our lives easier. It does not really matter if it's compiled statically or loaded dynamically when only we are supposed to mess with them anyway.

One reason I already brought – more independence.

[rude]

Gah, Christ ...

I don't even have time to answer your posts properly, so short versions of everything:

• More liek unemployed. (Take a joke)!
• You have no influence on naming (functions, files) beyond that of normal users, sorry.
• Abstraction will break, but we are cut big amounts of slack due to our 2D choice.
• Developers who whish to make custom extensions to LÖVE may do so, but they should call it something else, and always distribute their engine with the game.
• I am perfectly happy with schoolboy trash-games. "Schoolboys" were actually the indended audience. In fact, project LÖVE was created to enable "schoolboys" to prototype their trash-games rapidly.

"Real" game developers would probably look for a C/C++ library rather than a pure Lua engine - even if it's extensible with plug-ins.

It's becoming gradually more clear that you're really creating a separate project here. So far we disagree on pretty much everything.

[rude]

Alxs may have split (he decided to start his own project), but he still got me thinking. It may be advategeous to split different modules into separate libraries. More specifically, split the different love-"devices" into separate SWIG modules, possibly loaded dynamically. Not really to improve independence or encourage custom extensions, but because:

• SWIG "prefers" this approach. (Obey SWIG)
• It will be (slightly) faster, due to less if-branching in the SWIG glue.
• We're rid of the damn colon in love.device:function() names. New and better: love.device.function().
• And most importantly, we can create custom Lua methods in each module (with ease).

This isn't horribly interesting for LÖVE users in general, but I wanted to "conclude" this thread, and warn you about a small change in function naming in the future. (Current: love.graphics:draw, Future: love.graphics.draw)

[mike]

This thread was born, thrived and died without me, but as axlslssl has split and rude has taken what he needs from this I am considering this thread closed, dead and buried. Let's move on.