下个大版本的规划

[chirsz-ever]

文档

使用 Doxygen 格式编写和生成文档，替换当前手写 HTML 的情况。
或者使用 MoinMoin，和当前文档风格比较像。

核心及绘图 API

取消将函数最后一个参数作为绘制对象的做法，而使用“当前绘制对象”的概念，让绘图设置保存在“渲染器”而非IMAGE 对象里。

增加“不可变图形对象”的类型或 IMAGE 内部状态，以支持硬件渲染优化。

从 C++ 角度来说，当前的做法（使用 NULL 作为默认参数）使得编写的绘制函数不通用，调用者无法知道一个函数内部是画到哪里。尽管也有 settarget，但这使得做同一件事有两个方法，不是一个好的设计。

取消 putimage 系列函数，改用设置 IMAGE 混合属性来决定混合效果。

加上 setscale 和 setclip， setscale 用于缩放，setclip 用于设置裁剪区。

编码和字符串

在源码中全面使用 UTF-8 编码，ege.h 的编码待讨论。
重新设计字符串相关 API，使之支持各种编码（可参考 DxLib）。
设计一套控制字体的 API，重新设置当前各绘图函数。

音频 API

直接山寨 SDL Audio

事件驱动输入

考虑鼠标、键盘、窗口事件，窗口事件包括移动、缩放、最大最小化、退出等。

兼容性

取消对 VC6 的支持，在源代码中使用 C++11 及以上技术。
20.08 版本尽量不加新功能，作为旧版的最后一版，类似 Python 2.7。

架构

核心是一套类似 SDL 的 C API（风格大概是 EGE_Init，EGE_DrawLine 这样的），基于此构建仿 BGI 的 C API 与 C++ API。底层则可选择使用 GDI+Win32、GTK、SDL 等，实现跨平台。

---

以上仅代表个人想法，欢迎讨论。

[royqh1979]

20.08已经发布了，是21.08尽量不增加新功能吧

[royqh1979]

关于文档

举双手双脚赞成

关于新版本和旧版本的兼容问题

是在新版本中完全不出现旧版本的函数吗？

还是说旧版本函数可以通过ege_legacy::line这样的形式访问？

或者新版本函数通过ege::drawLine这样的形式访问？

关于绘图API的PIMAGE参数

对于SDL不熟，简单看了一下SDL的代码，里面是通过Render参数来指定在哪里绘图。个人认为这个设计和在line函数里面用PIMAGE参数来指定在哪里绘图没有本质区别。（目前的IMAGE相当于把图片和渲染器放在一个类里，分开当然更灵活，放在一起我觉得大多数情况下也是没问题的）。如果要分开的话，应尽量对用户透明。

我觉得line这类函数可以接受NULL作为参数，表示在当前目标图片上绘图。
也可以搞两个重载函数，一个不接受PIMAGE参数，表示在当前目标上绘图；一个接受，但是不可以为NULL。

最重要的是，gettarget绝对不能返回NULL和1、2、3、4这类非合法指针。

绘图API建议1 坐标变换

目前EGE里面没有坐标变换的概念，所以才会有putimage_rotate这种函数的需求。最好能增加常用的rotate/zoom(scale)/translate/shear/reflection变换。（参见http://royqh.net/easygraphics/tutorials/009_transforms.html ）

绘图API建议2 增加Path或者定义填充区域的支持

在打开反锯齿后，图形的边缘会被模糊化处理，当图形的边界线比较细时会导致flood fill无法正确闭合。因此需要增加定义填充区域或者Path的功能。（参考http://royqh.net/easygraphics/tutorials/005_1_vertices.html ）

关于编码

支持ege.h使用UTF-8编码（我的Dev-C++ 2020已经支持了，哈）
在EGE中没必要支持多种字符编码和信息本地化，libiconv和gettext已经很简单了，没必要再封装一层。
xyprintf还是很好使的，比sprintf之后再drawText要方便的多。

常用对话框

包括信息提示，获取输入

OpenCV支持

OpenCV是流行的视觉处理库。是否应提供PIMAGE 和 Mat的转换函数？
至少，在文档中应提供PIMAGE和Mat相互转换的教程和程序示例。

关于测试

是否需要引入测试机制，以及用什么测试工具？

[chirsz-ever]

关于新版本和旧版本的兼容问题

用户直接用的 C API 和 C++ API 长得比较像 BGI，也比较像当前版本的函数，C++ API 有 namespace ege。line 这种函数没有指定绘图目标的函数，高层 API 里也不会暴露 Renderer。

目前EGE里面没有坐标变换的概念，所以才会有putimage_rotate这种函数的需求。最好能增加常用的rotate/zoom(scale)/translate/shear/reflection变换。（参见http://royqh.net/easygraphics/tutorials/009_transforms.html）

括号混进超链接里了。链接里似乎用的是类似 OpenGL 的方式进行变换，我觉得可以，而且可以通过直接传入变换矩阵来实现更多复杂的效果。但配合视口、裁剪等功能会让概念变得复杂，这方面需要更多讨论。

在打开反锯齿后，图形的边缘会被模糊化处理，当图形的边界线比较细时会导致flood fill无法正确闭合。因此需要增加定义填充区域或者Path的功能。（参考http://royqh.net/easygraphics/tutorials/005_1_vertices.html）

同意，可以增加 Path（折线、圆、贝塞尔曲线，参考 SVG），去掉 flood_fill 功能。

关于编码

“信息本地化”没必要，多种字符编码还是有必要的。字体和字符串绘制则需要考虑现代字体设置的复杂性与易用性之间的平衡。

常用对话框
OpenCV支持

由第三方库支持。可以考虑提供常用的模态窗口。

关于测试

大概会采取逐像素比对的方式。没找到合适的测试框架。

[royqh1979]

关于编码

“信息本地化”没必要，多种字符编码还是有必要的。字体和字符串绘制则需要考虑现代字体设置的复杂性与易用性之间的平衡。

这方面我是觉得libiconv已经够简单了

cd=iconv_open ( tocode, fromcode);
iconv (cd, inbuf, insize, outbuf, outbuflen);
iconv_close(cd);

而且现在EGE编译时的依赖已经够多了。。。

常用对话框
OpenCV支持

由第三方库支持。可以考虑提供常用的模态窗口。

关于测试

大概会采取逐像素比对的方式。没找到合适的测试框架。

[chirsz-ever]

当前 EGE 编译时只依赖了 libpng。

编码问题……如果只允许 UTF-8，输出乱码怕是会成为每个用户都会问的问题，源码用 UTF-8 保存了又要问为啥控制台显示异常……。我的想法是使用默认 ANSI 编码，同时可自由指定 MBCS 所用格式覆盖默认设置，这也方便了其他国家的用户。

[royqh1979]

当前 EGE 编译时只依赖了 libpng。

编码问题……如果只允许 UTF-8，输出乱码怕是会成为每个用户都会问的问题，源码用 UTF-8 保存了又要问为啥控制台显示异常……。我的想法是使用默认 ANSI 编码，同时可自由指定 MBCS 所用格式覆盖默认设置，这也方便了其他国家的用户。

现代的编译器都可以在编译时指定源代码编码的，所以这个应该不是问题

[chirsz-ever]

API 设计参考：https://gist.github.com/louisstuart96/c0174991207aff6c617ecbc1dbb9f33c