快速存储Bitmap的Marshal（高难度API，不解释）

柳之一

vx xp均可以使用
object_id * 2 + 16 这个是关键中的关键。详细的部分请调查ruby的资源的rb_obj_id和DATA_PTR这个部分。

io形式等等按照自己的需求来自己设定

1. class Font
   
2. def marshal_dump;end
   
3. def marshal_load(obj);end
   
4. end
   
5. class Bitmap
   
6. # 传送到内存的API函数
   
7. RtlMoveMemory_pi = Win32API.new('kernel32', 'RtlMoveMemory', 'pii', 'i')
   
8. RtlMoveMemory_ip = Win32API.new('kernel32', 'RtlMoveMemory', 'ipi', 'i')
   
9. def _dump(limit)
   
10. data = "rgba" * width * height
    
11. RtlMoveMemory_pi.call(data, address, data.length)
    
12. [width, height, Zlib::Deflate.deflate(data)].pack("LLa*") # 压缩
    
13. end
    
14. def self._load(str)
    
15. w, h, zdata = str.unpack("LLa*"); b = new(w, h)
    
16. RtlMoveMemory_ip.call(b.address, Zlib::Inflate.inflate(zdata), w * h * 4); b
    
17. end
    
18. # [[[bitmap.object_id * 2 + 16] + 8] + 16] == 数据的开头
    
19. #
    
20. def address
    
21. buffer, ad = "xxxx", object_id * 2 + 16
    
22. RtlMoveMemory_pi.call(buffer, ad, 4); ad = buffer.unpack("L")[0] + 8
    
23. RtlMoveMemory_pi.call(buffer, ad, 4); ad = buffer.unpack("L")[0] + 16
    
24. RtlMoveMemory_pi.call(buffer, ad, 4); return buffer.unpack("L")[0]
    
25. end
    
26. end

复制代码

注意，这个脚本对于增强你的游戏性没有什么帮助，是关于如何储存图片的。
能打算使用这个的也是不需要范例的，要范例的估计也用不到。

不知道能不能解决 沉影不器 的 求把缓存里的bitmap压入存档的有效率的办法。如果不是的话，请原谅在下。

灼眼的夏娜

以下引用沉影不器于2008-8-10 9:20:20的发言：

我没下载那些什么ruby资源之流,我是先默认'object_id*2 + 16'成立,那么所有内存操作都明显成立了.

。。。。并不都是这样的。。。。  这个16是和扩展类的data指针偏移对应的……{/gg}

danny8376

以下引用dna_7086于2008-8-11 12:38:50的发言：


以下引用link006007于2008-8-9 12:09:57的发言：

我一直很好奇  
我觉得  最关键是lz最早是怎么得到bitmap的图像数据是保存在Bitmap实例内存首地址偏移这么多的量之后的内存地址中的



你用OllDBG跟踪GAME.EXE试试吧,应该也能得到吧...

跟踪没用
因为主程序是RGSSX0XX.dll
而且这还是个直译器
能得到什么东西啊
还不就一堆直译器的指令



楼主
想问一下address
最后传回的是內存的实体地址
还是RGSS内部的地址


顺便介绍一下此脚本吧


# 贴上此脚本后
# 可直接用Marshal模组读写Bitmap类
# 不需多做修改
# 介绍一下Marshal模组运作原理
# 以脚本呈现
# 不代表实际执行的脚本
# def Marshal.dump(obj, port = nil, limit = 100)
#   result = # obj._dump(limit) or obj.marshal_dump 其中一个
#   return result if port == nil
#   写入 result 至 port
# end
# def Marshal.load(port)
#   dat = 读取 port
#   return # obj._load(dat) or obj.marshal_load(dat) 其中一个
# end
# 上面的 写入 和 读取 为一些IO的指令
class Font
  # Marshal.dump 对类调用的主程序
  def marshal_dump
  end
  # Marshal.load 对类调用的主程序
  def marshal_load(obj)
  end
  # 上面的方法没定义内容是因为
  # Font类对Bitmap类中的存储不重要
  # 而预设Font类也没有这2个方法
