Yae - Game engine for MoonScript, in MoonScript

[Davidobot]

-snip-

It's not really plausible to create a couple thousand new meshes every 1/60 of a second, so I was thinking of seeing how Java does its image morphing so nicely and efficiently.

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").

I don't know if this is already done, but from what I've heard, LÖVE is very CPU-based, so offloading stuff to the GPU would help improve performance.

[slime]

-snip-

It's not really plausible to create a couple thousand new meshes every 1/60 of a second, so I was thinking of seeing how Java does its image morphing so nicely and efficiently.

Please don't ever call a love.graphics.new* function every frame.
[wiki]Mesh:setVertex[/wiki] and [wiki]Mesh:getVertexCount[/wiki] exist (as well as [wiki]Mesh:setDrawRange[/wiki])!

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").

There's the option of splitting the line and the fill modes for shape drawing into different functions, as discussed here: https://bitbucket.org/rude/love/issue/6 ... filled-and

[deathbeam]

Slime is right. It is no-no to create objects in draw and update callbacks. It will make kill your game's performance and make your GC very very sad.

Hey guys, NÖN was deleted from LuaRocks. I didn't received any notification but maybe it is because NÖN isn't typical lua package. I need to make cross-platform installer or if anyone of you know Leafo and how can I get in touch with him to discuss this.

EDIT:
Sent him email, waiting for his reply.

EDIT2:
NON is still here https://rocks.moonscript.org/modules/deathbeam/non. Just search query is not returning any results for NON for some reason.

[deathbeam]

Okay, LuaRocks issue was with wrong set Lua version, I already fixed this in GitHub repository.

Today I made some updates.

* non.graphics.print, non.graphics.printf, non.graphics.draw and methods for drawing shapes are working identically to LÖVE (without support for shearing).
* non.system.getOS is fully working and can return Windows, Linux, OS X, Android, iOS and Ouya. Also, as second return it returns current operating system version
* added non.system.getMemoryUse to what returns current memory use by Java and by native (C) code
* refactored source code and increased performance of calling callbacks
* added back non.java module
* added non.system.vibrate(seconds)

Working on Ouya support. Right now, engone supports it but there is almost no way to get input from controllers.

Small preview what prints some debug values to console and plays musics, draws image and simple text:

[deathbeam]

I did few updates yesterday (I had birthday and I spent it by programming NÖN ). I added non.graphics.arc and also optimized Objects performance (Image, Font, Quad, Source).

[I~=Spam]

Wow! You are adding features really fast! (I remember when no new version of LOVE was released for 2 years...)

Working on Ouya support. Right now, engone supports it but there is almost no way to get input from controllers.

That is cool! Too bad about the controllers... I am sure someone has done it before in java... I hope.

Running as admin in the command line when not needed is a bad idea... Or is that just your username? Nice screenshot BTW. I also notice you haven't registered windows. I use arch linux so I don't have to worry about that kind of thing.

I did few updates yesterday (I had birthday and I spent it by programming NÖN ).

I have done similar coding projects on my birthday too.

[deathbeam]

Wow! You are adding features really fast! (I remember when no new version of LOVE was released for 2 years...)

I am trying to have everything working as fast as possible

That is cool! Too bad about the controllers... I am sure someone has done it before in java... I hope.

Hey, I never said it is not possible (actually, it is quite easy to do) . I just need to think about nice API (because handling controllers for Ouya is almost same as handling input from joystick and gamepad, so I am deciding if I will add general non.controllers module or non.joystick, non.ouya etc.).

Running as admin in the command line when not needed is a bad idea... Or is that just your username? Nice screenshot BTW. I also notice you haven't registered windows. I use arch linux so I don't have to worry about that kind of thing.

Who likes supporting Microsoft? Me not And I am always running everything as admin (that is why I am constantly reinstalling Windows because I am even too lazy to install antivirus lol).

I have done similar coding projects on my birthday too.

Today I was again working on NON and I tried to test simple LOVE sample on it (Passing Clouds). It worked without any modifications (except conf.lua of course). Here is screenie:



In attachment below is actual source of that demo (with some modifications for dynamic screen size). To start it:
* Download latest NON source from here https://github.com/non2d/non
* Navigate to downloaded source directory
* Run

Code: Select all

luarocks make non-dev-1.rockspec

or right click non-dev-1.rockspec and click Install (if on Windows and have LuaRocks for Windows installed properly)
* Download and extract passingclouds.zip to some directory
* From command line navigate to that directory and run

Code: Select all

non start

[I~=Spam]

Today I was again working on NON and I tried to test simple LOVE sample on it (Passing Clouds). It worked without any modifications (except conf.lua of course). Here is screenie:

That is amazing! Now I really want to know how well this performs on mobile. LOVE used to have a "port" that was written in java specifically for running LOVE on android. It was really slow and didn't have many features (and a lot of bugs).

I wouldn't be surprised if it performs nicely.

As a suggestion maybe you could make a tool that analyzes LOVE source (including conf.lua) and converts it to a NON project. If there are any unsupported functions being called the tool could report that too.

[deathbeam]

That is amazing! Now I really want to know how well this performs on mobile. LOVE used to have a "port" that was written in java specifically for running LOVE on android. It was really slow and didn't have many features (and a lot of bugs).

I wouldn't be surprised if it performs nicely.

I have tested it on my Asus tablet and it performs very nice. But my tablet is quad-core with 1GB RAM, so maybe I should try it with some slower android device

As a suggestion maybe you could make a tool that analyzes LOVE source (including conf.lua) and converts it to a NON project. If there are any unsupported functions being called the tool could report that too.

Hmm that is a lot of work. I will maybe simply add messages what will print that called function is not yet implemented or something like that. Actually, I already implemented this system into NON source, but I am not using it anywhere

I did another update, and that is pre-compiling of NON core source code, so this greatly decreased build times. Also, restructured source code to be more readable.

EDIT:

Passing clouds on

- my Android x86 quad-core 2GHz, 1GB ram tablet:



- my Android arm-v7 single-core 1GHz, 512MB ram phone



I do not noticed any performance issues on both devices.

[deathbeam]

I did another small improvements while I still have some time (today I have practical maturity exams, wish me luck with my 2x100W power amplifier ) and I moved modified third-party source code to separate directory in source (and separate artifact, now it is "io.nononsense:thirdparty" for Maven Central).

Also, changed icon and updated samples on website for upcoming 0.7.0 release.

New icon: