Yae - Game engine for MoonScript, in MoonScript

[Roland_Yonaba]

All of this is far beyond my capabilities, as of now, but I strongly admire your comitment in this work.
It looks pretty solid already. Don't rush, and take your time tuning every single part of the engine and the API until you are completely fine with the way it looks.
Keep on!

PS: I would löve to know how you came up with the name NÖN... It's just nonsense, to me...

EDIT: 1500th post.

[T-Bone]

PS: I would löve to know how you came up with the name NÖN... It's just nonsense, to me...

I think you mean...

*puts on sunglasses*

nönsense

YEEEEEAAAAAAAAH

[I~=Spam]

I was working on this "port" for a long time. But I was gaining courage to post it also here

I am glad you posted here.

I am having small problems with metatables in LuaJ backend right now, but most of API is already finished. Only thing left is non.graphics module and make Source, File and Image objects working (as I said before, having some troubles with userdata and metatables).

Sorry I cannot be of much help... I am only familiar with adding metatables to userdata in c/c++... I wouldn't be surprised if luaj is different. I don't program in java just mostly c++ (more c++ than lua in fact...).

And yes, I will try to add autocomplete support to IDE. As I am using pretty nice script area Swing component (Swing is GUI for Java) what supports adding your own autocompletions, it will be easy.

Nice! That is good to hear!

[Roland_Yonaba]

I think you mean...

*puts on sunglasses*

nönsense

YEEEEEAAAAAAAAH

Ha ha! This is definitely what I meant!

[deathbeam]

Originally it was only "non" but I decided to change it to NÖN
1. Because of search engines
2. Because of LÖVE

I solved my issues with LuaJ and metatables by not using userdata at all. Now, objects (like Font, Image or Source) are simply tables with methods who accepts self as first parameter so you can simply do ":".

Also, almost finished rendering API. I only need to implement shearing and scissors. I almost implemented shearing right now with help of 2D affines.

I was not able to port entire LÖVE API because of cross-platform issues. For example, love.system.getOS is not possible, so I renamed it to getPlatform for NON and it returns "desktop", "android "or ios". Also, power informations etc. And I do not implemented few methods from love.window and some of them are working differently (like non.window.getMode returns screen dimensions and boolean if screen is fullscreen).

[Davidobot]

Since this is in Java, would it be possible to implement efficient textured polygons (like Minecraft), I know this can be done in LÖVE with this lib: viewtopic.php?f=5&t=12483 but it is rather slow? Or like overall better Image drawing/handling.

[slime]

Since this is in Java, would it be possible to implement efficient textured polygons (like Minecraft)

[wiki]love.graphics.newMesh[/wiki]

For 3D you'd have to interpret one of the non-position vertex attribute components as the Z coordinate in a vertex shader, since meshes currently have a fixed set of per-vertex attributes.

[Davidobot]

Since this is in Java, would it be possible to implement efficient textured polygons (like Minecraft)

[wiki]love.graphics.newMesh[/wiki]

For 3D you'd have to interpret one of the non-position vertex attribute components as the Z coordinate in a vertex shader, since meshes currently have a fixed set of per-vertex attributes.

I thought it was already discussed here that meshes are terrible at doing textured polygons, as they warp poorly and improperly, which is why the textured polygon library was created.

[slime]

I thought it was already discussed here that meshes are terrible at doing textured polygons, as they warp poorly and improperly, which is why the textured polygon library was created.

Meshes are just fine (and in fact, every single hardware-accelerated 3D game you've ever played essentially uses the same thing.) The library you linked was released before Meshes existed in LÖVE.
The issue with things looking weird will happen if you don't specify 3D coordinates properly in your vertex shader (and you'll probably want a perspective projection matrix instead of love's standard orthographic projection matrix, too.)

There have been a few tech demos where people have demonstrated this.

This is all very off-topic for this thread, though.

[deathbeam]

@Davidobot Everything is possible. And yes I am planning to add meshes too to engine as I want to support most of LÖVE API.
But if you have any tips how to handle drawing better, then you are welcome Right now I am thinking about changing how shapes are drawn to screen (as I think that mode parameter should be last and default to "line" or "fill"). But right now I am focusing to mimic LÖVE API for atleast graphics, audio and filesystem module (I succesfully replicated 99% of filesystem API and even added few advanced options to it).

EDIT:
Also, for performance (maximum build and startup speed), configuration file will probably stay in YAML and not in Lua as seen in LÖVE. Why? Because some configurations required for builds needs to be loaded before builds (like package and version). And starting Lua interpreter just to load configuration file will slow down builds a lot. Also, config must be loaded before main screen appears, so it will also slow down startup times as I cannot pass created Lua interpreter to main screen with current setup efficiently. So that's why I will stay with lightweight YAML parser.