What a LÖVEly API!

Ever since I gave up on making my own game engine through C++ and Libretro bindings, I took another thorough look at Lua and LÖVE.

What I found was amazing.

First, I found Moonscript, a language that compiles to and simplifies the already pleasantly simple Lua language. One big benefit is its adding support of classes. I mean, while I am still concerned with how this object-oriented programming is actually a pseudo-functionality, that this feature is built in this simplifying language is just great! Also, because Moonscript compiles to Lua, I can write PICO-8 programming in Moonscript, classes and all, before pasting the code in the cartridge! I do not have to worry about a separate function that simulates object-oriented programming in PICO-8! Indeed, there is already a way of inputting Moonscript in the PICO-8. My only real concern that I would not be able to mix regular Lua with Moonscript or use regular Lua libraries with .moon files.

Going back to the LÖVE forums had me reacquainted with several libraries and introduced to a lot of new ones:

  • bump.lua adds simple collision detection.
  • cargo efficiently loads resources.
  • il8n helps organise localisation.
  • locco generates documentation based on Markdown-formatted comments.
  • lovekit gives a lot of functionality and is based on Moonscript. While I do not know what each sublibrary does, I like tilemap, which draws the game setting from a small pixel image.
  • lyaml parses .yaml files.
  • material-love provides Material Design to GUIs in LÖVE.
  • push manages the different possible solutions a game might have.
  • sodapop is an animation library.
  • SUIT is an immediate GUI.

All this made me actually eager towards game development!

Advertisements

P = NG

After my previous adventures in rendering .png files to a software framebuffer, I realised that I needed to convert between lodepng’s RGBA 4-bits-per-pixel format to Libretro’s RGB565 format. My studies since my last post brought me to pixconv.c which has a function, conv_rgba4444_argb8888, that does just that type of conversion. I need to give the function the following in this order:

  1. the output variable
  2. the input variable
  3. the dimensions of the image file
  4. the output pitch
  5. the input pitch

In theory, all I had to do was add lodepng and pixconv.c to my project, run a test.png file through those two, and put the resulting data in the framebuffer.

The result was a mess. Learning that <iostream>, a stape at my studies of C++, was worthless when working in C, was actually the easy part. Even if I did not exactly know what type of data type were the variables that held the RGBA4444 and RGB565 arrays (I settled on unsigned char when void did not work), the makefile refused to recognize lodepng_decode32_file and logepng_error_text, even after I put those two types in various places (though not at the same time) inside the actual libretro_test.c file. I learned that this issue comes from the linker, which is related to the makefile.

At this point, I decided to give up at least temporarily. I mean, while there is the possibility that this is the last problem and that I actually have everything else right, I decided that this matter requires advanced knowledge that is specialized on C++. I mean, I have a Master’s Degree in Software Engineering, but my actual usage of the fundamentals of C++ and related languages were all in Integrated Development Environments. I barely know anything more than how to run make (not “CMake”, but “make”)!

This lack of specialized knowledge is also the reason why I am no longer pursing either adapting a current C++ engine to Libretro or, per Radius’ suggestion, using OpenGL. I still would have to deal with compiling the C++ code in those situations.

In light of this, I was looking more seriously at Rust, which has bindings to Libretro. While Rust is not object-oriented in the conventional sense, Rust has features that have just about the same functionality anyway. The problem is checking how the current game engines that use Rust render graphics. After all, I want to use software rendering because I want my games to be played at the full range of consoles that run Retroarch, not just the ones that can handle both versions of OpenGL.

I am also seriously considering going back to Lua per my original plans. Not only does LÖVE have no need of a distinct compilation process but also displays graphics through an API that works great and easy. In fact, the ease of use LÖVE provides is the reason why I picked using LÖVE instead of straight C++ in the first place! The main reason why I am not so sure is because that the reason why I wanted to leave Lua in the first place was because Lua did not have any proper support of object-oriented programming. I would much rather use the real deal, especially since Re-Hoard needs object-oriented programming! Even if there is an alternative, this lack of functionality may hamper heavily my plans of future games!

I tried to see how Lutro, Libretro’s interpreter of LÖVE, displays games written in LÖVE. I mean, LÖVE apparently uses SDL, but that does not seem to be a problem to Lutro. However, I got overwhelmed once again.

Eevee is right; if I were to write from scratch, I would be essentially inventing the universe if I needed to get off the ground. Then there is compilation afterwards.

Why write in LÖVE?

While I previously wrote of the benefits of writing through the Pico-8, I would need to write larger games through LÖVE, instead. The reason behind this came from a decision during early planning of my Master’s Project, which I wanted to be a game. I wanted to target Libretro, actually, because of the:

  • free license
  • cross-platform support
  • specific, through game-oriented design

However, games that target Libretro would have to be writen in C or C++, both programming languages that, despite my familiarity, were unpleasantly complex. However, I found out about Lutro, a porting of LÖVE to Libretro, the main benefit being an ability to write games in the far more pleasant-to-use Lua. Another benefit was that, though Lutro was still a work in progress, the original LÖVE had benefits that were similar to Libretro. The original LÖVE also achieved similar maturity, which meant that I could write games through original LÖVE, get similar benefits, and still be ready when the Lutro port matures.