'분류 전체보기'에 해당되는 글 413건

10년전만해도 이게 뭔 뚱딴지같은 소리냐 했을텐데 2025년 지금은 AMD만큼 리눅스 지원이 잘 되는 제품이 없습니다.

과거엔 인텔이 최고였고 ClearLinux라는 인텔에서 직접 만든 배포판도 있을 정도였지만 지금 인텔의 상태가 말이아니기에 리눅스관련 직원들이 해고되었다는군요. 실제로 몇몇기능은 커널에 구현되다 말았고요.
(이러다 제온이 리눅스 서버시장에서 조차 밀리는거 아닌가 싶습니다)

AMD는 이와 반대로 리눅스 지원이 좋아지다못해 최고의 성능을 발휘하는 OS와 CPU가 되었습니다. 특히 쓰레드리퍼나 에픽을 쓸때 윈도우에 비해 리눅스의 성능이 정말 굉장하지요.

거기다 스팀덱출시 이후 라데온에서 리눅스의 Vulkan성능이 대폭 좋아져서 윈도의 라데온과 비교해 성능을 더 뽑아내고 있습니다. 심지어 Nvidia의 DLSS와 다르게 AMD는 비슷한 기능인 FSR도 네이티브로 돌리지요.

10년전만 하더라도 리눅스 데스크탑은 인텔CPU에 인텔그래픽이 진리였습니다. 성능문제는 둘째치고 안정성면에서 문제가 심했거든요. 만약 3D를 원한다면 Nvidia카드를 박아서 Nvidia의 독점드라이버를 설치해야했고요. 물론 그래도 안정성은 충분했습니다. 커널버전에 따른 호환성은 있었을지언정 드라이버만 설치되면 쓰는데는 지장이 없었으니까요.

그런데 AI의 대두이후 Nvidia의 드라이버는 CUDA를 위시한 컴퓨트성능위주로 흘러가게 되었고 Vulkan과 OpenGL성능이 나락으로 가기 시작했습니다. 언제부터인가 Vulkan의 지원되는 수준이 떨어지고 강점이었던 OpenGL의 안정성조차 떨어지더군요.

인텔은... 그때나 지금이나 바탕화면 표시기...였지요.

그런데 스팀덱에 AMD칩셋이 쓰이고 AMD가 Vulkan에 투자하면서 이야기가 달라지기 시작했습니다.
Doom Eternal만 해도 Vulkan버전으로 돌리면 AMD그래픽카드에서 성능이 배로 좋아진다고 하지요. DirectX나 OpenGL성능이 경쟁사에 비해 떨어지니 최신API인 Vulkan에 투자한듯합니다.
그런데 그게 스팀덱에서 꽃을 피운듯합니다.

그리고 AMD의 드라이버는 (완벽한건 아니지만)오픈소스입니다. amdgpu라는 이름으로 공개되어있습니다. 커널에 직접 반영도 되고 덕분에 Wayland지원도 빨랐습니다. 그러다보니 사용자가 늘어날 수록 안정성이 좋아지는 경향이 있는데(버그리포트가 그만큼 많아지므로 생각지못한 패닉이 줄어듭니다) 스팀덱으로 인해 AMD그래픽사용자가 늘어나자 안정성이 급격히 좋아지기 시작했습니다.

최근 제 Debian시스템을 기준으로 Nvidia 1660에서 돌아가지 않던 게임이 RX570에서 돌아가는것을 확인했습니다. 원인은 Vulkan드라이버였습니다. FSR이 켜지면서 프레임이 좋아진건 덤입니다.

10년전엔 그렇게 라데온 욕을 퍼부었는데 지금은 칭찬하는 제 모습을 보니 그것도 참...

lsfg란 기술이 있습니다.

스팀에서 일명 "오리"라고 불리는 프로그램의 프레임생성 기능을 의미 합니다.

정식 명칭은 Lossless Scale Frame Generation 입니다만 다들 그냥 오리라고 부릅니다.

이는 원래 윈도우에서 쓰이는 FSR이나 DLSS를 편하게 쓰기위한 기술이었습니다만 LSFG라는 기술을 개발해 기존 그래픽카드의 종류와 상관없이 어디서든 사용이 가능한 프레임 생성 기술이 만들어졌습니다.

다만 이건 어디까지나 윈도우 전용이었고 리눅스에선 Proton에서 돌리는 뭔가 이상한 방식이었습니다.

그러다 https://github.com/PancakeTAS/lsfg-vk

lsfg-vk라 하여 Vulkan을 네이티브로 돌리는 LSFG 포팅이 이루어집니다. 주로 스팀덱 같은 UMPC에서 이루어진다고 하며 우월한 성능의 SteamOS에 힘입어 유용하게 돌아가고 있습니다.

이걸 일반 리눅스PC 에서도 이용이 가능합니다.

https://github.com/PancakeTAS/lsfg-vk/wiki/Installation-Guide

여기에 설치 가이드가 있습니다. 미리 빌드가 된 deb을 이용할 수도 있지만 저는 그냥 빌드를 했습니다. 아무래도 아직 활발히 개발중인 물건이다보니 그냥 빌드하는게 더 낫겠다는 생각이 들더군요. 무슨 AUR쓰는 기분이지만 그냥 제 기분이 그렇습니다.

이렇게 하면 /usr/local에 설치가 됩니다.

이제 GUI를 설치합니다.

/usr/local/share/vulkan/implicit_layer.d/

그리고

"library_path": "liblsfg-vk.so",

이 부분을

    "library_path": "/usr/local/lib/liblsfg-vk.so",

이렇게 고칩니다.

그리고 Ctrl+O를 눌러서 저장하고 나갑니다.

이제 

lsfg-vk-ui

명령을 통해서 UI를 불러와 봅시다.

이렇게 하면 설치가 완료 된 것입니다.

Steam에서 Lossless Scaling을 구매후 설치까지 하시면 이제 세팅이 완료 됩니다.

이제 제일 핵심인 Lossless Scaling을 설치합니다.

vkcube를 통해 프레임이 얼마나 늘어났는지 확인해봅시다.

