RMXP多核心技术可行性、与为之众筹的可行性

Im剑侠客

#
# 从2004年RMXP发布至今，已有17个年头了。相信有很多人跟我一样，还是非常喜欢使用XP。

虽然历时久远，却不改之喜爱之情。犹如珍贵的初恋相见，一方依然清风拂柳，另一方依旧星驰俊采。

# 本贴探讨两个可行性：

1.RMXP展开CPU多核心的技术应用可行性；

2.招募技术组为之众筹的可行性。

# 如果放开CPU多核心的性能展望；

doki、doki的心跳感觉，这将会是那一辆经过了改造的86，轻量化车身，引擎马力上到10000+匹，
这时，我们将会为其换上一个全新的计速量表，然后开启一段前所未有的新体验。

# 请求相关技术人员，细谈CPU多核心应用的技术可行性；

这一个技术应用可行性，诚邀技术人员回答。
如果技术可行，我们将展开众筹的可行性探讨。

# 估算基本价格；

# 技术组招募；

# 众筹金额：初拟定为5W rmb。作为给予开发人员的感谢金。

# 众筹人数：
如果有50人，每人分担2%，即：1K；
如果有100人，每人分担1%，即：500；
如果有1000人，每人分担0.1%，即：50；
更理想的如果有1W人，则每人仅需分担0.01%，即：5块。

# 众筹的本质：先驱的勇士行为，即：作为前人栽树，与后人一同乘凉。

# 有多少人愿意参与众筹。

# 众筹的方案：发挥Project1全体论坛成员大团结！第三方信用担当！

# 信用方案：
拟定方案一：选择一个众筹网站。
拟定方案二：在本论坛选举一位信用成员作为代表。

考虑到方案一很可能会有抽成，最终的众筹金额将会产生损耗。
所以暂且预选方案二。

方案二预选细节：

经过选举出来的代表，他将开启一个专用的账户，众筹金额在谈定技术组之后，众筹成员将金额打入账户，由代表管理。全程公开接受监督。

信用代表大家可以投票/推荐，在这里我推荐：数字君(89444640)。

# 给付(预选)方案：

初始可行版本完成后，给付技术组总众筹金额的40%，其后的1年时间，剩余的众筹金额每月给付5%。（12 * 5% = 60% ，(40+60)% = 100%）
在这一年里，技术组保障后续的维护，即保修1年。
最后，交易行为结束，合作愉快。


# 特别在此探讨RMXP底层性能提升的可行性，
只因对其感情深厚，多年相伴不离不弃，愿意继续一同前行，直到远方。

灯笼菜刀王

其实, 以我个人来说, 我并不在乎XP多不多核, 因为比起华丽,我更在乎流畅,所以尽量不去折腾它老人家,笑

相比之下我更希望XP(工具不行,至少成品)能在手机端无障碍运行, 因此我用XP的时候尽量节制, 不染指那些"黑科技", 笑, 期待能有完美支持XP作品的模拟器(RPGXP Player连精灵翻转都不支持,遗憾~)

我喜欢XP, 它的小巧干练也是主要原因之一, 看往后的RM系列,越来越臃肿,耸肩, 如果你们所谓的"新生", 是把原本娇小清秀的XP搞得虽然珠光宝气但是臃肿肥硕的MVMZ一样, 那不好意思, 这不是我的菜,笑

嘛, 归根结底, 追求性能追求画面, 还扒着RM干嘛呢, 把这些精力放在更优秀的引擎上不好么?  RM终究是有极限的, 不要做人了,DIO

想起了不久前看到的一个视频
都2020年了还有FC新作

能克服机能限制的作品在我眼里可比那些无节制膨胀的5A大作漂亮得多, 笑, 性能不是重点, 有爱才是关键, 毕竟比起40岁高龄的FC, XP也才18岁嘛, 还能再战数十载, 笑

Im剑侠客

