init:
每个像素只运行一次。在这里设置轨道初值和所需的辅助变量。
了解规范 FRM-like v1 Definition 如何驱动已发布的 Standard 公式,然后使用独立的 Classic-compatible Editor 示例,切勿混淆这两种源码契约。
FractalPark FRM-like v1 是已发布 Standard Definition 背后的规范、类型化源码语言。一个 Definition 会固定其语言、标准库、NumericProfile、parameters、初始状态、重复执行的轨道步骤和继续迭代谓词。
Classic .frm 源自 Fractint 生态系统,仍是 Classic-compatible 独立 Editor 和导入管线使用的源码契约。FractalPark 会单独扫描和诊断该方言;Classic 源码以及 frmSemanticsVersion 1 或 2 并不是规范 FRM-like v1 的替代拼写。
关于这一体系更广泛的起源与历史,可参阅 Fractint 项目网站.
此兼容性表描述 Classic-compatible Editor 和导入路径。规范的已发布 Standard Definition 使用单独版本化的 FRM-like v1 parser、类型化 IR、standard32 backend 和固定的 Safety Envelope。
| 级别 | 含义 | 已验证范围 |
|---|---|---|
| 支持 | 已有编译器测试覆盖,可以直接使用,无须额外说明语义差异。 |
|
| 适配 | 可以使用,但采用有说明的 FractalPark 语义,或属于 FractalPark 扩展。 |
|
| 暂不支持 | 当前编译器或文件流程无法保真处理;会明确拒绝,而不会静默改写。 |
|
这是经过测试的 Classic 兼容性基线,并不声明完整的 Fractint 兼容性;它与 Standard 发布台账是两套彼此分离的口径。
这些 Classic 导入能力计数来自版本化兼容性清单:588 个目标条目包含 579 个 strict-v2 通过项和 9 个有文档记录的豁免;另有 117 个独立条目以固定不变的理由被排除。它们不计入已发布的 FRM-like v1 Definition。
参数:p1, p2, p3, p4, p5 · 函数槽:fn1, fn2, fn3, fn4
能力清单 v1 · 严格语义 v2
规范 FRM-like v1 与当前 Classic Editor 示例都具有命名公式以及 init、loop 和 bailout 的概念,但它们的完整语法不同。在 v1 中,语义 directive 和可选的类型化 parameters section 也是 Definition 的一部分。
每个像素只运行一次。在这里设置轨道初值和所需的辅助变量。
每轮迭代运行一次。更新 z,以及下一轮仍需使用的其他状态。
返回是否继续迭代的条件。条件变为假时,当前点已经逃逸。
这些区段名是语法结构而非注释;缺少或拼错任何一个都会产生诊断信息。
两种界面都刻意保持精简。下列摘要是共享概念;请使用已发布 Formula Record 的 Source 操作查看规范 directive 和类型化 parameter,并使用 Editor diagnostics 处理 Classic 源码。
FractalPark 从不将源码文本直接粘贴进 shader。规范 v1 源码经由其类型化 parser 和 CPU/GLSL backend;Classic Editor 源码经由其 scanner、selected-entry frontend、canonical formula model 和 plugin compiler。
来自编辑器、粘贴或本地文件的原始文本,是编译流程的权威输入。
词法分析器识别名称、数字、运算符、区段标记、注释和指令,同时保留源码位置。
解析器构建结构化公式树,并报告格式错误的声明、表达式和控制流块。
校验器检查名称、类型、区段和受支持语义,通过后才建立规范化公式。
代码生成器输出着色器函数,并记录生成 GLSL 到原始 FRM 位置的映射。
编译成功后,公式会转成渲染器和着色器组装系统共同使用的标准插件契约。
每种源码契约各有一条自己的实现路径。已发布 Standard runtime 使用 FRM-like v1;独立 Editor 和当前自定义公式示例使用 Classic-compatible 路径。两者均不会悄然回退到另一方。
这些是 Classic-compatible Editor 示例,不是规范 FRM-like v1 Definition。它们从小型二次公式逐步扩展到 parameters 和有状态反馈;每个源码块均来自共享 Editor registry,并在测试期间编译。
第 1 课
最基础的逃逸时间公式, 适合先看清 init / loop / bailout 的最小结构.
重点:公式声明与 init / loop / bailout 结构。先确认最小版本能够编译,再尝试修改指数或逃逸阈值。
StarterBrot {
init:
z = 0
loop:
z = z^2 + c
bailout:
|z| < 4
}第 2 课
演示 p1 / p2 参数槽位, 以及 cabs 与 |z| 的不同用法.
重点:p1 与 p2 参数槽、复数常量,以及把 cabs(z) 作为显式模长函数。
ParameterDrift {
init:
z = 0
loop:
z = z^2 + c + p1 * 0.15 + p2 * (0.05, -0.02)
bailout:
cabs(z) < 8
}第 3 课
用 zPrev 做记忆反馈, 并推荐搭配 orbitEcho 着色查看轨道包络.
重点:用 zPrev 取得上一轮轨道状态。无需手动维护第二个状态变量,也能引入记忆反馈。
OrbitEcho {
init:
z = pixel
loop:
z = sqr(z) + zPrev * (0.30, -0.12) + pixel * (0.85, 0.0)
bailout:
|z| < 48
}独立 FRM Editor 通过稳定 ID 打开这些 Classic-compatible、经过编译检查的示例。公式源码会留在当前标签页,直到你将它保存到云库,且绝不会嵌入 URL。这不会启用规范 v1 导入或写入器。
编译会在最早出现不安全状态的阶段停止,并提供面向源码的错误信息。被拒绝的语法不会被改写成一个只是看起来相似的结果。
意外字符和不支持的标识符会连同行号、列号一起报告。
格式错误的区段、表达式或控制流块会在语义校验之前被诊断。
未知变量、无效赋值、类型不匹配和未支持语义都会阻止代码生成。
生成的 GLSL 保留位置映射,可将着色器编译失败定位回原始 FRM 代码。
修复错误时应从第一条信息开始;后续诊断往往只是同一个缺失符号或无效表达式引发的连锁结果。
你写的公式默认是私有的,除非你明确选择分享。公式有三种流转方式——每一种都由你显式触发,没有静默发生。
默认私有
公式保存在你的云端库中,仅自己可见。保存的作品会把公式源码副本存进草稿里,所以作品打开时永远是你离开时的样子。
下载 .frm 文件
你的公式是纯文本。随时从「我的公式」下载,自己留一份——不需要导出申请,不需要等待。
发布作品,分享源码
发布使用了自定义公式的作品,会以 MIT 许可证公开公式源码:任何人都可以阅读、复制并在其上继续创作。社区页面会展示来自元数据的公式名,并提供源码下载。对已发布的作品而言,这一步不可撤销。
打开 Explore,比较内置公式的行为、着色、变换、动画和导出控制,再开始编写自定义公式。
打开 Explore使用专用 FRM Editor 完成当前的 Classic-compatible 编译、预览、导入和下载工作流。它不接受规范 FRM-like v1 源码;请从 Formula Record 检查已发布 v1 源码,并使用该 Record 的 Open 或 Remix 操作运行它。
历史背景与实现细节分开链接,以明确区分 Fractint 传承和 FractalPark 当前的编译器契约。