(사실 vkcube만으로는 딱히 얼마나 늘어났는지는 감이 안 옵니다. 직접 게임을 하나 실행하는게 제일 편합니다.)

vkcube를 실행해서 돌아가는 속도를 확인 한 다음

DISABLE_LSFG=1 vkcube

를 했을 때 4배정도 더 빠르면 적용이 완료 된겁니다.

만약 차이가 없다면 적용이 안 된겁니다.

Path to Lossless.dll을 고쳐주시면 됩니다. 스팀 기본 설치시

~/.steam/steam/steamapps/common/Lossless Scaling/Lossless.dll

여기입니다. 실제로는 조금 다를 수 있으니 직접 스팀에서 확인 후에 지정하시면 됩니다.

lsfg-vk-ui를 실행해서 창을 띄워놓고 게임을 같이 실행합니다.

여기서 Create New Profile을 클릭하면

새로운 프로파일이 생성 됩니다. 오른쪽 profile name의 돋보기를 클릭하면

현재 실행되고 있는 프로그램 리스트가 쫙 뜹니다. 여기서 게임의 프로세스를 클릭합니다.

여기서 원하는 만큼 설정해주시면 됩니다.

이런식으로 게임별로 LSFG를 설정해서 사용하시면 됩니다.

삭제 방법은 

그리고 재부팅입니다.

이제 안 됩니다...

파일을 수정하면 넥슨 안티치트가 변조를 의심하며 작동 안 되게 바뀌었습니다. 이제 한국어ED를 쓸 수가 없게 되었습니다...

아쉽지만 어쩔 수 없지요. 사실 이게 맞는거고 그동안 마음대로 수정이 가능했던게 이상했던 것이었습니다.

다만.... 용하야 이제 좀 그냥 한국어판 정식으로 적용 좀 해줘라..

=========이전에 가능했던 시절의 글 ===================

블루아카이브라는 게임이 있습니다.

분명 모바일 게임이지만 PC용 클라이언트가 존재합니다. 스팀으로 제공되기에 리눅스에서도  아주 잘 실행 됩니다. Proton9.0이상이기만 하면 잘 됩니다. 안티치트도 넥슨 자체 제작을 사용해서 스팀덱을 지원하는거 같더군요.

대충 이런 게임입니다만

그냥 흔한 미소녀 가챠 게임입니다.

하지만 특이하게도 넥슨에서 만들고 일본에서 먼저 서비스해서 뭔가 일본어로 된 환경이 자주 나옵니다.

그렇기에 한국어로 더빙까지 진행 헀음에도 일본어로 된 엔딩들이 일부 나옵니다.

그런데 넥슨에서는 이미 주요 엔딩이나 인게임 뮤직비디오를 한국어로 더빙해서 공개해놓았습니다. 심지어 한국어 OST까지 만들었지요. 그런데 정작 인게임에는 적용이 안 되었다는게 많이 안타깝더군요.

하지만 PC버전의 장점이 뭐겠습니까? 게임의 수정이 쉽다는 것입니다. 조금 뒤져보니 음원들을 ogg형태로 쉽게 교체 가능하게끔 된것을 확인 했습니다.

 블루 아카이브 PC 버전은 인게임 비디오도 mp4로 되어 있어서 바로 볼 수 있는 구조였습니다.

그래서...

직접 한국어 OST버전으로 교체해봤습니다.

처음보시는 분들은 뭐가 달라진게 있나 싶으실텐데 원래 인게임은 일본어로 된 음원이 튀어 나옵니다. 특히 아래 시즌1의 엔딩은 딴 사람도 아니고 윤하가 부른 버전이기에 게임에 적용되지 못한게 아쉽더군요. (자세히 보면 가사도 위 영상과 다르게 음원과 똑같이 나옵니다.)

적용 방법은..

스팀판에 한해서 가능합니다. (모바일은 별도의 루팅등의 방법 없이는 불가능)

스팀 라이브러리에서 블루아카이브에 오른쪽 버튼을 눌러 속성에 들어갑니다.

설치된 파일에서 찾아보기를 눌러서 게임이 설치된 곳의 탐색기 창을 띄웁니다.

그 다음

위의 파일을 다운로드 받아서 해당 위치에 압축을 풀어 덮습니다.

만약 원래의 일본어로 되돌리고 싶다면 속성에서 무결성 검사를 한번 하시면 됩니다.

적용된 에피소드는

1. 메인스토리 최종전 Final 에피소드 ED

2. 메인스토리 무장 호시노 에피소드 ED

3. 이벤트스토리 방과후 디저트부 밴드 MV

4. 이벤트스토리 시스터즈 아이돌 MV

5. 이벤트스토리 드레스 히나 MV 및 ED

모든 음원의 저작권은 넥슨게임즈에 있습니다.

그러니까.... 이걸 인게임에 제대로 적용해달라고....

어떤 사람은 이렇게 이야기합니다.
"남 좋은일해서 뭐하냐"

어떤 사람은 또 이렇게 이야기합니다.
"돈도 안되는걸 하고 있네"

보통 이쪽은 하나도 모르는 수많은 꼰대들이 이런식으로 이야기하곤 합니다. 대부분 이렇게 이야기하는 사람들은 돈만보고 살아왔거나 자기자신만 아는 경우가 많습니다.

그런데 다들 알다시피 오픈소스는 수많은 기여자들의 취미활동으로 많은 수가 굴러갑니다. 솔직히 저 사람들 입장에선 이해가 안 될겁니다. 그런데 "성취감"이라는게 뭐라 형용할 수없는 중독성을 지니고 있습니다.

특히 내가 기여한 무언가가 다른 누군가에게 유용하게 쓰이고 있을때의 그 기분이란...

거기다가 보통 오픈소스프로젝트에는 한줄이라도 코드에 기여했거나 그냥 UI용 아이콘 하나라도 만들어주면 Thanks To에 이름이 올라갑니다.
영화 끝날때 크레딧에 내 이름이 써있다고 생각해보세요. 그리고 심지어 사람들이 작품을 칭찬한다고 상상하면 난 거기에 모래알만큼 기여했지만 어찌됐건 기분이 좋습니다.

