|
|
z****e
发帖数: 54598 | 3 争议很大，expression里面一堆的括号让人很崩溃
fp最大的障碍就是其可读性，一堆的括号 |
|
z****e
发帖数: 54598 | 4 就是沙盒机制嘛
applet n年以前提出的概念
很无聊，做一个很简单的东西都要数字签名
吃太饱了，而且浏览器很不靠谱
各个浏览器平台是不一样的，对付这种兼容性足够让人崩溃 |
|
z****e
发帖数: 54598 | 5 脚本不适合写游戏，很逆天
而且脚本太依赖平台，浏览器一个兼容搞死人
相比之下，java以前那么弱的时候
都能搞出minecraft这种东西，理论依据在于只考虑一个平台那就是jvm
下面os的兼容性让jvm搞定，java天生就是干这个的
以前推广主要问题在于api支持不够
java2d和3d都不是很成功，慢，现在javafx搞硬件加速这些
其本质就是直接调用directx和opengl接口去执行代码
而且用户要安装下载jvm，这也是很大的问题
而且以前把jvm打包进去的话，体积很大
体积大一个主因是官方不怎么支持这种搞法
现在javafx算是官方支持了，而且打包时候有trim
但是即便trim了，还是偏大，但是mono为这种方式做出了一个很好的榜样
反正都大 |
|
|
z****e
发帖数: 54598 | 7 我当然知道是那个a
但是某人问的不是这个
某人的问题我上面阐述过了
就是几层不同颜色的叠加，最后一层是透明色
最后应该显示什么颜色 |
|
z****e
发帖数: 54598 | 8 理论上，理论上applet也能搞定浏览器
但是做起来处处受限，很不爽
完全没有必要，干脆让用户去下载去点击去安装就好了 |
|
b*******s
发帖数: 5216 | 9 就给个例子，quake已经移植进去了，你的进展如何？ |
|
z****e
发帖数: 54598 | 10 一般逻辑是直接调用os提供的grapic api就好了
但是如果是js的话，要先通过浏览器，向浏览器申请资源
然后浏览器再向os申请调用各种图形接口
这样做实在是太苦逼了
因为os和浏览器之间有各种不协调
jvm的好处是只要对付一个os的不同
但就这一点差异，花了十多年的时间，才逐步有所改变
到现在也只能说desktop会好点，mobile和tablet上还是不行 |
|
b*******s
发帖数: 5216 | 11 google的远景是chrome os
这个明显是为那个准备的 |
|
z****e
发帖数: 54598 | 12 等推广了再说，js本身就是图简单的产物
这样搞只会更复杂，如果更复杂的话，没有必要用js了 |
|
b*******s
发帖数: 5216 | 13 如果都是调用底下c/c++写的api
java有什么优越性？为什么不是go或者干脆还是c/c++？至少少一层接口重包装
还没有各种类型，naming之类的问题 |
|
g*****g
发帖数: 34805 | 14 desktop是没有前途的，跟.net永远争不过的。 |
|
z****e
发帖数: 54598 | 15 google除了搜索以外，最成功的产品是什么？
安桌
为什么安桌会流行起来？
因为java
丫要是上来就用go，那就离挂掉不远了
chrome os那个，等推广了再说，android的成功是既成事实
不要wishful thinking |
|
z****e
发帖数: 54598 | 16 java写起来简单
oo跟游戏里面各个对象可以直接对应
还有就是，会的人多，这很重要
如果不是java，android估计会挂 |
|
z****e
发帖数: 54598 | 17 如果单是指望在win上推广，那肯定是不行的
但是现在谁敢忽视mac用户市场？
现在做什么游戏，都要有一个mac版 |
|
b*******s
发帖数: 5216 | 18 android采用java是硬件环境难以预计，所以需要虚拟机
代价是性能上和使用体验上，硬件配置高过水果的，都不及水果机器 |
|
b*******s
发帖数: 5216 | 19 游戏工业其实用不了多少人，和常规应用类的不一样
需求比较明确集中的产业，都是这样 |
|
z****e
发帖数: 54598 | 20 钓丝机嘛，游戏就是给钓丝玩的
高富帅不玩游戏的，java要想在安桌上运行，也需要单独处理ui部分
这个mvc就有优势了，m不变，vc变一下就好了
可以复用核心代码，然后javafx搞定不同的desktop平台
现在就剩下水果平台还需要时间检验，不过我看minisoft推荐了一个那个vm不错
可以直接编译成objective c代码，不过还没成熟，等成熟 |
|
z****e
发帖数: 54598 | 21 不要那么大，做不了那么大，哥没打算把这一辈子都投进去做赌注
从app开始，一点一点做，做到什么样是什么样 |
|
b*******s
发帖数: 5216 | 22 desktop的确没什么前途，即使有需要，也可以用离线模式对付 |
|
|
z****e
发帖数: 54598 | 24 所以最后还是要去mobile
java能对付安桌，太好了
然后剩下的，用javafx移植
这样就可以垮尽可能多的平台了 |
|
b*******s
发帖数: 5216 | 25 google ncl的架构上有一个好处，就是它不是只能直接调用系统api
比如很常见的我要买half life的引擎，javafx就没法直接用，还要移植 |
|
d****i
发帖数: 4809 | 26 同意，以前Sun的Solaris有个叫Java Desktop的桌面系统，名字虽然这么叫，实际上是
为了marketing，Solaris下的Java Desktop System是GNOME的，也就是C和C++写的，所
以即便是Sun也没有用Java来写自己的操作系统的桌面，后来Solaris 11就干脆把Java
Desktop的名字给去掉了。 |
|
z****e
发帖数: 54598 | 27 半条命那种游戏引擎是要烧钱的
这种搞不起，没有钱投入 |
|
z****e
发帖数: 54598 | 28 java用来写app就行了，用来写桌面就有些不太对头了
显然os应该用c来写，但是java写app这个在安桌上已是既成事实
顺着做就好了，然后javafx提供了一定的可移植性到桌面
蛮好
Java |
|
b*******s
发帖数: 5216 | 29 我举这个例子是说明，反正也是调用native code
js ＋ sandbox灵活性比java ＋ vm ext的高 |
|
z****e
发帖数: 54598 | 30 加载引擎的话，直接用c去写不就可以了
没有必要再搞一个js，而且sandbox里面要申请资源
很麻烦，处处受限 |
|
b*******s
发帖数: 5216 | 31 受限是对安全性做trade off，如果是一次性工作，还能忍受 |
|
z****e
发帖数: 54598 | 32 浏览器很臭蛋的，不是那么容易搞的
随着系统的增大，受到的限制会越来越明显地凸显出来
最后怒而不用是大多数的结局走向
其实也没有必要，一个os就够折腾了 |
|
|
g*****g
发帖数: 34805 | 34 这个也是没多大前途的，不能指望每台机器都装了chrome。 |
|
|
z****e
发帖数: 54598 | 36 哪有，ios就不好处理
还有xbox和ps
这也都是平台
不过尽可能兼容滴兼容平台是jvm设计之初的出发点 |
|
b*******s
发帖数: 5216 | 37 那我们没有本质的观点差异
讲到新平台，valve在搞steam主机
关注过没有？ |
|
z****e
发帖数: 54598 | 38 还有SteamOS
微软自己傻逼，把valve往绝路上逼
所以valve决定自己搞硬件和os
不过这个是类linux的系统，无非是加多了图形api的distro
如果普及开来的话，让java想办法去兼容，无非跑一个jvm
javafx已经有linux版了，所以兼容chromeos或者streamos应该都不成太大问题 |
|
b*******s
发帖数: 5216 | 39 这家搞不好能成，手里大把的pc game资源，驱动已经得到几个大厂支援 |
|
b*******s
发帖数: 5216 | 40 这家的目的就是游戏，而且是pc游戏主机化，java恐怕不合适 |
|
z****e
发帖数: 54598 | 41 win平台当初打遍天下很大程度靠的是这些游戏
最早暴雪的游戏都不支持mac，现在随着mac的销量上升
越来越多游戏登陆mac，那如果steamos能给linux打开一扇窗的话
那对java是大利好，对win是大利空 |
|
z****e
发帖数: 54598 | 42 desktop和linux跑jvm都没有问题
只要不太疯狂消耗性能，跑点2d游戏问题不大 |
|
b*******s
发帖数: 5216 | 43 平板上主要是2d，pc已经基本是非3d没人买了 |
|
z****e
发帖数: 54598 | 44 不会，这个要看美工的水平
你看vanillaware的游戏一样卖得很欢快
还有一堆hgame，其实都是2d的
当年好几个黑马都是2d的，比如突袭
3d美工制作成本太高，承受不了 |
|
|
z****e
发帖数: 54598 | 46 如果steamos强化了图形接口的话
jvm只需要把javafx那部分接口用steamos的api给对接上
剩下就搞定了
如果steamos用的是opengl的话
那应该不需要修改，就可以支持到 |
|
|
|
b***i
发帖数: 3043 | 49 问题就在与最后那一层透明色，这个透明色本身我无法实现了，所以我无法和原来的颜
色叠加了。
我说的是用JavaFX摞起来多个Canvas的情况。这里，我用多个Canvas来表示多个层。每
个Canvas用graphicsContext单独控制图案，当然JavaFX最后会把上层透明色和底下的
颜色混合显示，如果上层Canvas有部分透明，则露出来下面的图案，这个和你理解是一
致的。但是我找不到的功能是这之前如何改变上层那个Canvas的某些点为透明色（从而
才能露出下层图案）。比如实现拉窗帘的效果。
JavaFX目前只能把一个矩形区域重新变透明, clearRect。我需要的，是用Java已经有
的画直线，矩形，扇形的函数来让上层Canvas中这些区域变透明，从而JavaFX在混合的
时候这个Canvas可以露出下面Canvas的图案。所以现在的问题是这个第一步，如何让一
个graphicsContext中的点变透明（从而才能露出下层的颜色）。
那么clearRect有什么不好呢？不好在于，我的窗户如果是圆的怎么办？只能一个点一
个点画了？按照我理想的方法，应该可以直接把Canvas画成白... 阅读全帖 |
|
b***i
发帖数: 3043 | 50 说太多了，这里简单说一下
底层纯蓝色的Canvas bCanvas;
然后覆盖一层纯红色的Canvas mCanvas;
然后再覆盖一层纯透明色的Canvas fCanvas;
某个Timeline我把fCanvas变成全黄色了。然后下一个Timeline，我怎么把这个fCanvas
上中间一个圆形区域变透明？从而露出红色的mCanvas? |
|