end
class Bitmap
  # 传送到内存的API函数
  # 读取内存用 参数为 字串 整数 整数
  RtlMoveMemory_pi = Win32API.new('kernel32', 'RtlMoveMemory', 'pii', 'i')
  # 写入内存用 参数为 整数 字串 整数
  RtlMoveMemory_ip = Win32API.new('kernel32', 'RtlMoveMemory', 'ipi', 'i')
  # 在此整数为1字节的整数
  # Win32API 会帮忙转换
  # 供 Marshal 模组用的写入方法
  def _dump(limit) # limit 为 深度限制 但这里忽略不使用
    # 生成 4 * width * height 个字节的字串
    # 所以 "rgba" 可换成 任何4字节的字串 如 "\000" * 4
    # 在此为 RtlMoveMemory_pi 生成所需的内存空间
    data = "rgba" * width * height
    # 调用 RtlMoveMemory_pi 读取
    # 以address为地址
    # 长度为data.length ( 即 4 * width * height )
    # 的内存资料 并存入 data 中
    RtlMoveMemory_pi.call(data, address, data.length)
    # 将 [width, height, Zlib::Deflate.deflate(data)] 打包
    # [width, height, Zlib::Deflate.deflate(data)]
    # width,  height 为图片宽度 ( Bitmap 内属性 )
    # Zlib::Deflate.deflate(data)为压缩 data 内的文字 (GZip)
    # 至于 Array.pack 的参数是什么不重要
    # 只要跟 String.unpack 的参数一样就好
     # ※ 回传给 Marshal.dump 的资料必须为 String ( 字串 ) 类物件
    # 　 因为 _dump 或 marshal_dump 的工作即为
    # 　 将该类物件转为字串给 Marshal.dump 存入
   [width, height, Zlib::Deflate.deflate(data)].pack("LLa*") # ??
  end
  # 供 Marshal 模组用的读取方法
  def self._load(str) # str 为 Marshal.load 读出的字串
    # 解包 str
    # 并将解包后的阵列([width, height, data(压缩后)])
    # 分别存入w, h, zdata
    # w => width, h => height, zdata => data(压缩后)
    w, h, zdata = str.unpack("LLa*")
    # 生成 以 w 和 h 为宽高的图片
    # new 为继承 Object 的方法
    # 因此在任何物件中都有此方法
    b = new(w, h)
    # 调用 RtlMoveMemory_ip 修改
    # 以b.address为地址
    # Zlib::Inflate.inflate(zdata) 为资料
    # Zlib::Inflate.inflate(zdata) 为解压缩 zdata 内的文字 (GZip)
    # 长度为 w * h * 4
    # 的内存资料
    RtlMoveMemory_ip.call(b.address, Zlib::Inflate.inflate(zdata), w * h * 4)
    # 回传 b
    # 在 Ruby 中无 return 的话
    # 会自动回传最后一个指令的回传值
    b
  end
  # [[[bitmap.object_id * 2 + 16] + 8] + 16] == 数据的开头
  def address
    # 定义 buffer 和 ad 为 "xxxx" 和 object_id * 2 + 16
    # 这是Ruby的多重指定
    # 左边超过右边时 超出的部份不会带入数值 ( 即同于带入 nil )
    # 右边超过左边时 超出的部份不管
    # 但左边最后一个变量以*开头时
    # 超出部份会以阵列带入该变量
    # 左边1个而右边超过1个时
    # 同于 *变数 = 值1, 值2, ...
    buffer, ad = "xxxx", object_id * 2 + 16
    # 下方为以 RtlMoveMemory_pi 逐步取得地址
    # 在此不做说明
    RtlMoveMemory_pi.call(buffer, ad, 4)
    ad = buffer.unpack("L")[0] + 8
    RtlMoveMemory_pi.call(buffer, ad, 4)
    ad = buffer.unpack("L")[0] + 16
    RtlMoveMemory_pi.call(buffer, ad, 4)
    # 回传 buffer.unpack("L")[0]
    # buffer.unpack("L") 在此不做说明
    return buffer.unpack("L")[0]
  end
