I don't know where you can find it (I don't use CMake on my projects), but...

I don't think you need to use any building system if you are making a header-only library. The appeal of the header-only libraries is that users can copy to their projects, and they add to their own building system. And if you ever need to use a building system, go with the simpler first (make), and switch to CMake only if you really need it.

If you want a build system for the purpose of configuration, you could explain on the README.md the macros that can be used to configure.

Check how I did with my library \/ If anyone wants to configure, they can use the -D option of their compiler, or use -include their_config_file.h and add the configuration macros in the header.

As an aside, yes, I'm still working on my gam.

I would lose my mind if I use separate files for each state.

Yeah, "sign"!

Thank you!

Is there a name for an operation that transforms any value greater than 0 to 1?

Like this:

Code:

vec velocity = {0, 3}
vec move = velocity.to_one()

print(move) // {0, 1}

I can't understand very much what you want to achieve, but looking at your code: is it correct that you are using CurrentPosX inside the Easing, when CurrentPosX will be overriden everytime you push a button?

^^^

You don't use easing functions for controlling an object. Easing functions are useful for animations - where the beginning is always the same, and the end is always the same.

If you want to smooth the motion, use acceleration instead of applying a fixed velocity.

I've been monitoring this thread. edit: all that I said bellow are just random considerations, not a "in favor"/"against" statement. And there are probably 100 typos

In my experience, Apple is hostile towards developers. I'm glad I no longer have to support that platform.

Two days before the announcement, I was working on the Cocoa/GL backend for my window creation library (sort of like glfw). When I saw the news, I immediatly removed all the code that I had for Cocoa. Felt really good.

But, even with situations like that, I think it doesn't mean OSes are less reliable/stable for the future of games than fantasy consoles. As long as the games are coded with a layer that groups what is platform specific, then it's good. GLFW and SDL, for example, are these kinds of layer. If OSes change in the future, it's a matter of updating these layers only. This is not less work than it would be with a fantasy console. If in the future the OSes change, the fantasy console itself will need to be updated.

So, fantasy consoles have the good aspect that there's no way that the developer will accidentally use any platform-specific feature, because the fantasy console's features is the only thing the developer will have access to. On the other hand, fantasy consoles add the need of an interpreter, which consumes processing power.

Code:

Native games: OS --interpret--> application
Fantasy console games: OS --interpret--> fantasy console application --interpret--> game in the console's language

Despite the second layer of interpretation, I believe even some processing consuming games could be done.

-------------------------------

Other thoughts.

Considering the subject surrounding the original post is the future of games. I assume as in preservation. A fantasy console has some advantages that using an abstraction library doesn't:

- The fantasy console works on an specific language, only. Native applications, even if they use abstraction libraries, are dependent on their compilers/interpreters, which are also subject of becoming unmaintained in the future.

- Fantasy console doesn't need to be necessarily an application, but can be a protocol. This means that someone can make an implementation of the Fantasy Console Protocol Deluxe in C, in Javascript, in Lua, in Assembly. This is what is happening now on Linux/FreeBSD: the Wayland protocol is being made to replace X11 in the future. Years ago, who would've thought that X11, an ancient established library, would have its days numbered? This is also an example of why we shouldn't believe that even well established tools, like GCC, will last forever.

Language of choice is important, but, ultimatelly, what will determine the binary compatibility (backwards-compatibility) is the convertions from (script) language to binary that the fantasy console will interpret. This is a difficult task that even Lua has problems with. I'm using Lua here as example, because honestly, it's the best candidate (although I have some critiques against Lua). Speaking as someone that has embed Lua with C.

Graphics can be easier than it seems. Expose an OpenGL-like API to the developer: the developer has to pass buffers, enable/disable some states, make a shader. Under the hood, the fantasy console could literally use OpenGL (or even DirectX, or Vulkan), just translating what the fantasy console language is passing to the lower level API.

Maybe we could leverage an existing VM in order to alleviate the load of developing this theoretical fantasy console. If our thing targeted the JVM for example, we wouldn't really have to worry that much about platform specific code, other than maybe graphics programming stuff.

