I returned!

After 31 days, I managed to get access to an Internet connection!

I’ll tell you later on how Puerto Rico’s recovering. Right now, though, I am just telling you that I am currently fine.

Advertisements

Hurricane Emergency

Hurricane Harvey was a no-go.

Hurricane Irma touched me, but other than a lot of debris and some electrical problems, there was not really a big deal.

Hurricane María, however, seems to be at a crash-course against me.

I am writing this ahead of time, but the hurricane is already touching my home country, Puerto Rico. I write this because I want to warn you if electrical problems would make any work impossible in the future. Due to a problematic infrastructure with electricity here that recently led Puerto Rico to a multiple-day blackout, I may risk not being able to do any work until 6 months afterwards.

Despite everything, I wish you all a good night.

SDL2 Targeted at Libretro?

The desire to find a way to handle graphics directly in Libretro came up again since about a couple of weeks ago.

I ended up at several venues of possible solutions, one being sdl-libretro. My big issue with trying this is that the repository uses SDL 1.2.15 when SDL2 already exists. After looking at the code, I made a folder that had the include, src, and test folders of the SDL2 source and the Makefile.libretro file of the sdl-libretro repository.

The compiler wanted EGL/egl.h . I ended up adding EGL, KHR, and X11 (actually a combination of X11 and XProto sources!) folders before the compiler requested sys/syscall.h . A search revealed that sys/syscall.h does not exist in Windows, the operating system I am using now. I temporarily modified the Makefile.libretro file by adding:

platform := win

after line 13 in the file. I also renamed the naming scheme from “SDL” to “SDL2” because I wanted to differentiate my experiment with SDL2 with the official sdl-libretro repository.

I ended up with a libSDL2_win.a file.

I am surprised and relieved that compilation apparently works, but what am I supposed to do with this file?

 

Re-Starting Fundamental Algorithms

I have been looking into how to do the fundamental algorithms that run Re-Hoard:

  • Some way of generating a maze
  • Some way of drawing a maze
  • Some way of directing the opponent’s movements whether they be patrolling or hunting while respecting collision
  • Some way of generating fully-functioning opponents

Though I looked for several maze generating modules already written in Lua, especially accounting the tight restrictions the Pico-8 has, I ended up coding the Recursive Backtracker algorithm that Jamis Buck wrote in his presentation on algorithms. (What really confused me way how to iterate over a 2D table in Lua.) However, I still needed some way of implementing queues in Lua. I ended up with the Deque module. I only put the specific functionality the game needed, though. I ran the code, but I ended up stuck today on some odd syntax error when dealing with this line:

 if dungeon[(current_cell.1) - 1][(current_cell.2)] == nil then

current_cell holds a table (a list, actually) that simply holds the “current” coordinates ({x, y}). Out of some reason, though, Pico-8 keeps saying:

‘)’ expected near ‘.1’

…even though I already put a closed parenthesis.

Thankfully, I already made a quick code that draws the map, which is actually a table full of “true”, “false”, or “nil” values.

On the opponent AI, Scathe at the Lexaloffe forums suggested repeatedly directing the opponent to a specific point in the map. His posts use a Pac-Man-style algorithm while the Pico-8 Zine used the A* algorithm, instead. I picked A*. This requires some careful attention from me, though I realized that the pathfinding algorithm also solves the issue with collision: pathfinding algorithms are designed to find the shortest path to a goal while avoiding obstacles, that is, the same obstacles that motivate me putting in collision detection in my game!

I already have the actual collision detection algorithm fully understood and coded, by the way.

On actually generating these opponents, I found Entity-Component Systems which not only promise to be more efficient but also do away with the need of object-oriented programming (in theory), making them a good fit to Lua, which does not have native support of OOP.

I would push these changes to GitHub, but I put all these algorithms on a separate cartridge because I want to focus on understanding and testing those algorithms specifically.

Reckless Foresight

When I formed my goal of releasing Re-Hoard and Reckless Abandon on September 10, I was thinking only on coding, graphics, and music.

I realized recently that there are more steps after that.

I am not only talking about testing or even translation. I want to give these games their own mini websites, advertising (with stellar art), and, in all, a proper release. That requires not only more programming, but also skills in how to use CSS, how to draw skillfully, and so on. I would also have to make the websites fascinating yet skillfully coded and designed. I would also have to add new features, including a guestbook and privacy policy.

In all, I need to give the games the respect they deserve.

I knew that making September 10 a mere goal instead of a promise was wise.

Release goals of Re-Hoard and Reckless Abandon

Please excuse the news blackout. Since July, I needed to rest, first. Afterwards, I got a new computer that replaced my old one which had a malfunctioning keyboard. After that, I spent my time setting up my computer to my liking and getting used to a new keyboard layout based on the 2nd ANSI Keyboard variation of the DH Colemak mod.* I am still yet from fully used to this layout, but I am reasonably competent here. Besides, I should not be putting off development of my games so long.

How does September 10 sound? I am not making any promises, but I should be getting back to work.

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!

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.

Understanding Graphics

I thought that I was just going to give up on understanding how Libretro renders graphics. However, I still had this urge of solving this problem.

That turned out to be a good thing.

After reading on other engines and thinking just how Libretro handles this stuff directly, I took another look at the example code and actually built the example. I then spent my time reading the code, adding my own comments there. I found out that I was ignorant or mistaken in a few points.

  • A software framebuffer, in the case of Libretro, refers to a 2D array in memory. Each cell in that array represents a pixel.
  • The “cb” in “video_cb” means “callback.”
  • Retro_video_refresh_t, in reality, is a function that renders the actual frame, taking the data, both dimensions, and pitch.
  • Speaking of “pitch”, that actually refers to the number of bytes between any two lines in the buffer, that is, the length of a scanline. The “stride” variable refers to the pitch.
  • The mouse is not involved in the demo; I was looking at variables that had the name “mouse” in them. They actually refer to the pitch.

My plans have me uploading my comments on the code later. Right now, I shall give what seems to be the general procedure in software rendering using Libretro.

In a nutshell:

  1. Declare a bitwise 2D array in memory. This is an abstraction of your framebuffer.
  2. Call retro_video_refresh_t, putting its contents in a static variable.
  3. Call retro_get_system_av_info, putting information that relates to the framebuffer.
  4. Make a static void function.
  5. In that function, copy into a local variable the contents of the array in Step 1.
  6. In the same function, fill the cells you want in that array with pixel data.
  7. In the same function, put the buffer, its dimensions and pitch in the variable in Step 2.
  8. At runtime, call that function.
  9. At the time of actually loading the game, set the pixel format.

The issue now is that I have to figure out how to either convert lodepng’s RGBA format to RGB565 or how to use Libretro’s own rpng.

Either way, I do not feel lost anymore today.