回复ppspssss “楼主你严重理解错我之前贴子是讨论服务器, 反被你理解成RMXP多核化, 你不懂就算别把大家误导了行不行”

如果你是“多核设想”的专利持有者，我愿意尊称你一句“大佬”。

电脑硬件的多核技术，“古”已有之，至少不是近年才诞生的产物。
本帖探讨的内容包含但不限于多核设想，核心目标是：探讨RMXP底层性能提升的可行性。本质上是来讨论问题的，到你这就成了“误导”？你觉得误导了什么呢？
在我已知的人群里，对RMXP底层性能提升是充满了期待的。这一个期待，我愿意称其为“制作者的浪漫”。虽然这一个期待是非常不成熟的，但是我依然非常喜欢这一份天真浪漫。

saterick

贴个和白菜君商量高分辨率模式时的对话截图。

miantouchi

存不存在这种情况，完全重写一份引擎，解决现有所有问题，并且还能兼容老版本xp，方便之前写好的工程，比如动画编辑器优化，图块和以前一样。

ppspssss

我終于明白了, 楼主我知你看过我之前那个贴子https://rpg.blue/forum.php?mod=viewthread&tid=476328
, 令你误以为RMXP多核心? 其实我是意思说用RMXP做服务器之间交互通訊, 并不是用RMXP本身做成多核心支持, 因此本身楼主理解我就是理解错了!!! 楼主應該不要再有这种奇怪的想法了

使用RMXP转RGD, 能令RMXP支持DirectX显卡运转 ,
RMXP的图像本身之所以不支持显卡是使用(软解)所以全使用CPU解码(显卡占用为0), 使用了RGD之后能使用显卡(硬解)绘制图像, 因此 已经足够日常使用,

坏数据

不太明白众筹的意义是什么  
不是众筹本身，我自己就组过团队做个硬件众筹。

软件众筹，大家都要吃饭我理解，但是这个事情，嗯。。。

你的意思是专门养一个技术组来搞吗？
如果仅仅是大家业余时间开发，作为刺激奖励，应该用不了这么多钱。

业余开发不值这个数，专职开发又好像不够？  这东西开发周期短不了吧？又不是现成的流程可以做完。实际时间难以预估。 如果已经清楚具体方向并有demo，又切实可行的日程，这样再开始众筹更有说服力。

Mr.Jin

Im剑侠客 发表于 2021-1-31 13:43
逻辑跟渲染能分开是最好的。逻辑部分如果仅仅应用于并行的处理上，也是极大的提升。渲染部分，压缩一下范 ...

我们所说的兼容性是指在不修改RGSS1接口和不修改不增添RMXP自带脚本的情况下达成优化，如果做不到这一点，意味着我们要重写/修改很多东西才能够使这种优化生效，那其实等于是重做了一个引擎，并不能够兼容已有的大量资源。
包括你说的load_bitmap这种东西，如果要更改资源加载方式(IO在后台线程操作)那肯定和现有写法是不兼容(除非你能接受页游那种，未加载完毕的图片显示个色块还是什么的)。所以说在保证兼容性的情况下，能做的多线程优化是非常有限的

Im剑侠客

Mr.Jin 发表于 2021-1-30 20:49
无论从RGSS1的接口还是从RMXP的自带脚本来看，都与多线程工作并不适配；这意味着如果你一定要用多线程优化 ...

逻辑跟渲染能分开是最好的。逻辑部分如果仅仅应用于并行的处理上，也是极大的提升。渲染部分，压缩一下范围，应用于cache类的self.load_bitmap，在一个时间内集中预载的时候，多核心分担，减少加载时间。
虽然兼容性是什么不是很清楚。想要的多核效果更多是同时作业，相同的工作量多人分担，以达到优化。

chd114

先不说钱
最大问题是做出来的东西不一定能商用吧，做这个东西起码先拿到xp开发商的许可，不然做出来也不会有多少人用的