易码技术论坛

 找回密码
 加入易码
搜索
12
返回列表 发新帖
楼主: laugj

给Lee的LavaX的建议 请Lee务必仔细看

[复制链接]
 楼主| 发表于 2006-5-24 11:03:00 | 显示全部楼层
希望以后在用LavaX写游戏的时候不会因为运行效率跟不上、某些重要功能无法实现而失望~!
发表于 2006-5-24 11:14:00 | 显示全部楼层
游戏的效率主要在于帖图。这是我多次测试得出的结论。

所以,一方面要优化帖图函数,用户也要尽量少用全屏幕更新,而多用局部更新。
发表于 2006-5-24 12:11:00 | 显示全部楼层
我也说点我的意见



以后的LAVAX能不能像JAVA一样分为几个版本呢?

比如说(假设)

在WQX上运行的叫LAVAX-WQX,颜色控制只有黑白或者灰度,只能用那么一点点内存

在电脑上就叫LAVAX-COM,能控制彩色颜色并且能控制和使用更多的内存

在手机上(能运行最好)就叫LAVAX-MOB,颜色内存都有限制



我没有实际做过什么跨平台的系统

只是想到了说了出来

有什么缺陷也希望大家能交流一下

反正我是希望LAVAX能像JAVA一样,到处跑

不过不像JAVA和K-JAVA,两者不能兼容



谢谢
发表于 2006-5-25 17:31:00 | 显示全部楼层
咳。只在电子词典上发展,难啊。没有硬件厂商希望再出一个微软,他们也不愿意做IBM。


呵呵,如果自己已经是微软了,还用当心硬件厂商吗!

现在也是机遇,很多弄内核的人都没注意到电子辞典这快!

不过这可是要走很长的路的!抓不准每一步,自己也就只会是流星过过而已。
 楼主| 发表于 2006-5-25 18:32:00 | 显示全部楼层
其实lee不用去费心思想图形部分怎么做
Lava自带的图形系统只要实现类似Win GDI的基本功能就行了
剩下的由扩展的图形功能来实现,那些东西可以慢慢更新 加强 修改
发表于 2006-5-25 18:49:00 | 显示全部楼层
我主要是想谈谈速度问题。

本机编译后的LavaX速度可以说已经非常快了。同样的代码,用gcc编译后速度也只是比LavaX本机编译略快一点。

LavaX-OS GBA版也已经发表了。对速度有高要求的可以试试。
发表于 2006-5-26 00:12:00 | 显示全部楼层
问:LavaX本机编译器提供下载吗?
答:暂时不提供下载。您可以把.lav文件交给我,我替您转换为LavaX可执行文件。

orz...
 楼主| 发表于 2006-5-26 02:01:00 | 显示全部楼层
速度问题不是很大,前提是有扩展性

例如写一个RPG游戏, 核心循环部分引用了"消息"机制,那么可以写一个用汇编替代这个核心部分的扩展库(消息插入、删除、调用、计时器等管理)

运行效率上只要解决几个程序中经常用到的比较要求效率的部分就好了

还有就是在低端平台上 lava伪指令cache的更详细的控制
发表于 2006-5-26 02:04:00 | 显示全部楼层
有问题吗?.lav文件又不是源码,一直是公开发布的。
发表于 2006-5-26 02:41:00 | 显示全部楼层
因为LavaX-OS扩展性太大了,连系统文件都是LavaX写然后本机编译。如果公开提供本机编译器的话,难免被不法分子利用侵犯版权。况且,LavaX一直是跨平台的,如果某人只发表本机编译版本,就失去跨平台的意义了。

要开放本机编译器还需做一些功夫,比如拟订一个协议:免费使用本机编译器的前提是必须在提供LavaX可执行文件的同时提供虚拟码文件,缴费使用则不受此限制。
 楼主| 发表于 2006-5-26 02:46:00 | 显示全部楼层
虚拟码? 伪指令吗? 类似PC中编译所生成的汇编obj?
LavaX的运行部分以及基本的功能是跨平台的

就如大多数计算机(计算机包括电子辞典)都能做那些基本运算、操作内存、控制外设一样
分各种平台做不同的LavaX在拥有了强大的扩展性能后根本无用


 楼主| 发表于 2006-5-26 02:54:00 | 显示全部楼层
接3单元2层(29楼):

至少大多数游戏最需要效率的地方也就是这了

如果制作者愿意,可以单独为各平台开发这个游戏所需要的一些扩展库

比如制作一个库,名字叫GAPI(Game Application Programming Interface)

其中提供一些游戏中经常使用的比较需要效率的函数,为那些函数提供高效的运行方式


