我是以一个初学者的身份来看这本书的,这个我在前言中就说过了,因此对本章的理解我有点举步维艰,因为本章有很多不常见的API,如游览文件夹,把图片读到特定的内存数据区,这些API都是我作为一个初学者首次遇到的,难免疑点重重,另外本章还有一些系统级定义的结构类型如位图相关结构,最令人头痛的是文件操作,文件操作涉及到指针,句柄(指针与句柄的概念非几十面A4的纸说不清,甚至可以写成一本厚厚的书),MFC对文件对象及文件操作的封装实现属于比较低层的Win32编程知识,Cqtml在书中说过,作为一个初学者,对上述这些东西不必深究,只要知道如何使用它们(系统API函数)就可以了,但是如果随着学习的深入,如果不深入理解Win32编程的一些低层知识,如ASM,MFC,OPP,各种编程语言的对象模型等,你将永远不能深入Win32编程而不能体会到其中的乐趣,对于一些概念的理解,你也将处于模糊的认识程度,本文如有知识上的失误,请高手一定指正,如果你觉得本文出自一个初学者之手没有什么看头的话,请千万止步..
首先来探索一下本章的知识结构,本章从178页的10-3:图形压缩包的使用可以分为前后二部分,前一部分包括OnButton()和LoadBmp(),后一部分主要包含LoadData()和GetPic0(),前一部分是不作为游戏的主体部分的,(后一部分的LoadData()和GetPic0()才是游戏的源程序部分)最后形成的"资源打包.exe"作为游戏的附件工具,这个工具用来对指定文件夹下的指定个指定文件名格式的.bmp和.txt(但是像"景"文件夹下的静物图片没有对应的.txt,程序是怎么处理这个例外情况的呢?景.dar是不是会照样生成?.dar中到底有什么内容呢?后面在谈到前后二部分作为互逆过程的对比会涉及到)作打包和压缩处理,注意这里的措词"打包"和"压缩",可以想像后一部分的LoadData()和GetPic0()是与前一部分的某个函数的功能或某个函数体内的某些语句功能是互为逆过程的,即将打包好的.gam和.dar一次性地读入内存,和在以后的取图操作中能够从.gam和.dar中读入所需的图形数据和偏移数据等,这当然是由GetPic0()中完成的,LoadData()发生在前,它将.gam和.dar一次性读入内存,涉及到MFC对二进制文件的读取知识,而OnButton()在(0,ShuLian)个循环里调用LoadBmp()作压缩打包处理涉及到MFC对二进制文件的写入操作,注意LoadBmp()并不是API,而是自定义的,LoadBmp()内封装了"将图形读入特定内存数据区bil的API,并且加入了新的功能,即不但读入.bmp到bil,还从.bmp对应的.txt读取2个偏移值到&bufx[pop],&bufy[pop],还形成一个&bufadd[pop],最后还验证显示以检验算法及打包结果,而所有的这些都是必要的,因此要在LoadBmp()内对这个API进行封装,现在我们来分析前后2部分互为逆过程的对比,刚才谈到对.gam的写入是按二进制方式进行的,而对.dar的写入是按.txt的写入进行的,对.gam和.dar的实际写入是在OnButton()体内(0,ShuLian)个循环之外进行的,因为所有的循环过程实际上只是Buf形成的过程,于是从173页C:写图形包开始,将其一次性写入到.gam,形成实际的.gam文件(Buf就是.gam文件的内容),每个循环都调用了一次LoadBmp(),LoadBmp(i)被执行,当前循环变量i的值指定的.bmp和.txt分别转化为bil和&bufx[i],&bufy[i],&bufadd[i],bil填充buf,&bufx[i],&bufy[i],&bufadd[i]填充数组bufx[],bufy[],bufadd[],直到i=ShuLian,Buf和三个数组最终形成,在经过C:写图形包,D:写偏移包后,.gam和.dar最终形成,因此最终和写入过程是在OnButton()体内的循环外完成的而不是在(0,ShuLian)个LoadBmp()里完成的,OnButton()作为资源打包.exe界面上的"打包"按钮的消息函数,在(0,ShuLian)个循环里调用LoadBmp(),为什么这样设置呢,这是程序的要求,资源打包.exe的程序流程就是要用户先点击"选择目录"获得指定的文件夹和指定文件夹下的资源个数ShuLian(此时它们被显示到程序界面上的二个文件框内),用户再点击"打包"按钮,OnButton()被执行,ShuLian个LoadBmp()过后,经过C,D二个最终写入过程,.gam和.dar最终生成,每一个LoadBmp()都是向Buf中添加数据块的过程和数组Bufx[],Bufy[],Bufadd[]当前元素值生成的过程,请读者自己想象一下OnButton()体内Buf的内存叠加过程和3个数组不断完善的过程这2个过程,我们知道硬盘上文件有二种,一种是二进制文件,其ASCII码是乱码,因为它在硬盘上的存在形式是按其中内存中被加载形成的镜像来存储的,文件的大小正是镜像的大小,文本文件就不用讲了,MFC对.txt文件的读写都存在一个"读写头"(前面讲到过,在读取初始化表.dat中),以指示下一次的写入位置和读取位置,写入和读取都是用特定的函数来完成的,那么在二进制文件的读写操作中是不是也存在一个"读写头"呢?前面说到,OnButton()体内,Buf的形成过程是内存数据叠加的形式,在i<ShuLian前,当前LoadBmp(i)完成之后,上一次Buf加上新添加的bil形成新的Buf,新的Buf的长度是一个整型数据,它作为一个记录指示下一次LoadBmp(),即LoadBmp(i=i+1)形成的bil的在更(第四声)新的Buf中的写入位置,LoadBmp(i=i+1)过后,更新的Buf的长度作为再下一个内存块的写入位置,很多人理解不了为什么Buf的长度是一个整型数据,如果你知道指针是一个32位整型数据的话你就能理解了(VB中没有指针,把HDC定义为Long),Buf因此既是内存长度,又是一个整型数据,起了指针的作用,指示着下一块内存的写入位置,其实它就是Bufadd[i]的值,打开.dar文件,第一列数据就是Bufadd[i],i属于(0,ShuLian),指示下一次的写入位置即bufadd[i=i+1],Bufadd[i]作为各个图片对应的在Buf中的图片位置,GetPic0()用它来提取指定的图片,打开.dar可以看到它们都是整型数据,共同构成了整个数组Bufadd[]的值,书中称它们为索引,它就相当于.txt中的"读写头",173页定义了Bufadd[1]=0,Buf的大小是15*1024*1024(15M),聪明的你现在一定能够理解这些数字的意义了吧?说完了后一部分再来说前一部分,LoadData()创建文件句柄(文件对象?)来读取.gam和.dar,GetPic0()中有一句根据内存是否为空来判断是否加载了压缩资源包以决定使用何种读取图片和偏移的方式的语句,OpenDir()中FindFile0()是在前一章定义的,封装了浏览文件夹的API,它的功能不仅是返回它的出口参数值,我们应该考虑到它的全部作用,即FindFile0()作为一个普通语句来调用完成的全部功能,除了返回出口参数,它的其它的功能还有将符合条件的文件加入列表框..
首先来探索一下本章的知识结构,本章从178页的10-3:图形压缩包的使用可以分为前后二部分,前一部分包括OnButton()和LoadBmp(),后一部分主要包含LoadData()和GetPic0(),前一部分是不作为游戏的主体部分的,(后一部分的LoadData()和GetPic0()才是游戏的源程序部分)最后形成的"资源打包.exe"作为游戏的附件工具,这个工具用来对指定文件夹下的指定个指定文件名格式的.bmp和.txt(但是像"景"文件夹下的静物图片没有对应的.txt,程序是怎么处理这个例外情况的呢?景.dar是不是会照样生成?.dar中到底有什么内容呢?后面在谈到前后二部分作为互逆过程的对比会涉及到)作打包和压缩处理,注意这里的措词"打包"和"压缩",可以想像后一部分的LoadData()和GetPic0()是与前一部分的某个函数的功能或某个函数体内的某些语句功能是互为逆过程的,即将打包好的.gam和.dar一次性地读入内存,和在以后的取图操作中能够从.gam和.dar中读入所需的图形数据和偏移数据等,这当然是由GetPic0()中完成的,LoadData()发生在前,它将.gam和.dar一次性读入内存,涉及到MFC对二进制文件的读取知识,而OnButton()在(0,ShuLian)个循环里调用LoadBmp()作压缩打包处理涉及到MFC对二进制文件的写入操作,注意LoadBmp()并不是API,而是自定义的,LoadBmp()内封装了"将图形读入特定内存数据区bil的API,并且加入了新的功能,即不但读入.bmp到bil,还从.bmp对应的.txt读取2个偏移值到&bufx[pop],&bufy[pop],还形成一个&bufadd[pop],最后还验证显示以检验算法及打包结果,而所有的这些都是必要的,因此要在LoadBmp()内对这个API进行封装,现在我们来分析前后2部分互为逆过程的对比,刚才谈到对.gam的写入是按二进制方式进行的,而对.dar的写入是按.txt的写入进行的,对.gam和.dar的实际写入是在OnButton()体内(0,ShuLian)个循环之外进行的,因为所有的循环过程实际上只是Buf形成的过程,于是从173页C:写图形包开始,将其一次性写入到.gam,形成实际的.gam文件(Buf就是.gam文件的内容),每个循环都调用了一次LoadBmp(),LoadBmp(i)被执行,当前循环变量i的值指定的.bmp和.txt分别转化为bil和&bufx[i],&bufy[i],&bufadd[i],bil填充buf,&bufx[i],&bufy[i],&bufadd[i]填充数组bufx[],bufy[],bufadd[],直到i=ShuLian,Buf和三个数组最终形成,在经过C:写图形包,D:写偏移包后,.gam和.dar最终形成,因此最终和写入过程是在OnButton()体内的循环外完成的而不是在(0,ShuLian)个LoadBmp()里完成的,OnButton()作为资源打包.exe界面上的"打包"按钮的消息函数,在(0,ShuLian)个循环里调用LoadBmp(),为什么这样设置呢,这是程序的要求,资源打包.exe的程序流程就是要用户先点击"选择目录"获得指定的文件夹和指定文件夹下的资源个数ShuLian(此时它们被显示到程序界面上的二个文件框内),用户再点击"打包"按钮,OnButton()被执行,ShuLian个LoadBmp()过后,经过C,D二个最终写入过程,.gam和.dar最终生成,每一个LoadBmp()都是向Buf中添加数据块的过程和数组Bufx[],Bufy[],Bufadd[]当前元素值生成的过程,请读者自己想象一下OnButton()体内Buf的内存叠加过程和3个数组不断完善的过程这2个过程,我们知道硬盘上文件有二种,一种是二进制文件,其ASCII码是乱码,因为它在硬盘上的存在形式是按其中内存中被加载形成的镜像来存储的,文件的大小正是镜像的大小,文本文件就不用讲了,MFC对.txt文件的读写都存在一个"读写头"(前面讲到过,在读取初始化表.dat中),以指示下一次的写入位置和读取位置,写入和读取都是用特定的函数来完成的,那么在二进制文件的读写操作中是不是也存在一个"读写头"呢?前面说到,OnButton()体内,Buf的形成过程是内存数据叠加的形式,在i<ShuLian前,当前LoadBmp(i)完成之后,上一次Buf加上新添加的bil形成新的Buf,新的Buf的长度是一个整型数据,它作为一个记录指示下一次LoadBmp(),即LoadBmp(i=i+1)形成的bil的在更(第四声)新的Buf中的写入位置,LoadBmp(i=i+1)过后,更新的Buf的长度作为再下一个内存块的写入位置,很多人理解不了为什么Buf的长度是一个整型数据,如果你知道指针是一个32位整型数据的话你就能理解了(VB中没有指针,把HDC定义为Long),Buf因此既是内存长度,又是一个整型数据,起了指针的作用,指示着下一块内存的写入位置,其实它就是Bufadd[i]的值,打开.dar文件,第一列数据就是Bufadd[i],i属于(0,ShuLian),指示下一次的写入位置即bufadd[i=i+1],Bufadd[i]作为各个图片对应的在Buf中的图片位置,GetPic0()用它来提取指定的图片,打开.dar可以看到它们都是整型数据,共同构成了整个数组Bufadd[]的值,书中称它们为索引,它就相当于.txt中的"读写头",173页定义了Bufadd[1]=0,Buf的大小是15*1024*1024(15M),聪明的你现在一定能够理解这些数字的意义了吧?说完了后一部分再来说前一部分,LoadData()创建文件句柄(文件对象?)来读取.gam和.dar,GetPic0()中有一句根据内存是否为空来判断是否加载了压缩资源包以决定使用何种读取图片和偏移的方式的语句,OpenDir()中FindFile0()是在前一章定义的,封装了浏览文件夹的API,它的功能不仅是返回它的出口参数值,我们应该考虑到它的全部作用,即FindFile0()作为一个普通语句来调用完成的全部功能,除了返回出口参数,它的其它的功能还有将符合条件的文件加入列表框..
768
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
