第一帖就发个软件吧——GVmakerAD

FantasyDR

移植自EastSun同学作的手机上的GVmaker模拟器。

于是在G1上也可以跑GVM1.0的程序了T_T
作为一个怀旧狂来说，这是多么愉快的事情啊。

源码可以在这里下载到：
http://code.google.com/p/jgvm/

如果你有G1（注意是G1，因为木有键盘就木有机会玩啊）
在Android Market上搜索GVmakerAD即可下载到，说明都写在软件的help菜单中。

注意键盘映射哦～～还有Bug以后再说了，跑起来比较慢，暂时先看个热闹吧。

jason

G1有全键盘, 可以当wqx了
赞一个~

ForeverMai

那个，图标很萌，游戏还没下-。-

Isword

无图无真相。。

叉烧饭

牛啊，不过没有G1，来凑热闹

CZJ1906

用wm模拟试试

waiting

能更新下吗？

llmmkc123

原帖由 jason 于 2009-8-24 13:45 发表
G1有全键盘, 可以当wqx了
赞一个~

想起了LEE当年流产的那个TC800纯LAVA计划。

FantasyDR

你是说更新啥？

Eastsun

原帖由 FantasyDR 于 2009-8-24 13:42 发表
注意键盘映射哦～～还有Bug以后再说了，跑起来比较慢，暂时先看个热闹吧。

咋会慢呢？
G1的硬件，其JVM的性能都比我的手机强N多Y

[ 本帖最后由 Eastsun 于 2009-10-5 20:05 编辑 ]

waiting

跑起来比较慢 真的是慢的很
特别时时空引擎的游戏 像神州之类的 走起路来一顿一顿的

Eastsun

介是咋回事呢？据原来那个帖子的反应，运行都还比较流畅才是。
我没有G1，无法测试，F有没有测试过是那一块的性能有问题？
我在多普达586W上测试，运行时间主要耗在从JGVM中复制图像数据到手机屏幕这一块，JGVM解释运行GVmaker程序本身速度应该不慢。

waiting

我 g1用的hero的系统
然后用java模拟的gvmaker psp的那个版本
速度很不错 感觉太快了点 全屏显示的 除了上下有白条 毕竟分辨率不是160X80的
apk的速度那就叫个 慢了  
一卡一卡的 显示屏幕小 还是黑白的 都没文曲星的 感觉的
java的gvmaker模拟器就是楼上做的 吧 如果有时间更新下吧 设置按键比较麻烦

Eastsun

话说你想要更新啥呢？g1是全键盘的，你只要使用psp那个版本，设置一次按键就不用再设置了，具体方法参考我原贴关于“高度可配置版”的说明

waiting

Java的版本确实不错，但有些时候按键也不好设，因为不知道程序用到的键有哪些，而且快的有点过头。按键延迟太小，一不小心就双击了，其实这些都可以忍受，最大的弊端是暂时没找到可用的java授权工具，每次启动模拟器要询问好几次，打开一个程序又要询问好几次，对于文件操作比较频繁的程序更是不停的询问，这个有解决的方法吗？
apk版的如果更新的话希望也可以全屏显示，背景颜色该下，可以自行设置键盘映射，最主要的还是速度了，就算我把cpu频率设到最高还是感觉向怕一样慢。

Eastsun

原帖由 waiting 于 2009-10-6 21:07 发表
Java的版本确实不错，但有些时候按键也不好设，因为不知道程序用到的键有哪些，而且快的有点过头。按键延迟太小，一不小心就双击了，其实这些都可以忍受，最大的弊端是暂时没找到可用的java授权工具，每次启动模拟器要询问好几次，打 ...

G1不是全键盘么？你把jar里面的default.ini（默认按键映射）改成手机键盘和文曲星1对1不就可以了么。这样文曲星上怎么玩，手机上照玩。
按键延迟太小。。。这个不太清楚，感觉我手机上还好
我没有G1，暂时也没有开发Android程序的兴趣，所以爱莫能助了。
不过手机上玩GVmaker，其实也就回味一下当年玩文曲星的乐趣罢了，不用太认真。

waiting

