DEV Community: Andrey_vdl

Não ter leak de memória é bem fácil, na real

Andrey_vdl — Mon, 24 Nov 2025 17:36:13 +0000

{INFO}: Esse post não tem relação nenhuma com o canal Bem fácil, na real, só achei que o título combinava 🙂

Se você coda em uma linguagem com gerenciamento manual de memória já deve ter se deparado com um double free ou com o famoso memory leak.

E por mais que existam Arenas, smart pointers e Garbage Collectors muita gente ainda falha em criar um programa sem vazamentos.

A solução é muito simples e provavelmente uma frase que você ouviu da sua mãe quando era criança "Coloque tudo de volta em seu devido lugar", mais especificadamente a parte "seu devido lugar", ou seja, aloque e desaloque memória em seu devido lugar.

int main()
{
    char *ptr = malloc(100 * sizeof(char));
    size_t addr = (size_t)ptr;

    for (int i = 0; i < sizeof("Hello, World!\n"); ++i, ++ptr)
        *ptr = "Hello, World!\n"[i];
    *ptr = '\0';

    ptr = (char*)addr;
    printf(ptr);

    free(ptr);
    return 0;
}

Nesse exemplo a memória alocada para ptr é desalocada no mesmo local que ptr.

typedef struct {
    char *ptr;
} Object;

Object objectInit(void)
{
    Object o;
    o.ptr = malloc(100 * sizeof(char));
    return o;
}

int main()
{
    Object obj = objectInit();
    size_t addr = (size_t)obj.ptr;

    for (int i = 0; i < sizeof("Hello, World!\n"); ++i, ++obj.ptr)
        *(obj.ptr) = "Hello, World!\n"[i];
    *(obj.ptr) = '\0';

    obj.ptr = (char*)addr;
    printf(obj.ptr);

    free(obj.ptr);
    return 0;
}

Já nesse outro a alocação não pode ser liberada na mesma função, então vamos liberar na função mais próxima dela, ou seja, no local onde a função alocadora foi chamada.

E isso é gerenciamento de memória for dummies... foi tão difícil assim?... Ah, sim, faltou falar de "e se a alocação falhar". Bom, se a alocação falhar, a gente só libera o que já foi alocado.

Fique avisado que o código que será visto a seguir é o maior pecado da programação, devido a algo tão proibido que somente os maiores programadores são permitidos de usar.

typedef struct {
    char *ptr;
    // ... finge que tem outros 100 atributos aqui.
} Object;

Object* objectNew(void)
{
    Object *o = NULL;

    o = calloc(1, sizeof(Object));
    if (!o)
        return NULL;

    o->ptr = malloc(100 * sizeof(char));
    if (!o->ptr)
        goto error_return;
    // ... inicializa os atributos

    return o;
error_return:
    // ... libera os atributos
    if (o->ptr) free(o.ptr);
    free(o);
    return NULL;
}

void objectDelete(Object *o)
{
    if (!o)
        return;
    // ... libera os atributos
    if (o->ptr) free(o->ptr);
}

void objectDelete2(Object **o)
{
    Object *temp = NULL;

    if (!o || !(*o))
        return;
    temp = *o;
    // ...
    if (temp->ptr) free(temp->ptr);
    free(*o);
    *o = NULL;
}

Object* objectDelete3(Object *o)
{
    if (!o)
        return o;
    // ...
    if (o->ptr) free(o->ptr);
    free(o);
    return NULL;
}

int main()
{
    Object *obj = objectNew();
    Object *obj2 = objectNew();
    Object *obj3 = objectNew();
    // ...
    objectDelete(obj);
    free(obj);
    // delete considera que o objeto principal/container é responsabilidade do usuário
    objectDelete2(&obj2);
    // delete2 considera já definir o objeto principal/container para nulo dentro da função.
    obj3 = objectDelete3(obj3);
    // delete3 prefere deixa o usuário decidir se o objeto vai ser definido para nulo.
    // um delete4 poderia ter flags que decidem se o objeto vai ser liberado ou não e se vai definido para nulo ou não.
    return 0;
}

Nesse último exemplo temos uma função que aloca um objeto e utiliza o temido ~~GOTO~~ em caso de erro, porque imagina o trabalho de ter que escrever cada if para cada possível erro no meio do código, é muito mais fácil pular para uma "zona de erro" e lidar com a liberação de recursos que estavam sendo utilizados.

Além da função que aloca o objeto, temos também funções que liberam os recursos após eles serem utilizados, cada uma com sua curiosa implementação um pouco diferente.

Bom, então é isso, se você simplesmente seguir essa regra é 99,99999% de certeza que você não vai ter um único leak de memória (os 0,00001% são de leaks internos de funções de bibliotecas).

Comentem casos que não foram abordados, discordâncias da minha opinião que podemos classificar minimamente como polêmica e é claro, compartilhe para seus amigos.