=================================

솔직히 오픈소스에 기여하는건 어렵지 않습니다. 심지어 프로그래밍을 못 해도 충분히 기여가 가능합니다. 많은 프로그램들은 전세계에서 만들어지다보니 수많은 언어지원이 어렵습니다.

프로젝트관리자가 기여자들이 가져다주는 코드들 중 제일 쌍심지켜고 환영하는게 번역물입니다. 왜냐하면 그 사람들은 최소 영어와 자국어외에는 모르거든요. 번역기를 쓰면 당연히 번역투로 나오기 때문에 엉망이라는건 본인들도 아주 잘 알고 있습니다.

그런데 갑자기 특정언어권 사용자가 직접 번역해서 가져다주면 그렇게 좋을 수가 없겠지요. 아마 바로 다음버전에 적용해줄 가능성이 높습니다.
"사용자층 확대"
"모국어 사용자라는 신뢰"
"번역을 기여할 정도로 내 작품을 쓰는자의 물건"

이 세가지 측면에서 좋은 기여가 없습니다.

개발자들은 번역된걸 쓰는경우가 적은편입니다. 보통영문판을 선호하지요. 하지만 보통의 한국인은 다릅니다. 기왕이면 한글판을 선호합니다.

저부터도 첫 오픈소스 기여가 번역이었습니다. 20문장 남짓이었지만 다음날 바로 적용해서 업데이트까지 해주더군요. 그리고 몇년이 지난지금 그 프로그램사용자들이 제 번역을 기준으로 사용법을 공유하고 있습니다.

이건 뭐라 형용할 수 없는 기분입니다.

Debian 최신 버전에서는 저장소 리스트를 관리하는 방식이 새롭게 바뀝니다.

일명 DEB822라고 불립니다.

이게 뭐냐면

/etc/apt/sources.list 파일을 이용해서 저장소를 설정 할 수 있습니다.

보통은 

요런 구조로 되어 있던 것을

/etc/apt/sources.list.d/debian.sources

요렇게 만들어서 여러줄로 쓰는 걸 말합니다. 어느정도 업데이트 하다보면 이런 방식으로 바꿀건데 진행할거냐고 물어봅니다. 저야 뭐 그냥 시키는대로 하는 편이라 그러라고 했더니 기존 sources.list파일을 백업하고 sources.list.d/debian.sources 파일을 위와같이 만들더군요. 물론 구글크롬 저장소와 MS VSCODE 저장소도 이런 식으로 바꿨습니다. 다만...

APT 업데이트를 할때마다 이런 오류가 뜹니다. 보통 이런 오류는 기존 list파일에서

요런식으로 arch=amd64를 적는 것으로 해결 할 수 있었는데 새롭게 바뀐 sources 파일 방식은 어떻게 해야할 지 감이 안 오더군요.

뒤져보니 https://repolib.readthedocs.io/en/latest/deb822-format.html

답이 여기 있더군요.

이걸 제일 아래에 적는 것으로 해결 가능하다고 합니다. 이게 없으면 기본 설정(i386, amd64 같이 사용)으로 설정 되는 것이고요.

VScode 같은 경우에도 이런식으로 적어주니 오류가 사라졌습니다.

아무래도 이 방식이 과도기다보니 문제가 좀 심하네요...

OpenRCT2 지금도 이리저리 손 대보고 있습니다.
소스가 공개되어있다보니 별의별걸 다 해볼 수 있더군요.

그러다 한가지 생각난게 있는데 openrct2-cli란게 있습니다. 이건 서버구축을 위해 만든거에 가까운데 게임자처는 돌아가도록 되어 있습니다. 콘솔명령을 내리면 실제로 공원에 적용이 되고요.

그렇게 생각해본게 그럼 이걸 띄우고 별도의 프론트엔드를 띄운다면 RCT2특유의 그래픽과 완전 별개인 그래픽으로 게임이 가능한거 아닌가? 라는 생각이 들었습니다.

실제로 비슷한 프로젝트가 있었습니다.
OpenRCT2-Unity
OpenRCT2를 내부에서 라이브러리 형태로 실행하고 Unity로 만드는 프로젝트입니다. Unity이기에 3D로 구동되는데 롤러코스터 타이쿤3 느낌이 납니다. 즉, 내가 만든 공원을 3D로 돌아다니는 것이지요.

근데 이 프로젝트는 현재 멈춰있습니다. 그게 딱히 기여자도 없고 흥미본위에 맞춰져 있었으니까요.

그런데 조금만 더 생각해보면 이야기는 조금 달라집니다. Unity든 Unreal이든 유명 게임엔진에 이걸 붙이면 디아블로2 리저렉션처럼 만들수 있다는 이야기가 됩니다.

OpenRCT2는 픽셀이 튀는 문제가 있습니다. FHD를 넘어 4k모니터가 보급되다보니 생기는 문제인데 기존 2D이미지를 뜯어고쳐서 고해상도로 올리고 프론트엔드처럼 만들면 고해상도로 충분히 게임이 가능해질 수 있습니다.

비슷하게 모바일버전인 롤러코스터 타이쿤 클래식의 경우 각 기기들의 해상도가 미친듯이 올라가다보니 픽셀튐과 색상이 더러워지는 문제가 생겼는데 이걸 OpenRCT2와 프론트엔드로 해결 할 수 있을지도 모릅니다. 그리고 프론트엔드에 따라 지금은 구동이 불가능한 iOS에서의 구동도 생각해볼 수 있습니다.

직접 현재 OpenRCT2를 뜯어서 고해상도에 맞추면 되지않냐고 생각할 수도 있습니다. 실제로 몇몇 옵션이 그걸 감안하고 생성되어 있습니다만 언제 완성될지 모릅니다. 그리고 전 그 때 그 감성도 좋지만 최신감성도 나쁘지 않다고 보거든요.
마치, 슈퍼마리오 메이커의 그래픽 스타일 변경처럼요.

