【窗体模式】以窗体来制作系统

写系统的时候要考虑好层的分配，不然会导致各种不可控的BUG产生
虽然只要考虑好就能做的好。
考虑到扩展性的话层和窗体之间的差距就体现出来了
当然了，层可以模拟出窗体的效果，比较麻烦就是了。
窗体包括了层的属性，不必考虑一个窗体内的层的分配
完全可以一个界面一个窗体
比如存档，读档，鉴赏画面，系统设置，游戏进行画面
分成5个不同的窗体
其中游戏进行画面就是我们一直在用的窗体
默认为kag
具体功能可以参考如下网址
http://kcddp.keyfc.net/bbs/viewthread.php?tid=857&extra=page%3D4
KCDDP上有很多前辈留下的文档，质量有保障

题外话：
感觉现在KRKR吧的程序有一种断档的倾向，
纯小白（完全可以通过文档解决问题的）
熟练运用KAG指令（熟练使用KAG实现各种需求 KAG很强大，完全可以实现99%的功能）
高手 (精通TJS，熟知各种内部类的构造)
分档的话大概是 1（小白） 2（小白++） 3(入门) 4（入门++） 5（进阶） 6（进阶++） 7（高手） 8（）
我个人处于哪个好用用哪个，KAG、TJS都用但不是精通，属于5.5的地步。
有问题的话大家给点面子别打脸打狠了，疼
现在吧里感觉就是1,2,3 6,7 的分布，完全没见着4，5的中坚力量，所以贴吧分外冷清啊

关于提示框，NoFound.tjs里有实现的代码。拉一个不用的层出来，在上面用drawText就行了，个人觉得不好看就加了张图

pan注baidu备com吞s防1qYnKniW

再一个就是2和z的基本底层构架和上层都不一样，2没有Bitmap这个作为缓存的东西，eval也不是那么太好用，窗体白边z也是没有的，但是z没有Console
反正很尴尬=-=2和z的系统两种写法，然而小白用不明白z也是的确，从零开始很少有人有耐心，基本都是给我解决方法...解决了完事- -

那我直接开楼说了...没办法
有几个最重要的变化，渲染基层什么的就不提了...
Console那个窗口取消，z没有Console窗口，取而代之的是Debug.addLoggingHandler这么个加入分发列表的东西，也就意味着这部分如果不习惯System.inform的话就要手写了
KAGParser直接被甩出去作为插件存在，同时移除了一些没什么卵用的类
现在的kr有32bit和64bit的两个exe
现在的脚本不再支持ANSI，转而变成UTF-8和Unicode两种编码，除了Startup.tjs硬性要求UTF-8意外可以通过Scripts.textEncoding来改变后续编码格式，数据文件(比如[].load)的编码无要求
Scripts.eval现在可以指定执行上下文了
新增Bitmap，ImageFunction，Rect这三个类
分别是图像缓存，图像缓存处理，范围判定
Bitmap和Layer之间仅仅可以复制完整的Bitmap到Layer上，但是Bitmap之间可以通过ImageFunction互相操作
Rect作为范围判定还是可以做碰撞这种东西的...
↑这三个东西把原本的纯Layer渲染变成了Bitmap<->TempBitmap->Layer这么种状态，但是如果想用默认Trans却需要Bitmap->TempLayer->TempBitmap->Layer.....
因为缓存类的存在，现在终于可以进行Update这种东西了，原先的话基本是GG
虽然画面刷新方法是改动刷新...不然卡死...

然而既然要用到渲染循环的话有些东西就必须要改否则用着太蛋疼
System.info = System.inform;
System.TempBitmap = new Bitmap();
var ThisVersion = "101";
var ThisPath = System.exePath + "Data/";
var ThisUUID = "a0f88fa4-006a-4452-886e-deoc158bf120";
var ThisScreen = [ System.screenWidth , System.screenHeight ];
var ThisOS = System.platformName.substring( 0 , 3 ) == "Win"?1:0;
var ThisExe = Storages.extractStorageName( Storages.chopStorageExt( System.exeName ) );
var ThisDesk = [ System.desktopLeft , System.desktopTop , System.desktopWidth , System.desktopHeight ];
Scripts.textEncoding = "Shift_JIS";
Scripts.dump = function{};
这个dump我有点强迫症，Version系统版本，UUID是IO核心的某段序列
除了Startup这些，就是BaseSystem那一球了
既然重写那就需要干脆点.......
因为渲染循环的问题，那么就至少需要增加一些基础数据结构
然后就是那些基础系统的改动...
比如路径下文件查询，自带的那个自动路径没什么好说的...
IO基础，Timer→Thread，报错分类，Log<->Console，还有补丁的基本判定加载，插件的加载

倒回来来说说场景这个东西
Global就是场景的根节点，而在Global下的类才会被调用Update，同Unity一样的管理方式，TAG和Layer，层级也就那样
场景本身是在渲染循环开始之前就已经做好的，在切换场景的时候调用Unit来选择性清空场景或者直接清空场景+GC来达到一个释放的目的，而这样的方式也不用去管理乱七八糟的层了
而加载/切换场景需要的是场景文件，这个场景文件本身需要有初始化函数和一个被动回调函数，因为有的时候加入异步中的时候就需要从异步里提出来之后做完回调
而场景文件本身就是个标记，有助于更快的读取存档和跳转，当然需要额外的标记步骤或者函数，而且这种方式的话不用考虑场景切换间有什么太大的不同，切换协定基本就是那样，除了必须要保存的以外也就没什么了
场景切换可以传值，这个值会直接被扔到初始化函数里(Start)，从而可以区别调用某些差别并不大的场景
而在场景下面同样可以传值的就是子场景，子场景一般为常驻物件所以使用Init来调用初始化，而且可以多次初始化来完成其切换...
而画面上，其他的基本是一大堆的操作类了

对于AVG相对不太友好，那个存档太麻烦，需要命令行
初始存档<-变化极限次数的命令行->最终存档
而随着上限的达到，初始存档会被命令行改变
之后的还原就是通过这一大堆标记命令行来快速还原，先还原数据，再还原画面
就是太麻烦了...................

不过现在到底是用操作类还是挂操作组件还没什么清晰点的思路，毕竟没写到那步
主要还是Update的调用逻辑那里了..是调用物件下的一个Update还是物件下所有组件的Update...