不好意思，这次失言了，这个圣诞节没版本发布。其实也不是没时间，不吃饭不睡觉还是有大把时间的，事实是我不想再碰那些代码了。

I'm sorry,there is no final release this christmas.Actually there still have some time if I save the eating and sleeping time.The truth is I don't want touch the code any more.

Next year should be a starting point to enter some parties, do some serious staff.

这个工具实际是从内存中把ETQW的数据段和代码段中相关的部分抓出来,然后保存到硬盘,存储成asm文件,然后编译一下生成的.说起来似乎比较简单,reverse engineering其实是很件费时间的事情.

Thanks~

To ArenAK:
简单说，PeonyGarden主要做一些我们自己觉得很＂cool＂的事情，目前打算参与DemoScene. 程序写的小是因为规则就是这么制定的，要不怎么叫256b　intro那，大家花时间写这么小的程序主要是因为觉得这是一种挑战．

To Nez:
Thanks,that's the spirit.

To Sir Garbagetruck:
At first, thank you for your attention.Next time you can just input english,I can read without much difficulty.
What can I say?As for job,I think it is some kind of real life stuff,sometimes I need it more than I like it.
As for DemoScene,take it as a hobby will be nice.

作者是michael abrash,以前有一本书<<图形开发人员指南>>(1997年出版的)作者.
原文链接:
http://www.gamasutra.com/features/20010117/abrash_pfv.htm

这个是软件渲染的engine,并没有调用opengl的接口,原因有两个:第一,手机上的opengl实现都太慢,第二,效果也不好.

那个文档的确那么描述的,但是如果这样的话,以前好象有个文章讲"modern software renderer",里面的填充算法采用的是类似光线跟踪的方法,不知道现在的显卡是不是这么处理的.
不管怎么样,这个思路可以借鉴一下,有时间试试.

我指的是clip.
如果B不进行clip操作,那么B中所有的象素点都要进行scissor test,这样做是不是会影响效率,因为很多点显然都不在此效范围内.还有如果scissor test可以满足要求的话,Guard Band的做用如何体现?B和C对于scissor test是等效的.
或者把上述观点完全推翻,假设是通过scissor test来处理,那么Guard Band的唯一用处是用来解决精度问题,因为B和C的区别,就在于他们投影的位置可能会超出屏幕的定点数的精度.但是我怀疑这样做效率损失会比得到的多.

长见识了.有一点出不太明白,想讨论一下,
首先我对于显卡驱动的渲染过程不是很了解(但是对于软件渲染了解一些), 按照一般的理论,光删化之前,必须要完成剪裁,对吧?对于图中B的三角形,在光删化的时候,也需要剪裁吧,你的意图是不是在剪裁的时候只计算剪裁产生屏幕的顶点,而对于u,v, color, specular, alpha and fog,这些只需要计算梯度就可以的,就没必要参与剪裁了,right?
第二,对于游戏,和一般的应用来说,跨度超越整个屏幕的三角形的面数应该不会很多,所以这个Guard Band 应该也不是越大越好.

Cool!

申请加入