Project1

标题: SRPG on Map 地图处理代码测试 [打印本页]
作者: 寒冷魔王    时间: 2014-11-28 16:54
标题: SRPG on Map 地图处理代码测试
本帖最后由 寒冷魔王 于 2014-11-28 17:05 编辑

SRPG on Map
地图处理，用于角色在面向多位元素的路线巡查。
经过一个多月的编写和算法优化，目前发布V2版的公测版。
我是使用的多维数组来处理和保存数据。
数据输出基元数组【【点】，【路线】，【可否放置】】
其中路线用1234来表示，转化RM请自行Input::。
由于Ruby对数组的处理极度低效，Path类的get_path仅仅多循环10次（扩大移动10）。为了弥补这一问题，我将相同的算法用Java实现（= =可怜我这个菜鸟不知道要怎么调用）
这不是一个长距离寻路的算法，仅仅提供在密集位置的移动的可能性。刚好看见R君写的Dijkstra算法RM寻路程序，就用他的吧~
目前只是测试版，由于长时间的开发及频繁地变更，程序内部可能会出现一定的错误。还望大家指出。
另外，本版本是V2的完结版，不会考虑算法的变更。如果涉及程序数据结构的大幅度变更还请跳过该版本。
另外我只学了几天的Java，请不要对Java版提出高级的问题。。


Ruby版

Java版


呼叫：
T君   R君      
作者: taroxd    时间: 2014-11-28 17:14
寻路现成脚本无数，何必自己写= =
作者: taroxd    时间: 2014-11-28 17:19
本帖最后由 taroxd 于 2014-11-28 17:23 编辑

To 楼上点评

如果你写这个的目的是为了锻炼你的脚本水平，那我完全支持你自己写一遍。

但如果你的目的是自己写一个 SRPG 系统，不重用现有的代码还是很浪费时间的不是吗？

另外，我的建议是，既然你没有用到 RM 的地图系统，不妨用 “图” 来表示数据。（不过拿 RGSS 表示图果然还是觉得很蛋疼）
作者: RyanBern    时间: 2014-11-28 19:21
Ruby版的给taroxd看好了
看代码看了两遍没看出来是Dijkstra算法，果然算法是除了自己以外别人都看不懂的东西啊……
而且这个Java程序写得，我可以说数组超过三维我就开始接受不了了吗？四维数组用起来真的好麻烦啊。如果你想要表示点对的话，还是新建一个类为好。
不过搞出一个脚本来也是很辛苦的，希望优化方面再多做做吧。

PS：我的代码60多行是如何变成450行的？
作者: 寒冷魔王    时间: 2014-11-28 20:37
本帖最后由 寒冷魔王 于 2014-11-28 20:47 编辑
RyanBern 发表于 2014-11-28 19:21
Ruby版的给taroxd看好了
看代码看了两遍没看出来是Dijkstra算法，果然算法是除了自己以外别人都看不 ...


= =那个啥，我是用Java把Ruby版的算法复刻了……不是Dijkstra算法。。

这是第三次尝试，全部都用数组储存。
第一次尝试定义了好多的类，结果又慢又乱= =而且程序有600+
Java版的puts()和print()就占去100行，各种get又是N多行= =
东西没有Ruby的多，但是基本的还是有的。


PS：你的那个我能说我看不懂RGSS吗= =另外用Java的话Ruby的60行变成个400多行是没问题的。
没办法，定一个void put()就要一大堆= =如果新建类表示类型输出的话又要一大堆= =
还有
{
}
占去的行数又有一大堆= =
作者: 寒冷魔王    时间: 2014-11-28 21:20
RyanBern 发表于 2014-11-28 19:21
Ruby版的给taroxd看好了
看代码看了两遍没看出来是Dijkstra算法，果然算法是除了自己以外别人都看不 ...


引用：
单说执行效率，不说开发效率。

首先，很明显，汇编是最高的，不需要解码，没有任何限制。
然后是C/C++等等直接静态编译到汇编的语言，它们的效率等同汇编，之所以是第二等是因为编译器本身产生的结果可能和【你自己】想要的结果有细微差异，从而降低效率——当然，虽然编译器越来越先进，这种事情越来越少了。
关于C++的编译期计算等等的问题，我们等会儿来说。
下一级别，估计有点超出你的想象了，是Java、JavaScript和LuaJIT/PyPy这些，也就是运行时编译到汇编的语言，它们的效率大概只比C/C++之类低50%的样子——也就是说，C做事需要1s，它们估计也就需要2s，问题是，现代的程序，大部分都是碎片化执行的，真正在CPU上面耗费的时间不多，因此，实际的包含大量IO的程序而言，其实效率上差多。
再下一个级别就是Lua、Python（这里是CPython）这种了，字节码执行，自带虚拟机，效率上大概比C慢出50倍这个数量级。但是某些操作如果语言直接内置（比如Python的列表合成），那效率就和C的相同，有些操作你手动搞，效率就比C慢50倍，因此语言的设计极其重要，要保证需要手动搞的东西都是对效率影响不大的。
再下一个级别就是内存里面直接放解析树，没有字节码的。比如Ruby，大概比C慢200倍左右，恩，不详细说了。
最后一个级别是连解析树都没有，直接一行一行分析完了就执行，比如VimL，大概比C慢1000倍（三个数量级）的样子。

执行效率上，就是这么个等级了。

再说说C和C++，很多人有误解，模板提高效率啊，constexpr提高效率啊什么的。其实，这些C编译器也可以做优化，只是难度会很高——没有语言级别的直接提示。比如说，gcc有一个优化已经出现很久了，就是自动内联函数指针——如果发现几次调用的时候，给出的函数指针都一样，那么直接把这个函数指针固化到函数里面，做成一个特殊的static函数给你调。这多么像C++的模板！我的意思是，不要迷信语言特性，C和C++的基本原理都是完全把一种概念模型上的表述换成另外一种表述，这种转换中的效率提升往往并没有那么明显，但的确是有的。它们的确是效率相差不大的两门语言。
作者: chd114    时间: 2014-11-29 09:35
寒冷魔王 发表于 2014-11-28 04:20
引用：

你的VA魔塔样板呢···



欢迎光临 Project1 (https://rpg.blue/) Powered by Discuz! X3.1