最新 | 最热门 | 最高评价

+0  Await:从 Swift 到 C++

Tag: C++ | 软件开发
sipoint 发于 2021年06月16日 01:09 | 点击: 606 | 展开摘要
上周三(6/9)早上醒来,发现全世界都在赞叹 WWDC 里宣布的新版 Swift async/await 特性。看了几条信息隐约说是基于 coroutine。尽管从去年起因为对 Apple Silicon Mac 迁移的失望已经把个人项目向 Windows 平台转移,但看在当年研究 Lua coroutine 和 Lisp continuation 下了很大功夫的份上,决定探索一下这个 Swift 语言新特性的细节。特别是在没有 VM 的语言上采用 coroutine 会有什

查看全文: http://www.udpwork.com/item/17914.html

+0  Exception Reconsidered

Tag: C++ | 软件开发
sipoint 发于 2020年12月24日 03:50 | 点击: 432 | 展开摘要
我一直是 C++ exception 的反对者。《Programming in Lua(二)- 异常与错误码》提到 Russ Cox 谈论 C++ exception 的所谓「根本缺陷」。我以前的认识是返回 error code 是最好的错误处理方式。

和返回 error code 不同,exception 会触发 call stack 的回退,从而失去了错误发生时的程序运行状态(指代运行状态的术语是 continuation)。这是我之前极力避免 exception 的最

查看全文: http://www.udpwork.com/item/17731.html

+0  Phong Model and Physically-Based

Tag: 软件开发
sipoint 发于 2020年04月25日 03:22 | 点击: 394 | 展开摘要
Phong model 大概是计算机图形领域最简单的材质模型。仅由三个 (组) 参数组成。Nuo Model Viewer 作为个人学习项目从实现 rasterization 渲染入手,自然最初只支持 Phong model。有个问题伴随着 Nuo Model Viewer 的扩展:是否要支持其它更复杂的材质模型?另一个相关问题是,如果 Nuo Model Viewer 支持 path-tracing,对于现有基于 Phong model 的模型是进行预处理转换成其它材质模型

查看全文: http://www.udpwork.com/item/17732.html

+0  单元测试和个人技能成长

Tag: 软件开发
sipoint 发于 2020年04月17日 05:46 | 点击: 376 | 展开摘要
最近看到个对单元测试的看法:

单元测试是预防错误的主要手段。如果一个团队所在的领域对错误的容忍度高,而其市场需要 move fast,就 (暂时) 不用有单元测试;反之,若所在领域对错误容忍度低,那么重视实践单元测试的团队会取得优势。

然而,单元测试并不是「预防错误的主要手段」。首先单元测试并非全部测试。除了单元测试,还有组件测试,系统整体的人工测试,自动化的整体测试等等。团队资源应该在所有测试类型间合理分配,而不是预设单元测试最重要。其次,错误预防的关键点在于 esca

查看全文: http://www.udpwork.com/item/17733.html

+0  一次性代码和坚固的基础

Tag: 软件开发
sipoint 发于 2019年10月13日 13:26 | 点击: 377 | 展开摘要
我对「技术债务」的态度和像对财务债务一样「中立」。借入债务以求发展是必要的,只要在 accounting 里确实把它标成「债务」。债务不断积累时要寻求机会逐步清除它们。比如说对还算能运行的代码进行 refactor。

这会遇到一种反对意见:这段代码估计一两年以后就要废弃了,何必费力气?只要修修补补撑段时间就好了。

其实我的经历是被这么评价的代码反而往往会跟随一个团队十几年。另一方面,有些被寄予很高期望,计划会被使用很多年的代码却连一次正式使用的机会都得不到就被抛弃了。

查看全文: http://www.udpwork.com/item/17734.html

+0  一张 WWDC 幻灯片

Tag: 软件开发
sipoint 发于 2019年04月04日 13:36 | 点击: 381 | 展开摘要
之前的 blog 里提到过,尽管早有愿望学 ray tracing,但 2018 前半年总提不起兴趣动手。六月 Apple WWDC 2018 里关于 ray tracing 的 session 成为我第一次真正接触 ray tracing。望着讲台上削减至极的幻灯片和 speaker 超快的解说,我想这似乎并不难,大概下周给同事总结 WWDC 时就可以自己解释这个问题。

实际上到现在过了十个月,才能说大致理解了这张幻灯片的数学原理。一个简单的 demo 固然能推进学习的进

查看全文: http://www.udpwork.com/item/17735.html

+0  Wavefront OBJ 与 Monte Carlo

