GN⁺: Bash에서의 Raycaster 구현

왜 이것이 어려웠는가

• Bash의 속도 문제: Bash는 매우 느려서 픽셀당 명령을 실행하면 적절한 프레임 속도를 달성할 수 없음. 화면 상태를 메모리에 유지할 수 없으며, 배열이나 문자열로 접근하는 데 시간이 많이 소요됨.
• 수학적 제한: Bash는 부동소수점 지원이 없고 수학 함수 라이브러리도 없음. 모든 수학 연산은 정수로 수행되며, 100000으로 스케일링됨.
• 터미널 그래픽 문제: 픽셀을 표현하기 위해 유니코드 반 블록을 사용하여 수직 해상도를 두 배로 늘림. 인접 픽셀의 색상을 알아야 하며, Bash는 상태를 저장할 수 없음.
• 기타 문제점:
  • 터미널 전체를 한 번에 업데이트하는 것이 어려움.
  • 대부분의 터미널은 비디오 게임을 위한 것이 아니며, 키 입력을 실시간으로 처리하기 어려움.
  • 터미널을 색상으로 채우는 데 많은 데이터가 필요함.
  • Bash는 여러 줄의 문자열을 한 번에 출력하지 않음.
  • ECMA48, VT100, VT200, Xterm 등의 표준은 복잡하고 이해하기 어려움.
  • 수학적 계산에 어려움이 있었음.

FAQ

• Q: 창 크기를 조정하면 문제가 발생함
  • A: 이슈를 열어주세요.
• Q: CPU가 과열되거나 오래된 컴퓨터가 느려짐
  • A: 환경 변수 FPS를 30 미만으로 설정해 보세요.
• Q: Bash 버전 5 미만에서 작동하지 않음
  • A: 맞음.
• Q: 이 코드가 순수 Bash인가요?
  • A: 아닙니다. 시작 시 stty를 호출하여 에코를 비활성화하고 종료 시 다시 활성화함.

[neo]

Hacker News 의견

• 이 게임은 실제로 3D가 아니기 때문에, 각 열마다 한 번만 레이 트레이싱을 실행하여 픽셀을 그리는 방식이 매우 영리함

  • 하늘, 풀, 실제 객체를 그리기 위해 필요한 만큼 "이 픽셀을 그리고 아래로 이동" 문자열을 반복하여 터미널에 출력함
  • 다른 제한된 환경을 위한 복셀 렌더 엔진 작업을 고려 중이며, 이 프로젝트에서 유용한 것을 찾을 수 있을 것 같음

• MS Batch로 작성된 레이캐스터가 있는지 궁금하다면, GitHub 링크를 참고할 수 있음

• Bash는 느리기 때문에 스크립팅이나 대화형 사용에 적합하지 않다고 생각함

  • 일부 인기 있는 Linux 배포판도 Bash를 스크립팅 셸로 사용하지 않음

• stty가 포크를 요구하는 것이 아쉬움

  • 다음 프로젝트에서는 Bash와 rowhammer를 사용하여 포크 없이 필요한 ioctls를 호출하는 방법을 찾을 수 있을 것임

• 여전히 매우 느린 셸을 사용하는 것이 이해되지 않음

  • 대부분의 앱은 stdout과 err에 쓰기만 하면 되므로, 텍스트를 더 빠르게 화면에 출력할 수 있어야 한다고 생각함

• Bash로 이런 것이 가능하다는 것을 몰랐음

  • Bash에 능숙하다고 생각했지만, 이 구현은 놀라움
  • 수학적 이해는 부족하지만, 보는 것만으로도 즐거움

• 9년 전 awk 레이캐스터도 언급할 가치가 있음

  • GitHub 링크를 통해 확인할 수 있음

• 이 프로젝트를 실행할 수 없어서 아쉬움

  • 이유는 모르겠지만, 뷰가 buffered라는 파일에 저장되고 즉시 종료됨

• 코드가 300줄밖에 되지 않아 인상적임

  • 이 프로젝트가 마음에 듦

• 이 도전은 정말 대단함

  • 가능하다는 것이 믿기지 않음