同时也希望lee在写解释器的时候,该需要高运行效率的地方千万不要因为一些不必要的东西而增加各种会降低运行效率的代码,想一些更高效的方法去解决

 楼主| 发表于 2006-5-26 02:58:00 | 显示全部楼层
另外  无用的支持 是算灌水的(论坛规定)

与其无意义的支持 不如多提些有用的意见~~~
发表于 2006-5-26 02:59:00 | 显示全部楼层
本机编译主要是用来提供给操作系统的,购买了LavaX-OS使用权的厂商也可以获得本机编译器从而增加自己所需要的功能,系统部分肯定不能100%跨平台。

应用部分当然还是跨平台的,如果用户想免费使用本机编译器,就必须签署同时公开虚拟码文件(.lav)的协议。虚拟码文件是跨平台的,这毋庸质疑。
 楼主| 发表于 2006-6-5 01:45:00 | 显示全部楼层
我的建议是将LavaX定义为一个操作系统,Lee做的只是卖(开发)操作系统给"硬件厂商"
而软件将会成为与"硬件厂商"分离的群体,当然不能说绝对分离 也可能有硬件厂商拥有自己的开发队伍 让他们去写

而软件的商业化会与硬件厂商毫无关系  更与LavaX本身没有关系
即使硬件厂商想用某种方法将软件约束到自己的产品上,也跟LavaX本身没有关系

所谓的编译器,也只是作为商业软件而去卖,就像M$的Visual Studio一样

LavaX是一个系统,他不只是一个语言,lee不需要保护语言 而是要保护LavaX的市场

如果lee想赚钱的话,是从市场上赚的 而不是从技术成果上赚到

也许会有很多人去做各种各样的编译器
就像有Borland的C++ Builder以及Delphi等Java等

lee不应该把他作为"侵权"

大家可以使用LavaX"语言"来写LavaX程序
也可以使用C++、C、Java、VB、Python等来写LavaX程序

所以说Lee的LavaX不应该是一个语言,应该是一个平台
lee要做的,不是耗劲心思去设计一个与C、C++不同的新语言,这豪无意义
lee要做的只是趁现在的"散沙"状态 "统一"电子辞典,或者说是低端PDA的软件市场

电子辞典这东西 对于我们学生来说边的越来越重要了

如果能实现的话、就有2种可能
诸如BBK、GGV、诺亚洲这些做电子辞典的厂商  很有可能变成只做学习软件以及其他软件的厂商

或者是变成只做硬件而购买LavaX的使用权的厂商

更或者说是变成只做硬件而让用户自行购买LavaX的厂商(小心盗版!)

也没准一个公司分成2个部门,一个主要做硬件,一个主要做软件

相对来说,让厂商来卖硬件和软件,再将LavaX系统捆绑销售,这样是最好的选择

LavaX系统是一个系统构架,厂商如果将LavaX系统捆绑销售,很可能是使用LavaX系统构架,然后自行开发应用程序(请注意系统程序和应用程序的分类) (比如说计算器、记事本、文件浏览器等)
但是 作为厂商  无法对LavaX的系统内部进行改造(例如增加指令、修改API等)

就如现在很多PDA 都是用的 CE"内核" 而很多用相同内核的PDA却完全不一样(请参考小日本的MC-21 (CE 2.11内核) 而M$的那些程序却一个没有,全都换成了卡西欧他们自己的开发的程序了)

Lee要做的是像M$一样去卖操作系统(嵌入式)
而不是去创造一个语言,语言是赚不到"钱"的

PS:没准有错别字   时间太急了  先不检查了
发表于 2006-6-5 19:54:00 | 显示全部楼层
LavaX是语言,是平台,是操作系统。

嵌入系统可以在各个层次应用LavaX虚拟机。
 楼主| 发表于 2006-6-5 23:47:00 | 显示全部楼层
可惜啊 如果lee坚持那么做的话 我就放弃了
发表于 2006-6-6 13:20:00 | 显示全部楼层
不过确实!在目前的WQX上的 LavaX VM的各个版本来看,LavaX VM对硬件的搜索不是很好,并不是横跨整个硬件系统
发表于 2006-6-7 18:58:00 | 显示全部楼层
在这里和你们讨论这些,我是真有感触,GGV的路好像不长了...
 楼主| 发表于 2006-5-21 22:44:35 | 显示全部楼层 |阅读模式
第n次了