일단 기존 OpenRCT2의 Viewport를 다른 게임엔진으로 들고오는것부터 생각해봐야겠네요.

PC프로그램의 상당수가 모바일로 이식된지는 오래됐습니다.
MS오피스도 그렇고 포토샵도 핵심기능에 한해 포팅되어있지요. 한컴오피스는 특이하게도 PC버전같은 UI로 모바일버전이 있지요.

다만 모바일버전의 경우 여러요소가 고려되다보니 PC버전과는 궤를 달리하는 물건도 꽤 많습니다. 그리고 포팅할때 UI/UX가 가장 골치아픕니다.

첫째로 화면이 작다보니 버튼들이 꽤 큰편입니다. MS오피스처럼 적극적으로 도구상자들을 쓸 경우 가뜩이나 작은 화면의 상단을 잡아먹습니다. 그러다보니 PC버전과 다르게 두번세번 클릭하게 만드는 경우가 많습니다. 그래서 상황에따라 필요한 도구상자를 띄우는 방식을 쓰거나 따로 기능메뉴 버튼을 만든뒤 기능을 메뉴에서 일일이 선택하는 방식을 씁니다. 이게 UX면에서 답답하게 만드는경향이 있어서 지금도 어떻게 하는게 좋을지 고민하게 만듭니다.

둘째로 마우스 동작방식이 다릅니다. 모바일은 기본적으로 마우스가 없습니다. 터치스크린이라는 조작계 하나뿐이지요. 그래서 커서가 버튼위에 있는 Mouseover상태가 없습니다.

옛날 프로그램의 경우 이 MouseOver상태를 상정하고 만든 경우가 꽤 있습니다. 이런경우 모바일로 넘어올때 해당기능이 골때립니다. 보통 이런경우 한번 터치(혹은 클릭)시 MouseOver에 해당하는기능이 나타나고 같은 부분을 터치(혹은 클릭)시 본래기능이 동작한다거나 해야합니다.

셋째로 마우스는 버튼이 3개나 있지만 터치스크린은 화면터치 하나 뿐이라는겁니다. 즉, 기존 입력계 기준 "마우스왼쪽버튼을 누른다" 하나만 있을 뿐입니다.

다만, Windows8이후 OS차원에서 터치스크린을 지원하다보니 이쪽은 OS에서 마우스를 에뮬레이션 해주기도 하니 좀 낫습니다. 특히 길게누르면 마우스 오른쪽버튼으로 처리해주는걸 OS에서 해주지요. 그래서 모바일로 포팅된 앱들을 보면 짧게 터치하면 왼쪽버튼 클릭이고 길게터치하면 오른쪽버튼 클릭되게끔 만들곤 합니다. 애초에 Windows에서 그렇게 해주니 똑같이 구현하는겁니다. 하지만 안드로이드나 iOS는 에뮬레이션 그런거 없으니 알아서 구현해야합니다.

넷째로 역시 터치스크린때문인데 스크롤 구현을 위해 "클릭"이라는 동작의 타이밍이 다릅니다. 이게 무슨소리냐면 MouseDown과 MouseUp의 차이인데, MouseDown은 마우스 버튼이 눌릴때, MouseUp은 마우스버튼이 눌렸다 떨어질때를 말합니다.

모바일이나 터치스크린은 "길게누른다"와 "스크롤 드래그"를 적극적으로 쓰기 때문에 PC에서 쓰던 "클릭"이라는 타이밍이 무조건 MouseUp상태가 되는 순간입니다. 만약 MouseDown때 기능이 동작한다면 "길게누르기"와 "스크롤 드래그"기능을 쓸 수가 없겠지요.

최근에 나오는 대다수 UI라이브러리의 경우 "Click"과 "MouseUp", "MouswDown"을 철저히 구분합니다만 옛날프로그램은 MouseUp과 MouseDown뿐이었습니다. 그래서 버튼을 클릭시 MpuseDown에다가 구현하는 경우가 꽤 있었고 이를 모바일에 포팅할때 애먹게 만들곤 했습니다. 그래서 입력기기에 따라 알아서 판단하는 "Click"이라는 상태가 하나 더 추가 됐습니다. 그래서 최근 라이브러리를 가져다가 Click에다가 구현하면 PC와 모바일 둘 다 해결가능합니다만 이미 만들어진 프로그램을 최신 라이브러리에 맞추는게 쉬운일은 아니겠지요. 그리고 모든 UI라이브러리가 다 그렇게 만들어진것도 아니고요.  (여전히 MouseUp과 MouseDown만 있는 라이브러리도 꽤 많습니다)

아에 터치스크린의 입력상태와 마우스의 입력상태를 따로따로 구분하는 라이브러리도 있습니다만 이러면 고려할게 많아져서 코드가 길어지다보니 이쪽은 코더가 고생하게 됩니다.

다섯째로 상시 통신연결하는걸 자제해야합니다. 이건 무슨 이야기이냐면 PC는 대부분 유선으로 연결되었기에 통신을 수시로 하지만 모바일은 통신이 끊기는 경우가 잦아서 특정타이밍에 몰아서 하는경우가 많습니다. 미국같이 땅덩어리가 넓은 경우 고속도로가면 통신이 끊기는 경우가 꽤 있습니다. 이때 통신을 시도하면 할 수록 쓸데없이 배터리만 나갑니다. 그래서 이 부분을 손 봐야합니다. 역시 최근 라이브러리는 이런걸 감안하지만 문제는 옛날 프로그램이지요.

최근 OpenRCT2의 안드로이드버전을 손보면서 느낀걸 이야기해봤습니다. 이쪽은 SDL을 쓰면서 UI라이브러리 따로 쓰지 않아 지금 한창 애먹고 있는중입니다. 뭔가 하나 구현하면 다른게 터지는 등의 문제가 심해서 그냥 다 뜯어서 처음부터 입력쪽을 다시 구현할까 고민중입니다.(...)

옛날에 구해다 놓았던 SATA SSD를 써먹기 위해서 이번에 싸게 SATA USB 엔클로저를 구매했습니다.