Tag: 软件开发
sipoint 发于 2019年02月25日 05:30 | 点击: 341 | 展开摘要
去年十月搬家到现在一直没有对 Nuo Model Viewer 做大改动。年前忙于布置新家。到新年前后稍感安定想增加些新功能,但越想越感觉已有的 ray tracing 代码缺乏数学依据,于是开始温习数学概念。

粗糙的实现

首先,考虑仅支持理想方向光源直射,以及理想纯漫反射材质 (Lambertian) 的 shading 公式 [1]:

这是两年前开始做 Nuo Model Viewer 时最先实现的公式。其实要分析很多细节才能保证完全正确的实现 —— 如何从模型材质

查看全文: http://www.udpwork.com/item/17736.html

+0  从 Metal 看 Vulkan —— 重用还是重建

sipoint 发于 2018年06月04日 04:42 | 点击: 2872 | 展开摘要
Apple 给自己的图形系统取名 Metal 之意在于强调其开销很低,图形应用程序如同直接运行在「金属硬件」( bare metal ) 上。但对 Metal 和 Vulkan 都有了解的人直观上会感觉后者更复杂也更直接反映硬件细节。「Metal 并不能像 Vulkan 那样程度地直接操作硬件」是 Khronos 和 Vulkan 拥趸的一贯观点。

Metal 和 Vulkan 的差异有很多值得讨论之处。绝大部分是前者相对后者在概念上的合并和简化。本来想写篇长文逐一说明,后

查看全文: http://www.udpwork.com/item/16879.html

+0  在谁的模式里思考

Tag: 软件开发 | Mac OS X
sipoint 发于 2018年05月08日 23:17 | 点击: 2034 | 展开摘要
当 CORBA 和 Java 还都很重要的时候,设计 CORBA 的 OMG 鼓吹所有编程语言都应该围绕 CORBA 的接口定义语言 (IDL) 进行面向对象设计;而 Sun Microsystems 则宣扬所有系统都要映射为 Java 的对象模式,数据库要用 Enterprise JavaBean,CORBA 也该被封装为 RMI over IIOP。这是本质一样而方向相反的两支传教队伍抢夺同一群开发者的口角。值得注意的是,这场博弈的每一方依然需要对方去做自己无法胜任的工作

查看全文: http://www.udpwork.com/item/16830.html

+0  显卡的今天和往事(续)

Tag: 软件开发 | Mac OS X
sipoint 发于 2018年03月07日 16:17 | 点击: 1910 | 展开摘要
上篇《显卡的今天和往事》提到买了 Radeon RX Vega 56。因为显卡的缘故对 AMD 的图形技术发展梳理了一下。以前一直以为 Apple 抛弃 OpenGL 去设计 Metal 是对 Driect3D 长久以来领跑的追赶,了解之后发现并非如此。在 DirectX 9 到 11 期间,AMD 的 PC 显卡驱动程序性能一直大幅落后于 nVidia,尽管其硬件理论性能并不差。与此同时 AMD 占据了 game console 图形处理的绝大部分份额,与 Microsof

查看全文: http://www.udpwork.com/item/16705.html

+0  显卡的今天和往事

Tag: Mac OS X
sipoint 发于 2018年03月07日 00:22 | 点击: 3733 | 展开摘要
从 2012 年起看到市面上的显卡越做越漂亮。颇有混合了 cyberpunk 和 steampunk 的感觉。无奈自 2005 年就已是纯粹的 laptop 用户,再无机会和精力搞台式机。我也安慰自己说反正也不常玩游戏。不过从 SIGGRAPH 2017 回来开始玩了一年多 real-time rendering,此种欲望越发强烈起来。业界似乎体会到我的心情。Intel 提出 Thunderbolt 3/USB Type-C 接口支持 PCI 协议。从 2017 年开始,可以

查看全文: http://www.udpwork.com/item/16695.html

+0  TRIPLE is More Than DOUBLE Plus One

Tag: 软件开发 | Mac OS X
sipoint 发于 2017年12月29日 04:57 | 点击: 1480 | 展开摘要
TRIPLE 与 DOUBLE 的问题

远在硬件加速的图形系统 ( graphics APIs ) 出现前,double-buffer 已经是流行的动画防闪烁技术,这个名称一直沿用到 OpenGL 之类硬件加速系统上的相似技术。而 Metal 之类低开销图形系统 ( low-overhead graphics APIs ) 的标准运行模式是 triple-buffer。同时看到这两个名称会引出几个问题:

为什么低开销系统采用「triple」,而不是「double」或者「q

查看全文: http://www.udpwork.com/item/16696.html
|<<<1234567>>>| 一共7页, 84条记录