end

dna_7086

以下引用link006007于2008-8-9 12:09:57的发言：

我一直很好奇  
我觉得  最关键是lz最早是怎么得到bitmap的图像数据是保存在Bitmap实例内存首地址偏移这么多的量之后的内存地址中的

你用OllDBG跟踪GAME.EXE试试吧,应该也能得到吧...{/fd}

沉影不器

以下引用link006007于2008-8-10 2:50:02的发言：
不会就是rb_obj_id 函数体里那段注释吧?  没看出来和object_id*2有什么关系
到现在也没看懂 ruby的对象的self和他对应的C结构体指针怎么算...
找到对应函数, 看不懂里面过程

我没下载那些什么ruby资源之流,我是先默认'object_id*2 + 16'成立,那么所有内存操作都明显成立了.

如今对font和bitmap内部类兴趣,我们知道Bitmap类有个属性font,现在从这份脚本往回猜,可猜得font在bitmap中是作为实例变量存在的...
以上,我希望得到楼主的确认并告知更多,可惜他总避而不谈,只是一再强调rb_obj_id和DATA_PTR...可Bitmap是标准库么....

1. 
   
2. class Bitmap
   
3.   def font
   
4.     self.font = Font.new("宋体",12)
   
5.   end
   
6. end
   

复制代码

link006007

半夜睡不着, 爬上来研究这个脚本果然很有催眠效果{/gg}
lz会写这个脚本, 应该可以自己DIY  ruby了吧?

以下引用沉影不器于2008-8-9 22:26:18的发言：object_id * 2 + 16<---这个楼主很早就说明了在ruby资源文件里头说的
这脚本的伟大还在于真的需要了解到很多内部类的构成啊啊啊...

不会就是rb_obj_id 函数体里那段注释吧?  没看出来和object_id*2有什么关系{/gg}
到现在也没看懂 ruby的对象的self和他对应的C结构体指针怎么算...
找到对应函数, 看不懂里面过程{/gg}

沉影不器

以下引用link006007于2008-8-9 12:09:57的发言：

我一直很好奇  
我觉得  最关键是lz最早是怎么得到bitmap的图像数据是保存在Bitmap实例内存首地址偏移这么多的量之后的内存地址中的

object_id * 2 + 16<---这个楼主很早就说明了在ruby资源文件里头说的
这脚本的伟大还在于真的需要了解到很多内部类的构成啊啊啊...

link006007

ls...  写了这么长... 没说到我想要的{/dk}

hide秀

这个帖子这么受人关注了
先不管柳之一这些内部方法怎么得到的
柳之一不解释。。。。
。。。我来解释下这个强贴吧
我到后面也有些疑问，麻烦柳之一解释下吧
如有分析的不对的地方，请指正{/hx}
[quote]
RtlMoveMemory_pi = Win32API.new('kernel32', 'RtlMoveMemory', 'pii', 'i')
RtlMoveMemory_ip = Win32API.new('kernel32', 'RtlMoveMemory', 'ipi', 'i')
一个是 传送字符串到内存 参数1:字符串 参数2:地址 参数3:长度
另一个 传送整型到内存   参数1:整型   参数2:地址 参数3:长度

def _dump(limit)
data = "rgba" * width * height
RtlMoveMemory_pi.call(data, address, data.length)
[width, height, Zlib::Deflate.deflate(data)].pack("LLa*") # 压缩
end