대충 이렇게 생긴 상자에 담긴 엔클로저인데 매뉴얼이고 뭐고 아무것도 없습니다. 다만 한가지 알 수 있던건 Orico사의 엔클로저의 짝퉁이라는것.

Orico제품이 워낙 좋다고 하니 이것에 대한 짝퉁이 만들어 진듯 합니다. 다만 Orico제품은 VIA 칩셋을 이용한 반면 이 제품은 JMicron의 칩셋을 이용했습니다. 사실 두 칩셋다 괜찮기로 유명한 물건입니다.

그런데..

무슨 이유인지 SSD가 드라이브로 인식이 되지 않습니다. 그래서 혹시나 하고 HDD를 꽂아보니 이건 또 인식이 되더군요. 그런데 JMS578칩셋이 SSD 인식이 잘 된다고 보통 이야기 하거든요. 그래서 혹시나 하고 펌웨어 문제인가 하고 찾아봤더니...

https://github.com/russinnes/jMicron-JMS578-Firmware-Linux/raw/refs/heads/main/JMicron%20JMS578%20Sata%20Crystal%20Enclosure%20FWUpdate.zip

뭔가 엄청나게 펌웨어가 많습니다.

의외로 Odroid라고 적힌게 있는데 하드커널에서 수정한 펌웨어라고 합니다. 아마도 Odroid에서 쓰기위해서 따로 만든 펌웨어 같은데 (여긴 별명이 취미로 소형 컴퓨터를 만드는 한국업체입니다.) 이걸로도 해보고 막 바꿔가며 해본 결과...

여기 있는 것중 구버전 v00.04.00.05 (선택된것이 아닌 Bus Power+ ODD가 적힌 펌웨어)로 바꾸니 이게 왠걸...?

갑자기 SSD가 인식이 됩니다.

어이가 없더군요. 이게 JMicron에서 제공한 표준 펌웨어 였고 여타 다른 업체에서 펌웨어 수정을 통해 별의별 작업을 해놓았나 보더군요. 그게 도리어 호환문제를 일으켰고 펌웨어를 계속 바꾸다보니 인식이 됐습니다. 이게 문제가 좀 있다고 하는데.... 그래도 일단 동작은 해야 뭘 쓰던가 말던가 하죠...

암튼 덕분에 고생좀 했습니다.

그런데 뭔가 좀 궁금해졌습니다. 다른 펌웨어는 어떨까?

그래서 작동이 되지 않던 1XX나 하드커널 펌웨어가 아닌 다른 펌웨어를 한번 해봤습니다.

JMS578_Beihuan_v68.01.00.02.bin

RD Version 체크하고 Inculde JMS577 NVRAM까지 하고 돌려봤습니다.

....? 이건 인식이 또 되네요?

이게 아마 UASP지원 펌웨어라고 알고 있는데 갑자기 뭔가 잘 되니까 또 이상한 기분....

일단 잘은 몰라도 뭔가 되기는 됐습니다.

OpenRCT2는 롤러코스터 타이쿤2를 리버스 엔지니어링해서 만들어진 프로젝트입니다.

리버스엔지니어링은 거의 완벽한 수준이고 플레이에도 전혀지장이 없습니다. 그리고 으레 그렇듯 소스가 공개되어있기에 이런저런 능력자들이 힘을 쓰고 있습니다.

대표적으로 한국어 지원문제가 있었는데 한국인 기여자분께서 TTF폰트 지원을 기여해 나눔고딕같은 폰트를 쓸 수 있었습니다. (대신 좀 config설정이 필요했습니다.)

그런데 안드로이드에선 한글이 나오지 않더군요. config의 위치를 파악하고(/sdcard/openrct2-user) 고쳤음에도 폰트를 읽지 못하는듯 싶었습니다.

https://github.com/OpenRCT2/OpenRCT2/issues/21634

이미 이슈가 되어있었는데 자세히보니 Android빌드에서 GetFontPath를 사실상 안 하더군요. 아니 애초에 불가능한듯 했습니다.

이슈 아래를 읽어보니 assets에 직접 ttf를 넣고 이걸 강제로 읽는건(그러니까 그냥 절대경로 리턴) 어떠냐는건데 나눔고딕이나 Noto sans cjk같은걸 넣으면 딱이긴 합니다.

그런데 그 뒤에 아무소식이 없는걸보면 아무래도 잘 안 됐나 봅니다. 그도 그럴게 freetype이 일단 적용되어야하고 또 그게 잘 된다는 보장도 없거든요.

차라리 g2.dat에 있는 폰트 스프라이트를 개조해서 한글 2000자 남짓을 넣는게 더 빠를지도 모르겠습니다.

그나저나 골때리는걸 보면 기여자는 기여자대로 적고 소스도 이해가 잘 안되니 이거야 원...

일단 안드로이드 버전빌드 환경부터 갖추고 직접 해보죠 뭐.


-----------------------소스코드 확인결과------

기본적으로 안드로이드 버전은 NoTTF 옵션으로 빌드되게 되어있습니다.
즉, TTF가 적용이 안 되는 겁니다.

해당옵션을 제거하고 빌드해보니 FreeType관련 오류가 쏟아지는군요. 안드로이드 NDK용 Freetype과 PC에서의 Freetype은 조금 다른가봅니다.