NES emulators (https://github.com/search?l=C&o=desc&q=nes+emulator&s=stars&type=Repositories) are probably the best, simple, start.

You might remember I was having issues with combining diacritics using Pango for text rendering...

Since I'm still set on having good international text support in my game engine, I decided to see what else I could find. I found out about HarfBuzz, which is a much lower-level text layouting library, and supposedly actually what Pango uses under the hood, but for some reason when using it directly I had no issues, which is weird.

But I'm happy that this worked, and is lighter-weight, even if it means I'll have to deal with line breaks and such myself, which HarfBuzz does not provide.



This particular test application only uses HarfBuzz to layout the glyphs, FreeType to get the corresponding pixels, and then I just copy them over to an SDL surface/texture (which will be an OpenGL texture or w/e in the actual engine of course), ready to be rendered. The (very incomplete) HarfBuzz documentation said something about "built-in OpenType support" so maybe I don't even need the additional dependency of FreeType either. Will look into it, I guess!

Good job!

Cool! I take it this is just to generate the bitmap fonts but I still have to write the layouting code for rendering myself?

Yes! I want to keep layout/rendering out of it, because there are so many different cases (hardware: opengl, directx, vulkan; software: cairo, sdl, ...). So, the focus is only on providing the font image, the codepoints and the glyph location in the image.

After the hiragana and katakana set, I will try to make an arabic set, which will be more challenging, because of the ligatures 

Made some updates on the generator (see README.md)

And I started working on a set of hiragana characters:

[Example]

I'm working on this project, and I needed an scalable method for including bitmap fonts in the future, for any language that I might need. Then I started this project "MonoGlyph" (like, 2 hours ago).

In short words, it's a Lua script, that you provide a PNG file containing the characters, and a text file containing the same characters. The script converts everything to a C header file, which contains the RGBA pixels of the image, the glyphs (with Unicode codepoint, and location on the image).

Project link: https://github.com/ferreiradaselva/monoglyph

"But, there's only one font in the repository!" The objective is: if more people contribute, that could be a big database of monospaced bitmap fonts, easily accessible from C.

Example

This image:


This text file:

Code:

!"#$%&'()*+,-./
0123456789:;<=>?
@ABCDEFGHIJKLMNO
PQRSTUVWXYZ[\]_a
bcdefghijklmnopq
rstuvwxyz{|}

And this command:

Code:

lua generate.lua /absolute/path/monoglyph/fonts/simple1_5x8x8
    /absolute/path/monoglyph/fonts/simple1_5x8x8.png
    128 48 // image size
    simple1_5x8x8 5 8 8 // font name, baseline, glyph width, glyph height
    /absolute/path/monoglyph/fonts/simple1_5x8x8.h

Will generate a header like this:

Code:

#ifndef SIMPLE1_5X8X8_GLYPHS_H
#define SIMPLE1_5X8X8_GLYPHS_H

#include "monoglyph.h"

static uint8_t simple1_5x8x8_rgba[] = {
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
...
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
};

static struct glyph simple1_5x8x8_glyphs[] = {
{
/* " " */
.codepoint = 32,
.col = 0,
.row = 0
},
        ...
};

static struct glyph_set simple1_5x8x8_glyph_set = {
.count = 0,
.glyph_baseline = 5,
.glyph_width = 8,
.glyph_height = 8,
.image_width = 128,
.image_height = 48,
.rgba = simple1_5x8x8_rgba,
.glyphs = simple1_5x8x8_glyphs
};

My library for window creation (SWFW) has *almost* complete support for Wayland and X11, and the work on Windows is progressing, thanks to VirtualBox. I discovered that you can simulate multiple monitors on VirtualBox, which helps to make tests.

Also, thinking about start a Patreon and Liberapay so, maybe, people want to support my open-source projects.

https://github.com/RandyGaul/tinycavestory



@qMopey, this is looking really nice!

Edit: also, you **probably** don't need that KHR file. You can generate a `glad.c/glad.h` without it using the argument `--omit-khrplatform`:

Code:

python main.py --generator ... --api ... --profile ... --out-path ... --omit-khrplatform --local-files

Why did we have the 512 bootloader for... forever? Because...

Actually, it's because UEFI is A PAIN IN THE ASS.

Procedural generation of brush (which I call raster-tool, bc "brush" is a wrong name for it).

Just some explanation: there are general density, general roughness, fading area density and fading area roughness. Density is the random probability of a pixel to be ON or OFF. Roughness is the subtle random change in the pixel transparency.

I have square and diamond shapes, besides the circle shape. I also need to make some other modes of procedural generation, because I want to make possible to simulate almost any real artistic tool using only the  automated generation. Leaving "brushes" using textures only as a last resource.

Single header file to define all structures of my game was getting to bloated, not here I am suffering to move everything to their own header, but worse, having to organize the project structure to work with opaque pointers as consequence.

Also, I hate naming things. You have no idea how many times I changed the structure name from "gameentry" to "entrypoint" and from "entrypoint" to "gameentry".

edit:

I'm really thinking about going back to "one massive header, multiple source files". Working with one opaque structure is fine, but multiple is a pain, especially if you are obsessed with keeping all your game structure as a static declaration. You will find yourself trying to solve circular inclusion inside circular inclusion inside circular inclusion.

edit 2:

Went back to "single header, multiple sources" scheme. At least some of the refactoring I made could be used.

edit 3:

I woke up with a solution. Back to multiple headers. Nothing like a good night of sleep.

Getting somewhere on my aquarelle shader after two days of nonstop coding (and modelling and texture work to have something to shade in the first place)… Suddenly the vision I had for this game is starting to seem quite possible!

That looks beautiful! 

All I know is that that is a beautiful ball.

I have a question. Those quads that form the sphere, does the triangles bend or are they perfectly plane?

Just saw you put up over 100 github commits. I was wondering where you went! Looks like you were working on things but just not pushing the work till now? 

Lots of stuff being done. Awesome! 

hey, randy! Yep, I wasn't pushing the commits, but I was working on it :D

daaaaaaaamn very cool!