我想做的事情是这样子:一个人物在地图中间,他走动时保持在屏幕中间,只是地图在移动,地图比较大,所以分割成一块一块小图片,在需要某部分时再行装载,这个装载过程暂时可以不考虑,主要是屏幕输出,我想问,如果直接用gdi来画,用平常的double buffer方法,先在临时bitmap上作图,然后再bitblt到hdc上,这样做行不行?大概一秒钟4帧左右,会不会觉得卡?大家在这方面一般的思路和做法是怎样的?我对directx不熟悉,如果gdi能做得到的话,就直接用gdi了没搞过,请不吝赐教!谢谢!!!

解决方案 »

  1.   

    我见过一个directx做的,也是delphi写的,好像叫 rpg directx demo 你可以搜索一下看看
      

  2.   

    bitblt可以画的。需要两张图片,其中一张mask。每秒4帧太少了
      

  3.   

    用GDI可能会有闪烁,用directx会更好一些收藏过一篇用DelphiX的,里面的例子和你那个比较像用Delphi + DirectX开发简单RPG游戏
    http://www.pconline.com.cn/pcedu/empolder/gj/delphi/0401/269462.html
      

  4.   

    谢谢各位!to sdzeng, 那个例子我先试试,不熟悉DirectX,而且感觉在directx里面做输入框,列表/表格什么的比较麻烦,不象windows程序,拖拉个空间,最多ownerdraw一下就行,所以才想用gdi,我刚才用graphic32试了一下20帧(不知道是否有,timer.interval=50),是有一点点闪烁的感觉,,我的地图有50多m,不宜整个装在内存吧?
      

  5.   

    如果地图不大,全部装进内存会快一些,人物移动后,
    根据鼠标偏移量,调整设口和视口坐标,就可以达到想要的效果。
    如果地图很大,就不适合全装进内存,这时就得考虑把地图分割,
    用一个队列作缓存,队列里装载相邻的几幅小图,
    人物移动时,根据鼠标偏移量,判断可能会用上哪几幅
    一时半会用不上的小图就抛弃掉,有可能用上的就预先装载还有,不建议用timer定时重绘,因为有的时候人物可能不行走,或者行走的幅度不大,
    没必要定时重绘,最好根据鼠标偏移量调整一下设口和视口坐标
      

  6.   

    1、地图的载入和sdzeng说的基本一样,补充一下的是,大的地图,通常是使用双线程,载入一个线程,绘制一个线程。
    2、闪烁的问题,跟使用GDI、GDI+还是DirectX关系并不大,游戏的制作都应该采用内存缓冲绘图技术:在内存中建离屏画布,把所有需要画的东西都先画上去,然后再到屏幕。
    3、通常游戏的刷新率是保持在每秒30帧,不过每秒24帧的刷新率就可以欺骗我们可怜的眼睛了。
      

  7.   

    补充一下,每秒4帧,只能说明你的代码没有优化,在使用GDI+的情况下,1024*1024的分辨率,保持每秒30帧的速度,问题不是很大,而使用GDI应该会更快了。
      

  8.   

    to sdzeng:>不建议用timer定时重绘,因为有的时候人物可能不行走,或者行走的幅度不大,
    >没必要定时重绘,最好根据鼠标偏移量调整一下设口和视口坐标启发很大,多谢了
    to yinxu:>补充一下,每秒4帧,只能说明你的代码没有优化,在使用GDI+的情况下,1024*1024的分辨率,
    >保持每秒30帧的速度,问题不是很大,而使用GDI应该会更快了。这样我有点信心了,对我鼓励很大,
    暂时先丢开作图和输出的问题,我再进一步尝试再问,目前我对这个程序的写法也很模糊,所以还没有作代码,我的情况是这样,我的游戏里有个时间日期的概念,人物移动和时间有关系,比如人物移动100像素,大概就消耗去一天了,时间一过去某些事件可能会触发,其他完成一定任务或行动的人物也会考虑进一步的行动,而且地图上还有其他人物,飞鸟,云雾等,那么是否这样子作,以timer为驱动,然后在timer的事件里作人物状态,行动,位置,事件等的计算,如果有必要更新屏幕的话再输出?
      

  9.   

    楼上几位干什么事呢???说了那么多有啥用...记的网易云风也是这样说,用这个小地图装载..我现在才觉的狂不舒服..我手里的一本VC++游戏设计也是这么讲的,实际上一点也好.我一直觉的大话西游的走路有点很碍眼!人物走路都不爽,韩国的破天一剑(2D),霸王大陆(3D).人物走在地图上很顺畅.我从不会跟他学去那样做,我还是喜欢魔兽的做法,一起把图片装载进去得了....至于网游里,大地图无缝衔接的技术,我还没想到办法..天堂2,霸王大陆都做到了,还有很多.看你游戏了,我一般都是装载大图,现在用户的机器配置都不错,大多数都比我的好.我的机器很烂...
      

  10.   

    我同事看了云风的书,现在的头脑不要太热,太崇拜他哟..一本烂书,害了一个人...基本的交流都没办法下去,嘴里就剩网易,云风了....开始,我也被他迷惑了....妈的,还好我清醒,我现在都E文游戏开发的书,基本很少看国内翻译的,或者所谓的高手的书.国外一个游戏引擎资深人员告诉我,把英语学好,到外国的网站多交流,学习.国外十大开源,免费游戏引擎,任何一款都绝对比风魂的好.可惜小弟在研究中...暂时没拿出一个有说服力的,我还在默默无闻的学习中....一句话,想超越国内的高人,多看E文书,多上E文游戏开发网站.当然多多练习也很重要.......希望,不会再有目光短浅的人..........游戏还是外国人的强,我们应该尊重他们,学习他们的东西...顺便举个例子,一个枪口射击的火花,很多人会找N副图去做这个效果,实际上只要一张就能完美解决这个效果(差距在这...)
      

  11.   

    汗,不好意思....心态不是很好,失礼了...
    刚刚被领导喊过去和同事讲游戏精灵的技术,结果被云风的Fans 一顿鄙视..我也是用Delphi 的,公司从上到下都比较轻视Delphi.推崇VC.结果不还是Delphi开发的游戏最多,技术含量最好,速度最快.这几天有点郁闷.上来发发闷气...请楼主别见怪...大家有空发帖聊聊Delphi游戏开发技术...适当的时候我也公开游戏代码.
      

  12.   

    推荐 Delphi + Asphyre 这个组合...Delphi + DelphiX  我用这个做了两个小游戏,贴图那一块本身控件封的不好.上面的是很不错的,两者效率上有很大差距...个人觉的是最佳Delphi开发游戏的平台...
      

  13.   

    抛了几块砖,终于引来了更大的砖
    我不是做游戏的,也没看过云风的书,
    以前做过一些图像处理类的工作,如有雷同,纯属巧合而已大图分割、缓存、多线程。
    在进行一些视觉要求不高应用的时候,
    这些也算是比较“传统”的办法,
    不停的装载、重绘的确有停顿的问题,
    不过,能处理好的话,应该可以把这个问题控制在可以忍受的范围内GDI本身就不是用来开发游戏的,否则MS也不会去搞个DirectX,
    所以还是应该根据实际的需求,来决定到底选哪种技术
    能实现要求的,就是好技术,实用第一
      

  14.   

    我还是不太认同yangbiao说的一次把背景图像全部装载的做法,
    也许50M的图像可以一次装载,100M、500M的呢?存在就是合理,毕竟很多游戏都不是像魔兽那样“吃”硬件,
    在效率和硬件之间找到一个平衡点,这对程序员来说,也算是个挑战
    不能一味依赖硬件。
      

  15.   

    我的游戏比较简单,仿制某个游戏,做来自己玩的,图片,游戏数据都算是现成的,主要是对象间具体关系以及AI和图形输出这些方面要废很大的功夫,属于自己业余爱好吧,因为我不熟悉作动画,所以就问了这个问题,在我的游戏中,实际上最复杂的图形部分就是在大地图上能走动和变化的东西了(太简单了是么?),所以这方面如果gdi能过关,或者说我能过关,游戏的图形部分就可以考虑用gdi了装图的事,其实也不是很要紧的,我只是问个经验数据,看看先怎么实现,反正只是一个接口,具体是一次装载还是load on demand这也可以只是设置的问题Asphyre我粗略浏览过,还有一个spriteengine,不过这些对我来说都太复杂了,我需要学习很多新东西,文档少,很多东西只有代码没有详细地讲解,spriteengine有个例子,演示的就是人物在地图上走动,和我的不完全一样,我的地图还有哪些地方要求人物具有怎样的属性才能到达,哪些地方某些资源比较多,哪些地方没有,什么时间走到哪里会发生怎样的事件等等特殊的地方,这要废很多时间去搞清楚才能用的比较灵活,也有可能要废很大的劲才能把某些不能满足我的需求的部分修改成自己期望的样子,directx也一样,对于我来说一者陌生,二者主要是制作起一些user interface起来不那么方便快捷,而如果直接用gdi的话,就可以相对的比较得心应手,大家都知道做一个游戏不是一两个月的事,何况我是业余的,最好能舍远求近明天后天再学习学习看看,有问题再问,先谢谢了:)ps:菜鸟不懂问问题我今天又重新体会到了
      

  16.   

    回答问题也要被人骂,郁闷...还是yangbiao厉害,工作三年就悟出真理了.
    不像我也是写了5\6年的,却还是在寻路.