日子不好过,这么点代码,写了那么久
最近在写一套跨平台的简单图形库,数学不好就是不行,来回算乱七八糟的各种东西都费事。。。
定义接口真的很费事,接口一遍一遍地改,然后里面的东西也在一遍一遍地改。。。
接口参数太多,还要写更多的函数,一次次转接。。。
麻烦。。。
typedef void (*DRAW_PROC)( int x , int y , int color , char *buf , int buflen , int xres , int yres );
定义接口真的很费事,接口一遍一遍地改,然后里面的东西也在一遍一遍地改。。。
接口参数太多,还要写更多的函数,一次次转接。。。
麻烦。。。
typedef void (*DRAW_PROC)( int x , int y , int color , char *buf , int buflen , int xres , int yres );
void* gdi_init( DRAW_PROC draw_proc , int xres_proc , int yres_proc , char *buf , int buflen );
char* gdi_get_buffer( void *pthis );
int gdi_get_w( void *pthis );
int gdi_get_h( void *pthis );
int gdi_get_buflen( void *pthis );
int gdi_destory( void* pthis );
int gdi_draw_rect( void* pthis , int t , int l , int h , int w , int color , int lw );
int gdi_fill_rect( void* pthis , int t , int l , int h , int w , int color );
int gdi_draw_round( void* pthis , int xc , int yc , int a , int b , int color );
int gdi_fill_round( void* pthis , int xc , int yc , int a , int b , int color );
int gdi_draw_line( void* pthis , int sx , int sy , int ex , int ey , int color , int lw);
int gdi_draw_bmp( void* pthis , int x , int y , int w , int h , char *buf , int buflen , int *retw , int *reth );
int gdi_GDI_copy_to_GDI( void *dec , int decx , int decy , int decxw , int decyh ,
void *src , int srcx , int srcy , int srcxw , int srcyh );
这里已经在我的角度上,极度地精简了大部分接口。。。
最变态的,从一个画布把一块指定位置指定大小的图片拷贝到另一个画布的指定位置指定大小,这么简单的一个功能,就要16个参数来实现。
画布缓冲区,画布宽,画布高,画布位信息,图片x坐标,图片y坐标,图片宽,图片高
这八个参数,需要两份,SRC一份,DEC一份。
(不知道为啥,我就喜欢dec,不喜欢dest。。。可能是因为 src 和 dec 字母长度一样,dest 的话,多了个字母。。。看着别扭。。。)
参数多了,要考虑的方向就多了。。。
位相同的情况,位不同的情况,源大,源小,上下左右越位。。。乱七八糟的。愁死了。。。
到这里我就体验到了一点——微软的 bitblt 真的太牛X了。。。
各种容错就乱七八糟一大堆,容错比功能部分代码还长。。。日子不好过。。。
容错在哪容,也是问题,在接口外面容错,但是里面写功能的时候,越界了,溢出了咋整。。。
就现在,我仍然在改这套接口,以及实现,太痛苦了。。。
以后用得着,还可能需要跨平台使用,所以内部东西,不能用对平台依赖性强的东西,不能用乱七八糟的东西。。。
都要被逼疯了。。。
void *src , int srcx , int srcy , int srcxw , int srcyh );
这里已经在我的角度上,极度地精简了大部分接口。。。
最变态的,从一个画布把一块指定位置指定大小的图片拷贝到另一个画布的指定位置指定大小,这么简单的一个功能,就要16个参数来实现。
画布缓冲区,画布宽,画布高,画布位信息,图片x坐标,图片y坐标,图片宽,图片高
这八个参数,需要两份,SRC一份,DEC一份。
(不知道为啥,我就喜欢dec,不喜欢dest。。。可能是因为 src 和 dec 字母长度一样,dest 的话,多了个字母。。。看着别扭。。。)
参数多了,要考虑的方向就多了。。。
位相同的情况,位不同的情况,源大,源小,上下左右越位。。。乱七八糟的。愁死了。。。
到这里我就体验到了一点——微软的 bitblt 真的太牛X了。。。
各种容错就乱七八糟一大堆,容错比功能部分代码还长。。。日子不好过。。。
容错在哪容,也是问题,在接口外面容错,但是里面写功能的时候,越界了,溢出了咋整。。。
就现在,我仍然在改这套接口,以及实现,太痛苦了。。。
以后用得着,还可能需要跨平台使用,所以内部东西,不能用对平台依赖性强的东西,不能用乱七八糟的东西。。。
都要被逼疯了。。。
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 记一次.NET内存居高不下排查解决与启示
· 探究高空视频全景AR技术的实现原理
· 理解Rust引用及其生命周期标识(上)
· 浏览器原生「磁吸」效果!Anchor Positioning 锚点定位神器解析
· 没有源码,如何修改代码逻辑?
· 全程不用写代码,我用AI程序员写了一个飞机大战
· MongoDB 8.0这个新功能碉堡了,比商业数据库还牛
· 记一次.NET内存居高不下排查解决与启示
· 白话解读 Dapr 1.15:你的「微服务管家」又秀新绝活了
· DeepSeek 开源周回顾「GitHub 热点速览」