Internal Architecture Improvements

[rude]

Right. So that's it, huh? Giving up? :evil:
Not even going to tell us what you have so far?

[alxs]

Well, with or without you I will do it anyway, I need a Lua-based game engine.

I'll keep the name "love" for now. When I do something good, I'll show you. Bullshit walks, you're right.

[rude]

Hahah! Okay then. Looking forward to it. 8-)

Now stop being emo.

[rude]

Meanwhile, though, can we still discuss internal LÖVE-stuff as stated in the original post? Or was this meant for "LOVE 2" only?

[alxs]

Discuss, huh. Ok

Let's start with your vision of this project. It would be nice to have a clear understanding. One day you are welcoming - another day you essentially tell me to f@%# off.
I think I can understand your concerns, it's your baby after all. But one day a child grows and you have to let go. I think it already happened when you put everything on web, setup such a nice site, logo, concept, etc.

Now do you want to be like a dog on a haystack (not eating it yourself and not allowing anyone to eat) or do you want to use the opportunity and give this project a significant boost, so it had a chance for a bigger future? Do you want it to be big at all? So, that lots of people use it for creating games? Do you?

State your vision, please.

[rude]

Well, Dr. House, I guess I have to use metaphors to answer?

Okay, I may have been unfair and I may have told you to fuck off slightly, but only because it seemed as the only way to get the message across. You seemed so ... hyperactive, and I was trying to suggest that we plan a little before coding. But if you like the code-first talk-later style, that's fine by me. ^_^

May I also remind you that one of the first things you said on the forum were "source sucks, needs rewrite". That sounds like "fuck you" to me, but I chose to interpret this as you wanting to help out. I assumed you could take the same amount of "truth" without being offended.

Enough of this! We were all thinking Lua interface before you showed up, so it's about ti~me someone starting working on the other end . As I understand you do not want to share any details until the basic structure is done?

Oh, and until we have at least 5 consecutive posts with constructive architecure discussion, this thread will be named "The Emo Thread".

[rude]

Okay, here's something constructive.

We've been going back and forth between different ways of implementing graphic routines. In our case, it boils down to where to put OpenGL calls. One approach involves only allowing these calls in a graphic device class [ Device -> Graphics -> OpenGLGraphics ], and another involves splitting rendering code into actual subclasses of objects [ Image -> OpenGLImage ], [ Font -> OpenGLFont ]. We use the latter currently, as it made our lives easier at the time.

Thoughts, people?

[alxs]

Well, thank you very much for putting a label on me. If I seem emo to you that's because I usually quite passionate about things.
I am a human being, not a Terminator, for Christ sake.

Second, I certainly don't share the "code first - think later" approach! If I seem hyperactive - 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, resulting in one minor build every two years or so... But this doesn't mean I am coding, coding, coding. I try to limit coding time to at most 1/3 of the whole time, because the whole essence of programming is thinking. So currently most of the time I am thinking, thinking, thinking

BTW, "must read" article for every programmer, I am 100% agree with Wil here:
http://www.wilshipley.com/blog/2005/02/ ... every.html

So, that covered, let's go to details.

I don’t think it’s a good idea to put device-dependent code into Image, Font, etc. They don’t need to know about all the ugly device details (and it will be messy to connect them and device together).

They should represent platform and device-independent data. One exception may be the File class (as I have coded it) – this class directly uses PhysFS for reading and writing. But it’s because it is simpler in this case. And PhysFS is already platform-independent.

Then, since Image, Font, etc. must be independent we need to develop our own internal, simple formats for such data. We can’t handle images internally as PNG or anything. Each file format will be decoded by “a format driver”, or loader, into our internal format (for example, very simple, like {Width, Height, BPP, data}).
Next, the way I see the whole architecture. In my opinion, the most flexible way to do it – is to create “drivers” or “plugins” as dynamically-loaded modules. These modules will expose an object (table) and methods to Lua scripts.

For example, if you specify in config the following line:

“use=vid_direct9;snd_direct8;inp_winmsg;usr_game;”

the Love Machine will load these DLL’s (or SO’s) from the “plugins” folder and register them internally. This means that each driver will be available via its own object in Lua, like:

video.setMode(800,600)
snd.playSound(“aaa”)
inp.getMouseX()
etc.

Now you may think that it’s bad to allow drivers to expose any methods they want, but actually it is most simple, unified and flexible configuration. We will need some conventions about most common methods, of course.

User may extend Love functionality by writing his own DLL that will be exposed the very same way to Lua scripts.
I didn’t yet investigated how to make it best technically, but I think it won’t be very hard.

Another thing – about resource identification.

The common practice is to use a special handle, like:
vera = loadFont(“vera.font”)
setFont(vera)

I suggest to use names directly:

load(“vera.font”) // this will call appropriate format driver and automatically create an internal object of type Font. Should be inside Init() function
use(“vera.font”) // this will recognize that this is, indeed, a font and use it correctly.

Enough for now

[alxs]

No, not enough

Couple of things:
a) Let's use Lua as much as possible, even for some engine functionality. BTW, I am aware of at least 3 commercial AAA games, written practically completely in Lua: PainKiller and two games from CryTech – FarCry and Crysis. I’ve extracted all the Lua scripts from all 3 and learning how they do it.

b) So, let’s create “love.lua” file in the main Love Machine folder that will be loaded before any game and will contain some functionality of the Engine and other helper functions.

[Merkoth]

From a user standpoint, I absolutely dislike the DLL idea, for a number of reasons:

1) Someone will have to produce .so equivalents of those libraries. That's cool if we're talking about "core" libraries, but it'll be extremely annoying not to be able to play a certain game because some custom DLL is not available for your platform.

2) For those people who want to extend the Löve Mächine (double umlaut for added awesomeness) through DLLs, they'll have to build them for every platform supported by the Löve Mächine. Should they decide not to do that, we go back to situation 1.

3)

Code: Select all

“use=vid_direct9;snd_direct8;inp_winmsg;usr_game;”

This scares the fucking hell out of me. The driver architecture is fine when used well (guichan is a great example), but those sound extremely platform dependant, so the less popular platforms will always lag behind the better supported ones. Moreover, this looks way more complex than it is right now, for the user of course.

It would be great to be able to extend Löve using Lua, of course.

It's a good thing I regularly update my local copy of the svn, just in case.

From a programmer standpoint it makes more sense, even though I tend to avoid using platform-specific code.