发表于

前言

我们在开发过程中经常会遇到需要对图片进行取色的情况

如果你也嫌弃下载取色软件麻烦

那么有一些顺手的工具可以满足我们的取色需求

使用Android Studio自带取色工具

在VCS版本管理关卡页面, 有一个取色工具

image-20230106102842956

image-20230106102709895

使用Chorme浏览器自带取色工具

进入控制台, 随便点击一个色块, 会弹出取色工具

image-20230106103019125

image-20230106103118581

本文为作者原创转载时请注明出处 谢谢

乱码三千 – 点滴积累 ,欢迎来到乱码三千技术博客站

发表于

介绍

在Godot中角色动画我们通常会使用AnimationPlayer这个节点去实现, 该节点支持关键帧

image-20220930172408017

image-20220930173110937

关于动画的一些注意事项

  1. 通常我们会让动画在运动帧开始, 然后在闲置帧结束,

    如此一来 当玩家按下按钮时 不管时间有多短 都能看到明显的动画, 而不是你已经移动了 然而角色的脚却还没动

本文为作者原创转载时请注明出处 谢谢

乱码三千 – 点滴积累 ,欢迎来到乱码三千技术博客站

发表于

介绍

Node2D节点继承自Node节点, 功能比Node丰富 这个不必多说, 从Godot右侧面板上可以很清晰地看清它们之间的继承关系, 以及暴露出来可供修改的属性:

image-20220930164400556

在实际开发中我们通常会使用Node2d节点, 从开发角度上它有以下优势:

  • 当我们将子场景拖拽进入Node节点中时, 自场景物体会自定移动到原点位置, 而Node2d则不存在该问题
  • 通过移动Node2d节点位置, 我们可以将整个场景进行移动, 然而Node节点不具备移动属性, 因此无法实现该效果

本文为作者原创转载时请注明出处 谢谢

乱码三千 – 点滴积累 ,欢迎来到乱码三千技术博客站

发表于

需求

当前素材库中只有一张小草地图片, 如下:

GrassBackground

如何将其铺满整个背景, 得到如下效果:

image-20220930152341903

我们可能第一时间会想到使用Tilemap, 不过手动绘制相对来说有些费时间, 在Godot中我们有更好的方法可以实现

实现方式一

使用Sprite+图片repeat的方式实现

  1. 首先创建一个Sprite节点

  2. 将草地图片添加至该节点的Texture属性上

    image-20220930153243013

  3. 启用Region属性

    image-20220930153318292

  4. 在纹理区域框选需要进行repeat的区域

    image-20220930153401635

  5. 选中草地文件 然后在导入面板开启重复功能, 最后点击重新导入

    image-20220930153526042

  6. 此时我们在纹理区域拉伸选框, 则可以对草地小图片进行重复并铺满整个背景

    image-20220930153638246

实现方式二

使用TextureRect+Tile实现

  1. 创建TextureRect节点

  2. 将图片拖拽至该节点的Texture属性上

    image-20220930154030277

  3. Stretch Mode属性选择Tile

    image-20220930154057353

  4. 此时拉伸图片则自动重复

    image-20220930154121259

本文为作者原创转载时请注明出处 谢谢

乱码三千 – 点滴积累 ,欢迎来到乱码三千技术博客站

发表于

原因一

使用国内镜像而该镜像未完全同步 导致包找不到

解决方法:

临时去除镜像即可:

1
export HOMEBREW_BOTTLE_DOMAIN=''

原因二

依赖程序缺失

解决方法:

需要进行单独安装, 比如报错Error: No such file or directory @ rb_sysopen - xxxxxxxc–jasper, 此时单独安装jasper:

1
brew install jasper

安装完后 再次运行之前的安装之前的指令即可

本文为作者原创转载时请注明出处 谢谢

乱码三千 – 点滴积累 ,欢迎来到乱码三千技术博客站

发表于

xmake介绍

xmake 是一个基于 Lua 的轻量级跨平台构建工具，使用 xmake.lua维护项目构建, 相当于是cmake的增强版, 其优点如下:

  • 简单易用
  • 能够像 Make/Ninja 那样可以直接编译项目
  • 可以像CMake/Meson 那样生成工程文件
  • 内置的包管理系统来帮助用户解决 C/C++依赖库的集成使用问题
  • 可以实现跟C/C++进行混合编译
  • 编译速度也是非常的快，可以跟Ninja持平
  • 简化了交叉编译