至Lee:
记得我以前在wqxsky跟你提意见,虽然说我那时水平不行,什么都不懂,但是你说的话很过分
我也总挑你刺
但是,我绝对不喜欢记仇
希望你能仔细看,如果那些地方不好,希望能指出原因
如果我今天给你提的建议你完全不放在眼里,觉得"胡说八道",觉得我什么都不懂
那就算了,大家也会知道你的RP是什么样

你所做的LavaX虽然从"跨平台"上做的很好
但是功能太少了(你不想承认吗?)
我现在我不跟你争"跨平台"好还是坏,我只从用的好不好这个角度来说(编写效果如何,使用效果如何)
现在我只是给你提意见,并将我的想法表述出来,并非要求你这么做,你可以做参考

虽然我不是很清楚目前LavaX"进化"到什么样了
但是我希望你考虑如下建议:
添加系统库、静态链接库以及动态链接库这3种功能


静态运行库就是编译好的LavaX代码,已经编译好的伪指令
他的用途是升级方便~易管理,节省编译时间(作用不大啊)
系统运行库就是根据不同平台而特意制作的"接口一样、功能一样只是程序不一样"的函数库
(系统库可以说你在为一个机器做解释器的时候就已经完成了)
你可以把他插件化(易与管理、添加与删除):比如某人开发了一个关于图形的一些功能,并把他命名为XGraphic
那么他就可以做一个XGraphic.plugin(如果是.dll也行.sys也行表达出意思就行了)
而某人写的程序用到了XGraphic库,那么解释器就会查看这个平台上(解释器)是否安装了对应的插件以及版本是否够高(版本最好是向下兼容,淘汰除外)
系统运行库还可以写成非汇编(LavaX伪指令),前提是对运行效率要求不是很高
动态运行库的作用主要是程序复用、易管理(升级、修复)、节省编译时间(作用不太大吧)
例如某人写了一个文本编辑器,用到了一些关于文本操作的函数
而他后来又写了一个其他程序,同样用到了文本编辑器所用到的函数
如果他将这些函数写成动态链接库,那么他所写的这2个程序更甚以后写的其他程序,都可以使用这个库而不需要重新编译,不需要增加目标文件的尺寸
如果这个库中的某个函数有bug
那么他就可以只修复这个库的bug而不是把他以前用的所有程序重新修改一次

所谓库可以这么大致分出来:

1、系统库: 这往往是需要很高的执行效率的函数库,例如图形操作,文件操作等,虽然LavaX本身已经有了你所说的"完美"的图形操作函数,但是这些还是不够的,可能由一些"非官方"的开发者编写了更有实际用途或更有效率的图形库,那么他就可以创造一个扩展的图形库

犹如Windows操作系统上安装的DirectX9一样,在刚装机时 这些功能是没有的,用户需要在安装DirectX9才可以使用这些功能,同样 这么设计便与升级,在某些功能升级或是完善的时候,就可以为某些功能的库提供单独的升级版本,而不用把整个系统(解释器)做升级

如果将这些实现了,我想 跨平台就不会那么困难了,因为 有变更的只是这些功能而以,除了这些功能以外的一些运算(打个比方,LavaX1.0的0x00-0x7f的指令)几乎是千篇一律 各平台都可以通用

再打个比方:
一个在160x80黑白平台上所写的程序,他对图形的操作 都是针对1Bit(黑白)以及160x80而设计的
但是 如果这个程序引用了单独提供的一个图形库  并且这个库的某个函数准确的描述了当前平台上的显示设备具体参数(分辨率 颜色等),那么这个程序就可以完美的"向下兼容"

也就是说 如果另一个320x240的彩屏机器上运行这个程序,就可以通过这个库来软转换(并非像NC系列的lava游戏在TC800上运行 出现花屏),这个库会模拟一个真实的160x80黑白显示屏的硬件 而事实上 这并不耗费太多的资源(如你所说,牺牲了一些速度)

2、用户编写的动态链接库:

这个库不是汇编代码,是LavaX伪指令,他的作用只是为了让代码的复用更加方便,以及能够更好的进行升级以及修改(只要保证函数的操作方式一致,即可以向下兼容)

3、用户或官方编写的静态链接库:

这一般是一些对速度没什么大要求的功能,他的出现纯粹是为了编译速度的增快或是减轻解释器的负担,他的组成包括一些编译好的静态库(Lib,LavaX伪指令),以及来调用这些函数的描述(头文件,提供了调用格式以及退回类型---即调用方式)

--------------------------------------------------------------------------

做个假想:
某个主要在320x240 16阶上编写的大型RPG游戏(很精致的那种)

在A某的机器上(T1200)出现了:
运行游戏需要DirectX 9.0(开个玩笑),请到http://xxx下载最新版

