Reverse engineering of Shenmue's source code revealed that the sun's position in the game is calculated using a simplified formula that doesn't account for axial tilt or the equation of time. This results in the sun rising and setting slightly earlier than it should in the game's real-world counterpart of Yokosuka, Japan, across all in-game dates. While noticeable, this discrepancy doesn't significantly impact gameplay and may have been a deliberate simplification for performance reasons on the Dreamcast. The author speculates whether it qualifies as a "bug" given its likely intentional nature and minimal effect on the overall experience.
A recent Clang optimization introduced in version 17 regressed performance when compiling code containing large switch statements within inlined functions. This regression manifested as significantly increased compile times, sometimes by orders of magnitude, and occasionally resulted in internal compiler errors. The issue stems from Clang's attempt to optimize switch lowering by transforming it into a series of conditional moves based on jump tables. This optimization, while beneficial in some cases, interacts poorly with inlining, exploding the complexity of the generated intermediate representation (IR) when a function with a large switch is inlined multiple times. This ultimately overwhelms the compiler's later optimization passes. A workaround involves disabling the problematic optimization via a compiler flag (-mllvm -switch-to-lookup-table-threshold=0) until a proper fix is implemented in a future Clang release.
The Hacker News comments discuss a performance regression in Clang involving large switch statements and inlining. Several commenters confirm experiencing similar issues, particularly when compiling large codebases. Some suggest the regression might be related to changes in the inlining heuristics or the way Clang handles jump tables. One commenter points out that using a constexpr hash table for large switches can be a faster alternative. Another suggests profiling and selective inlining as a workaround. The lack of clear identification of the root cause and the potential impact on compile times and performance are highlighted as concerning. Some users express frustration with the frequency of such regressions in Clang.
Some websites display boxes instead of flag emojis in Chrome on Windows due to a font substitution issue. Windows uses its own Segoe UI Emoji font for most emoji, but defaults to a lower-quality bitmap font called "Segoe UI Symbol" specifically for flag emojis. This bitmap font lacks the necessary glyphs for many flag combinations, resulting in the missing emoji. Websites can force Chrome to use the correct, vector-based Segoe UI Emoji font by explicitly specifying it in their CSS, ensuring flags render properly.
Commenters on Hacker News largely discuss the technical details behind the issue, focusing on the surprising interaction between Chrome, Windows, and the specific way flags are rendered using two combined code points. Several point out the complexity and unexpected behaviors that arise from combining characters, particularly when dealing with different systems and fonts. Some users express frustration with the inconsistency and lack of clear documentation around emoji rendering. A few commenters offer potential workarounds or solutions, including using a fallback font or pre-rendering the flags as images. Others delve into the history and evolution of emoji standards and the challenges of maintaining compatibility across platforms. A compelling comment thread explores the tradeoffs between using the combined code points for flags versus using dedicated single code points, highlighting the performance implications and rendering complexities. Another interesting discussion revolves around the role of fonts and the challenges of designing fonts that support a rapidly expanding set of emojis.
Pixel 4a owners who haven't updated their phones are now stuck with a buggy December 2022 battery update as Google has removed older firmware versions from its servers. This means users can no longer downgrade to escape the battery drain and random shutdown issues introduced by the update. While Google has acknowledged the problem and promised a fix, there's no ETA, leaving affected users with no immediate solution. Essentially, Pixel 4a owners are forced to endure the battery problems until Google releases the corrected update.
HN commenters generally express frustration and disappointment with Google's handling of the Pixel 4a battery issue. Several users report experiencing the battery drain problem after the update, with some claiming significantly reduced battery life. Some criticize Google's lack of communication and the removal of older firmware, making it impossible to revert to a working version. Others discuss potential workarounds, including custom ROMs like LineageOS, but acknowledge the risks and technical knowledge required. A few commenters mention the declining quality control of Pixel phones and question Google's commitment to supporting older devices. The overall sentiment is negative, with many expressing regret over purchasing a Pixel phone and a loss of trust in Google's hardware division.
A quirk in the Motorola 68030 processor inadvertently enabled the Mac Classic II to boot despite its ROM lacking proper 32-bit addressing support. The Classic II's ROM mistakenly used a "MOVEA" instruction with a 32-bit address, which should have caused a failure on the 24-bit address bus. However, the 68030, when configured for a 24-bit bus, ignores the upper byte of the 32-bit address in this specific instruction. This unintentional compatibility allowed the flawed ROM to function, making the Classic II's boot process seemingly normal despite the underlying programming error.
Hacker News commenters on the Mac Classic II boot anomaly generally express fascination with the technical details and the serendipitous nature of the discovery. Several commenters delve into the specifics of 680x0 instruction sets and how an invalid instruction could inadvertently lead to a successful boot, speculating about memory initialization and undocumented behavior. Some share anecdotes about similar unexpected behaviors encountered during their own retrocomputing explorations. A few commenters also highlight the importance of such stories in preserving computer history and understanding the quirks of older hardware. The overall sentiment reflects appreciation for the ingenuity and occasional happy accidents that shaped early computing.
Summary of Comments ( 16 )
https://news.ycombinator.com/item?id=43345285
Hacker News users discuss whether the perceived sun position error in Shenmue is actually a bug or a deliberate design choice. Some commenters suggest it's a performance optimization, avoiding complex calculations for marginally improved visuals. Others argue it's simply a bug, pointing to inconsistencies with the in-game clock and world design. Several discuss the challenges of reverse engineering older games, particularly with limited documentation, and the difficulty of definitively labeling something a bug without access to the original source code and developer intentions. The discussion also touches on the nostalgic appeal of Shenmue and the dedication of its fan community in dissecting the game's intricacies.
The Hacker News post about a potential sun position oversight in Shenmue generated several interesting comments.
One commenter pointed out that the game's use of pre-calculated lighting and shadows was a common technique in the late 90s due to hardware limitations. They suggested that the discrepancy in sun position might be a deliberate simplification made to optimize performance. This comment also discussed the challenges of realistically simulating time of day in games, noting that even modern games sometimes struggle with accurate sun and shadow behavior.
Another commenter shared a personal anecdote about working with a former Sega developer. This anecdote highlighted the common practice of "good enough" approximations in game development, especially during that era. They argued that minor inconsistencies like the sun position issue were often overlooked in favor of meeting deadlines and staying within performance constraints.
Several commenters discussed the technical details of how the sun's position is typically calculated in games, including the use of spherical coordinates and transformation matrices. These discussions provided further context for understanding the potential source of the discrepancy in Shenmue. One comment even speculated about the specific code or algorithms that might have been used by the developers.
One commenter mentioned the "You're not supposed to see that" phenomenon often encountered in games. This highlights how developers often prioritize creating the intended player experience over perfect realism, accepting minor inconsistencies that are unlikely to be noticed by most players.
Finally, some commenters expressed admiration for the original poster's dedication to reverse engineering and analyzing the game's inner workings. They appreciated the insight into the technical challenges faced by game developers, particularly during the Dreamcast era.
Overall, the comments section provided a mix of technical explanations, historical context, and personal anecdotes that helped shed light on the potential sun position oversight in Shenmue. The commenters generally agreed that the issue was likely a deliberate simplification or a minor bug, rather than a significant flaw in the game's design.