G1不是全键盘么？你把jar里面的default.ini（默认按键映射）改成手机键盘和文曲星1对1不就可以了么。这样文曲星上怎么玩，手机上照玩。
我开始也这么想的 但g1的键盘还是比较特殊的 如果a-z全部映射上 那方向键和caps都只得用轨迹球
要是能够映射其他几个不是ascii标准里的向搜索键之类的就好了
其实主要的是授权的问题比较麻烦  上面的都还好
我也只是比较怀旧 现在想起来只有完文曲星的那段时间值得我留恋了

FantasyDR

原帖由 Eastsun 于 2009-10-6 13:32 发表
介是咋回事呢？据原来那个帖子的反应，运行都还比较流畅才是。
我没有G1，无法测试，F有没有测试过是那一块的性能有问题？
我在多普达586W上测试，运行时间主要耗在从JGVM中复制图像数据到手机屏幕这一块，JGVM解释运行GVmaker程序 ...

嗯，我看下来主要也是这里慢。

绘制操作还有改进的地方，比如屏幕操作现在使用的是一个32bit的数组，其实2bit就够了，或者8bit也行。
另外，解释器在某些地方会被阻塞，这会造成解释器无法以固定频率工作。比如，调用等待键盘响应的函数，解释器也被阻塞了，那个tick()就不返回了。

不过，毕竟是怀旧软件，有空儿再说吧^_^

Eastsun

原帖由 FantasyDR 于 2009-10-7 19:12 发表


嗯，我看下来主要也是这里慢。

绘制操作还有改进的地方，比如屏幕操作现在使用的是一个32bit的数组，其实2bit就够了，或者8bit也行。
另外，解释器在某些地方会被阻塞，这会造成解释器无法以固定频率工作。比如，调用等待键盘响 ...

用8bit应该是最快的方式
但也不至于会造成慢吧，我多普达586W才200MHZ的CPU还挺流畅的
至于按键阻塞，这不是应该的么？
至于解释器以固定的频率工作，这个需求不是必要的吧？快一点一般没多大影响，大部分GVmaker程序都有自己的延迟判断。
当然如果你想，可以修改一下nextStep的方法签名，让它返回一个值反应所执行的指令是否是阻塞。甚至添加一个方法 boolean isNextStepBlock(),在执行nextStep之前获得该指令的执行状态。

Eastsun

刚才去看了一下AD版的代码，这里似乎可以优化？

1.     public void update() {
   
2.         // TODO: use buffer directly
   
3.         IntBuffer buffer = IntBuffer.allocate(ScreenModel.WIDTH * ScreenModel.HEIGHT);
   
4.         buffer.put(mBuffer);
   
5.         
   
6.         buffer.position(0);
   
7.         mBitmap.copyPixelsFromBuffer(buffer);
   
8.         mDirty = false;
   
9.     }

复制代码

每update一次，会allocate一个新的IntBuffer,这个肯定会严重影响性能。
至少根据我查看docs，这个IntBuffer完全是不必要的。
直接使用mBitmap的setPixels方法将mBuffer传入就OK了。
另一方面，这个mDirty应该也是不需要的，我的ScreenModel已经对刷屏事件进行了优化，只在需要的时候刷屏。
这个mDirty会造成跳帧。

附：Bitmap的setPixels方法文档：

  public void  setPixels  (int[] pixels, int offset, int stride, int x, int y, int width, int height)
Since: API Level 1

Replace pixels in the bitmap with the colors in the array. Each element in the array is a packed int prepresenting a Color
Parameters
pixels         The colors to write to the bitmap
offset         The index of the first color to read from pixels[]
stride         The number of colors in pixels[] to skip between rows. Normally this value will be the same as the width of the bitmap, but it can be larger (or negative).
x         The x coordinate of the first pixel to write to in the bitmap.
y         The y coordinate of the first pixel to write to in the bitmap.
width         The number of colors to copy from pixels[] per row
height         The number of rows to write to the bitmap
Throws
IllegalStateException         if the bitmap is not mutable
IllegalArgumentException         if x, y, width, height are outside of the bitmap's bounds.
ArrayIndexOutOfBoundsException         if the pixels array is too small to receive the specified number of pixels.