Cobertura de teste em C existe e vou te ensinar a usar

Andrey_vdl — Wed, 29 Jan 2025 18:28:41 +0000

Cobertura de teste é algo importante no desenvolvimento de software.

Testes garantem que seu software funciona do jeito que foi feito para funcionar e a cobertura de teste garante que você checou todas as possibilidades do seu código, ou seja um complementa o outro. Várias linguagens modernas em 50% dos casos vão ter uma biblioteca ou ferramenta para gerar um resumo dessa cobertura, mas você sabia que o C tem uma ferramenta """nativa""" para isso?

Vamos começar com um código bem simples que só retorna ±42:

#include <stdbool.h>

int return_42(bool ret_neg) {
  if (ret_neg)
    return -42;
  return 42;
}

E agora o simples arquivo de teste:

#include <assert.h>
#include <stdbool.h>
#include <stdio.h>

int return_42(bool ret_neg);

int main() {
  assert(return_42(false) == 42);
  assert(return_42(true) == -42);
  puts("Nice");
  return 0;
}

Agora podemos compilar o código com gcc/cc utilizando as seguintes flags -fprofile-arcs e -ftest-coverage.

Isso vai gerar um executável e arquivos com a extensão .gcno.

Com esses arquivos criados executamos o teste e após o fim da execução arquivos com a extensão .gcda serão criados.

Com esses novos arquivos criados podemos passar eles pelo gcov, instale o gcov e depois execute-o passando o nome dos arquivos .gcda e .gcno (normalmente eles vão ter o mesmo nome do .c, mas eles podem ter outro nome), com isso teremos arquivos com a extensão .gcov. O gcov já vai te dar um mini resumo sobre a cobertura, porém precisamos deixar isso mais visual já que você não vai ter 1 teste simples (eu por exemplo to extrapolando 120 testes em uma biblioteca).

Vamos utilizar agora o lcov, instale ele, utilize ele com as flags -c, -d . e -o foobar.info, ele ira gerar o arquivo com o nome que você passou na flag -o e também vai imprimir um resumo da cobertura, infelizmente esse resumo não diz quais funções foram vistas, mas com o arquivo .info criado podemos utilizar a flag -l foobar.info e o lcov vai imprimir uma tabela com um resumo mais legível, porém ainda assim, só temos uma porcentagem, não conseguimos ver quais linhas foram checadas, então vamos para o último passo para tornarmos isso muito melhor de ser visualizado.

Simplesmente utilize genhtml passando como argumento o foobar.info e a flag -o bar_html, o genhtml vai gerar uma pasta contendo todo o resumo da cobertura de uma forma muito mais legível (você pode abrir esse html como quiser, meu método favorito é com python -m http.server -d bar_html).

Você também pode utilizar o clang, porém as flags mudam, eu não fui muito a fundo por não gostar tanto do clang e também por achar o resultado final mais feio, mas pelo que tentei tudo funciona utilizando llvm e tudo que você tem que fazer é instalar 2 ferramentas do llvm.

Para finalizar o genhtml é bem customizável com bastante flags, o meu normalmente é assim:

E bom, por hoje é só, até a próxima!

Projetos para experimentar linguagens

Andrey_vdl — Sat, 27 Apr 2024 23:03:39 +0000

No momento que estou escrevendo isso ainda sou um estudante da 42, e como uma escola que te ensina a programar, a 42 tem uma variedade de projetos, grande parte deles pode ser utilizado para experimentar as capacidades de uma linguagem de programação, por motivos óbvios eu não vou descrever o projeto inteiro, só o esperado, de resto:

"Por Thor, por Odin, use seu cérebro." -PDF 2013-2024

FT_Philosophers 🍴

Esse é bem simples, simplesmente resolva o problema do jantar dos filósofos, seu programa deve receber argumentos na chamada do programa:

Número de filósofos;
Tempo de vida em milissegundos;
Duração de um jantar em milissegundos;
Duração do sono deles em milissegundos;
Opcionalmente o número de jantares de cada um;

O programa deve ter uma thread para cada filósofo e deve trabalhar com mutex (ou qualquer coisa similar na sua linguagem).
Outra opção é fazer o projeto com forks e semáforos.

FT_Minitalk 👂🗨️

Fazer uma simples comunicação entre 2 programas, um cliente que recebe um PID e uma string e deve enviar o texto dessa string para o servidor via sinais (SIGUSR1 e SIGUSR2 de preferência), e o servidor vai exibir seu PID, receber uma string por bits e imprimir essa string.

FT_Pushswap 🔄️⤴️⤵️

