This GitHub repository, titled "pseudo3d," showcases a remarkably concise implementation of a raycasting engine written entirely in Bash script. The provided code leverages the shell's built-in string manipulation capabilities and arithmetic functionalities to render a pseudo-3D perspective of a simple world map defined within the script itself. The world map is represented as a two-dimensional array of characters, where different characters signify different types of walls or empty space.
The core of the raycasting algorithm involves iterating through the screen's horizontal pixels, calculating the viewing angle for each pixel based on the player's position and viewing direction. For each pixel, a "ray" is cast from the player's position into the world map, effectively tracing a line until it intersects with a wall character. The distance to the wall intersection is then calculated using a simplified distance formula.
This distance value determines the height of the wall segment to be drawn on the screen for that particular pixel. Closer walls result in taller wall segments, creating the illusion of perspective. The rendering process utilizes ANSI escape codes to directly manipulate the terminal output, drawing vertical lines of varying heights representing the walls. Different wall characters in the map are visually distinguished by using different colors for the rendered wall segments, again achieved through ANSI escape codes. The rendering process updates the terminal output in real-time, providing a dynamic view as the player navigates the world.
The player's movement and rotation are handled through basic keyboard input. The script detects specific key presses, updating the player's position and viewing angle accordingly. This dynamic update combined with the real-time rendering loop creates an interactive experience where the player can explore the defined world from a first-person perspective. While rudimentary, the implementation successfully demonstrates the fundamental principles of raycasting in a surprisingly minimal and accessible manner using the Bash scripting environment. The code's brevity and reliance on built-in shell functionalities serve as a testament to the versatility and unexpected capabilities of the Bash scripting language beyond typical system administration tasks.
This GitHub project, titled "obsidian-textgrams," introduces a novel approach to managing and displaying ASCII diagrams within Obsidian, a popular note-taking and knowledge management application. The plugin specifically addresses the challenge of storing and rendering these text-based diagrams, which are often used for visualizations, technical illustrations, and quick sketches. Instead of relying on image embedding, which can be cumbersome and inflexible, obsidian-textgrams allows users to store these diagrams directly within their Markdown files as code blocks. This maintains the inherent portability and editability of plain text.
The plugin leverages a custom code block language identifier, likely textgram or similar, to delineate these diagrams within the Markdown document. This allows Obsidian, with the plugin installed, to distinguish them from standard code blocks. Upon encountering a textgram code block, the plugin intercepts the rendering process. Instead of displaying the raw ASCII text, it parses the content and dynamically generates a visual representation of the diagram. This rendering is likely achieved using a JavaScript library capable of interpreting and visualizing ASCII characters as graphical elements, connecting lines, and forming shapes based on the provided input.
This approach offers several advantages. Firstly, it keeps the diagrams within the text file itself, promoting version control friendliness and avoiding the need to manage separate image files. Secondly, it facilitates easier editing. Users can directly modify the ASCII text within the code block, and the rendered diagram will update accordingly, streamlining the iterative design process. Finally, this method likely preserves the semantic meaning of the diagram, as the underlying ASCII text remains accessible and searchable within Obsidian. This stands in contrast to raster image-based diagrams where the underlying information is lost in the pixel data. In essence, obsidian-textgrams transforms Obsidian into a more powerful tool for working with ASCII diagrams, offering a more integrated and streamlined workflow compared to traditional image-based approaches.
The Hacker News post "Show HN: Store and render ASCII diagrams in Obsidian" at https://news.ycombinator.com/item?id=42112168 generated several comments discussing various aspects of the project.
Several commenters appreciated the utility of the tool, particularly for quickly sketching out diagrams within Obsidian. One user pointed out the advantage of having diagrams rendered directly within the note-taking application, rather than relying on external tools or image uploads. They specifically mentioned the convenience this offers for quick brainstorming and idea capture. This sentiment was echoed by another user who highlighted the speed and ease of use compared to traditional diagramming software.
The discussion also delved into the technical aspects of the project. One commenter inquired about the rendering process, specifically whether it was client-side or server-side. The project creator clarified that rendering is handled client-side using JavaScript within Obsidian. This prompted further discussion about potential performance implications for complex diagrams.
The choice of using Mermaid.js for rendering was also a topic of conversation. One commenter suggested PlantUML as an alternative, praising its flexibility and extensive feature set. They also pointed out PlantUML's wider adoption and the availability of server-side rendering options. This led to a discussion about the trade-offs between different rendering engines, considering factors like ease of use, feature richness, and performance.
Some commenters expressed interest in extending the plugin's functionality. One suggestion involved integrating with other Obsidian plugins, specifically those focused on graph visualization. Another user proposed adding support for other diagram formats beyond Mermaid.js, such as Graphviz.
Overall, the comments reflect a positive reception of the project, with users acknowledging its practicality and potential for enhancing the Obsidian note-taking experience. The discussion also highlighted areas for potential improvement and expansion, including exploring alternative rendering engines and integrating with other Obsidian plugins. There was a definite interest in the technical aspects of implementation and a healthy discussion regarding the chosen technical stack as well as some alternatives.
Summary of Comments ( 34 )
https://news.ycombinator.com/item?id=42475703
Hacker News users discuss the ingenuity and limitations of a bash raycaster. Several express admiration for the project's creativity, highlighting the unexpected capability of bash for such a task. Some commenters delve into the technical details, discussing the clever use of shell built-ins and the performance implications of using bash for computationally intensive tasks. Others point out that the "raycasting" is actually a 2.5D projection technique and not true raycasting. The novelty of the project and its demonstration of bash's flexibility are the main takeaways, though its practicality is questioned. Some users also shared links to similar projects in other unexpected languages.
The Hacker News post titled "A Raycaster in Bash" (https://news.ycombinator.com/item?id=42475703) has generated several comments discussing the project, its performance, and potential applications.
Several commenters express fascination with the project, praising the author's ingenuity and ability to implement a raycaster in a language like Bash, which isn't typically used for such computationally intensive tasks. They admire the technical achievement and the demonstration of what's possible even with limited tools.
Performance is a recurring theme. Commenters acknowledge that the Bash implementation is slow, with some sharing their own experiences and benchmarks. Suggestions are made for potential optimizations, including using a different shell like
zshfor potential performance gains, leveragingawk, and exploring alternative algorithms. The inherent limitations of Bash for this type of application are recognized, and the discussion explores the trade-offs between performance and the novelty of the implementation.The practical applications of the project are also debated. While some view it primarily as a technical demonstration or a fun experiment, others suggest potential use cases where performance isn't critical. One commenter proposes using it for generating simple visualizations in constrained environments where other tools might not be available.
The choice of Bash itself is discussed. Some commenters question the rationale behind using Bash, suggesting more suitable languages for such a project. Others defend the choice, highlighting the value of exploring unconventional approaches and pushing the boundaries of what's possible with a familiar scripting language. The discussion touches upon the educational aspects of the project and its potential to inspire creative solutions.
Beyond the technical aspects, there's appreciation for the author's clear and well-documented code. The readability and organization of the project are commended, making it easier for others to understand and learn from the implementation. The project is also seen as a testament to the flexibility and power of Bash, even beyond its typical use cases. Some commenters express interest in exploring the code further and potentially contributing to its development.