The Weekly Squeak

Category: 3D

  • Exploring Croquet in Squeak 6.0: A Community-Driven Effort

    Exploring Croquet in Squeak 6.0: A Community-Driven Effort

    An initiative has recently emerged within the Squeak community to explore bringing Croquet into the modern Squeak 6.0 environment, with their efforts opening up possibilities for personal and educational applications, and potentially paving the way for long-term developments. Community members Edwin Ancaer and Timothy have taken it upon themselves to explore, port, and troubleshoot Croquet – an ambitious collaborative 3D environment originally designed to run in earlier 32-bit versions of Squeak.

    Croquet was a groundbreaking software architecture designed for deep collaboration, originally built as an open, free, and highly portable extension of the Squeak programming system. It provided a platform for both development and real-time collaborative work, with no separation between user and developer environments. Focused on 3D shared spaces, Croquet enabled users to interact in context-based collaborations, observing each other’s actions and focus in real time. A collaboration protocol called TeaTime powered this synchronization, and rendering was based on OpenGL. While newer, proprietary descendants of Croquet have evolved since, the version being revived in Squeak 6.0 reflects this original, exploratory vision.

    Croquet Jasmine, a developer’s release of the system, is available and can be run live in a web browser using the SqueakJS virtual machine – allowing others to easily explore Croquet without a local setup. You can try a live version here: codefrau.github.io/jasmine/.

    Technical Hurdles and Graphics Considerations

    Efforts began early in the process, building on Nikolay Suslov’s work to get the original Open Croquet running on the latest versions of Squeak 5.x. His work laid the groundwork for achieving compatibility with Squeak 6.0. You can explore his repository here: github.com/NikolaySuslov/croquet-squeak. You can also check out detailed steps Nikolay has provided to bring Croquet into an early alpha version of Squeak 6.0 here.

    A primary obstacle encountered was the tight coupling between Croquet and OpenGL 1. As Vanessa Freudenberg pointed out, OpenGL has been deprecated on macOS for years, complicating efforts to run the system on 64-bit machines. Vanessa suggested considering Vulkan or OpenGL 4 as possible alternatives for the rendering backend.

    In consideration of a long-term solution, it is helpful to explore the potential paths forward, each with its own trade-offs:

    • Re-implement OpenGL 1 as a compatibility layer – Offers limited long-term value and would still not work effectively on macOS due to deprecated OpenGL support and the absence of modern graphics capabilities. Efforts like MoltenGL, which aim to bridge OpenGL to Metal, do not support OpenGL 1, making this path particularly challenging.
    • Migrate to a modern OpenGL (3.x or 4.x) – More viable than OpenGL 1 in terms of features, and partially supported on macOS (up to OpenGL 4.1). However, it is deprecated and no longer maintained on Apple platforms, making it an unstable foundation for future development.
    • Adopt Vulkan for high performance – A modern, low-overhead graphics API designed as a successor to OpenGL. While Vulkan is not natively supported on macOS, it can be used via MoltenVK, which translates Vulkan calls to Metal. This option requires significant integration work but offers the most long-term potential across platforms.

    For a long-term solution, Vulkan appears to be the most promising path – essentially a modern, cross-platform successor to OpenGL, developed to overcome many of its limitations. Although not natively supported on Apple platforms, Vulkan’s compatibility through MoltenVK makes it a viable candidate for achieving performance and portability across environments.

    While these options are worth exploring for long-term solutions, they may be unnecessarily complex for personal or educational use. However, the current efforts could prove valuable down the road by revealing key details, helping future work begin from well-understood points in the development process.

    Vanessa has managed to run Croquet Jasmine without modifying the Smalltalk code by using the browser-based SqueakJS VM, with a custom OpenGL 1 implementation written in JavaScript. This was accessed via FFI and mapped to modern WebGL. The approach preserves the original graphics code inside the image while offloading rendering to the browser, and could serve as a model for similar efforts going forward.

    Debugging and the Role of C in a Self-Hosting Environment

    In efforts to get Croquet working with Squeak 6.0, contributors encountered challenges requiring low-level debugging. Their focus shifted to analyzing behavior via the debug VM, aiming to isolate root causes of instability or failure.

    One may wonder why Squeak, being a self-hosting environment, might still require work in C. The environment is written in Smalltalk and is capable of building and evolving itself entirely from within. This self-hosting capability enables fast iteration, deep system visibility, and live modification of running code – all without leaving the environment.

    However, Squeak runs on a virtual machine, with performance-critical parts written in a restricted subset of Smalltalk known as Slang (Swiki link). Slang is not a separate language, but a subset of Smalltalk designed to be translatable into C for compilation. This allows the virtual machine, which is largely written in Smalltalk, to be compiled into efficient native code for multiple platforms. When issues arise at the VM level – such as those involving primitives, foreign function interfaces, or memory management – developers must drop down into the generated C code to diagnose and resolve them. You can read more about the Squeak VM on the Swiki here and here.

    The benefit of this design is excellent portability: the Smalltalk environment remains consistent across platforms, while only the VM layer needs to be recompiled or adapted for different operating systems or hardware. Having this level of separation allows the Squeak image to remain consistent across multiple platforms without exposing the underlying hardware implementation to the image code itself.

    Further analysis suggested that inconsistencies between expected and actual behavior in the virtual machine’s handling of system-level function calls were at the heart of the issue – at least for now. By carefully tracing how external interfaces were being resolved and invoked, the contributors were able to isolate a likely point of failure. The realization was met with enthusiasm, signaling meaningful progress toward resolving the issue.

    The Irony of Debugging and Systems Development

    Edwin humorously remarked that he never expected working in Smalltalk would lead him back to debugging C code – a twist that underscores the unpredictable nature of systems development. Tim Rowledge added that, during his time at ParcPlace, it was an inside joke that those who got hooked on Smalltalk inevitably ended up spending too much time writing C, while the C++ fans who joined the team found themselves writing Smalltalk instead. The irony of this unexpected reality highlights the surprising paths developers take when working with complex systems.

    Looking Ahead

    We extend deep appreciation to Nikolay Suslov for his foundational work in bringing the original Open Croquet to Squeak 5.x, which has served as a solid base for moving toward compatibility with Squeak 6.0. A special thanks also goes to Edwin and Timothy for their time, dedication, and resourcefulness in troubleshooting and adapting Croquet to modern Squeak 6.0 systems. Their efforts contribute to the broader community by preserving an important piece of Squeak history and helping to lay the groundwork for future advancements.

    The effort to bring Croquet to Squeak 6.0 is ongoing. We wish those involved continued success and invite anyone curious to jump in, contribute, and join the effort to keep Squeak a vibrant environment for innovation and exploration!

    Have a great time with Smalltalk and keep on Squeaking!

  • Ray Casting With Squeak

    Ray Casting With Squeak

    Ray Casting With Squeak

    On the Squeak developers mailing list, Lauren Pullen shared her experience (found here) using Squeak while working on a rendering engine for a first-person maze game, similar to the technique used to render the original Wolfenstein 3D game. Wolfenstein 3D used a rendering technique known as ray casting. Her project captured our attention prompting us to seek additional information from her about it.

    What is Ray Casting?

    Ray casting is an early rendering technique used in computer graphics and video games, particularly in 2.5D and 3D environments. It is a simplified form of ray tracing, where a ray is cast from the player’s or camera’s perspective into the environment, and the distance to the nearest object along that ray is calculated. This process is repeated for each column on the screen, creating a 3D representation of the 2D world. Ray casting was widely used in the early days of 3D gaming, particularly in games like Wolfenstein 3D (1992).

    From Lisp to Squeak

    Lauren, with her extensive experience in Common Lisp, initially chose it to create a GUI application. However, she faced significant challenges. The graphics library was unreliable, often failing to start, and the outdated documentation made it difficult to work with. She studied MVC while designing her application but struggled with basic functionality, such as displaying a simple window.

    She decided to switch to Smalltalk, specifically Squeak, which had an immediate impact. The graphical elements worked seamlessly from the start, and although she missed some features from Common Lisp, like restarts and method combinations, Squeak provided a development environment that allowed her to focus on development without drastically changing her mental approach to problems.

    Comparing Development Tools

    For game development, she initially relied on a much earlier version of Game Maker Pro. When she explored Godot, she found its complexity overwhelming compared to Smalltalk. The disorganization in Godot’s tutorials made her question how to create a basic viable product efficiently. In contrast, though seemingly minimal, Squeak’s classes Form and UserInputEvent provided all that was needed.

    Advantages of Squeak

    In Squeak, she found it easy to work with graphical elements. Drawing interface components and importing graphics were straightforward, thanks to the source code access for built-in drawing functions. This simplicity was crucial for her development process. While working on the game, she realized that making changes and seeing immediate results was invaluable for debugging. Her experience with Forth taught her the value of functions that do one thing well, and Smalltalk’s debugging tools like Inspect-It and Debug-It further streamlined the process.

    Challenges and Solutions

    However, she encountered challenges. While most errors in Smalltalk were easy to handle—usually, closing the Debugger was all that was needed—some issues could freeze the image, making recovery a bit more manual than desired. She found herself needing to use the Recover Changes window to restore unsaved changes more often than she would have liked.

    In terms of rendering, she faced performance limits with BitBlt when texturing the floor and ceiling. To overcome this, she turned to the AbstractGPU library, leveraging the graphics card for drawing. She continued to use the ray caster to determine what the player could see to speed up the game, but introduced edge pop-in, where objects on the screen edges would suddenly appear while turning the camera, because of differences between the ray caster’s projection and the GPU’s projection. Increasing the field of view used by the ray caster resolved this issue.

    Testing Using Morphic Dungeon

    Morphic Dungeon is what Lauren developed and uses to test the movement and texturing code. She wants to work with textures that are not symmetrical, which requires mapping the top-left corner of the texture to different positions on each face of the 3D objects. This approach also allowed her to test back-face culling—a technique that improves performance by not drawing faces of a 3D object that are not visible to the camera—in the GPU mode. In this mode, the “back faces” are flipped horizontally and appear further away, as if looking at the inside of a transparent painted box instead of the outside. Back-face culling will be essential for rendering the “walls” of tiles that the player can enter or see through, such as grass or support beams along the grid edges.

    Lauren implemented three movement modes:

    • Free Movement and Free Turning
    • Grid-Locked Movement and Free Turning
    • Grid-Locked Movement and Grid-Locked Turning

    Full Free Movement is similar to Wolfenstein 3D, allowing sub-pixel steps and small increment camera rotations.

    Grid-Locked Movement is useful for first-person dungeon crawlers. Grid-Locked Turning forces camera rotation to 90-degree increments, similar to classic non-raycaster games like Wizardry or modern titles like Etrian Odyssey. Free camera rotation, with Grid-Locked Movement, is also supported which is similar to the modern title Operencia.

    While using Morphic Dungeon to test the different movement modes, Lauren encountered an amusing floating point error whereby the player would step repeatedly through walls and out of the play area. This provided a humorous insight into the potential bugs she might encounter.

    Additionally, Lauren tested the game with a family member, revealing that the 40×40 maze, though not difficult from an overhead view, proved challenging from a first-person perspective without an overhead view or compass. This feedback helped her adjust the difficulty of the first area to better suit new players.

    Future Plans

    Looking ahead, she plans to explore non-flat levels and dynamically stitching multiple maps together. This might result in overlaps while rendering, so the ray caster will be in charge of telling the graphics card what to draw. Meanwhile, she will focus on improving floor and ceiling loading performance, although this is currently less critical due to the few vertices involved.

    Lauren believes that developing a game is a great way to introduce people to programming. While tools are useful, having something that you can play with is fun. Old tile-based games and raycasters are particularly appealing to her because they are simple to work with, even for beginners.

    Overall, Lauren believes that Squeak has proven to be an excellent choice for her project, offering the simplicity and functionality needed for a successful game development experience.

    Why Not Give It a Try?

    If you would like to experiment with ray casting in Squeak, you can find out more about her project from SqueakSource here. To use the 3D accelerated package, you will also need AbstractGPU by Ronie Salgado, available (here). Ronie is the author of a number of terrific 3D development tools, including Woden (here) and Sysmel (here). Be sure to explore these excellent resources as well!

    Have a great time with Smalltalk and keep on Squeaking!