Chai Chai Chai

ChaiScript is a new scripting language more directly based on C++. That means actual classes and stronger overall capabilities.

ChaiLove is essentially LÖVE with ChaiScript. LÖVE has spoiled me with its mature functionality and many user-provided libraries, but ChaiLove actually seems complete.

 

This puts me at a crossroads. In one thing, ChaiLove combines LÖVE’s ease of use and freedom from compilation with C++’s functionality. On the other hand, ChaiScript requires C++14 since version 6.0.0, which was previously C++11 since version 5.3.0, which was Boost up to version 4.3.0. Stone Soup got those problems with C++11 being too new to old compilers, making my “a game that runs in any platform that runs RetroArch or even just Libretro” difficult.

I shall keep an eye on ChaiLove, but I am not permanently switching from my plans of making a game “from scratch”.

Advertisements

Touch-ups on the game package

I knew that there were some things missing!

Strings: The Better String Library seems more robust and secure than the standard C++ strings. The library also has rudimentary UTF-8 support, though I fear that I may have to supplement the library with better support.

Internationalization: This is very important in my case: at the very least, I am selling games to the Puerto Rico, Dominican Republic, and United States markets! Fortunately, I found Poedit. I never liked the idea of using spreadsheets in localization, thus using Poedit’s gettext files, which are a simpler localization format, were much better. Other than the required UTF-8 support, Poedit also recognizes pluralized forms and “ballpark” translations. The features I want are on the free version, though I can always compile the program myself if I needed to do so.

Documentation: ROBODoc is flexible almost incredibly; ROBODoc not only supports any language that supports comments but also exports to a lot of other formats. I wonder how I am going to write the comments in a way that does not get in the way of the code, though, especially since I read Clean Code

Logging: I do not exactly know what exactly is logging other than what a log is. However, this may be useful in case my game gets errors. Now, I think of using plog, but with g3log‘s crash-safe sinks. After all, while I like plog’s ease of use and UTF-8 support, g3log’s sinks that hold the log data give g3log resistance against crashes. I do not want to chose between ease of use and crash safety, even if that means that I would have to do more work myself.

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.

Broken Physics; Broken Graphics

I am starting to change my mind.

I looked into Chipmunk after Box2D warned me about Box2D requiring a lot of C++ experience. However, Chipmunk itself seems too complex. Worse, I could not find an API-indifferent way of putting graphics on the physics objects!

I looked into other game engines, but they, true to my predictions, use SDL or OpenGL and do not seem to have ways of rendering directly to the framebuffer. Speaking of the framebuffer, I am still awaiting on information on what exactly is a framebuffer in the first place. On Radius’ defense, Radius is probably taking time out of a busy day in making an appropriate reply.

I just feel frustrated because I feel lost. Radius gave me a much-needed nudge, but I need more.

I am not going back to Lua because I need the capabilities that C++ or Rust give. Even so, the Rust libraries and engines probably have the same dependencies on SDL or OpenGL that the other game engines have.

I should be spending this time working on my PICO-8 games.

I shall look at rpng, Libretro’s own decoder of .png graphics. That, being of Libretro itself, should have a way of rendering directly to the framebuffer.

Lua to the End?

From the beginning of my game career, I intended to make games that use Libretro, a C/C++ library that can be used in writing emulators and standalone games. The reason why I learned Lua in the first place was because, compared to using straight C or C++, writing games in Lua and relying on the Lutro core seemed to be the more comfortable option. Indeed, because Lua programs do not need to be compiled, I ended up saving myself plenty of precious time in my last two college projects back when I took my Master’s Degree. Developing my final project using LÖVE instead of trying to understand the Libretro library, especially given the one-trimester deadline, spared me from a lot of grief. That knowledge of Lua also helped me develop games for the PICO-8, an all-in-one platform that not only helped me get used to normal game development but also has several channels of delivery, my favourite one being uploading the game itself in image format. You can even play these games in your browser with little fuss!

However, I am starting to feel the limitations Lua has. While Reckless Abandon has simple code, Re-Hoard has a game plan that needs object-oriented programming when generating random anti-hoarders, each with their own patrolling and hunting styles, per stage. Lua does not have any object-oriented functionality; other people fake that functionality using metatables. Even with that fake functionality, I fear that I would be better off relying on the real thing. Besides, if Lua lacked true object-oriented functionality, then what else would Lua lack? Other consideration include less layers of abstraction that might interfere with my wanting to interact with Libretro itself, the bigger maturity of C++ tools and libraries, and practice in a language that is still in high demand in the workplace. In fact, the more advanced aspects of Lua actually use a C library!

On the other hand, the gains from the lack of a compilation time proved to be an assets when I debugged my college projects. Also, LÖVE games store their assets as-is instead of they being baked directly in the program; I can edit a sprite or switch around a song and see the effects when running the game anew.

Despite these benefits, I am seriously considering working on my new games with C++ from now on. In fact, though Reckless Abandon would stay a PICO-8 game, I might move Re-Hoard to C++.

I just need to figure out how to display and move .png sprites and implement collision detection while I use Libretro.