官方文档

GITHUB

环境准备

  • 编译宿主平台: MAC

  • 交叉编译目标平台: Linux, Windows, IOS, Android ….

  1. 下载xmake

    1
    bash <(curl -fsSL https://xmake.io/shget.text -k)

  2. 测试c代码准备 文件取名为main

    1
    2
    3
    4
    5
    6
    #include <stdio.h>
    int main(int argc, char** argv){
        printf("Hello World!\n");

        return 0;
    }

  1. 在源码目录下新建xmake.lua文件

    并加入以下配置

    1
    2
    3
    4
    5
    6
    7
    8
    add_rules("mode.debug", "mode.release")

    -- 编译项目名称
    target("main")
    		-- 指定编译形式 可执行文件 还是静态库or动态库
        set_kind("binary")
        -- 指定需要参与编译的源码文件
        add_files("src/main/c/main.c")

编译前的环境准备好了,那接下来 咱们挨个来实现目标平台的可执行文件生成

生成phone平台程序

  1. 下载xcode

    直接应用市场下载

  2. 给xmake指定编译目标平台

    1
    xmake f -p iphoneos

  3. 编译程序

    1
    xmake build main

    编译成功后 可以在build目录中找到对应的可执行文件

    image-20220929172751417

生成Mac平台的程序

  1. 给xmake指定编译目标平台

    1
    xmake f -p macosx

  2. 编译程序

    1
    xmake build main

    编译成功后 可以在build目录中找到对应的可执行文件

    image-20220929173058827

  3. 执行程序

    由于编译宿主平台刚好是Mac 所以我们可以直接执行程序

    1
    xmake run main

    image-20220929173203142

生成Windows平台程序

  1. 下载mingw-w64

    1
    brew install mingw-w64

  2. 给xmake指定编译目标平台

    1
    xmake f -p mingw

    或者使用图形化界面配置

    1
    xmake f --menu

    img

    配置完后 我们查看xmake的配置显示当前平台为mingw:

    image-20220930102409815

  3. 编译程序

    1
    xmake build main

    编译成功后 我们可以在build目录下找到生成的exe可执行文件:image-20220930101946291

  4. 关于mingw内部编译器

    我们打印编译信息会发现mingw内部采用的是gcc编译工具

    image-20220930102723811

生成Android平台程序

  1. 下载NDK

    点击进入下载页面

  2. 给xmake指定编译目标平台

    1
    xmake f -p android --ndk=ndk路径

    此时我们查看xmake配置显示当前编译平台为android:

    image-20220930101224522

  3. 编译程序

    1
    xmake build main

    编译成功后 可以在编译目录查看到生成的可执行文件

    image-20220930101319392

xmake常用指令

  1. 重置配置

    1
    xmake f -c

  2. 指定交叉编译工具

    1
    2
    3
    xmake f --toolchain=clang
    或者
    xmake f --toolchain=gcc

  3. 查看当前工程信息和xmake信息

    1
    xmake show

  4. 编译过程中查看完整的编译选项

    1
    xmake -rv

  5. 查看当前配置

    1
    xmake config -v

    image-20220929181646806

  6. 卸载xmake

    1
    xmake update --uninstall

常见问题汇总

  1. 交叉编译报错 unknown platform for xcode!

    解决方案: 卸载xmake重装

本文为作者原创转载时请注明出处 谢谢

乱码三千 – 点滴积累 ,欢迎来到乱码三千技术博客站

发表于

前言

目前主流的平台有:

  • Windows
  • Mac
  • Linux
  • Android
  • IOS

当C/C++程序写好后 如何快速在当前平台编译出各个平台的可执行文件

现在比较成熟的方案有:

  • 利用docker容器编译
  • 利用cmake构建交叉编译环境

利用docker容器编译

基于GCC套件, 可实现对Android, Linux, Windows, Web平台的交叉编译, 详细介绍如下:

  • dockcross/base

    Base image for other toolchain images. From Debian Jessie with GCC, make, autotools, CMake, Ninja, Git, and Python.

  • dockcross/android-arm

    The Android NDK standalone toolchain for the arm architecture.

  • dockcross/android-arm64

    The Android NDK standalone toolchain for the arm64 architecture.

  • dockcross/linux-arm64

    Cross compiler for the 64-bit ARM platform on Linux, also known as AArch64.

  • dockcross/linux-armv5

    Linux armv5 cross compiler toolchain for legacy devices like the Parrot AR Drone.

  • dockcross/linux-armv5-musl

    Linux armv5 cross compiler toolchain using musl as base “libc”.

  • dockcross/linux-armv6

    Linux ARMv6 cross compiler toolchain for the Raspberry Pi, etc.

  • dockcross/linux-armv7

    Generic Linux armv7 cross compiler toolchain.

  • dockcross/linux-armv7a

    Toolchain configured for ARMv7-A used in Beaglebone Black single board PC with TI SoC AM3358 on board, Cortex-A8.

  • dockcross/linux-mipsel

    Linux mipsel cross compiler toolchain for little endian MIPS GNU systems.

  • dockcross/linux-mips

    Linux mips cross compiler toolchain for big endian 32-bit hard float MIPS GNU systems.

  • dockcross/linux-s390x

    Linux s390x cross compiler toolchain for S390X GNU systems.

  • dockcross/linux-ppc64le

    Linux PowerPC 64 little endian cross compiler toolchain for the POWER8, etc. Important: Due to Issue #430, automatic build of newer images has been disabled.

  • dockcross/linux-x64

    Linux x86_64 / amd64 compiler. Since the Docker image is natively x86_64, this is not actually a cross compiler.

  • dockcross/linux-x86

    Linux i686 cross compiler.

  • dockcross/manylinux2014-x64

    Docker manylinux2014 image for building Linux x86_64 / amd64 Python wheel packages. It includes Python 3.5, 3.6, 3.7, 3.8, and 3.9. Also has support for the dockcross script, and it has installations of CMake, Ninja, and scikit-build. For CMake, it sets MANYLINUX2014 to “TRUE” in the toolchain.

  • dockcross/manylinux2014-x86

    Docker manylinux2014 image for building Linux i686 Python wheel packages. It includes Python 3.5, 3.6, 3.7, 3.8, and 3.9. Also has support for the dockcross script, and it has installations of CMake, Ninja, and scikit-build. For CMake, it sets MANYLINUX2014 to “TRUE” in the toolchain.

  • dockcross/manylinux2014-aarch64

    Docker manylinux2014 image for building Linux aarch64 / arm64 Python wheel packages. It includes Python 3.5, 3.6, 3.7, 3.8, and 3.9. Also has support for the dockcross script, and it has installations of CMake, Ninja, and scikit-build. For CMake, it sets MANYLINUX2014 to “TRUE” in the toolchain.

  • dockcross/manylinux2010-x64

    Docker manylinux2010 image for building Linux x86_64 / amd64 Python wheel packages. It includes Python 2.7, 3.4, 3.5, 3.6, 3.7 and 3.8. Also has support for the dockcross script, and it has installations of CMake, Ninja, and scikit-build. For CMake, it sets MANYLINUX2010 to “TRUE” in the toolchain.

  • dockcross/manylinux2010-x86

    Docker manylinux2010 image for building Linux i686 Python wheel packages. It includes Python 2.7, 3.4, 3.5, 3.6, 3.7 and 3.8. Also has support for the dockcross script, and it has installations of CMake, Ninja, and scikit-build. For CMake, it sets MANYLINUX2010 to “TRUE” in the toolchain.

  • dockcross/manylinux1-x64

    Docker manylinux1 image for building Linux x86_64 / amd64 Python wheel packages. It includes Python 2.7, 3.4, 3.5, 3.6, 3.7 and 3.8. Also has support for the dockcross script, and it has installations of CMake, Ninja, and scikit-build. For CMake, it sets MANYLINUX1 to “TRUE” in the toolchain.

  • dockcross/manylinux1-x86

    Docker manylinux1 image for building Linux i686 Python wheel packages. It includes Python 2.7, 3.4, 3.5, 3.6, 3.7 and 3.8. Also has support for the dockcross script, and it has installations of CMake, Ninja, and [ scikit-build](http:// scikit-build.org/). For CMake, it sets MANYLINUX1 to “TRUE” in the toolchain.

  • dockcross/web-wasm

    The Emscripten WebAssembly/asm.js/JavaScript cross compiler.

  • dockcross/windows-static-x64

    64-bit Windows cross-compiler based on MXE/MinGW-w64 with win32 threads and static linking.

  • dockcross/windows-static-x64-posix

    64-bit Windows cross-compiler based on MXE/MinGW-w64 with posix threads and static linking.

  • dockcross/windows-static-x86

    32-bit Windows cross-compiler based on MXE/MinGW-w64 with win32 threads and static linking.

  • dockcross/windows-shared-x64

    64-bit Windows cross-compiler based on MXE/MinGW-w64 with win32 threads and dynamic linking.

  • dockcross/windows-shared-x64-posix

    64-bit Windows cross-compiler based on MXE/MinGW-w64 with posix threads and dynamic linking.

  • dockcross/windows-shared-x86

    32-bit Windows cross-compiler based on MXE/MinGW-w64 with win32 threads and dynamic linking.

具体使用可参见Github

使用cmake构建交叉编译环境

首先我们需要下载cmake构建工具

然后下载用于交叉编译的套件

以Mac平台为例, 如果我需要编译各个平台的可执行文件, 那么首先需要下载能在Mac平台运行的目标平台编译包, 比如:

  • android平台:下载 Mac平台可运行的NDK (基于clang)

  • ios平台: 下载iphoneos SDK, xcode自带 我们只需下载xcode即可 (基于clang)

  • windows平台:下载MinGW 或者 MXE/MinGW-w64 (基于GCC)

  • Linux平台:如 arm/x86-Linux-gnueabi套件(基于GCC)

本文为作者原创转载时请注明出处 谢谢

乱码三千 – 点滴积累 ,欢迎来到乱码三千技术博客站

发表于

前言

在c/c++语言编译时 我们经常能碰到关于静态库(static)和动态库(shared)的链接

那它们有什么区别呢

静态库

静态库(static)是程序在编译期间进行链接的, 它会被打包进可执行程序当中

动态库

动态库(shared)也叫共享库, 它是在程序运行是进行链接的, 以独立的文件存在, 不会被打包进可执行程序中, 但是程序在执行时需要能找到这个库的具体位置, 否则程序可能出错

不同系统中动态库的文件类型

系统 动态库后缀 静态库后缀
Linux .so .a
Mac .dylib .a
Windows .dll .lib

两种库的优势和劣势

静态库

优势:

  • 将依赖的静态库直接打包进可执行文件中, 不用担心对方的机器找不到库导致无法运行
  • 由于直接嵌入到了执行程序中 因此运行速度较快

劣势:

  • 会导致可执行文件的体积过大
  • 如果多个程序使用了同一个静态库 一旦静态库出现bug, 那么与之相关的所有可执行程序都要进行重新编译

动态库

优势:

  • 能有效减少可执行程序的体积
  • 一旦库出现bug, 只需修复并重新编译库即可

劣势:

  • 需要将库放到指定路径下 供主程序调用 操作起来相对麻烦
  • 运行速度相对静态库会慢一些

总结

静态库和动态库, 没有孰优孰劣一说, 具体看实际的应用场景, 每种库都有它的用武之地

本文为作者原创转载时请注明出处 谢谢

乱码三千 – 点滴积累 ,欢迎来到乱码三千技术博客站

发表于

问题1

下载时提示SSL certificate problem:

1
2
3
4
5
6
curl: (60) SSL certificate problem: certificate has expired
More details here: https://curl.haxx.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

原因:

这是证书认证缺失导致，可以在请求时关闭ssl证书认证

解决方案:

命令行中加上-k即可, 如:

1
curl -fsSL https://xmake.io/shget.text -k

本文为作者原创转载时请注明出处 谢谢

乱码三千 – 点滴积累 ,欢迎来到乱码三千技术博客站

0%