Fat R笔记……与减肥无关

Questions and Answers for 0.60b

---

Q:
JavaMagic对只支持MIDP 1.0的用户有用吗?
A:
如果您的手机只支持MIDP 1.0，可以选中“禁止JavaMagic使用MIDP 2.0特性”选项。这个选项不是为了让MIDP 1.0手机能玩MIDP 2.0游戏，而是让JavaMagic以兼容MIDP 1.0方式处理游戏，使处理过后的游戏仍然能在MIDP 1.0手机上运行。当然，这样会损失一些功能，注意阅读该选项的提示信息

---

Q:
JavaMagic对Nokia用户有用吗?
A:
目前JavaMagic可以有限度地支持Nokia手机。JavaMagic处理过的非Nokia游戏（即没有使用Nokia API的游戏）可以在Nokia手机上运行。但对于使用了Nokia API的游戏，用JavaMagic处理过后是不能在Nokia手机上运行的（也许以后我会加入针对这一问题的功能，看情况吧）。不过这里要提醒的是，如果Nokia用户想用JavaMagic来处理键位与Nokia不兼容的游戏会有一个很头大的问题，就是如何确定游戏各个按键的键码。

---

Q:
那么，怎么确定游戏使用的键码?键码设置对话框到底要怎么填?
A:
从0.60b开始，JavaMagic允许更为自由的键码映射:

首先要正确填写右边的键码，也就是游戏使用的键码，然后再在左边填写你的手机上对应的按键的键码，建立映射关系。左边可以根据你的意愿填写。例如想把手机的[#]键映射成游戏的右软键，就在左边的Right-Softkey栏填入[#]键的键值35，同时把左边#栏的35改成0（同一个键码只能在左边分配一次，因为不能将同一个键码映射成多个按键）。Custom区的6个按键一般情况下不会用到，除非游戏使用了上面几个标准按键以外的键（但是我目前还没见过这种游戏）。

左边填写的键码是你的手机使用的键码，可以通过testkey之类的程序测得。右边填写的是游戏使用的键码，但由于针对不同手机的游戏使用的键码可能不同，又没有直接的办法可以测量，因此这是一个比较麻烦的地方。大多数的游戏使用的是Nokia的键码（也就是JavaMagic默认的键码），实际使用中采用Nokia键码也能解决大部分游戏。对于那些采用非Nokia键码的游戏，这里提供三个参考方法：

[1] 碰运气 除了Nokia键码，还有一部分游戏使用的是1,6,2,5,20,21,22或者-1,-6,-2,-5,-20,-21,22两套键码。两套键码对应的配置文件分别是Doc\OT735i MotoVxxx.xml和Doc\Sample1.xml。再加上西门子的键码Doc\Siemens.xml和Doc\Nokia.xml，这4套键码应该能解决目前的主流游戏了。可以点击右边的“从文件读取”，载入不同的配置文件来尝试不同的键码。
[2] 如果以上4套键码都不适合该游戏，可以向能正常运行该游戏（无按键兼容问题）的其它用户求助，让他们帮忙测一下自己手机的键码，然后填到你的JavaMagic键码设置对话框的右边。
[3] 自己找反编译/反汇编工具分析游戏的class文件……

---

Q:
为什么我设置了强制全屏，**游戏还是不能全屏显示呢？
A:
这里要澄清一下，全屏功能是为了移除屏幕上下方的手机界面的提示栏（电量、时间显示、软键提示等），让游戏可以使用完整的屏幕来进行显示。也就是说，全屏功能只是扩大了可以用来显示的范围，但不保证游戏一定会利用所有的屏幕范围来显示。以当年的某手机为例，该手机全屏分辨率是128x128，正好是Nokia S40V1的分辨率。而那些Nokia游戏一般不会以全票模式运行，也就是说画面下方会有一条空白的软键提示栏，游戏能使用的区域只有128x116。将这些Nokia S40游戏进行强制全屏处理后，就能在该手机上显示完整的画面了。因此，强制全屏只适用于那些画面分辨率是固定的，并且接近或等于您的手机的全屏分辨率的游戏。

---

Q:
我设置了“仅当游戏可能能自动适应屏幕分辨率时全屏”，但一些游戏虽然全屏了，却不能把画面扩大到整个屏幕，而仅仅是在屏幕上留下丑陋的空白区域？
A:
有的游戏画面分辨率是固定的，在不同分辨率的屏幕上显示的画面都一样，但是有的游戏是能够根据不同屏幕分辨率调整游戏画面的，这类游戏在JavaMagic里被称为“能自动适应不同分辨率”的游戏。JavaMagic能够自动识别这类游戏（根据游戏是否会查询屏幕高/宽度来判断），并根据判断结果设置游戏是否全屏运行。然而不是所有会查询屏幕分辨率的游戏都会根据分辨率调整画面，有的游戏可能仅仅是在显示logo的时候用查询到的数值来让logo居中显示，游戏画面依然采用固定的分辨率。对于这类游戏JavaMagic就会出现“误判”。可以在JavaMagic中设置不强制全屏，重新处理游戏，让它回到非全屏模式下运行。

---

Q:
JavaMagic不支持大屏幕的手机吗？
A:
可能之前的分辨率设置那三个按键让人产生了误会，所以现在我已经把它改了。事实上JavaMagic是能够自由设定分辨率的，不仅仅是那几个按键上标示的数值。240x320的屏幕我没有实际测试过，理论上应该是支持的（除非游戏本身不支持），但我用176x208分辨率的模拟器测试是可以正常工作的。

---

Q:
JavaMagic要花很长时间来重新生成jar文件？
A:
JavaMagic默认采用KZip来压缩jar，这样可以使生成的jar体积更小。但KZip的高压缩率是以压缩时间为代价的。如果你不在乎那几k的体积差异，可以选择其它压缩工具来压缩。目前版本除了KZip，还可以选择7Zip或者WinRAR作为压缩引擎。

---

Q:
我的游戏之前是能运行的，用JavaMagic处理过后就运行不了了，怎么回事？
A:
如果只是个别游戏会这样，可以尝试：
[1] 关闭MANIFEST的过滤功能
[2] 设置使用WinRAR进行压缩
然后重新处理游戏。
如果是所有游戏都这样，可以测试以下选项：
[1] 取消“启用键码转换功能”
[2] 设置“不强制使用全屏模式”
[3] 设置“不对分辨率进行指定”
[4] 取消“进行字体替换”
[5] 关闭MANIFEST的过滤功能
[6] 设置使用WinRAR进行压缩
[7] 设置禁止使用MIDP 2.0特性
看看到底是哪个选项造成游戏不可用，然后发送报告给我
另外，最好找简单的程序来测试，例如处理testkey.jar，看看处理过后的testkey能否运行。

---

Q:
JavaMagic会对游戏造成负面影响吗？
A:
JavaMagic的处理方式是有代价的。它需要在游戏中插入一个类来实现它的功能，这个类当然也是要消耗一些系统资源的（没测试过实际的占用量）。对于资源比较紧张的机器，有可能JavaMagic处理过后就内存不足了（不过目前我没遇到过……出问题的都是处理之前就内存不足的……-_-!）。另外，经过JavaMagic处理的游戏是不可还原的（但可以再次被JavaMagic处理），并且可能会丧失一些通用性，因此如果要在网上发布修改过的游戏（这里先不讨论这种行为的合法性），最好注明经过JavaMagic处理，并同时提供未处理的版本。

---

Q:
我的手机型号是***，我遇到了*****问题...
A:
呃，对不起，我并没有那款手机，告诉我型号对我没有太大意义……当然，希望您能够从上面的Q&A中找到您的问题的答案

我的JavaMagic分辨率设置成128x160,然后发现一些处理过后的游戏以这个分辨率运行,JavaMagic却没有将它们识别为能够自动适应分辨率。因为心虚，知道JavaMagic的自动适应分辨率识别功能不太完善，于是就战战兢兢地研究了半天。结果找来找去找不到它到底通过什么来判定分辨率，最后用模拟器跑了一下未处理过的版本，终于发现了真相——原来那几个游戏本来就是固定在128x160下运行的……

最新试了n个游戏都是大屏幕的（很多我的手机都玩不了，泪……最痛苦的是好不容易找到一个能在那么小的屏幕上正常显示的游戏，结果经过漫长的等待，进度条走到9x%的时候，内存不足退出了…… 难道天下做软件的都这副德行，硬件宽裕了就抛弃了当年艰苦奋斗压榨系统资源的作风了么）突然冒出那么几个小屏幕的游戏还真是一时反应不过来……

不过最后还是决定完善一下自动适应分辨率的判别，毕竟这还是一个Bug，虽然修正起来会比较麻烦……

可是……我觉得这样看起来实在太专业/显得难用了啊！
肯定有很多小白看到这种界面后会马上呆掉，然后心有余悸地关掉它……

这个是期待已久的增强的字体修改（不好意思，我仍然不打算提供很高的自由度）


这个是期待已久的任意键的键值映射


当然现在这个还只是一个半成品……就算成品出来，一定还是会有很多bug，毕竟太久没接触这方面，很多东西都不熟悉/不记得了……