Um programa baseado na Torre de Hanói, onde você deve ordenar uma sequência numérica usando 2 stacks, como você só tem 2 "torres" ao invés de 3, você tem mais liberdade com os movimentos para a stack A e B, desde empurrar um número do topo da stack A para o topo da B e vice-versa, rotacionar eles 1 posição para baixo, rotacionar eles 1 posição para cima, até trocar os 2 números do topo da stack A ou B. A regra de números grandes não poderem ficar em cima de números pequenos é descartada por motivos óbvios.

FT_Minishell 🔥

Simplesmente recrie o bash... Não ele inteiro, mas sim:

executar comandos baseados no PATH, caminho relativo e absoluto;
expandir variáveis de ambiente;
refazer as builtins env, export, cd, echo, pwd, unset e exit;
lidar com Ctrl+D, Ctrl+\ e Ctrl+C;
redirecionamentos e heredoc;
Histórico de comandos;

Para facilitar um pouco, você pode usar uma biblioteca de readline, aspas abertas podem ser um erro, a única opção de builtin que precisa ser feito é o -n do echo e o heredoc não precisa ser parte do histórico... De resto, boa sorte (você vai precisar).

FT_Solong 🕹️

Um simples jogo 2D onde o jogador deve coletar itens e depois ir até a saída. O programa deve ler o mapa a partir de um arquivo onde caracteres representam:

1 parede;
0 espaço vazio;
c coletável;
e saída;
p posição inicial do personagem;

FT_Fdf 🪢

A simples renderização de um modelo de arame, o programa deve ler de um arquivo a configuração de cada ponto e vértice desse modelo, onde a posição horizontal e vertical no arquivo é igual à posição x e y e o valor de cada posição representa a altura no eixo z.

FT_Fractol ❄️

A renderização de fractais sendo só obrigatório o conjunto Mandelbrot e o conjunto Julia.

FT_Cub3d 🎮

Similar ao solong, porém a renderização é feita com raycasting, não há coletáveis nem saída e a posição inicial agora é representada por N, S, W ou E.

FT_Minirt 🩻

Renderização de objetos com luz e sombra com raytracing, os objetos são apenas uma esfera, um plano e um cilindro.
Um arquivo possui informações sobre cada objeto da cena, a posição da câmera, a rotação de cada objeto, a origem da luz, a força da luz ambiente e a direção da câmera.

FT_Irc 💬🗨️

Criação de um servidor que recebe e responde requisições do protocolo IRC.

FT_Webserv 🛜

Criação de um servidor que recebe e responde requisições do protocolo HTTP.

IN CONCLUSION

Existe mais um projeto que pode ser interessante, mas vou optar por ocultá-lo.
Escolhi os projetos anteriores por explorarem conceitos como threads, processos, bibliotecas gráficas, parsing e sockets, creio que esses são conceitos que toda linguagem deve permitir e logo te fazem explorar todas as capacidades de uma linguagem... Ou a falta delas.

Herança, Abstração e Interface com Street Fighter

Andrey_vdl — Fri, 15 Mar 2024 01:16:34 +0000

Olá mundo!
Vim aqui trazer alguns exemplos em C++ como funcionam classes, classes abstratas e interfaces.
Para que o texto fique mais claro para todos e possa ser adaptado para outras linguagens, a keyword "virtual" e a implementação de um método puramente virtual de C++ serão substituídas por macros.
PS. eu não sou um sênior, então tudo escrito aqui é do ponto de vista de um júnior que aprendeu POO recentemente.
pps. diante de feedbacks ficou claro que você precisa ter um mínimo de background para entender esse texto por completo, então eu recomendo pesquisar um pouco sobre como criar classes e o que é overload de função, pode ser qualquer linguagem, o importante é que você entenda o básico.

Index 🔗

Começando
Classe
Classe Abstrata
Interface
conclusão

Começando 🔰

Bom, para começar tenho que falar um pouco sobre Street Fighter para aqueles que não conhecem.
Street Fighter se trata de uma franquia de jogos de luta 2D, normalmente no padrão 1 VS 1 com melhor de 3.
Street Fighter tem mecânicas bem básicas, cada personagem tem uma barra de vida e uma barra de super, podem executar golpes fracos, golpes fortes, derrubadas, defesas, saltos, golpes no ar, golpes especiais e super golpes, mas no nosso caso só vamos nos preocupar com a barra de vida, a barra de super, golpes especiais e super golpes.

Classe 🤵‍♂️

Uma classe se trata de um molde de algo, normalmente chamamos uma instância desse molde de objeto, é daí que vem o termo "Programação Orientada a Objeto" (POO).
No caso desse texto iremos fazer moldes de personagens de Street Fighter, para não ficar muito longo vamos só fazer 2 deles, Ryu e Chun-Li.

#include <iostream>

#define CONSTRUTOR
#define DESTRUTOR

class Ryu {
public:
  int vida;
  int super;