这个方法是开辟临时内存空间的
"rgba"看作是4个字节
data = "rgba" * width * height
像素的集合块(其实是开辟内存空间，并没有实质内容，就是字符串"rgba"的循环)

RtlMoveMemory_pi.call(data, address, data.length)
把像素集合块存储到内存地址
记得这个定义的时候是传送字符串么 就是把"rgba"的字符串循环存入
实际已经占用了内存
参数指定了数据块，要传送的地址，数据块长度

[width, height, Zlib::Deflate.deflate(data)].pack("LLa*")
这个是把宽度，高度，数据组成的数祖转换成2进制形式字符串组
这里转换3个数据
第一和第二个是把bitmap的 宽度，高度打成长型(一个字节用C,超过一个字节用I或者L)
第三个a*是先把数据块所有字符串用Zlib压缩成压缩数据 然后打包成ASCII形式
不过这个不知道这么做有啥用。。
纯粹打包下成字符串 也没有带入变量
请柳之一解释。。

def self._load(str)
w, h, zdata = str.unpack("LLa*"); b = new(w, h)
RtlMoveMemory_ip.call(b.address, Zlib::Inflate.inflate(zdata), w * h * 4); b
end

这个是定义从内存读取像素点阵块

w, h, zdata = str.unpack("LLa*");
记得之前的方法最后已经把数据打包成的字符串组么
这个就是把字符串组里面的数据打包还原成数组
感觉和之前那个没有带入变量的字符串组有点联系{/gg}
并且分别传给变量w,h,zdata(还未Inflate)

b = new(w, h)
生成bitmap对象 带入b

RtlMoveMemory_ip.call(b.address, Zlib::Inflate.inflate(zdata), w * h * 4); b
把Inflate后的zdata数据 存入对象偏移后的地址(这个稍后解释)
这个api定义的时候是i型的 因为存入的是实际rgba像素值和透明度值了
并不是之前那个定义为p的"rgba"临时字符串组 这些小细节不知道大家注意了没有{/wx}

def address
buffer, ad = "xxxx", object_id * 2 + 16
RtlMoveMemory_pi.call(buffer, ad, 4); ad = buffer.unpack("L")[0] + 8
RtlMoveMemory_pi.call(buffer, ad, 4); ad = buffer.unpack("L")[0] + 16
RtlMoveMemory_pi.call(buffer, ad, 4); return buffer.unpack("L")[0]
end

这个adress方法就是定义要存入的地址
返回的是一个地址
buffer, ad = "xxxx", object_id * 2 + 16
buffer = "xxxx"  定义字符串"xxxx"
ad = object_id * 2 + 16   定义初始化内存偏址
object_id是 是这个bitmap对象的内部分配的id
根据ad = object_id * 2 + 16 判断
这个object_id 和对象存放数据的地址有关

RtlMoveMemory_pi.call(buffer, ad, 4)
把字符串"xxxx"存入初始化内存 地址为:object_id * 2 + 16

ad = object_id * 2 + 16
ad = buffer.unpack("L")[0] + 8
ad = buffer.unpack("L")[0] + 16

这三个地址分别 存入4个字节 也就是 "xxxx"

概括就是 存入四个字节"xxxx" 偏移4个字节
再存入四个字节"xxxx" 偏移12个字节
再存入四个字节"xxxx"
不知道有什么用....{/gg}

最后返回的是
return buffer.unpack("L")[0]
应该是实际数据要存入的内存地址

解释完毕....

我也补充下疑问...
return buffer.unpack("L")[0]
应该是实际存放地址开始部分
但是之前的注释
# [[[bitmap.object_id * 2 + 16] + 8] + 16] == 数据的开头
应该是相等的地址。。。。
但怎么想也联系不到一起。。。{/gg}
其实也就是object_id 和 buffer.unpack("L")[0] 的关系
麻烦柳之一解释下。。。{/wx}

link006007

{/ll}  你不会是那个程序员吧~~~
哎  劫狱去...{/hx}