Category: Notes

  • Donki Hills está oficialmente no Steam há mais de um ano!

    Donki Hills está no Steam há mais de um ano!

    Há exatamente um ano o projeto apareceu na página do Steam e, desde então, o jogo já percorreu um longo caminho. Durante esse tempo, houve muitos experimentos, mudanças e buscas pela direção em que Donki Hills deveria se desenvolver.

    O trabalho na jogabilidade continua e agora o projeto está gradualmente adquirindo sua verdadeira face. Donki Hills está começando a se transformar no que deveria ser – Comédia em primeira pessoa Roguelike Parody Survival Horror.

    Uma estranha aventura onde o terror encontra o humor, a exploração e situações inesperadas. Você tem que ir até a cidade, procurar objetos, resolver enigmas e aos poucos desvendar o segredo que o levará até Maria.

    Abaixo estão novas capturas de tela do próximo teste do protótipo. Este ainda não é o visual final do jogo, mas já dá para sentir o clima da cidade e o rumo que o projeto está tomando.

    Muito interessado em ouvir sua reação! 👀
    O que você acha da nova direção? Quais são suas impressões sobre a atmosfera e ideias do jogo?

    Obrigado a todos que adicionaram Donki Hills à sua lista de desejos, acompanham o desenvolvimento e apoiam o projeto ❤️

    Ainda há muitos experimentos, novas mecânicas e estranhas aventuras pela frente.

    https://store.steampowered.com/app/3476390/Donki_Hills/

  • Ignorando o afogamento em processadores de laptops para jogos

    Os fabricantes de laptops para jogos modernos geralmente configuram os sistemas para que o processador aqueça até 90 graus e até atinja 100 graus Celsius sob carga. Este problema é especialmente grave no verão, durante a execução de jogos exigentes ou tarefas de trabalho pesadas.

    Devido ao aquecimento extremo, o afogamento é ativado (redefinindo as frequências do processador para evitar danos físicos), o que leva a uma perda acentuada de desempenho, congelamentos e queda no FPS. Há muitas maneiras de combater o superaquecimento (desde o uso de placas de resfriamento até a subvoltagem), mas neste artigo descreverei o método mais simples e rápido que é relevante para o Windows 11 e versões anteriores do sistema operacional.

    O método consiste em limitar o estado máximo do processador por meio das configurações da fonte de alimentação:

    1. Abra Opções de energia por meio da Pesquisa do Windows ou do Painel de controle.
    2. No plano de energia ativo, vá para a seção de alteração de parâmetros adicionais.
    3. Encontre a ramificação Gerenciamento de energia do processador.
    4. Expanda a opção Estado máximo do processador.
    5. Para Conectado, altere o valor de 100% para 80% ou menos.

    Depois de aplicar essas configurações, o processador não fará mais overclock automático para frequências extremas que geram excesso de calor. Embora o desempenho máximo máximo diminua em aproximadamente 20%, o processador não superaquecerá mais. A operação estável em uma frequência reduzida sem estrangulamento é MUITO melhor e mais confortável para o sistema do que saltos bruscos e constantes no desempenho devido ao superaquecimento em temperaturas abaixo de 100 graus.

    Cada laptop é único, por isso recomendo que os usuários experimentem e encontrem o equilíbrio ideal (porcentagem) que fornecerá o desempenho desejado sem superaquecimento.

  • Portando Surreal Engine C++ para WebAssembly

    Neste post irei descrever como portei o motor de jogo Surreal Engine para WebAssembly.
    https://demensdeum.com/demos/SurrealEngine/”
    Motor Surreal – um motor de jogo que implementa a maior parte das funcionalidades do Unreal Engine 1, jogos famosos neste motor – Torneio Unreal 99, Unreal, Deus Ex, Imortal. Refere-se a mecanismos clássicos que funcionavam principalmente em um ambiente de execução de thread único.
    Originalmente tive a ideia de assumir um projeto que não conseguiria concluir em um prazo razoável, mostrando assim aos meus seguidores do Twitch que existem projetos que nem eu consigo realizar. Durante minha primeira transmissão, de repente percebi que a tarefa de portar o Surreal Engine C++ para WebAssembly usando Emscripten era viável.

    Um mês depois, posso demonstrar meu conjunto de garfo e motor no WebAssembly:
    https://demensdeum.com/demos/SurrealEngine/
    O controle, como no original, é feito por meio das setas do teclado. A seguir, pretendo adaptá-lo para controle móvel (tachi), adicionando iluminação correta e outros recursos gráficos da renderização do Unreal Tournament 99.

    Por onde começar?

    A primeira coisa que quero dizer é que qualquer projeto pode ser portado de C++ para WebAssembly usando Emscripten, a única dúvida é quão completa será a funcionalidade. Escolha um projeto cujas portas de biblioteca já estejam disponíveis para Emscripten; no caso do Surreal Engine, você tem muita sorte, pois o motor usa o SDL 2, OpenAL – bibliotecas. ambos foram portados para o Emscripten. No entanto, Vulkan é usado como uma API gráfica, que atualmente não está disponível para HTML5, o trabalho está em andamento para implementar WebGPU, mas também está em fase de rascunho, e também não se sabe quão simples será a porta adicional de Vulkan para WebGPU, depois de totalmente padronizada. Portanto, tive que escrever meu próprio renderizador básico OpenGL-ES/WebGL para Surreal Engine.

    Construindo o projeto

    Construir sistema no Surreal Engine – CMake, que também simplifica a portabilidade, porque o Emscripten fornece aos seus construtores nativos – recursos de atualização. emcmake, emmake.
    O porte do Surreal Engine foi baseado no código do meu último jogo em WebGL/OpenGL ES e C++ chamado Death-Mask, por isso o desenvolvimento foi muito mais simples, eu tinha todos os build flags necessários comigo e exemplos de código.
    Um dos pontos mais importantes em CMakeLists.txt são os flags de construção do Emscripten, abaixo está um exemplo do arquivo do projeto:

    set(CMAKE_CXX_FLAGS "-s MIN_WEBGL_VERSION=2 
    -s MAX_WEBGL_VERSION=2 
    -s EXCEPTION_DEBUG 
    -fexceptions 
    --preload-file UnrealTournament/ 
    --preload-file SurrealEngine.pk3 
    --bind 
    --use-preload-plugins 
    -Wall 
    -Wextra 
    -Werror=return-type 
    -s USE_SDL=2 
    -s ASSERTIONS=1 
    -w 
    -g4 
    -s DISABLE_EXCEPTION_CATCHING=0 
    -O3 
    --no-heap-copy 
    -s ALLOW_MEMORY_GROWTH=1 
    -s EXIT_RUNTIME=1")
    

    O próprio script de construção:

    clear
    emmake make -j 16
    cp SurrealEngine.data /srv/http/SurrealEngine/SurrealEngine.data
    cp SurrealEngine.js /srv/http/SurrealEngine/SurrealEngine.js
    cp SurrealEngine.wasm /srv/http/SurrealEngine/SurrealEngine.wasm
    cp ../buildScripts/Emscripten/index.html /srv/http/SurrealEngine/index.html
    

    A seguir, vamos preparar index.html, que inclui o pré-carregador do sistema de arquivos do projeto. Para fazer upload para a web, usei o Unreal Tournament Demo versão 338. Como você pode ver no arquivo CMake, a pasta do jogo descompactada foi adicionada ao diretório de construção e vinculada como um arquivo de pré-carregamento para Emscripten.

    Alterações principais no código

    Então tivemos que mudar o loop do jogo, você não pode executar um loop infinito, isso leva ao congelamento do navegador, em vez disso você precisa usar emscripten_set_main_loop, escrevi sobre esse recurso em minha nota de 2017 “Portando jogos SDL C++ para HTML5 (Emscripten)
    Alteramos o código para sair do loop while para if, então exibimos a classe principal do mecanismo de jogo, que contém o loop do jogo, no escopo global, e escrevemos uma função global que chamará a etapa do loop do jogo do objeto global:

    #if __EMSCRIPTEN__
    #include <emscripten.h>
    Engine *EMSCRIPTEN_GLOBAL_GAME_ENGINE = nullptr;
    void emscripten_game_loop_step() {
    	EMSCRIPTEN_GLOBAL_GAME_ENGINE->Run();
    }
    #endif
    

    Depois disso, você precisa ter certeza de que não há threads em segundo plano no aplicativo; se houver, prepare-se para reescrevê-los para execução de thread único ou use a biblioteca phtread no Emscripten.
    O thread de segundo plano no Surreal Engine é usado para reproduzir música, os dados vêm do thread do mecanismo principal sobre a faixa atual, a necessidade de tocar música ou sua ausência, então o thread de segundo plano recebe um novo estado por meio de um mutex e começa a reproduzir uma nova música ou faz uma pausa. O thread de fundo também é usado para armazenar música em buffer durante a reprodução.
    Minhas tentativas de construir o Surreal Engine para Emscripten com pthread não tiveram sucesso, porque as portas SDL2 e OpenAL foram construídas sem suporte para pthread e eu não queria reconstruí-las por causa da música. Portanto, transferi a funcionalidade do fluxo de música de fundo para execução de thread único usando um loop. Ao remover as chamadas pthread do código C++, movi o buffer e a reprodução de música para o thread principal, para que não houvesse atrasos, aumentei o buffer em alguns segundos.
    A seguir, descreverei implementações específicas de gráficos e som.

    Vulkan não é compatível!

    Sim, Vulkan não é compatível com HTML5, embora todos os folhetos de marketing apresentem suporte multiplataforma e amplo suporte de plataforma como a principal vantagem do Vulkan. Por esse motivo, tive que escrever meu próprio renderizador gráfico básico para um tipo OpenGL simplificado – – ES, é usado em dispositivos móveis, às vezes não contém os recursos modernos do OpenGL moderno, mas porta muito bem para WebGL, que é exatamente o que o Emscripten implementa. A escrita da renderização básica de blocos, renderização bsp, para a exibição da GUI mais simples e renderização de modelos + mapas foi concluída em duas semanas. Esta foi talvez a parte mais difícil do projeto. Ainda há muito trabalho pela frente para implementar todas as funcionalidades da renderização do Surreal Engine, portanto, qualquer ajuda dos leitores é bem-vinda na forma de código e solicitações pull.

    OpenAL suportado!

    A grande sorte é que o Surreal Engine usa OpenAL para saída de áudio. Depois de escrever um hello world simples em OpenAL e montá-lo em WebAssembly usando Emscripten, ficou claro para mim como tudo era simples e comecei a portar o som.
    Após várias horas de depuração, ficou óbvio que a implementação OpenAL do Emscripten possui vários bugs, por exemplo, ao inicializar a leitura do número de canais mono, o método retornava um número infinito, e após tentar inicializar um vetor de tamanho infinito, C++ trava com a exceção vector::length_error.
    Conseguimos contornar isso codificando o número de canais mono para 2048:

    		alcGetIntegerv(alDevice, ALC_MONO_SOURCES, 1, &monoSources);
    		alcGetIntegerv(alDevice, ALC_STEREO_SOURCES, 1, &stereoSources);
    
    #if __EMSCRIPTEN__
    		monoSources = 2048; // for some reason Emscripten's OpenAL gives infinite monoSources count, bug?
    #endif
    
    

    Existe uma rede?

    Atualmente, o Surreal Engine não suporta jogos online, o jogo com bots é compatível, mas precisamos de alguém para escrever IA para esses bots. Teoricamente, você pode implementar um jogo em rede no WebAssembly/Emscripten usando Websockets.

    Conclusão

    Concluindo, gostaria de dizer que a portabilidade do Surreal Engine acabou sendo bastante tranquila devido ao uso de bibliotecas para as quais existem portas Emscripten, bem como à minha experiência anterior na implementação de um jogo em C++ para WebAssembly em Emscripten. Abaixo estão links para fontes de conhecimento e repositórios sobre o tema.
    M-M-M-MATANÇA DE MONSTRO!
    Além disso, se você quiser ajudar o projeto, de preferência com código de renderização WebGL/OpenGL ES, escreva para mim no Telegram:
    https://t.me/demenscave

    Links

    https://demensdeum.com/demos/SurrealEngine/

    https://github.com/demensdeum/SurrealEngine-Emscripten

    https://github.com/dpjudas/SurrealEngine

  • Encaminhamento de porta entre clientes via Chisel: um túnel simplificado sem L3

    Quando dois dispositivos estão protegidos por NAT ou firewalls rígidos e não podem “ver” um ao outro diretamente, uma VPN parece ser a solução padrão. Mas um túnel L3 completo (como WireGuard ou OpenVPN) é muitas vezes redundante: requer direitos de root, configuração de interfaces virtuais e pode entrar em conflito com rotas existentes.

    Nesses casos, é conveniente usar Chisel – um túnel TCP/UDP que roda sobre HTTP e usa WebSockets para transferência de dados. Nesta nota mostrarei como “encaminhar” uma porta de um cliente para outro através de um servidor intermediário.

    Como funciona?

    Imagine a situação: você tem o Cliente A (por exemplo, seu servidor doméstico), o Cliente B (seu laptop de trabalho) e um VPS com endereço IP público. Os clientes A e B podem acessar o VPS, mas não um ao outro.

    O esquema de encaminhamento ficará assim:
    1. O Cliente A conecta-se ao VPS e abre uma porta “reversa” no servidor. Agora tudo que chega na porta X do servidor vai para a porta Y do Cliente A.
    2. O Cliente B conecta-se ao VPS e encaminha a porta Z de sua máquina local para a porta X do servidor.
    3. Como resultado, o Cliente B acessa localhost:Z e termina em Cliente A:Y.

    Esta abordagem é uma das soluções nos casos em que a comunicação com um VPS não implementa uma camada L3 ou não há capacidade de configurar o roteamento entre clientes. Trabalhamos exclusivamente a nível de aplicação e porto.

    Etapa 1: iniciar o servidor

    No seu VPS, basta executar o Chisel no modo servidor. O sinalizador --reverse é necessário para permitir que os clientes abram portas no lado do servidor.

    chisel server --port 8080 --reverse
    

    Etapa 2: Conectando o Cliente A (Fonte)

    Digamos que o Cliente A queira abrir o acesso ao seu servidor web local na porta 3000. Ele se conecta ao VPS e diz: “reserve a porta 2000 no servidor e encaminhe para mim para 3000”.

    chisel client vps-ip:8080 R:2000:127.0.0.1:3000
    

    Agora a porta 2000 no VPS (na interface de loopback) leva ao Cliente A.

    Etapa 3: Conectando o Cliente B (Consumidor)

    Agora o Cliente B deseja acessar este recurso. Ele se conecta ao mesmo VPS e encaminha sua porta local 8080 para a porta 2000 do servidor.

    chisel client vps-ip:8080 8080:127.0.0.1:2000
    

    Preparar! Agora, ao abrir http://localhost:8080 no Cliente B, você verá o serviço em execução no Cliente A.

    Segurança e nuances

    Chisel suporta autenticação através do sinalizador --auth, que é altamente recomendado ao trabalhar através de servidores públicos. Você também pode usar certificados TLS para criptografar o tráfego.

    A principal vantagem desta abordagem é que não há necessidade de dispositivos TUN/TAP e tabelas de roteamento complexas. Este é um túnel simplificado que faz exatamente uma coisa: vincula portas por meio de uma conexão WebSocket. Isso funciona até mesmo por meio de proxies corporativos se você configurar o Chisel para funcionar pela porta 443.

    Saída

    Chisel é um utilitário para tarefas específicas de rede. Quando você precisa encaminhar portas entre nós isolados sem configurar uma VPN completa, uma combinação de túneis de encaminhamento e reverso através de um servidor de retransmissão acaba sendo uma solução completamente viável.

    Links

    https://github.com/jpillora/chisel

  • Por que não consigo corrigir o bug?

    Você passa horas trabalhando no código, analisando hipóteses, ajustando as condições, mas o bug ainda é reproduzido. Parece familiar? Esse estado de frustração costuma ser chamado de “caça aos fantasmas”. O programa parece viver sua própria vida, ignorando suas correções.

    Um dos motivos mais comuns – e mais irritantes – para essa situação é procurar um erro no lugar completamente errado do aplicativo.

    A armadilha dos “falsos sintomas”

    Quando vemos um erro, nossa atenção é atraída para o local onde ele “disparou”. Mas em sistemas complexos, onde ocorre um bug (travamento ou valor incorreto) é apenas o fim de uma longa cadeia de eventos. Ao tentar consertar o final, você está lutando contra os sintomas, não contra a doença.

    É aqui que entra o conceito de fluxograma.

    Como funciona na realidade

    Claro, não é necessário desenhar (desenhar) diretamente um fluxograma no papel todas as vezes, mas é importante tê-lo em mente ou em mãos como um guia arquitetônico. Um fluxograma permite visualizar a operação de um aplicativo como uma árvore de resultados.

    Sem compreender essa estrutura, o desenvolvedor muitas vezes fica tateando no escuro. Imagine a situação: você edita a lógica em uma ramificação de condição, enquanto a aplicação (devido a um determinado conjunto de parâmetros) vai para uma ramificação completamente diferente na qual você nem pensou.

    Resultado: você gasta horas em uma correção de código “perfeita” em uma parte do algoritmo, o que, é claro, não faz nada para corrigir o problema em outra parte do algoritmo onde ele realmente falha.


    Algoritmo para derrotar um bug

    Para parar de bater em uma porta fechada, você precisa mudar sua abordagem ao diagnóstico:

    • Encontre o estado na árvore de resultados:Antes de escrever o código, você precisa determinar exatamente o caminho que o aplicativo seguiu. Em que ponto a lógica tomou o rumo errado? Qual estado específico (Estado) levou ao problema?
    • A reprodução tem 80% de sucesso: Isso geralmente é feito por testadores e testes automatizados. Se o bug estiver “flutuante”, o desenvolvimento estará envolvido no processo de busca conjunta de condições.
    • Use o máximo de informações possível: registros, versão do sistema operacional, parâmetros do dispositivo, tipo de conexão (Wi-Fi/5G) e até mesmo uma operadora de telecomunicações específica são importantes para a localização.

    “Fotografia” do momento do erro

    Idealmente, para corrigi-lo, você precisa obter o estado completo do aplicativo no momento em que o bug foi reproduzido. Os logs de interação também são extremamente importantes: eles mostram não apenas o ponto final, mas também todo o caminho do usuário (quais ações precederam a falha). Isso ajuda a entender como recriar um estado semelhante novamente.

    Dica futura: se você encontrar um caso complexo, adicione informações estendidas de registro de depuração a esta seção do código, caso a situação aconteça novamente.


    O problema dos estados “indescritíveis” na era da IA

    Em sistemas modernos que usam LLM (Large Language Models), o determinismo clássico (“uma entrada, uma saída”) é frequentemente violado. Você pode passar exatamente os mesmos dados de entrada, mas obter um resultado diferente.

    Isso acontece devido ao não determinismo dos sistemas de produção modernos:

    • Paralelismo de GPU: as operações de ponto flutuante da GPU nem sempre são associativas. Devido à execução paralela de threads, a ordem em que os números são adicionados pode mudar ligeiramente, o que pode afetar o resultado.
    • Temperatura e aceleração da GPU: a velocidade de execução e a distribuição de carga podem depender do estado físico do hardware. Em modelos enormes, essas diferenças microscópicas se acumulam e podem levar à seleção de um token diferente na saída.
    • Lote dinâmico: Na nuvem, sua solicitação é combinada com outras. Diferentes tamanhos de lote alteram a matemática dos cálculos nos kernels.

    Sob tais condições, torna-se quase impossível reproduzir “esse mesmo estado”. Somente uma abordagem estatística aos testes pode salvá-lo aqui.


    Quando a lógica falha: problemas de memória

    Se você estiver trabalhando com linguagens “inseguras” (C ou C++), o bug pode ocorrer devido a corrupção de memória.

    Esses são os casos mais graves: um erro em um módulo pode “sobrescrever” dados em outro. Isso leva a falhas completamente inexplicáveis ​​e isoladas que não podem ser rastreadas usando a lógica normal do aplicativo.

    Como se proteger no nível arquitetônico?

    Para evitar esses bugs “místicos”, você deve usar abordagens modernas:

    • Padrões de programação multithread:a sincronização clara elimina condições de corrida.
    • Linguagens thread-safe: Ferramentas que garantem a segurança da memória em tempo de compilação:
      • Rust: o sistema de propriedade elimina erros de memória.
      • Simultaneidade Swift 6:fortes verificações de isolamento de dados.
      • Erlang: isolamento completo do processo por meio do modelo de ator.

    Resumo

    Consertar um bug não é escrever um novo código, mas entender como o antigo funciona. Lembre-se: você pode estar perdendo tempo editando uma filial que a administração nem sequer toca. Registre o estado do sistema, leve em consideração o fator de não determinismo da IA ​​e escolha ferramentas seguras.

  • Por que a documentação é sua melhor amiga

    (e como criar soluções que continuem funcionando após as atualizações)

    “Os aplicativos só podem usar APIs públicas e devem ser executados no sistema operacional atualmente enviado.” Diretrizes de revisão de aplicativos da Apple

    Se você já começou a trabalhar com um novo framework e se pegou pensando: “Agora vou entender tudo sozinho, ler a documentação é muito longo”, você definitivamente não está sozinho. Muitos de nós temos um instinto investigativo natural: tente primeiro e só depois leia as instruções. E isso é completamente normal.

    No entanto, nesta fase pode ser fácil deixar-se levar e acabar numa situação em que o código funciona muito bem, mas talvez dependa de características não óbvias do sistema.

    Por que às vezes não é suficiente simplesmente “descobrir por conta própria”?

    Frameworks, especialmente os fechados, são sistemas complexos e de múltiplas camadas. Freqüentemente, eles ocultam lógica interna e otimizações que:

    * não estão descritos em documentação pública;
    * não garantem que o comportamento será mantido no futuro;
    *pode sofrer alterações com o lançamento de novas versões;
    * pode conter recursos conhecidos pelos desenvolvedores que ainda não foram corrigidos.

    Quando agimos intuitivamente, existe o risco de construirmos arquitetura com base em observações aleatórias e não em regras documentadas. Isso pode tornar o código mais sensível a atualizações.

    A documentação não é uma limitação, mas um suporte confiável

    Os desenvolvedores de frameworks criam manuais para nos ajudar. Atuando dentro da documentação, obtemos:

    * estabilidade;
    * apoiar;
    * comportamento previsível do sistema.

    Ao ultrapassar esses limites, assumimos riscos adicionais e a manutenção desse código torna-se mais difícil.

    Experimentos? Certamente. Mas com uma compreensão dos limites.
    A curiosidade é uma ótima característica para se ter em um desenvolvedor. Explorar e experimentar coisas novas é absolutamente essencial. Mas aqui está um pequeno desejo:

    A maneira mais confortável de experimentar é confiar nas melhores práticas.

    A documentação é um mapa que mostra quais caminhos são mais seguros e suportados pelos criadores.

    Uma perspectiva externa: aconselhamento especializado

    Muitas vezes aprendemos com colegas experientes:

    * eles conduzem cursos úteis,
    * falar em conferências,
    * escrever livros e blogs maravilhosos,
    * compartilhe sua visão única.

    Muitos deles compartilham experiências verdadeiramente valiosas. Mas vale lembrar: se as abordagens do autor contrariarem a documentação oficial, podem revelar-se frágeis.

    Esses “padrões empíricos” às vezes:

    * trabalhar apenas em uma versão específica do framework;
    * sensível a atualizações;
    * pode se comportar de maneira imprevisível em situações incomuns.

    Aprender com a comunidade é ótimo e gratificante. Mas qualquer conselho, mesmo o mais confiável, deve sempre ser cuidadosamente verificado nos manuais oficiais.

    Um pouco sobre SOLID

    Três ideias dos princípios SOLID complementam perfeitamente esta abordagem:

    * Princípio Aberto/Fechado: Tente estender o comportamento por meio de APIs públicas e, se possível, não dependa de implementação oculta.
    * Princípio da Substituição de Liskov: Confie no contrato, não na implementação específica. Caso contrário, as mudanças ocultas podem levar a dificuldades inesperadas.
    * Inversão de Dependências: crie dependências em abstrações, não em detalhes.

    Na prática, isso significa que estar vinculado a detalhes internos e não documentados da estrutura torna o sistema frágil.
    Com base em interfaces públicas e contratos, obtemos:

    * melhor isolamento do código de mudanças na estrutura;
    * facilidade de teste;
    * previsibilidade e confiabilidade da arquitetura.

    E se houver um bug?

    Acontece também que tudo é feito de acordo com as regras, mas o resultado não atende às expectativas. Os frameworks evoluem e nem sempre são perfeitos. Nesses casos:

    * Construa um exemplo mínimo que reproduza o problema.
    * Certifique-se de que apenas APIs documentadas sejam usadas.
    * Envie um relatório de bug – a equipe de desenvolvimento certamente apreciará seu trabalho e tentará ajudar.

    Se o exemplo depender de soluções alternativas, será muito mais difícil para os desenvolvedores fornecerem suporte.

    Como aproveitar ao máximo a estrutura

    *Consulte a documentação.
    * Siga os guias e recomendações dos autores.
    * Experimente a funcionalidade descrita.
    * Verifique conselhos da Internet com fontes oficiais.
    * Localize bugs respeitando os contratos-quadro.

    Conclusão

    Frameworks são ferramentas poderosas com suas próprias regras de jogo. Ao esquecê-los, corremos o risco de tornar nosso código excessivamente vulnerável. Mas todos nós queremos que os produtos criados durem muito tempo e não exijam correções urgentes após cada pequena atualização.

    Manuais e documentação são um excelente suporte que ajuda a criar soluções verdadeiramente confiáveis.

    Fontes

    https://developer.apple.com/app-store/review/guidelines/
    https://en.wikipedia.org/wiki/SOLID
    https://en.wikipedia.org/wiki/API
    https://en.wikipedia.org/wiki/RTFM

  • Construindo um aplicativo C++ SDL para iOS no Linux

    Nesta nota, descreverei o procedimento para construir um aplicativo C++ SDL para iOS no Linux, assinar um arquivo ipa sem uma assinatura paga do Apple Developer e instalá-lo em um dispositivo limpo (iPad) usando macOS sem Jailbreak.

    Primeiro, vamos instalar o conjunto de ferramentas de compilação para Linux:
    https://github.com/tpoechtrager/cctools-port

    O conjunto de ferramentas precisa ser baixado do repositório e siga as instruções no site do Godot Engine para concluir a instalação:
    https://docs.godotengine.org/ru/latest/development/compiling/cross-compiling_for_ios_on_linux.html

    No momento, você precisa baixar o Xcode dmg e copiar o SDK de lá para construir o cctools-port. Esta etapa é mais fácil de concluir no macOS; basta copiar os arquivos SDK necessários do Xcode instalado. Após a montagem bem-sucedida, o terminal conterá o caminho para o conjunto de ferramentas do compilador cruzado.
    A seguir, você pode começar a construir o aplicativo SDL para iOS. Vamos abrir o cmake e adicionar as alterações necessárias para construir o código C++:

    SET(CMAKE_SYSTEM_NAME Darwin)
    SET(CMAKE_C_COMPILER arm-apple-darwin11-clang)
    SET(CMAKE_CXX_COMPILER arm-apple-darwin11-clang++)
    SET(CMAKE_LINKER arm-apple-darwin11-ld)
    
    

    Agora você pode compilar usando cmake e make, mas não se esqueça de adicionar $PATH ao conjunto de ferramentas do compilador cruzado:

    
    PATH=$PATH:~/Sources/cctools-port/usage_examples/ios_toolchain/target/bin
    
    

    Para correta vinculação com frameworks e SDL, escrevemos eles em cmake, dependências do jogo Space Jaguar por exemplo:

    
    target_link_libraries(
    ${FSEGT_PROJECT_NAME}
    ${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/libclang_rt.ios.a
    ${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/libSDL2.a
    ${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/libSDL2_mixer.a
    ${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/libSDL2_image.a
    "${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/CoreServices.framework"
    "${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/ImageIO.framework"
    "${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/Metal.framework"
    "${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/AVFoundation.framework"
    "${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/GameController.framework"
    "${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/CoreMotion.framework"
    "${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/CoreGraphics.framework"
    "${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/AudioToolbox.framework"
    "${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/CoreAudio.framework"
    "${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/QuartzCore.framework"
    "${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/OpenGLES.framework"
    "${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/UIKit.framework"
    "${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/Foundation.framework"
    )
    
    

    No meu caso, as bibliotecas SDL, SDL_Image, SDL_mixer são compiladas antecipadamente no Xcode no macOS para vinculação estática; Frameworks copiados do Xcode. Também foi adicionada a biblioteca libclang_rt.ios.a, que inclui chamadas de tempo de execução específicas do iOS, por exemplo isOSVersionAtLeast. Incluída macro para trabalhar com OpenGL ES, desabilitando funções não suportadas na versão mobile, semelhante ao Android.
    Depois de resolver todos os problemas de construção, você deverá obter o binário montado para arm. A seguir, vamos considerar a execução do binário montado em um dispositivo sem Jailbreak.
    No macOS, instale o Xcode, cadastre-se no portal da Apple, sem pagar pelo programa do desenvolvedor. Adicione uma conta no Xcode -> Preferências -> Contas, crie um aplicativo em branco e construa em um dispositivo real. Durante a montagem, o dispositivo será adicionado à sua conta de desenvolvedor gratuita. Após a montagem e lançamento, você precisa construir o arquivo; para fazer isso, selecione Dispositivo e produto iOS genérico -> Arquivo. Depois que o arquivo for compilado, extraia os arquivos incorporados.mobileprovision e PkgInfo dele. No log de construção do dispositivo, encontre a linha de codesign com a chave de assinatura correta, o caminho para o arquivo de direitos com a extensão app.xcent e copie-o.
    Copie a pasta .app do arquivo, substitua o binário no arquivo por um compilado por um compilador cruzado no Linux (por exemplo, SpaceJaguar.app/SpaceJaguar) e, em seguida, adicione os recursos necessários ao .app, verifique a integridade dos arquivos PkgInfo e incorporado.mobileprovision no .app do arquivo, copie novamente se necessário. Assinamos novamente o .app usando o comando codesign – codesign requer uma chave de entrada para assinar, o caminho para o arquivo de direitos (pode ser renomeado com uma extensão .plist)
    Após assinar novamente, crie uma pasta Payload, mova a pasta com a extensão .app para lá, crie um arquivo zip com Payload na raiz, renomeie o arquivo com a extensão .ipa. Depois disso, no Xcode, abra a lista de dispositivos e arraste e solte o novo ipa na lista de aplicativos do dispositivo; A instalação via Apple Configurator 2 não funciona para este método. Se a nova assinatura for feita corretamente, o aplicativo com o novo binário será instalado em um dispositivo iOS (por exemplo, iPad) com certificado de 7 dias, o que é suficiente para o período de teste.

    Fontes

    https://github.com/tpoechtrager/cctools-port

    https://docs.godotengine.org/ru/latest/development/compiling/cross-compiling_for_ios_on_linux.html

    https://jonnyzzz.com/blog/2018/06/13/link-error-3/

    https://stackoverflow.com/questions/6896029/re-sign-ipa-iphone

    https://developer.apple.com/library/archive/documentation/Security/Conceptual/CodeSigningGuide/Procedures/Procedures.html

  • Construa para Windows no Ubuntu MinGW CMake

    Neste post irei descrever o processo de construção de bibliotecas e aplicações para Windows usando o conjunto de ferramentas MinGW32 no Ubuntu.
    Instale o vinho, mingw:

    sudo apt-get install wine mingw-w64
    

    Depois disso, você já pode construir aplicativos C/C++ para Windows:

    # C
    i686-w64-mingw32-gcc helloWorld.c -o helloWorld32.exe      # 32-bit
    x86_64-w64-mingw32-gcc helloWorld.c -o helloWorld64.exe    # 64-bit
     
    # C++
    i686-w64-mingw32-g++ helloWorld.cc -o helloWorld32.exe     # 32-bit
    x86_64-w64-mingw32-g++ helloWorld.cc -o helloWorld64.exe   # 64-bit
    

    O exe coletado pode ser verificado usando vinho.
    A seguir, vamos dar uma olhada nas alterações na compilação do CMake, no arquivo CMakeLists.txt, adicionando coisas específicas do MinGW ao arquivo de compilação:

    if (MINGW32)
    set(CMAKE_SYSTEM_NAME Windows)
    SET(CMAKE_C_COMPILER i686-w64-mingw32-gcc)
    SET(CMAKE_CXX_COMPILER i686-w64-mingw32-g++)
    SET(CMAKE_RC_COMPILER i686-w64-mingw32-windres)
    set(CMAKE_RANLIB i686-w64-mingw32-ranlib)
    endif()
    
    // для сборки shared dll
    elseif (MINGW32)
    add_library(FlameSteelEngineGameToolkit.dll SHARED ${SOURCE_FILES})
    else()
    
    // обязательно линкуем со всеми зависимостями
    if (MINGW32)
    target_link_libraries(
                            FlameSteelEngineGameToolkit.dll 
                            -static-libgcc
                            -static-libstdc++
                            SDL2 
                            SDL2_mixer 
                            /home/demensdeum/Sources/cube-art-project-bootstrap/FlameSteelFramework/FlameSteelCore/FlameSteelCore.dll
                            /home/demensdeum/Sources/cube-art-project-bootstrap/FlameSteelFramework/FlameSteelBattleHorn/FlameSteelBattleHorn.dll
                            /home/demensdeum/Sources/cube-art-project-bootstrap/FlameSteelFramework/FlameSteelCommonTraits/FlameSteelCommonTraits.dll)
    
    set_target_properties(FlameSteelEngineGameToolkit.dll PROPERTIES
            PREFIX ""
            SUFFIX ""
            LINK_FLAGS "-Wl,--add-stdcall-alias"
            POSITION_INDEPENDENT_CODE 0 # this is to avoid MinGW warning; 
            # MinGW generates position-independent-code for DLL by default
    )
    else()
    

    Nós coletamos:

    cmake -DMINGW32=1 .
    make
    

    A saída será uma dll ou exe, dependendo do que você está coletando. Para um exemplo prático, você pode dar uma olhada no repositório do novo Cube-Art-Project e suas bibliotecas:
    https://gitlab.com/demensdeum/cube-art-project

    https://gitlab.com/demensdeum/FlameSteelEngineGameToolkitFSGL

    https://gitlab.com/demensdeum/cube-art-project-bootstrap

    Fontes
    https://arrayfire.com/cross-compile-to-windows-from-linux/

  • Construindo aplicativos macOS para Ubuntu OSXCross CMake

    Nesta postagem, descreverei a construção de aplicativos C++ multiplataforma para macOS em uma máquina de compilação Ubuntu usando CMake e osxcross.
    Primeiro, instale o conjunto de ferramentas osxcross:
    https://github.com/tpoechtrager/osxcross
    A instalação ocorre em 3 etapas, baixando as dependências:

    cd tools
    ./get_dependencies.sh
    

    Baixe o XCode.xip do site oficial da Apple e, em seguida, baixe o SDK do XCode:

    ./gen_sdk_package_pbzx.sh /media/demensdeum/2CE62A79E62A4404/LinuxSupportStorage/xcode111.xip
    

    Espero que você tenha lido o contrato de licença do XCode na última etapa. A seguir, construa o conjunto de ferramentas com o prefixo necessário:

    INSTALLPREFIX=/home/demensdeum/Apps/osxcross ./build.sh 
    

    Agora você pode usar osxcross do diretório de prefixos da etapa anterior. Vamos adicionar uma nova macro de construção para o CMake e escrever tudo o que for necessário:

    if (OSXCROSS)
    SET(CMAKE_SYSTEM_NAME Darwin)
    SET(CMAKE_C_COMPILER o64-clang)
    SET(CMAKE_CXX_COMPILER o64-clang++)
    SET(CMAKE_C_COMPILER_AR x86_64-apple-darwin19-ar)
    SET(CMAKE_CXX_COMPILER_AR x86_64-apple-darwin19-ar)
    SET(CMAKE_LINKER x86_64-apple-darwin19-ld)
    SET(ENV{OSXCROSS_MP_INC} 1)
    endif()
    

    A vinculação dinâmica não foi bem-sucedida para mim, então exportamos as bibliotecas estaticamente:

    if (OSXCROSS)
    add_library(FlameSteelCore STATIC ${SOURCE_FILES})
    else()
    

    Em seguida, você pode se deparar com o fato de não ter as bibliotecas necessárias para osxcross. Encontrei isso ao usar SDL2. osxcross oferece suporte a pacotes de bibliotecas prontos – macports. Por exemplo, instalando o mixer SDL2:

    osxcross-macports -v install libsdl2_mixer
    

    Depois disso, você pode começar a construir bibliotecas/aplicativos normalmente no link cmake-make, não se esqueça de especificar a vinculação estática de bibliotecas, se necessário.

    Montagem manual de bibliotecas

    Atualmente, encontrei o problema de arquivamento incorreto de bibliotecas durante a vinculação estática; ao construir o aplicativo final, recebo o erro:

    file was built for archive which is not the architecture being linked (x86_64)
    

    Muito semelhante a este ticket, conseguimos implementar uma solução alternativa que resultou na conclusão correta da compilação. Vamos descompactar a biblioteca estática e construí-la novamente usando o arquivador osxcross:

    ar x ../libFlameSteelCore.a
    rm ../libFlameSteelCore.a
    x86_64-apple-darwin19-ar rcs ../libFlameSteelCore.a *.o
    

    Além disso, um dos problemas que considero pessoalmente é a falta de capacidade de executar aplicativos macOS diretamente no Ubuntu (pelo menos com parte da funcionalidade). Claro, existe um projeto querido, mas o suporte ainda deixa muito a desejar.

    Fontes

    https://github.com/tpoechtrager/osxcross

  • Geração de imagem local: modelo ComfyUI e FLUX

    Hoje em dia, você não precisa depender de serviços em nuvem: você pode gerar imagens de alta qualidade inteiramente no seu próprio hardware. Neste post, descreverei como executar o modelo FLUX moderno localmente em seu computador usando o ComfyUI.

    ComfyUI usa arquitetura baseada em nós. Isso permite que você:
    – Controle totalmente todas as etapas da geração.
    – Compartilhe facilmente “fluxos de trabalho” prontos

    FLUX é um modelo grande, portanto os requisitos de hardware são superiores a SD 1.5 ou SDXL:
    Placa de vídeo (GPU): Nvidia RTX com 12 GB VRAM ou superior (para um trabalho confortável). Se você tiver 8 GB ou menos, terá que usar as versões quantizadas (GGUF ou NF4).
    Memória de acesso aleatório (RAM): mínimo 16 GB (de preferência 32 GB e superior).
    Espaço em disco: Aproximadamente 20–50 GB para modelos e componentes.

    A maneira mais fácil de iniciar o FLUX é usar um modelo pronto. Basta procurar por fluxo de texto para imagem na janela de fluxos de trabalho e instalar.

    Escreva um prompt em inglês no nó `Text to Image (Flux.1 Dev)`, selecione a resolução (FLUX funciona bem com 1024×1024 e até superior) e pressione RUN.

    A primeira geração pode demorar, pois os modelos serão carregados na memória da placa de vídeo.

    https://github.com/comfyanonymous/ComfyUI

  • Codificação local Vibe: LM Studio, VS Code e Continue

    Se você deseja usar redes neurais para ajudar a escrever código (a chamada codificação Vibe) e possui um computador bastante poderoso, por exemplo, com uma placa de vídeo Nvidia RTX, você pode implantar todo o ambiente de forma absolutamente gratuita em sua máquina. Isso resolve problemas com assinaturas pagas e permite que você trabalhe com segurança com projetos sob NDA, já que seu código não é enviado para lugar nenhum. Neste post irei descrever como montar um pacote local de LM Studio, VS Code e a extensão Continue.

    Ferramentas para codificação local do Vibe

    Para um trabalho confortável, precisamos de três componentes principais:
    LM Studio: um aplicativo conveniente para baixar e executar LLMs locais. Assume toda a complexidade de trabalhar com modelos GGUF e disponibiliza um servidor local compatível com a API OpenAI.
    VS Code: um editor de código popular e familiar.
    Continue: extensão para VS Code que integra redes neurais diretamente no ambiente de trabalho. Permite conversar, destacar código para refatoração e oferece suporte ao preenchimento automático.

    Requisitos de hardware

    Os modelos de idioma local consomem muita memória:
    Placa de vídeo (GPU): Nvidia com 8 GB VRAM ou superior (para trabalho confortável com modelos com 7 a 8 bilhões de parâmetros). Modelos mais pesados ​​exigirão 16 GB de VRAM.
    Espaço em disco: cerca de 500 GB para armazenar vários modelos baixados.

    Configurando o link

    O processo de configuração é bastante simples e não requer manipulações complexas no terminal:
    1. Baixe e instale o LM Studio. Use a pesquisa integrada para encontrar um modelo leve como Qwen Coder ou gemma3:12b.
    2. No LM Studio, vá para a guia Servidor Local e clique em Iniciar Servidor. Por padrão, ele começará em `http://localhost:1234/v1`.
    3. Abra o VS Code e instale a extensão Continue da loja de plugins.
    4. Abra o arquivo de configuração Continue e adicione um novo modelo, especificando o provedor `openai` e o endereço do seu servidor local do LM Studio.

    Você pode então se comunicar com seu LLM local diretamente na barra lateral Continuar, fazer perguntas sobre seu código e gerar novos componentes.

    Por que isso funciona?

    Como escrevi anteriormente, os LLMs se saem melhor com estrutura plana e código WET (Write Everything Twice). Os modelos de parâmetros locais podem ser inferiores a gigantes como o GPT-4 quando se trata de projetar arquiteturas complexas, mas são mais do que capazes de gerar código padrão, refatorar funções simples e prototipagem rápida.

    Além disso, com a codificação local do Vibe, seu código nunca sai da máquina. Isso torna essa combinação ideal para desenvolvimento corporativo e trabalho com dados confidenciais.

    Saída

    As redes neurais locais não são capazes de substituir totalmente um programador ou projetar um sistema complexo. No entanto, a combinação de LM Studio + VS Code + Continue proporciona independência dos serviços em nuvem e mantém a privacidade. Esta é uma ferramenta auxiliar totalmente funcional para tarefas rotineiras, se você estiver disposto a suportar as limitações de pequenos modelos e controlar de forma independente a arquitetura do projeto.

    Links

    https://code.visualstudio.com/
    https://lmstudio.ai/
    https://continue.dev/

    Fontes

    https://youtu.be/IqqCwhG46jY
    https://www.youtube.com/watch?v=7AImkA96mE8

  • Geração de vídeo local: ComfyUI e LTX-2.3

    Anteriormente, a criação de vídeos usando redes neurais era prerrogativa de serviços em nuvem como Runway ou Luma. Hoje, se você possui uma placa gráfica Nvidia moderna, pode gerar vídeos de alta qualidade diretamente no seu computador. Neste post, vou explicar como configurar a geração de vídeo local usando ComfyUI e o modelo LTX-2.3 efetivo.

    Ferramentas para geração de vídeo

    Para trabalhar, precisaremos de:
    ComfyUI: uma interface poderosa com uma arquitetura baseada em nós que permite personalizar de forma flexível o processo de geração.
    LTX-2.3: Um modelo moderno da Lightricks, otimizado para criar vídeos suaves e detalhados com requisitos de memória de vídeo relativamente moderados.

    Requisitos de hardware

    Gerar vídeo é um processo que consome muito mais recursos do que trabalhar com imagens:
    Placa de vídeo (GPU): Nvidia RTX com 8 GB VRAM é o mínimo necessário para uma resolução de 768×512. Para uma operação confortável e resoluções mais altas, é altamente desejável ter de 16 a 24 GB de VRAM.
    Memória de acesso aleatório (RAM): mínimo 32 GB. Modelos de vídeo e VAEs ocupam muito espaço durante o download.
    Espaço em disco: cerca de 500 GB para o próprio modelo e componentes relacionados.

    Configuração e inicialização

    O processo de lançamento do LTX-2.3 no ComfyUI é o seguinte:
    1. Atualize o ComfyUI: O modelo é relativamente novo, portanto, certifique-se de ter a versão mais recente da interface instalada.
    2. Fluxo de trabalho de instalação: A maneira mais fácil é encontrar um modelo JSON pronto para vídeo LTX. O modelo requer nós específicos para trabalhar com espaço latente de vídeo.
    3. Prompt e parâmetros: Insira uma descrição da cena em inglês. Observe que o LTX-2.3 entende bem o movimento (por exemplo, “a câmera orbita”, “movimento rápido”).

    Por que escolher LTX-2.3?

    O LTX-2.3 é notável porque oferece resultados comparáveis ​​aos serviços de nuvem proprietários, mas é executado localmente. Isso lhe dá:
    Privacidade total: seus prompts e vídeos gerados não vão para servidores de outras pessoas.
    Controle: você pode experimentar a taxa de quadros (FPS), a resolução e a intensidade do prompt sem ter que pagar por cada tentativa.

    A geração de vídeo local ainda está em desenvolvimento ativo e o LTX-2.3 é uma excelente entrada no mundo da “Hollywood doméstica”.

    Links

    https://github.com/comfyanonymous/ComfyUI
    https://huggingface.co/Lightricks/LTX-Video

  • Geração de música local: modelo ComfyUI e ACE-Step-1.5

    Hoje em dia, você não precisa depender de serviços em nuvem para criar conteúdo: você pode gerar música de alta qualidade inteiramente em seu próprio hardware. Neste post, descreverei como executar o modelo moderno ACE-Step-1.5 localmente em seu computador usando o ComfyUI.

    ComfyUI usa arquitetura baseada em nós. Isso permite que você:
    – Controle totalmente todas as etapas da geração de áudio.
    – Compartilhe facilmente “fluxos de trabalho” prontos.

    ACE-Step-1.5 é um modelo avançado para geração de música que requer recursos computacionais significativos. Os requisitos de hardware são superiores aos de muitos sintetizadores simples:
    Placa de vídeo (GPU): Nvidia RTX com 8 GB VRAM ou superior (12 GB+ recomendado) para um trabalho confortável com alta qualidade.
    Memória de acesso aleatório (RAM): mínimo 16 GB (de preferência 32 GB e superior).
    Processador (CPU): Processador multi-core moderno com bom suporte para computação AVX/CUDA.
    Espaço em disco: Aproximadamente 20–50 GB para modelos e componentes.

    A maneira mais fácil de executar o ACE-Step-1.5 é usar um modelo de geração de áudio pronto. Basta pesquisar texto musical em áudio na janela de fluxos de trabalho e instalar.

    Escreva um prompt descrevendo o gênero e o clima (por exemplo, “faixa de synthwave edificante com baixo pesado”) no nó `Prompt Input`. Especifique a duração desejada e pressione RUN.
    A primeira geração pode levar algum tempo, pois os modelos serão carregados na memória da placa de vídeo e processarão padrões acústicos complexos.

    https://github.com/comfyanonymous/ComfyUI
    https://www.youtube.com/watch?v=UAlLD5fS7-c

  • Redes neurais locais usando ollama

    Se você deseja lançar algo como ChatGPT e possui um computador bastante potente, por exemplo com uma placa de vídeo Nvidia RTX, então você pode executar o projeto ollama, que permitirá que você use um dos modelos LLM prontos em sua máquina local, totalmente gratuito. ollama oferece a capacidade de se comunicar com modelos LLM, na forma de ChatGPT; também na versão mais recente, foi anunciada a capacidade de ler imagens e formatar os dados de saída no formato json.

    Também executei o projeto em um MacBook com processador Apple M2 e sei que os modelos mais recentes de placas de vídeo da AMD são suportados.

    Para instalar no macOS, acesse o site da ollama:
    https://ollama.com/download/mac

    Clique em “Baixar para macOS”, você baixará um arquivo no formato ollama-darwin.zip, dentro do arquivo estará Ollama.app que precisa ser copiado para “Aplicativos”. Depois disso, inicie o Ollama.app, provavelmente o processo de instalação ocorrerá na primeira inicialização. Depois disso, na bandeja você viu o ícone ollama, a bandeja fica no canto superior direito ao lado do relógio.

    Depois disso, inicie um terminal macOS normal e digite o comando para baixar, instalar e executar qualquer modelo ollama. Uma lista de modelos disponíveis, descrições e suas características podem ser conferidas no site da ollama:
    https://ollama.com/search

    Escolha o modelo com menos parâmetros caso ele não caiba na sua placa de vídeo no lançamento.

    Por exemplo, o comando para iniciar o modelo llama3.1:latest:

    ollama run llama3.1:latest
    

    A instalação para Windows e Linux é geralmente semelhante, em um caso haverá um instalador ollama e trabalharemos posteriormente com ele via Powershell.
    Para Linux, a instalação é feita por script, mas recomendo usar a versão do seu gerenciador de pacotes específico. No Linux, ollama também pode ser iniciado através de um terminal bash normal.

    Fontes
    https://www.youtube.com/watch?v=Wjrdr0NU4Sk
    https://ollama.com

  • Estabilização de vídeo usando ffmpeg

    Se você deseja estabilizar vídeos e remover o tremor da câmera, a ferramenta `ffmpeg` oferece uma solução poderosa. Graças aos filtros integrados `vidstabdetect` e `vidstabtransform`, você pode obter resultados profissionais sem usar editores de vídeo complexos.

    Preparando-se para o trabalho

    Antes de começar, certifique-se de que seu `ffmpeg` suporta a biblioteca `vidstab`. No Linux você pode verificar isso com o comando:

    bash  
    ffmpeg -filters | grep vidstab  
    

    Se a biblioteca não estiver instalada, você poderá adicioná-la:

    sudo apt install ffmpeg libvidstab-dev  
    

    Instalação para macOS via brew:

    brew install libvidstab
    brew install ffmpeg
    

    Agora vamos passar para o processo.

    Etapa 1: análise de movimento

    Primeiro você precisa analisar o movimento do vídeo e criar um arquivo com parâmetros de estabilização.

    ffmpeg -i input.mp4 -vf vidstabdetect=shakiness=10:accuracy=15 transfile=transforms.trf -f null -  
    

    Parâmetros:

    tremor: Nível de vibração do vídeo (padrão 5, pode ser aumentado para 10 para casos mais complexos).
    precisão: Precisão da análise (padrão 15).
    transfile: Nome do arquivo para salvar os parâmetros de movimento.

    Passo 2: Aplicar Estabilização

    Agora você pode aplicar a estabilização usando o arquivo de transformação:

    ffmpeg -i input.mp4 -vf vidstabtransform=input=transforms.trf:zoom=5 output.mp4
    

    Parâmetros:

    input: Aponta para o arquivo com parâmetros de transformação (criados na primeira etapa).
    zoom: Fator de zoom para remover bordas pretas (por exemplo, 5 – zoom automático até que os artefatos sejam removidos).

  • Máquinas de computação de Turing

    Apresento a sua atenção uma tradução das primeiras páginas do artigo de Alan Turing “ON COMPUTABLE NUMBERS WITH AN APPLICATION TO THE PROBLEM OF RESOLUTION” de 1936. Os primeiros capítulos contêm uma descrição dos computadores, que mais tarde se tornaram a base da computação moderna.

    A tradução completa do artigo e a explicação podem ser lidas no livro do popularizador americano Charles Petzold, intitulado “Reading Turing: A Journey through Turing’s Historical Article on Computability and Turing Machines” (ISBN 978-5-97060-231-7, 978-0-470-22905-7)

    Artigo original:
    https://www.astro.puc.cl/~rparra/tools/PAPERS/turing_1936.pdf

    SOBRE NÚMEROS COMPUTÁVEIS COM APLICAÇÃO AO PROBLEMA DE RESOLUÇÃO

    AM TURING

    [Recebido em 28 de maio de 1936 – lido em 12 de novembro de 1936]

    Os números “computáveis” podem ser brevemente descritos como números reais cujas expressões como frações decimais são calculáveis ​​de um número finito de maneiras. Embora à primeira vista este artigo trate os números como computáveis, é quase tão fácil definir e explorar funções computáveis ​​de uma variável inteira, uma variável real, uma variável computável, predicados computáveis ​​e similares. Contudo, os problemas fundamentais associados a estes objetos computáveis ​​são os mesmos em cada caso. Para uma consideração detalhada, escolhi números computáveis ​​como objeto computável porque o método de considerá-los é o menos complicado. Espero descrever em breve a relação entre números computáveis ​​e funções computáveis ​​e assim por diante. Paralelamente, serão realizadas pesquisas no campo da teoria das funções de uma variável real expressa em termos de números computáveis. Pela minha definição, um número real é computável se a sua representação decimal puder ser escrita por uma máquina.

    Nos parágrafos 9 e 10 apresento alguns argumentos para mostrar que os números computáveis ​​incluem todos os números que são naturalmente considerados computáveis. Em particular, mostro que algumas grandes classes de números são computáveis. Incluem, por exemplo, as partes reais de todos os números algébricos, as partes reais dos zeros das funções de Bessel, os números π, e e outros. No entanto, os números computáveis ​​não incluem todos os números definíveis, como evidenciado pelo seguinte exemplo de um número definível que não é computável.

    Embora a classe dos números computáveis ​​seja muito grande e em muitos aspectos semelhante à classe dos números reais, ela ainda é enumerável. No §8 considero certos argumentos que parecem argumentar o contrário. Quando um destes argumentos é aplicado corretamente, tiram-se conclusões que, à primeira vista, são semelhantes às de Gödel*. Esses resultados têm aplicações extremamente importantes. Em particular, como mostrado abaixo (§11), o problema de resolução não pode ter solução.

    Num artigo recente, Alonzo Church introduziu a ideia de “calculabilidade efectiva”, que é equivalente à minha ideia de “computabilidade”, mas tem uma definição completamente diferente. Church também chega a conclusões semelhantes em relação ao problema da resolução. A prova da equivalência entre “computabilidade” e “efetivamente calculável” é apresentada no apêndice deste artigo.

    1. Computadores

    Já dissemos que números computáveis ​​são aqueles números cujas casas decimais são contáveis ​​por meios finitos. Uma definição mais clara é necessária aqui. Este artigo não fará nenhuma tentativa real de justificar as definições aqui dadas até chegarmos ao §9. Por enquanto, observarei apenas que a justificativa (lógica) (para isso) é que a memória humana é, por necessidade, limitada.

    Comparemos uma pessoa no processo de cálculo de um número real com uma máquina que é capaz de cumprir apenas um número finito de condições q1, q2, …, qR; Vamos chamar essas condições de “m-configurações”. Esta máquina (isto é, assim definida) está equipada com uma “fita” (análoga ao papel). Esta correia que passa pela máquina é dividida em seções. Vamos chamá-los de “quadrados”. Cada um desses quadrados pode conter algum tipo de “símbolo”. Em qualquer momento, existe apenas um desses quadrados, digamos o enésimo, contendo o símbolo que está “nesta máquina”. Vamos chamar esse quadrado de “símbolo digitalizado”. Um “caractere digitalizado” é o único caractere do qual a máquina está, por assim dizer, “diretamente consciente”. No entanto, ao alterar sua configuração m, a máquina pode efetivamente lembrar alguns dos caracteres que “viu” (digitalizou) anteriormente. O possível comportamento da máquina a qualquer momento é determinado pela configuração m qn e pelo símbolo digitalizado***. Vamos chamar esse par de símbolos de qn, “configuração”. A configuração assim designada determina o comportamento possível de uma determinada máquina. Em algumas dessas configurações em que o quadrado digitalizado está em branco (ou seja, não contém nenhum caractere), a máquina escreve um novo caractere no quadrado digitalizado e em outras configurações apaga o caractere digitalizado. Esta máquina também é capaz de se mover para escanear outro quadrado, mas desta forma só pode se mover para o quadrado adjacente à direita ou à esquerda. Além de qualquer uma destas operações, a configuração m da máquina pode ser alterada. Neste caso, alguns dos caracteres escritos formarão uma sequência de dígitos, que é a parte decimal do número real que está sendo calculado. O restante nada mais será do que marcas imprecisas para “ajudar a memória”. Neste caso, apenas as marcas imprecisas acima mencionadas podem ser apagadas.

    Afirmo que as operações aqui consideradas incluem todas as operações usadas no cálculo. A justificativa para esta afirmação é mais fácil de entender para o leitor que conhece a teoria das máquinas. Portanto, na próxima seção continuarei a desenvolver a teoria em questão, com base na compreensão do significado dos termos “máquina”, “fita”, “digitalizado”, etc.

    *Gödel “Sobre as Sentenças Formalmente Indecidíveis dos Principia Mathematics (publicado por Whitehead e Russell em 1910, 1912 e 1913) e Sistemas Relacionados, Parte I,” Journal of Mathematics. Física, boletim mensal em alemão nº 38 (para 1931, pp. 173-198.
    ** Alonzo Church, “Um problema indecidível na teoria elementar dos números”, American J. of Math., No.
    *** Alonzo Church, “Uma nota sobre o problema da resolução”, J. of Symbolic Logic, No. 1 (1936), pp.