  CONSTRUTOR Ryu( void ): vida( 100 ), super( 0 ) { };
  DESTRUTOR  ~Ryu( void ) { };
  // ... implementacao das outras acoes
  void       especialHadoken( void ) { };
  void       especialTatsumaki( void ) { };
  void       especialShoryuken( void ) { };
  void       superShinkuHadoken( void ) { };
  void       superShinShoryuken( void ) { };
};

class ChunLi {
public:
  int vida;
  int super;

  CONSTRUTOR ChunLi( void ): vida( 100 ), super( 0 ) { };
  DESTRUTOR  ~ChunLi( void ) { };
  // ... implementacao das outras acoes
  void       especialSpinningBirdKick( void ) { };
  void       especialHyakuretsukyaku( void ) { };
  void       especialKikoken( void ) { };
  void       superKikosho( void ) { };
  void       superHoyokusen( void ) { };
};

Ok, por enquanto isso parece bom, mas eu honestamente cortei parte dos especiais da Chun-Li e do Ryu, leve em consideração que também não implementei o que cada especial e super faz, quanto de dano causam e quanto da barra de super usam. Outro ponto negativo de fazer a classe diretamente é que o código se tornaria menos genérico, você teria que configurar um caminho para cada luta possível (ou fazer infinitos overload de função) e Street Fighter tem mais de 32 personagens (o número de combinações é X^2 considerando que você pode colocar um personagem para lutar consigo mesmo, com 44 você tem 1,936 combinações possíveis) e a cada novo jogo (ou DLC ou nova versão para a Capcom coletar uma grana) temos mais personagens.

Classe Abstrata 👨👔

Se uma classe é um molde, uma classe abstrata é o molde do molde. A forma mais simples de eu explicar uma classe abstrata é com fruta, imagine que de um lado você tem uma classe maçã e do outro uma classe banana, a classe abstrata de ambas é uma classe chamada fruta, pois o molde de uma maçã e uma banana é uma fruta, as duas tem nutrientes diferentes, formatos diferentes, sabores diferentes, mas ambas são classificadas como frutas (em um jogo você poderia classificar elas numa classe abstrata como item de cura ou comida).
Agora vamos abstrair Ryu e ChunLi por suas semelhanças, se você prestou atenção percebeu que eles têm em comum a barra de vida e de super.

#include <iostream>

#define CONSTRUTOR
#define DESTRUTOR
#define IDENTIFICA virtual
#define HERDA_DE : public

class ALutador {
public:
  int vida;
  int super;

  CONSTRUTOR           ALutador( void ): vida( 100 ), super( 0 ) { };
  IDENTIFICA DESTRUTOR ~ALutador( void ) { };
};

class Ryu HERDA_DE ALutador {
public:

  CONSTRUTOR Ryu( void ): ALutador( ) { };
  DESTRUTOR  ~Ryu( void ) { };
  // ... implementacao das outras acoes
  void       especialHadoken( void ) { };
  void       especialTatsumaki( void ) { };
  void       especialShoryuken( void ) { };
  void       superShinkuHadoken( void ) { };
  void       superShinShoryuken( void ) { };
};

class ChunLi HERDA_DE ALutador {
public:
  CONSTRUTOR ChunLi( void ): ALutador( ) { };
  DESTRUTOR  ~ChunLi( void ) { };
  // ... implementacao das outras acoes
  void       especialSpinningBirdKick( void ) { };
  void       especialHyakuretsukyaku( void ) { };
  void       especialKikoken( void ) { };
  void       superKikosho( void ) { };
  void       superHoyokusen( void ) { };
};

Além de termos diminuído o código de cada classe, agora não precisamos codar um caminho para cada luta possível, visto que um objeto da classe pai consegue guardar uma classe filho (eu sei que muitas pessoas vão falar que uma classe abstrata não pode ser instanciada, porém, em C++ isso só acontece quando você tem um método puramente virtual), então agora só temos 1 caminho, uma função que recebe dois ALutador podem ser tanto 2 Ryu, 2 ChunLi ou 1 Ryu e 1 ChunLi (esse é o famoso conceito de polimorfismo), porém ainda temos um problema, se passarmos um Ryu como ALutador para lutar, ele não vai conseguir executar nenhum tipo de ataque, pois cada personagem tem um nome diferente de ataque.

Interface 🔦

Se classe abstrata é um molde de molde, podemos comparar interfaces como uma lanterna que vem sem pilhas, isso, pois a principal diferença entre classes abstratas e interfaces é que interfaces não possuem variáveis, apenas funções.
Vamos deixar Ryu e ChunLi mais genéricos para que não tenhamos que descubrir quem são.

#include <iostream>

#define CONSTRUTOR
#define DESTRUTOR
#define IDENTIFICA virtual
#define HERDA_DE : public
#define SEM virtual
#define IMPLEMENTACAO = 0

