Hoarding sounds and sprites

Yesterday, I did something that I thought that would not happen any time soon.

I did all of the sounds and sprites that the game needed.

I think that part of the problem was that the amount of sounds and sprites needed was large. There was also difficulty in making a title screen and the music.

I already mentioned how I managed to solve the music problem. The title screen was a form of roundabout ingenuity. I wanted a title screen that has a font in this style, but I was willing to just take a bold font then “hollow out” the font. The font I ended up picking was Paytone One. I then wrote the title in GIMP (using a black-colored aliased font) then used the Perspective Tool in getting the title to look close to the perspective I wanted. I then resized the title in Paint.Net without using anti-aliasing. However, the Perspective Tool seemed to have anti-aliased the title already. I ended up manually filtering the pixels; any pixel that had at least 128 opacity was colored pure black while the lighter pixels were colored black.* I then copied the title to the Pico-8 pixel-by-pixel.

Getting the colors of the title working was difficult. I quickly realized that the text did not have the thickness that would have let me make the outlines of the font that I wanted to simulate. I ended up not drawing outlines that surrounded the inner “holes” of the title’s letters. After I made minor pixel-level adjustments in the title’s formation, I searched for the right colors. I had in mind a color scheme that used a yellow fill but suggested a castle (which is also the reason behind the high perspective), but I had to approximate, given the palette that the Pico-8 used.

After that, the whole thing was easy. After the experience in remixing the music, I made all of the sound effects in the Pico-8 tracker. I also noticed what a difference different octaves made in the Pico-8, I adjusting an earlier song that did not sound right because of the wrong octaves.

All that is left is the code. I am actually more worried that the code would actually work.

 

  • = Only later did I realize that I could have looked for a way that transformed the title’s perspective without anti-aliasing. A bit of searching said that I could have set the Interpolation of the Perspective Tool to “None.”
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.