I'm forking Love2D. Support for 3D coming.

[ncarlson]

Hi everyone,

I've been working on a game off and on for the last 10 months or so. It's called RogueMiner. Up until now, I've been using my own engine which is based on SDL, OpenGL and FMOD.

I was recently bitten by the Node.JS bug, and decided that it would be great to incorporate Google's V8 javascript engine into my game, similar to what Love2D does with Lua. Here's a video of another guy with the same idea.

So, I've been studying Love2D's source for the past few days, trying to suss out it's architecture. Today it dawned on me that development would progress much faster if just forked Love2D and added 3D routines, rather than shoe-horn V8 into my existing engine. In the spirit of sharing, the forked code will be available on Github under the MIT license. (I'll post the repository URL later today or tomorrow.)

My question is, has anyone else already done this? I've seen a few faux 3D examples on the forums, but immediate-mode calls (glBegin/glEnd) are way too slow for what I'm trying to accomplish.

It's not much, but here's my progress over the past few hours.



If you have any advice or suggestions, I'd love to hear them.

Thanks.

[Tesselode]

Congratulations on getting 3D working. I tried to make it work but it broke pretty quickly. I think a Love3D would be pretty useful for people who are already used to Love2D.

[tentus]

Cool deal. I'm curious, what model format are you going to support, at least to start with? I hear that .X is relatively easy to work with (http://www.shamusyoung.com/twentysidedtale/?p=12242).

[kikito]

Hi,

First of all, I wish you luck!

... immediate-mode calls (glBegin/glEnd) are way too slow for what I'm trying to accomplish.

That sounds like a ... hunch. In my limited experience with high-performance algorithms, they are sometimes counter-intuitive. If you haven't done them already I'd recommend making some performance tests before crossing that option out. Just to be sure.

[pekka]

Eh, it's pretty well known immediate mode is old, old-style OpenGL and not as fast as modern methods. It has even been dropped from OpenGL ES, hasn't it? It's sticking around in some versions for pure backwards compability.

Anyway, if you want to try using immediate mode, you can use display lists to speed them up (masses of tutorials for them on the web too). Probably the only thing recommending this approach for serious use is that it avoids having to deal with the low data representation needed by OpenGL calls that send more data at once to the graphics pipeline. They pretty much take a pointer to a section of memory that needs to have a specific format, so you need to set that up on the C++ side. So, if you want to stay on Lua side, immediate mode and display lists it is. (Unless there is a ready OpenGL library for Lua you can adapt.)

[slime]

VBOs are the way to go.

[ncarlson]

I'm curious, what model format are you going to support

It's very unlikely that I will support any model format. At the moment, I have two goals:

* Modify the current OpenGL environment that creates through gl calls so that a third dimension is supported. This means glOrtho, adding depth testing, culling, etc. I've already done this, in a sense, but I need to test every 2D drawing function to make sure they function correctly.
* Add support for VBOs.

... immediate-mode calls (glBegin/glEnd) are way too slow for what I'm trying to accomplish.

That sounds like a ... hunch.

The performance penalty of immediate-mode is well documented. In fact, the modern programmable graphics pipelines that we know and love are a solution to the inefficiencies of immediate-mode.

VBOs are the way to go.

Coming soon!

[slime]

Technically VBOs already exist in one form in love as spritebatches.