class IGolpes {
public:
  DESTRUTOR virtual ~IGolpes( void );
  SEM void      especial1( void ) IMPLEMENTACAO;
  SEM void      especial2( void ) IMPLEMENTACAO;
  SEM void      especial3( void ) IMPLEMENTACAO;
  SEM void      super1( void ) IMPLEMENTACAO;
  SEM void      super2( void ) IMPLEMENTACAO;
};

class ALutador HERDA_DE IGolpes {
public:
  int vida;
  int super;

  CONSTRUTOR           ALutador( void ): vida( 100 ), super( 0 ) { };
  IDENTIFICA DESTRUTOR ~ALutador( void ) { };
};

class Ryu HERDA_DE ALutador {
public:

  CONSTRUTOR Ryu( void ): ALutador( ) { };
  DESTRUTOR  ~Ryu( void ) { };
  // ... implementacao das outras acoes
  void       especial1( void ) { };
  void       especial2( void ) { };
  void       especial3( void ) { };
  void       super1( void ) { };
  void       super2( void ) { };
};

class ChunLi HERDA_DE ALutador {
public:
  CONSTRUTOR ChunLi( void ): ALutador( ) { };
  DESTRUTOR  ~ChunLi( void ) { };
  // ... implementacao das outras acoes
  void       especial1( void ) { };
  void       especial2( void ) { };
  void       especial3( void ) { };
  void       super1( void ) { };
  void       super2( void ) { };
};

Ok não reduzimos o código de Ryu e ChunLi, isso, pois fizemos com que Ryu e ChunLi tivessem métodos genéricos de especiais e supers, e vocês podem até pensar que seria melhor só implementar com o nome genérico, porém implementar por uma interface permite facilitar a expansão, afinal cada personagem pode ter 3 especiais, mas alguns podem ter 4, 6, 9, a interface permite que tenhamos 9 especiais e que apenas 3 deles sejam implementados para o Ryu e 4 deles para a ChunLi.

Conclusão 🏁

Espero que tenham gostado e entendido um pouco, vou deixar uma main aqui no final com um exemplo simples com o Ryu, e vou propor um desafio para quem quer mais.

#include <iostream>

#define CONSTRUTOR
#define DESTRUTOR
#define IDENTIFICA virtual
#define HERDA_DE : public
#define SEM virtual
#define IMPLEMENTACAO = 0

class IGolpes {
public:
  virtual ~IGolpes( void ) { 
    std::cout << "CONTINUE?" << std::endl;
  };
  SEM void especial1( void ) IMPLEMENTACAO;
  SEM void especial2( void ) IMPLEMENTACAO;
  SEM void especial3( void ) IMPLEMENTACAO;
  SEM void super1( void ) IMPLEMENTACAO;
  SEM void super2( void ) IMPLEMENTACAO;
};

class ALutador HERDA_DE IGolpes {
public:
  int vida;
  int super;

  CONSTRUTOR           ALutador( void ): vida( 100 ), super( 0 ) { };
  IDENTIFICA DESTRUTOR ~ALutador( void ) {
    std::cout << "YOU LOSE!" << std::endl;
  };
};

class Ryu HERDA_DE ALutador {
public:

  CONSTRUTOR Ryu( void ): ALutador( ) { };
  DESTRUTOR  ~Ryu( void ) {
    std::cout << "K.O!" << std::endl;
  };
  // ... implementacao das outras acoes
  void       especial1( void ) {
    std::cout << "HADOKEN!" << std::endl;
    super += 25;
  };
  void       especial2( void ) { };
  void       especial3( void ) { };
  void       super1( void ) {
    if (super >= 50) {
      std::cout << "SHINKU HADOKEN!" << std::endl;
      super -= 50;
    }
  };
  void       super2( void ) { };
};

class ChunLi HERDA_DE ALutador {
public:
  CONSTRUTOR ChunLi( void ): ALutador( ) { };
  DESTRUTOR  ~ChunLi( void ) { };
  // ... implementacao das outras acoes
  void       especial1( void ) { };
  void       especial2( void ) { };
  void       especial3( void ) { };
  void       super1( void ) { };
  void       super2( void ) { };
};

int main()
{
    ALutador* ryu = new Ryu();

    ryu->especial1();
    ryu->especial1();
    ryu->especial1();
    ryu->super1();

    delete ryu;
    return 0;
}

O desafio é: adaptar isso para outros jogos, como as classes de armas de um Call of Duty ou Battlefield, ou então criar um bestiário de inimigos igual o de Castlevania Symphony of the Night, ou os diferentes carros de um Forza Horizon.
Bom isso é tudo, obrigado por ler até o final, como recompensa fique com esse momento épico no mundo dos jogos onde o jogador Daigo (jogando com o Ken) vira uma partida que ele tinha praticamente perdido.

edit 2024/03/23: adicionado pps.

Básico Sobre A MiniLibX

Andrey_vdl — Fri, 26 Jan 2024 22:00:00 +0000

