Oilybear 最近的时间轴更新 Oilybear 最近的时间轴更新 |
OilybearV2EX 第 404927 号会员，加入于 2019-04-23 12:42:43 +08:00 |
Oilybear 最近回复了
看你持股都是大的指数，这种买卖基本上我建议看市盈和市净的水位，节后就算跌你不卖又不是真的亏损，当然你要追情绪赚钱就是另外一种玩法了
29 天前 回复了 erde 创建的主题 › Apple › Airpods Pro3 发布了，降噪提升至 2 倍，续航提升至 8 小时，感觉很值得换？ |
@kenshinhu 我是冤种，买 app2 lightning 的时候没看 2 周后要出 typeC 的，现在被迫准备两条充电线
43 天前 回复了 tiancaiXD 创建的主题 › 互联网 › 为什么现在缩写越来越多，都快看不懂中文了 |
@niurougan 你试试 xjp
43 天前 回复了 tiancaiXD 创建的主题 › 互联网 › 为什么现在缩写越来越多，都快看不懂中文了 |
前几天我司产品刚接到阿 sir 的通知，内容安全你懂的，人该低头得低头
115 天前 回复了 aqtata 创建的主题 › git › 两处修改需要分开提交吗？ |
按照常理来说就是分开提交
117 天前 回复了 stimw 创建的主题 › 程序员 › macos / windows 日常混用 快捷键极其割裂 |
我感觉还好，摸到 mac 的键盘肌肉记忆自动 mac 快捷键，反手模键盘操作 window 的设备秒切
2024-03-04 23:06:38 +08:00 回复了 Oilybear 创建的主题 › 程序员 › 想开发一个桌面应用软件，求前辈们推荐技术栈 |
@nicholasxuu 我确实有这个想法，不过你也提醒我了，文档里面（ https://support.forzamotorsport.net/hc/en-us/articles/21742934024211-Forza-Motorsport-Data-Out-Documentation ）是有明确指明每秒 60 个遥测数据，差不多平均 0.016S ，一个算可用范围。
相比 rfactor2 这种专业性更强的游戏，在导出视频时就能从游戏引擎层采集了同步的遥测数据。FM 只能获取遥测，也就是说即便采取同步录制，采集的视频和遥测数据的对应也可能有问题，录制方式导致或者其他因素。
另外我想其实更重要的是快速验证一下软件可行性，至于这些视频同步分析这些功能有一些可预知的难度我想放到以后的版本中实现。退而求其次，利用刹车点的曲线 gap 和时速也能够推倒计算刹车点差多少米，在配合重刹区的一些指示牌去调整。其实能做的想法还蛮多的，弯角名称的播报，车胎磨损的语音提醒，就想有个赛道工程师在 TR 里做我们的专属工程师，一步一步来哈哈哈
相比 rfactor2 这种专业性更强的游戏，在导出视频时就能从游戏引擎层采集了同步的遥测数据。FM 只能获取遥测，也就是说即便采取同步录制，采集的视频和遥测数据的对应也可能有问题，录制方式导致或者其他因素。
另外我想其实更重要的是快速验证一下软件可行性，至于这些视频同步分析这些功能有一些可预知的难度我想放到以后的版本中实现。退而求其次，利用刹车点的曲线 gap 和时速也能够推倒计算刹车点差多少米，在配合重刹区的一些指示牌去调整。其实能做的想法还蛮多的，弯角名称的播报，车胎磨损的语音提醒，就想有个赛道工程师在 TR 里做我们的专属工程师，一步一步来哈哈哈
2024-02-29 09:44:28 +08:00 回复了 Oilybear 创建的主题 › 程序员 › 想开发一个桌面应用软件，求前辈们推荐技术栈 |
@bronyakaka 感谢你的推荐，我自己本职是 Python 开发相关。
Python 的 GUI 方向，wxPython 和 pyqt 我两个 python 比较主流的 GUI 方案在其他项目上使用过，当时需要配合 pytorch 做一些实时完成一些采集和推理。个人体感不是很好，毕竟数据采集相关的工作肯定有独立的线程/进程维护，不会放置在和 GUI 相关的主进程中，但是 Python 的多线程受制于 GIL ，多进程的话数据共享也需要而外的进程维护数据相对性能牺牲代价较大。
这个项目的运行环境是运行游戏的同时还运行该软件，后期预想的甚至是配合 N/A 卡的一些录制 API 同步进行一部分录制，以满足圈速分析上刹车点分析的一些需求，所以性能层面可能要很早考虑。
目前我的决定是使用上面的前辈推荐的 tauri 这个框架 [前端技术栈+本地 Rust 后端] ，毕竟非商业项目尝鲜一下，另外一个是我觉得 python 有潜在风险不太适合，但是还是感谢你的推荐，以后有什么小工具需要快速实现又尽可能考虑美观的地方我会看一下 flet 这个框架。
Python 的 GUI 方向，wxPython 和 pyqt 我两个 python 比较主流的 GUI 方案在其他项目上使用过，当时需要配合 pytorch 做一些实时完成一些采集和推理。个人体感不是很好，毕竟数据采集相关的工作肯定有独立的线程/进程维护，不会放置在和 GUI 相关的主进程中，但是 Python 的多线程受制于 GIL ，多进程的话数据共享也需要而外的进程维护数据相对性能牺牲代价较大。
这个项目的运行环境是运行游戏的同时还运行该软件，后期预想的甚至是配合 N/A 卡的一些录制 API 同步进行一部分录制，以满足圈速分析上刹车点分析的一些需求，所以性能层面可能要很早考虑。
目前我的决定是使用上面的前辈推荐的 tauri 这个框架 [前端技术栈+本地 Rust 后端] ，毕竟非商业项目尝鲜一下，另外一个是我觉得 python 有潜在风险不太适合，但是还是感谢你的推荐，以后有什么小工具需要快速实现又尽可能考虑美观的地方我会看一下 flet 这个框架。
Select Language