在B某的机器上(T1200)出现了:
您的DirectX版本:8.0版本过低,请到http://xxx下载最新版

在C某的机器上(NC2600C)出现了:
本程序要求使用320x240的显示区域,与您的机器:160x80 1位 不符,无法做转换
(程序中判断当前分辨率是否比要求的要小,色深是否在4阶以下)

在D某的机器上(480x240的HPC)系统做了自动的转换
(在DirectX的设置里可以设置转换方式,即1:1放大(不敢想象效果)还是自定义(手动填写分辨率))

在E某(NC1020?哈!)的机器上解释器提示:
系统可用内存不足,无法除始化程序(程序在编译时将记录总共分配的内存,也就是说 在编译LavaX程序的时候 永远不会提示内存空间不足,足不足在解释器的地方将会判断)

而在F某(未知机型)上解释器提示:
动态分配内存失败:系统内存空间不足

而在G某上程序提示:
没有找到音频设备,是否忽略?

在H某上运行某红外传输软件:
没有找到红外设备(确定后退出)

在I某上运行某MP3播放程序:
音质超烂,而且卡
(因为在DirectSound中启用的是软解码并且硬件有限制)




一个LavaX平台构想:
打开LavaX解释器,选设置
找到系统库管理,里面有:
memory.dll   | 内存管理库     | 作者ee 公司:XXX 备注:XXX 版本:XXX 安装时间:XXX
file.sys     | 文件系统库     | 作者ee 公司:XXX 备注:XXX 版本:XXX 安装时间:XXX
gdi.dll      | 标准图形接口库 | 作者ee 公司:XXX 备注:XXX 版本:XXX 安装时间:XXX
network.sys  | 标准数据传输库 | 作者:Lee 公司:XXX 备注:XXX 版本:XXX 安装时间:XXX
bluetooth.dll| XXX蓝牙        | 作者:XXX 公司:XXX 备注:XXX 版本:XXX 安装时间:XXX
system.dll   | 系统控制库     | 作者:Lee 公司:XXX 备注:XXX 版本:XXX 安装时间:XXX
xxxsys.dll   | X机型系统控制库| 作者:XXX 公司:XXX 备注:for xx机型only 安装时间:XXX
jpeg.dll     | jpeg解码器     | 作者:XXX 公司:XXX 备注:XXX 版本:XXX 安装时间:XXX
............略

在看某人些的某字典程序中的文件:
xdict.exe
lib.dll
dict.dll
word.dll
config.ini
dic\简明.dic
dic\牛津.dic
dic\计算机.dic

某文字处理软件目录下:
word.exe
config.cfg
reg.dat
script.exe
hotkey.exe
hotkey.dll
config\hotkey\default.cfg
config\hotkey\XXX.cfg
config\template\default.tmp
config\template\letter.tmp
config\template\note.tmp
lib\graph\male.gif
lib\graph\female.gif
lib\graph\mail.gif
richedit.dll
IME.dll
form.dll
word97.dll
gif.dll
jpeg.dll

某解压缩软件的目录:
wqxzip.exe
checkout.dll
7-zip.dll
zip.dll
cab.dll
jar.dll
tar.dll
rar.dll
register.exe
License.txt

------------------------------------------------------------------------


如此岂不是更好?
在使用各函数的时候添加一个include 应该并不难吧
不可能出现那种拿过来大家都不会用的事情~

一般来说 常用功能不需要使用动态链接库等
如果想用好他 具体学一学 也不费什么事

建议:提供标准的指针处理,我不想跟你争论指针安不安全的问题
但是PC上都这么用了n年了,也没有淘汰他,而且指针太好用了,希望能够支持他

inline函数:这对提高程序效率来说太重要了

动态内存分配:缺他可不行

输入法系统:建议内置他,作为伪指令或是汇编形式的系统库,如果安装其他输入法(五笔等),都要在这个输入法系统的基础上制作(这个库里有安装具体输入法发相关功能函数,如果要添加输入法 可以写一个安装程序,调用这个系统库,来将输入法安装到系统中的)

建议将LavaX作为系统内核 尽量少用解释器的形式




以上:真正的跨平台,一个程序编译了成了伪指令  只要有LavaX解释器 以及程序特殊要求的一些东西 就能完美运行
您需要登录后才可以回帖 登录 | 加入易码

本版积分规则

Archiver|手机版|小黑屋|EMAX Studio

GMT+8, 2025-7-8 06:48 , Processed in 0.016773 second(s), 18 queries .

Powered by Discuz! X3.4

© 2001-2017 Comsenz Inc.

快速回复 返回顶部 返回列表