Introdução

Olá, pessoal, hoje eu gostaria de fazer um pequeno tutorial sobre usar a MLX francesa.
Por mais que ela seja ruim, ela é bem básica, mas mesmo assim pega gente de surpresa.
PS. Esse texto é para dar um pequeno guia para quem tentou fazer algo e recebeu um segfault na cara.

Tabela de conteúdo

Começando
Imagens
Teclado
Mouse
XPM
Problemas Com A Produção
Vídeo

Começando

Bom todo projeto começa com uma preparação e a minha foi de fazer um simples Makefile:

TARGET=Pong.exec
LIB_MLX=minilibx/libmlx.a
FLAGS=-Wall -Wextra -Werror
MLX_FLAGS=-lXext -lX11 -lm -lz
SOURCES=main.c

all: ${TARGET}

${LIB_MLX}:
    @make -C minilibx

${TARGET}: ${LIB_MLX} ${SOURCES}
    cc ${FLAGS} -g3 -Iminilibx ${SOURCES} minilibx/libmlx.a -o ${TARGET} ${MLX_FLAGS}

clean:
    rm -f ${TARGET}
.PHONY: clean

re: clean all
.PHONY: re

Depois disso seguimos com uma main bem simples e direta:

#include "minilibx/mlx.h"
#include <stdlib.h>

typedef struct ClassMlx
{
  void* mlx;
  void* win;
} ClassMlx;

int main(void)
{
  ClassMlx* engine = calloc(1, sizeof(ClassMlx));
  int ret = 0;

  ret = initEngine(engine);
  if (ret < 0) {
    free(engine);
    return (ret);
  }
  mlx_loop(engine->mlx);
  destroyEngine(engine);
  free(engine);
  return (0);
}

int initEngine(ClassMlx* engine)
{
  engine->mlx = mlx_init();
  if (engine->mlx == NULL) {
    return (-1);
  }
  engine->win = mlx_new_window(engine->mlx, 800, 600, "PONG");
  if (engine->win == NULL) {
    mlx_destroy_display(engine->mlx);
    free(engine->mlx);
    return (-2);
  }
  return (0);
}

void destroyEngine(ClassMlx* engine)
{
  mlx_destroy_window(engine->mlx, engine->win);
  mlx_destroy_display(engine->mlx);
  free(engine->mlx);
}

Não vou entrar em muitos detalhes sobre como as coisas funcionam debaixo dos panos, mas citei um pouco na minha documentação, vamos focar na produção. Nesse momento ao rodar o código temos uma tela preta que não fecha, por isso faça Ctrl+C no terminal.

Imagens

Bom vamos alterar um pouco o código para desenhar um quadrado branco na tela

#include "minilibx/mlx.h"
#include <stdlib.h>

typedef struct ClassMlx
{
  void* mlx;
  void* win;
  void* img;
} ClassMlx;

int main(void)
{
  ClassMlx* engine = calloc(1, sizeof(ClassMlx));
  int ret = 0;

  ret = initEngine(engine);
  if (ret < 0) {
    free(engine);
    return (ret);
  }
  mlx_loop_hook(engine->mlx, renderGame, engine);
  mlx_loop(engine->mlx);
  destroyEngine(engine);
  free(engine);
  return (0);
}


int initEngine(ClassMlx* engine)
{
  engine->mlx = mlx_init();
  if (engine->mlx == NULL) {
    return (-1);
  }
  engine->win = mlx_new_window(engine->mlx, 800, 600, "PONG");
  if (engine->win == NULL) {
    mlx_destroy_display(engine->mlx);
    free(engine->mlx);
    return (-2);
  }
  engine->img = mlx_new_image(engine->mlx, 800, 600);
  if (engine->img == NULL) {
    mlx_destroy_window(engine->mlx, engine->win);
    mlx_destroy_display(engine->mlx);
    free(engine->mlx);
    return (-3);
  }
  return (0);
}

int renderGame(void* param)
{
  ClassMlx* engine = (ClassMlx*)param;

  renderMap(engine);
  mlx_put_image_to_window(engine->mlx, engine->win, engine->img, 0, 0);
  return (0);
}

void renderMap(ClassMlx* engine)
{
  for (int y = 0; y < 300; y++) {
    for (int x = 0; x < 400; x++) {
      drawPixel(engine->img, x, y, 0xFFFFFF);
    }
  }
}

void drawPixel(void* img, int x, int y, int color)
{
  int bpp = 0;
  int size_line = 0;
  int endian = 0;
  char* data = mlx_get_data_addr(img, &bpp, &size_line, &endian);
  char* pixel = NULL;

  /*
   * explicacao da formula:
   * (y * size_line) = posicao vertical com base na largura da imagem.
   * (bpp / 8) = converte os bytes da imagem em uma linha de pixels
   * (x * (bpp / 8)) = escolhe o pixel da linha
   */
  pixel = data + (y * size_line) + (x * (bpp / 8));
  *(int*)pixel = color;
}