선택지는 두가지입니다.
1. 안드로이드 freetype을 따로 빌드해서 TTF가 적용되게 한다.
2. 그냥 무식하게 한글 2038자 정도를 스프라이트 파일에 쑤셔넣는다. (참고 https://github.com/OpenRCT2/OpenRCT2/issues/13318)

위 방식을 쓰면 어쨌건 외부TTF를 이용해서 폰트를 쓸 수있게 되는거고 아래방식을 쓰면 무식하긴하지만 앞으로 한글 렌더링 걱정을 안 해도 되는 겁니다.

일단은 위 방식으로 해볼건데 안되면 일이 커지겠지만 아래방식으로 시도할겁니다.
 
 
========================2025.03.12========================
 
한글 성공했습니다.
Freetype이 전혀 적용이 안 만들어져 있는줄 알았는데 사실 안드로이드 빌드용 라이브러리에 freetype이 이미 있었더군요.
대체 왜 컴파일할때 안 만들어 넣었는지는 전혀 모르겠지만...
 
다만, 소스코드의 일부를 수정해야 했습니다. 현재 안정버전인 0.4.20 기준으로
 

 
/src/openrct2/platform/PlatformAndroid.cpp
위 파일에서 165번째 줄
std::string GetFontPath(const TTFFontDescriptor& font)

std::string GetFontPath(const TTFFontDescriptor& font)
{
    //STUB();
    //return {};
    return "/sdcard/openrct2/rct2.ttf";
}

이 함수를 이렇게 고쳐서 ttf파일의 경로를 강제로 지정합니다. 어차피 g2.dat를 넣기 위해서 /sdcard/openrct2 폴더는 만들어야 하니 그냥 여기에 넣으면 될겁니다.
저는 역사와 전통의 나눔고딕을 넣었습니다. 물론 rct2.ttf라고 파일명을 바꿔서요.
 
그리고
/src/openrct2-android/app/src/main/CMakeLists.txt
 
여기를 많이 고쳐야 합니다. 의외로 버그도 좀 있습니다.

193번때 줄
include_directories(SYSTEM "${CMAKE_BINARY_DIR}/libs/include/freetype2")
이렇게 된걸

include_directories(SYSTEM "${CMAKE_BINARY_DIR}/libs/include/freetype")

 
뒤에 2를 지우셔야 합니다. 빌드 될때 제일 오류가 많이 난 이유인데 빌드 폴더에 들어가보니 freetype2가 아니라 freetype 이더군요. 그래서 이 부분을 고쳤습니다.
 

 
그리고 197번째 줄 저는 주석 처리한 뒤에 아래에 새로 적었는데
add_definitions(-DDISABLE_DISCORD_RPC -DDISABLE_OPENGL -DGL_GLEXT_PROTOTYPES -D__STDC_LIMIT_MACROS -DNO_TTF -DSDL_MAIN_HANDLED)
 

add_definitions(-DDISABLE_DISCORD_RPC -DDISABLE_OPENGL -DGL_GLEXT_PROTOTYPES -D__STDC_LIMIT_MACROS -DSDL_MAIN_HANDLED)

 
-DNO_TTF를 지워줍니다. 이 부분은 NoTTF 빌드 옵션을 건다는 의미이므로 해당 옵션을 지워야 정상적으로 돌아갈겁니다.
 

 
그리고 제일 많이 괴롭힌건데 254번째 줄에

target_link_libraries(openrct2 android stdc++ log dl SDL2 png z icu icuuc icudata crypto ssl freetype)

ssl뒤에 freetype을 적어 줍니다. 이것때문에 또 왕창 오류가 났는데 알고보니 openrct2 메인라이브러리에도 freetype함수를 불러오게끔 되어 있더군요.
 
그리고 빌드 시 오류중 하나를 잡기 위해서
sudo apt install nlohmann-json
 
위 명령어로 nlohmann-json 패키지를 설치후에
/usr/include/niohmann 폴더를
src/thirdparty/niohmann으로 복사합니다. 이러니까 안드로이드 스튜디오에서 알아서 잘 인식하더군요.

 
그리고 안드로이드에 설치하는 법대로 알아서 OpenRCT2를 설치하고 실행하면..
폰트가 깨져 있을 겁니다.
이번에는 PC에서 했던 대로 config.ini를 수정해야 합니다.
스마트폰에서 openrct2-user 폴더에 들어가면 config.ini파일이 있습니다. 이걸 열고
[font]부분을 찾으면 죄다 비어있을 텐데 나눔고딕 파일을 openrct2/rct2.ttf 파일명으로 넣어놓고 다음과 같이 수정합니다.

출처 : https://telk.kr/tb/free/1599?category=53

 
다른 폰트를 쓴다면 저 수치는 또 변할겁니다. 하지만 PC에서와 같기에 인터넷 잘 뒤지면 수치를 찾을 수 있을 겁니다.
이제 안드로이드에서 OpenRCT2를 실행하면...

 
PC에서 보던 그 모습 그대로 뜨는 군요.

 
이제 안드로이드에서도 OpenRCT2를 한글로 즐기는 방법을 찾았습니다.
남은건... 수정소스를 PR 하는 것 뿐.

===============2025.3.20===========
이제 PR된 소스가 Approve되었습니다.
이제 안드로이드 버전에서도 한글로 된 인터페이스가 사용가능해질 예정입니다.

추가로 전 sdcard에서 ttf를 따로 넣는 방식을 썼는데 소스 리뷰어분이 시스템폰트를 쓸 수 있게끔 구현해주셨습니다. 즉, 좀 더 편리해졌습니다.

이제 터치인터페이스만 고치면 안드로이드에서 롤러코스터 타이쿤을 아무문제없이 쓸 수 있을듯 합니다.

프린세스 메이커3 한국어판은 총 3가지가 있습니다.
만트라판
후지쯔판
스팀판
 
현재 가장 구하기 쉬운 버전은 스팀판입니다. 다만 10명중 10명에게 물어보면 거의 다 스팀판 싫어합니다... 일본어 음성이라 별로인 것도 있고 옛날 추억삼아 하는 게임이라 그때 그 느낌이 아니라서 별로라는 군요.
 
대부분은 만트라판을 추천합니다만 이쪽은 또 호환성 문제가 많습니다. 16비트 코드를 요구하는 부분이 있어서 최신 OS에선 당연하다는 듯 제대로 안 돌아갑니다.
그래서 XP이후에 출시된 후지쯔판에 만트라판 데이터를 섞은 버전을 추천하는 편입니다. Winlator도 16비트 코드가 당연히 안 돌아가므로 32비트 코드로만 구성된 후지쯔판이 가장 잘 돌아갑니다. (만트라판이 안 돌아가는건 아닌데 뭔가 버벅거립니다.)
 
본래라면 당연히 직접 구하셔야 합나다만...
https://doogie838.tistory.com/1206

여기서 호환성패치와 기타 등등이 되어진 버전을 구할 수 있습니다. 암호가 걸려있다는 문제가 있는데 그건
https://nemo838.tistory.com/4494

여기에 써있으니 그걸 잘 이용하시면 됩니다.
 
저작권이 아직 멀쩡히 살아있는 게임입니다. 왠만하면 스팀판이라도 구매는 하고 해당 파일을 이용하도록 합시다. (저는 사실 이미 두가지 판본의 CD를 갖고 있습니다만 설치 후 융합하는게 귀찮은 관계로...)
 
위의 고전게임 배포 블로그에선 레지스트리와 버그픽스, 호환성 패치가 되어져 있으므로 일반 PC에선 아주 잘 굴러갈겁니다. 심지어 Wine에서도 잘 굴러갑니다.
 
다만 Winlator에서 굴리려면 추가 삽질이 동반됩니다.
우선 컨테이너는

Name은 알아서 잘 정하시고 Graphic Driver는 VirGL을 쓰겠습니다. 뭔가 이쪽이 오류가 덜 합니다.

Game Controller는 솔직히 다 필요없으므로 꺼주시는 걸 추천합니다. 컨테이너 설정은 이 정도면 됩니다.
 
 
그리고 게임도 미리 어느정도 PC에서 손을 본 다음 스마트폰에 설치합시다.
알아서 잘 해당 블로그에서 잘 다운로드 받아보면  _inmm을 통해 CD-DA패치가 되어 있으며 dgvoodoo를 통해 DDraw 호환패치가 되어져 있습니다. 이중 dgvoodoo를 무력화 할 것입니다. 이유는 VirGL에서 문제가 있거든요.
 

여기 보시면 ddraw.dll 파일이 있습니다. 이걸 파일명을 바꿔줍니다. 전 뒤에 .bak을 붙였습니다. 만약 DXVK를 꼭 쓰겠다고 하신다면 원래대로 다시 돌려주시면 됩니다.
 

 
그리고 위 파일을 다운받아 덮어 씌웁니다.
해당 파일은 오프닝 영상을 없애고 호환성 로더를 실행 시키기 위한 DLL파일과 실행파일에 직접 해킹을 통해 메시지박스를 제거한 버전입니다. 메시지 박스가 제거된 관계로 게임이 안 꺼지는 문제가 있는데 어차피 최신 OS에서는 제대로 종료가 안 되고 프로세스가 남아 강제종료 해야 합니다.

이렇게 하시면 게임은 준비됩니다. 이걸 스마트폰에 넣습니다.
 

 
스마트폰과 USB연결 후에 Download 폴더에 통째로 복사하면 되겠지요. 아니면 다른 방법을 통해 복사하시면 됩니다.
 
이제 Containers 에서 해당 컨테이너를 실행합니다.

이제 여기서 아까 넣은 폴더를 선택후에 C:로 복사합니다. D:에서 바로 실행도 가능하긴 한데 뭔가 오류가 있을 가능성이 있고 Android시스템과 꼬일 수 있습니다. 복사를 합시다.
 

 
이렇게 C:안에 복사를 해두면 실수로 다운로드폴더에서 지워버려도 남아 있게 됩니다.
이제 바로 실행!은 아니고 레지스트리를 입력해야 합니다.
 
시작 - system tools - Registry Edtiror를 클릭합니다.
 

 
레지스트리-레지스트리 가져오기
이후에 C:에 우리가 복사한 곳으로 가면 Doogie라는 폴더가 있습니다. 위 블로그 제작자분이 만들어둔 레지스트리 입력파일입니다. 이걸 입력해야 게임이 실행됩니다.
 

여기 보시면 파일이 4개가 있는데 파일을 하나하나 열기해서 입력해야 합니다.
 

성공적으로 추가되었다고 메시지가 뜨는데 이걸 한번씩 다 하세요. SetPathX.reg를 제외하고 총 3번 하시면 됩니다.
(SetpathX.reg는 윈도8이후 전용입니다. Wine에선 SetPath.reg만 해도 문제없습니다)
 
그리고 OS를 윈도우XP로 바꿉시다. 후지쯔판은 XP를 위해 만들어진 버전입니다. 따라서 XP로 해야 잘 실행되겠지요.

시작- System Tools - Wine Configuration
여기서

 
windows 버전을 WindowsXP로 바꿉니다.
그리고

 
데스크탑 종료를 해줍니다.
이제 컨테이너가 꺼질텐데 다시 실행하려고 하면 실행이 안 될겁니다. 아마 셧다운 되는데 시간이 걸려서 그럴겁니다. 조금 기다리거나 휴대폰을 그냥 껐다 켜는게 더 빠를 수도 있습니다.
 
이제 다시 Containers에서 다시 환경을 실행해 봅시다.
 
그리고 _PM3Win.exe가 있을 겁니다. 오리지널 프린세스메이커3가 아닌 검정색 아이콘입니다.
이 프로그램은 호환성을 위한 메모리 패치 및 강제종료시 프로세스가 남는 것을 감시하는 역할을 합니다. 즉, 최신OS에서의 호환 문제를 해결합니다.
 
이걸 실행해 봅시다.
몇번실행하다보면 어느 순간 실행이 됩니다.

 
그리고 위 스크린샷에 있는 위치즈음을 클릭 해보면 환경설정이 가능해집니다.

 
CDDA연주는 무슨이유인지 계속 오류가 나면서 귀찮아 지는 문제가 있습니다. 그렇기에 BGM을 꺼버리는게 동작하는데 가장 좋습니다.
다만 아래의 Winamp방식으로 바꿔서 재생하니 제대로 된 음악을 들을 수 있었습니다. 제일 아래 설정 참조. 다만 Winamp가 따로 돌아가다보니 휴대폰에 불이나려 합니다. 그냥 끄는게 정답일수도 있습니다.

그리고 화면 특수효과도 꺼주셔야 게임할때 안정적으로 돌아갑니다. 저게 켜지면 은근히 버벅거리더군요.

Winamp설정안하고 기본 (DirectShow방식)을 쓰면 아래처럼오류납니다. WMP가 문제인걸로 보입니다.

CD-DA가 되어야 배경음악이 나올텐데 이게 말을 안 듣습니다. 이것도 일종의 호환패치인데 아쉽더군요. 리눅스 PC에서는 따로 가상드라이브를 만들어서 해당 ISO파일을 넣는 방식으로 음악을 들었는데 Winlator에선 안 되니 아쉽네요. _inmm이 이용도로 나온건데 아쉽네요.(WMP를 설치하면 된다는 이야기도 있는데 안 해봤습니다.)

그래서 위에 호환패치에 이러한 설정으로 된 레지스트리를 포함했습니다.(BGM을 기본적으로 끕니다)

이제 이후에는 게임을 켤때마다 이런식으로 켜면 힘들겠죠?
바로 실행 가능한 아이콘을 만들어 봅시다.

 
_PM3WIN.exe 파일을 여기서 복사합니다. 그리고 Desktop 에다가 바로가기를 만듭니다.
메뉴에 보면 있는 Edit-Paste Shortcut을 누르면 됩니다.

 
 
이러면

햄버거 매뉴 - Shorcuts에 이렇게 아이콘이 뜨게 됩니다. 이걸 누르면 바로 실행이 됩니다. 이제 작은 마우스는 쓸 일이 없을 테니 터치스크린으로 교체를 하고 이를 위해 가상 버튼을 하나 만듭시다.
 

 
햄버거 버튼을 누르고 Input Controllers를 누릅니다.
 

 
그리고 여기서 추가로 더하기 버튼을 눌러서 가상버튼 프로필을 만듭시다.

우리는 여기서 PM3라고 했습니다. 그냥 이건 마음대로 하시면 됩니다.

 
Controls Editor를 눌러서 이제 버튼을 배치합시다.
이제 여기서 가로모드로 하는걸 추천합니다. 아마 저는 오른쪽 위나 아래에 뒤로 가기 버튼 역할을 할 수 있는 ESC버튼을 만들려고 합니다.

 
 
해당 화면에서 버튼을 만들고자 하는 부분을 먼저 클릭 한 뒤에 버튼을 누르면 None 이라는 이름의 동그라미 하나가 생깁니다. 이게 버튼 역할을 할겁니다. 이걸 이리저리 끌고 다니면서 위치 조정을 할 수 있습니다. 그다음 톱니 버튼을 누르면 여기에 어떤 기능을 부여 할 수 있습니다.

여기서 Binding에 ESC를 하나 만듭시다. 프린세스 메이커는 이거 하나만 있어도 됩니다. 나머지는 마우스 클릭이거든요. 빨리 넘기기 위한 CTRL 키를 만드셔도 되는데 저는 귀찮아서 넘기겠습니다.
 
그리고 Shorcuts로 실행 했을때 버튼과 해상도를 설정합시다. Shortcuts를 눌러서 다시 세팅을 추가로 합시다.
 
 

오른쪽의 점점점을 누른다음 Settings를 눌러서 손을 봅시다.

 
Screen Size를 960x544로 바꿉니다. 이유는 사실 640x480의 게임에 창테두리를 포함하는 크기입니다.
 
그리고 Win Components가 있는 부분을 오른쪽으로 땡기다 보면  Advanced가 있습니다.

여기서 Input Controls에 Profile을 아까 우리가 만든 PM3 프로파일로 바꾸고
아래 Simulate touch screen에 체크를 합니다.
 
이제 게임을 다시 실행해 봅시다.

이제 스마트폰에서 게임이 가능해졌습니다. 심지어 터치스크린이라 옛날과 또 다른 맛이 있습니다.
 
P.S 제가 올린 실행파일에서 메시지 박스를 제거 했는데 이게 일반 PC에선 문제가 전혀 없습니다. 그런데 winlator에선 메시지가 게임창 뒤로 넘어가서 게임이 안 넘어가는 문제가 있습니다. 그래서 그냥 메시지박스가 나오지 않도록 바이너리 패치가 일부 적용되었습니다. 이로인해 불안정해질 가능성이 없지않아 있습니다.
 
 
===============================25.3.10==============
배경음악이 안나오는건  _inmmserv.exe와 DirectShow가 문제가 생긴 탓으로 보입니다.
그래서 역사와 전통의 Winamp로 구동되게끔 조금 손을 대봤습니다.

이걸 프린세스메이커3가 설치된곳에 풀어서 덮어씌운다음 다시 실행하면 CDDA가 Winamp로 재생될겁니다.

위의것은 음질이 좋기로 유명한 프라운호퍼 디코더가 적용된 2.95버전입니다. 다만 WineGecko를 설치해야합니다.

아래는 HTML이 제거된 2.09버전입니다. 대신 음질은 애매합니다. 하지만 WineGecko가 필요없기에 조금더 가볍습니다.

우선 AudioDriver를 Pulseaudio로 바꿔줍니다.
ALSA는 한 프로세스가 독점하면 다른 프로세스가 접근할 수없는 문제가 있습니다. (대신 PulseAudio는 사운드 딜레이가 약간 있습니다)

그리고 NoHTML이 아닌 것을 적용하셨다면

시작-System Tools- Wine Gecko Install을 눌러 WineGecko를 설치하거나 그냥 Winamp폴더의 winamp.exe를 따로 실행해서 WineGecko를 설치합니다.

Winamp 2.95는 HTML을 요구합니다. 마음에 안 드시면 Nohtml버전을 쓰시면 됩니다. 대신 음질은 상대적으로 구립니다.

그리고 프린세스메이커3를 실행하고 환경설정에 들어갑니다.

여기서 CDDA로 바꿔줍니다.
이건 게임 실행때마다 바꿔주셔야합니다. BGM을 미리 활성화하니까 어찌된영문인지 게임이 멈추더군요. 그래서 이런방식으로 게임실행후 BGM을 활성화했습니다.

이제 거의 완벽해졌습니다!