This is a raycasting engine for 2D→3D projection, inspired by 1992 Wolfenstein
 |
|---|
| Engine in action with custom neon textures |
Note
These installation steps assume availability of x11 and clang or gcc
-
Clone the repository; enter the created directory.
$ git clone https://github.com/mitadic/raycasting_game; cd raycasting_game -
Optional: tweak the settings manually in
cub3d.hbefore compiling// Settings # define SCREEN_W 800 # define SCREEN_H 600 # define PLAY_FPS 60 # define ROT_SPEED_FEED 0.015 # define MOV_SPEED_FEED 0.0125 -
Compile
$ make
Run the app with a map of your choosing.
./cub3d maps/full.cubAdd your custom maps/*.cub files with specifications for
- maps (
1: walls,0: walkable tiles,N|W|S|E: player position and orientation) - textures (
.xpmformat images only) - floor & ceiling colors (RGB)
The goal of the project was to recreate the then revolutionary tech behind Wolfenstein 3D from scratch. Although the engine is natively 2D, it renders a first-person 3D perspective by simulating a 3D environment on a 2D map.
We start with a 2D grid-based map where each cell represents walls (1) or empty space (0). Using raycasting, we simulate the player's perspective by casting rays in different directions and calculating wall distances. Each ray represents a "line of sight" from the player’s position in a specific direction. As each ray moves forward, it checks for wall intersections on the map grid. We display different wall heights based on distance to give a depth illusion. The closer a wall is, the taller it appears. As the player moves around and rotates, the 3D render updates, showing only what the player "sees" based on the rays cast.
The project requires understanding vectors, trigonometry, and distance calculations. Before we dive into the math, let's go over a few important concepts
defines how wide the player's visible world is in terms of angles. A wider FOV means fewer rays but a zoomed-in view.
The direction the player is facing, crucial for determining where rays are cast.
The angle for each individual ray cast relative to the player's position, calculated based on the player angle and FOV.
Since walls are aligned with grid cells, we implemented the DDA Alorithm that only checks for walls at grid intersections, allowing us to optimize wall hit detection. The algorithm determines the distance from the player to the wall by stepping through the grid either horizontally or vertically, depending on which direction the ray is moving.
- Calculate the initial side distances (side_dist_x, side_dist_y), which represent the distance from the player to the nearest grid boundary in both the X and Y directions.
- Calculate the step size that represent the distance the ray has to travel along each axis (X or Y) to move from one grid line to the next. Use the ray’s direction and step size (delta_dist_x, delta_dist_y) to increment the ray’s position step-by-step until it intersects a wall.
- Once a wall is hit (grid value equals '1'), we calculate the exact intersection point between ray and the grid by determining whether the ray crosses a vertical or horizontal grid line first, adjusting for the player's position and the ray's direction to find the precise coordinates. Finally, we calculate the distance from the player to the wall at the intersection point, first using the Pythagorean theorem, then refining the distance by adjusting for overshoot caused by stepping past grid lines.
If you have any feedback, feel free to reach out to the authors.
| Team |  |
 |
Responsibilities |
|---|---|---|---|
| Jasmin Nguyen | @JasminNguyen | jasnguye@student.42.fr | maths, rendering, QoL features, performance optimization |
| Milos Tadic | @mitadic | mitadic@student.42.fr | map parsing, minilibX integration, testing, visuals |
We thank our peers of 42 Berlin for their limitless drive for discovery and for their rigor and precision in providing feedback. We are likewise grateful to 42 Berlin itself for fostering a culture of inclusive excellence.