void destroyEngine(ClassMlx* engine)
{
  mlx_clear_window(engine->mlx, engine->win);
  mlx_destroy_image(engine->mlx, engine->img);
  mlx_destroy_window(engine->mlx, engine->win);
  mlx_destroy_display(engine->mlx);
  free(engine->mlx);
}

Com isso você deve ter uma tela preta com um retângulo branco no canto superior esquerdo.

Vou só fazer uma pequena edição de uma função para nunca mais mexer nela (se você fizer a mesma alteração vai ter uma linha no meio da tela).

void renderMap(ClassMlx* engine)
{
  for (int y = 0; y < 600; y++) {
    drawPixel(engine->img, 400, y, 0xFFFFFF);
  }
}

Teclado

Vamos mexer de novo com a main para poder controlar a raquete de pong (também aproveitei e adicionei um hook na função setEngine que permite fechar a janela com o botão X):

#include "minilibx/mlx.h"
#include <X11/X.h>
#include <X11/keysym.h>
#include <stdlib.h>

typedef struct ClassPlayer
{
  int x;
  int y;
  int moveStyle;
} ClassPlayer;

typedef struct ClassMlx
{
  void* mlx;
  void* win;
  void* img;
  ClassPlayer player;
} ClassMlx;

int main(void)
{
  ClassMlx* engine = calloc(1, sizeof(ClassMlx));
  int ret = 0;

  ret = initEngine(engine);
  if (ret < 0) {
    free(engine);
    return (ret);
  }
  setEngine(engine);
  mlx_loop(engine->mlx);
  destroyEngine(engine);
  free(engine);
  return (0);
}

int initEngine(ClassMlx* engine)
{
  engine->player.x = 0;
  engine->player.y = 300;
  engine->player.moveStyle = 0;
  engine->mlx = mlx_init();
  if (engine->mlx == NULL) {
    return (-1);
  }
  engine->win = mlx_new_window(engine->mlx, 800, 600, "PONG");
  if (engine->win == NULL) {
    mlx_destroy_display(engine->mlx);
    free(engine->mlx);
    return (-2);
  }
  engine->img = mlx_new_image(engine->mlx, 800, 600);
  if (engine->img == NULL) {
    mlx_destroy_window(engine->mlx, engine->win);
    mlx_destroy_display(engine->mlx);
    free(engine->mlx);
    return (-3);
  }
  return (0);
}

void setEngine(ClassMlx* engine)
{
  mlx_key_hook(engine->win, keyEvents, engine);
  mlx_hook(engine->win, DestroyNotify, NoEventMask, mlx_loop_end, engine->mlx);
  mlx_loop_hook(engine->mlx, renderGame, engine);
}

int keyEvents(int keycode, void* param)
{
  ClassMlx* engine = (ClassMlx*)param;

  if (keycode == XK_Up && engine->player.y > 10) {
    engine->player.y -= 10;
  }
  if (keycode == XK_Down && engine->player.y < 590) {
    engine->player.y += 10;
  }
  if (keycode == XK_space) {
    engine->player.moveStyle = !engine->player.moveStyle;
  }
  if (keycode == XK_Escape) {
    mlx_loop_end(engine->mlx);
    return (0);
  }
  return (0);
}

int renderGame(void* param)
{
  ClassMlx* engine = (ClassMlx*)param;

  // esse for e para limpar a imagem antes de pintar ela de novo.
  for (int y = 0; y < 600; y++) {
    for (int x = 0; x < 800; x++) {
      drawPixel(engine->img, x, y, 0);
    }
  }
  renderMap(engine);
  renderPlayer(engine);
  mlx_put_image_to_window(engine->mlx, engine->win, engine->img, 0, 0);
  return (0);
}

void renderPlayer(ClassMlx* engine)
{
  for (int pos_x = 0; pos_x < 5; pos_x++) {
    for (int pos_y = engine->player.y - 10; pos_y < engine->player.y + 10; pos_y++) {
      if (pos_y < 0 || pos_y >= 600) {
        continue;
      }
      drawPixel(engine->img, pos_x, pos_y, 0xFF0000);
    }
  }
}

Só de extra vamos adicionar os placares:

int renderGame(void* param)
{
  ClassMlx* engine = (ClassMlx*)param;

  for (int y = 0; y < 600; y++) {
    for (int x = 0; x < 800; x++) {
      drawPixel(engine->img, x, y, 0);
    }
  }
  renderMap(engine);
  renderPlayer(engine);
  mlx_put_image_to_window(engine->mlx, engine->win, engine->img, 0, 0);
  mlx_string_put(engine->mlx, engine->win, 200, 42, 0xFF00, "0");
  mlx_string_put(engine->mlx, engine->win, 600, 42, 0xFF00, "0");
  return (0);
}

Mouse

Vocês devem ter notado que configurei o espaço para alterar uma variável, mas ele não é utilizada em lugar nenhum, pois agora vamos utiliza-la:

int renderGame(void* param)
{
  ClassMlx* engine = (ClassMlx*)param;

  for (int y = 0; y < 600; y++) {
    for (int x = 0; x < 800; x++) {
      drawPixel(engine->img, x, y, 0);
    }
  }
  movePlayerMouse(engine);
  renderMap(engine);
  renderPlayer(engine);
  mlx_put_image_to_window(engine->mlx, engine->win, engine->img, 0, 0);
  mlx_string_put(engine->mlx, engine->win, 200, 42, 0xFF00, "0");
  mlx_string_put(engine->mlx, engine->win, 600, 42, 0xFF00, "0");
  return (0);
}

void movePlayerMouse(ClassMlx* engine)
{
  int x = 0;
  int y = 0;

  if (engine->player.moveStyle == 0) {
    return;
  }
  mlx_mouse_get_pos(engine->mlx, engine->win, &x, &y);
  (void)x;
  if (y > 10 && y < 590) {
    engine->player.y = y;
  }
}

Sei que para algumas pessoas parece certo utilizar a mlx_mouse_hook para pegar o movimento do mouse, mas, na verdade do metódo que fiz agora, podemos pegar a posição do mouse antes de renderizar a raquete (sem contar que o mouse_hook só é ativado quando o mouse tem um clique ou scroll).

XPM

XPM é um formato de imagem bem desconhecido, mas que conquiste em um array de string do C.

/* XMP3 */
static char *place_holder[] = {
"5 30 2 1",
"+ c #FFFFFF",
"- c #0000FF",
"+----",
"++---",
"+++--",
"++++-",
"+++++",
"+++++",
"+++++",
"+++++",
"+++++",
"+++++",
"+++++",
"+++++",
"+++++",
"+++++",
"+++++",
"+++++",
"+++++",
"+++++",
"+++++",
"+++++",
"+++++",
"+++++",
"+++++",
"+++++",
"+++++",
"+++++",
"++++-",
"+++--",
"++---",
"+----"
};

Pra facilitar as coisas a MiniLibX só aceita XPM e ela carrega como uma imagem igual a mlx_new_image:

int renderGame(void* param)
{
  ClassMlx* engine = (ClassMlx*)param;

  for (int y = 0; y < 600; y++) {
    for (int x = 0; x < 800; x++) {
      drawPixel(engine->img, x, y, 0);
    }
  }
  movePlayerMouse(engine);
  renderMap(engine);
  // renderPlayer(engine);
  mlx_put_image_to_window(engine->mlx, engine->win, engine->img, 0, 0);
  mlx_string_put(engine->mlx, engine->win, 200, 42, 0xFF00, "0");
  mlx_string_put(engine->mlx, engine->win, 600, 42, 0xFF00, "0");
  renderPlayer2(engine);
  return (0);
}

void renderPlayer2(ClassMlx* engine)
{
  int width = 0;
  int height = 0;
  void* texture = mlx_xpm_file_to_image(engine->mlx, "./raquete.xpm", &width, &height);

  if (engine->player.y > 0 && engine->player.y < 600) {
    mlx_put_image_to_window(engine->mlx, engine->win, texture, engine->player.x, engine->player.y);
  }
}

Preste atenção na ordem das put_image_to_window se não você vai ter apenas uma tela preta com uma linha no meio e dois números.

E pronto, acho que isso é realmente o básico que você precisa pra fazer algo com a MiniLibX, claro existem muitas outras funções, mas como citei você pode achar elas na minha documentação.

Problemas Com A Produção

Se você não falha em pelo menos 90% das vezes, seus objetivos não foram ambiciosos o suficiente. - KAY, Alan

Que ótima frase para começar essa seção (honestamente peguei ela quando comecei a escrever isso), isso, pois montar esse tutorial foi uma grande falha.
Para começar, a primeira falha foi do primeiro vídeo, que ficou parecendo uma reunião de PowerPoint (essa parte foi cortada do vídeo final).
A segunda foi eu ter que lidar com o Vim depois de 1 ano sem tocar nele, e ainda ter o GitHub Copilot me recomendando código errado que me fez pensar que eu não lembrava mais como codar com a MiniLibX.
Já a terceira falha foi o fato de tentar gravar áudio no calor com o ventilador desligado.
A quarta falha foi ver que eu leio um tele prompt mais rápido do que o texto sobe.
E a quinta falha foi por não conseguir gravar áudio porque o microfone do meu notebook não é sensível, o que me obrigaria a gritar.
Com isso, tudo o que sobrou foi um roteiro e um vídeo que se tornaram esse post.