ORN

이 게임은 스트라이커즈 1945 시리즈 중 유일하게 네오지오로 나온 게임으로, 전작들은 자체기판으로 돌아갔다. 그런데 네오지오는 본작 출시당시 출시 9년차에 접어든 다른 기기였으면 황혼기를 지나고도 한참 되었을 시기인데, 이 때문에 성능상 한계가 많았다.
우선 그래픽: 네오지오는 스프라이트 하나당 최대 16색만 지원하며, 이는 스트라이커즈 1945 2 이후에 쓰인 자체기판의 최대 256색에 비해 대략 16배정도 감소한 수치이다. 이때문에 네오지오에서 16색 이상의 그래픽을 표현하기 위해서는 스프라이트 위에 또 다른 스프라이트를 겹치는 방법을 사용해야 하지만 이 방법 또한 스프라이트의 최대 갯수(16x16-512 380개, 자체기판은 16-256x16-256 최대 896개. 이건 자잘한 스프라이트가 많이 필요한 상황에서 약점이 된다.)가 그만큼 줄어든다는 문제도 있고, 32색 이상을 표현해야 할 경우 255색 스프라이트 하나를 까는 것보다 표현 가능한 총 색상수에 비해 용량이 낭비된다는 문제가 있다. (256색(8비트) 스프라이트 1개(256색) = 8비트 vs 16색(4비트) 스프라이트 3개(48색) = 12비트) 대신 네오지오의 스프라이트는 각 타일 단위로 색을 바꿀 수 있어 잘만 활용하면 그럴싸하게 보일 수 있기는 하다. 하지만 알파 블렌딩을 네오지오에서는 아예 지원 자체를 안하므로 이 부분에 해당하는 요소는 어쩔 수 없이 빠졌다.
또 하나는 CPU. 자체기판에 달린 28.64MHz짜리 SH2에 비해 한세대 전급 성능을 가진 12MHz짜리 68000을 사용하며, 이는 성능 확보를 이유로 많은 부분을 희생시키는 원인이 되었다. 매 스테이지가 진행되는 동안 색상표를 바꾸지 않는다던가, 하드웨어적 확대/축소를 전혀 사용하지 않고 일일이 확대/축소된 스프라이트를 그래픽 ROM에 저장해놓고 필요할 때마다 바꿔쓴다던가, 일부 스프라이트의 크기가 줄어들었다던가, 탄속의 가,감속을 없앴다던가 하는 게 있다. 그럼에도 불구하고 화면에 너무 많은 오브젝트가 깔리면 간혈적으로 느려지기도 한다.
그나마 사운드는 Z80으로 따로 처리되는데, 이는 통짜 사운드 샘플을 재생, 반복하는 식으로 음악 루틴을 구성한 것을 빼면 사이쿄 초기 건버드에 쓴 것과 동일한 계열(Z80 계열 + YM2610 조합)을 사용한다. 이 경우 CPU 처리량을 줄일 수 있지만 반대로 각 샘플의 길이와 주파수만큼 ROM 용량이 늘어나는 부작용이 있다.
그 결과물은 그래픽 ROM 도합 64MB(512메가비트), 프로그램 ROM 도합 5MB(40메가비트), 샘플 ROM 도합 16MB(128메가비트)이 달린 카트리지에 담겨서 나왔으며, 이는 네오지오로 나온 모든 게임 중에서도 손꼽히게 많은 용량을 사용한 것이다. 이는 전작들보다 많은 용량이기도 하며, 대부분은 그래픽 위에 깔릴 그래픽용으로 할당되었으리라 짐작할 수 있다.
게임 자체는 나쁘지 않고, 시스템적으로 바뀐 부분도 존재하며, 전반적으로 1945 2에 기반하지만 상기한 이유로 스테이지 구성이나 심지어 나오는 보스도 바뀐 부분이 존재한다.

LZSS with Literal copy command
기반이 되는 LZSS 압축 알고리즘은 LZ77의 개량형으로, 압축이 필요하지 않은 부분(압축을 했을 때 오히려 압축 전보다 크기가 늘어나는 부분)은 단일 문자로 저장하도록 개선되었다. 이를 이진 파일에 적용할 경우, 단일 문자/오프셋, 길이 형식 토큰 여부를 설정하는 비트를 읽고 검사함으로써 이를 달성할 수 있다.
나는 여기에 더해 첫 바이트에 압축 여부 비트에 더해 문자의 갯수를 결정하는 비트를 추가함으로써 긴 비압축 문자의 표현을 효율적으로 할 수 있도록 하는 LZSS 알고리즘의 변형을 구상했다.
이것이 LZSSL 알고리즘이라 부르는 알고리즘이다.
이 알고리즘으로 압축한 결과물은 바이트 단위로 정렬되어 비트 단위 접근이 필요하지 않으며, 1비트 검사 비트가 첫 바이트의 최상위 비트에 할당되어 있고, 나머지 비트는 검사 비트의 결과에 따라 출력할 문자의 갯수 또는 복사할 문자의 갯수 + 복사할 문자의 위치의 최상위 비트들이 따라온다. (이 경우 다음 바이트는 이 위치의 하위 비트로 할당된다.)
이를 '토큰'이라 하며, 압축 결과물은 모두 토큰으로 구성되어 있다. 토큰의 구조는 다음과 같다.
- 첫 바이트의 최상위 비트: 검사 비트
- 검사 비트가 1(비압축 문자의 배열)인 경우, 나머지 7개 비트는 출력할 문자의 갯수를 의미한다. 이후 이 비트값 +1 만큼의 바이트가 따라오며, 이들은 압축 없이 출력할 일련의 문자를 의미한다. 또한 이들 문자는 슬라이딩 윈도우의 끝부분에 하나씩 저장된다.
- 검사 비트가 0(문자열 복사)인 경우, 뒤의 4비트는 복사할 문자열의 길이 + 3, 나머지 3비트는 복사할 문자열의 위치의 상위 3비트에 할당되며, 다음에 오는 바이트는 복사할 문자열의 위치의 하위 8비트에 할당된다. 이들 정보를 가지고 슬라이딩 윈도우에 있는 문자들을 복사해 출력한다.
- 따라서 본 알고리즘에서 사용하는 슬라이딩 윈도우의 크기는 2KiB(2의 11승)이다.
슬라이딩 윈도우는 처음에는 모두 0으로 초기화되어 0값의 배열로 시작하는 파일에 대한 압축 효율성에 도모한다.

또한 이 알고리즘의 변형으로 가변 길이 바이트 토큰을 사용하는 것도 있는데, 이는 각각 출력할 문자의 개수와 복사할 문자의 위치 값의 최상위 비트를 이들의 가변 바이트 플래그로 전용하여 더 큰 파일에 대한 압축 효율성을 꾀한다. 다만 이 변형은 파일이 어느정도 이상 클 경우에만 최대한의 효과를 발휘한다.

다음은 이 알고리즘을 ANSI C로 구현한 구현체이며, 기존에 존재하는 LZSS의 ANSI C 구현체의 포크임과 동시에 개조판이다.

https://github.com/cam900/lzss/tree/lzss_literal

복합 동기 (Composite sync)는 옛날 패미컴 시절부터 사용되었던 유서깊은 방식으로, 수직 동기 (VSync) 신호와 수평 동기 (HSync) 신호를 한 신호에 합성해 출력하는 것을 의미하고, 이 과정에는 주로 XNOR 게이트가 사용된다. 흔히 말하는 컴포지트 비디오는 이 신호에 더해 색상 신호 등을 한 신호에 합성한 방식이다.
유럽에서 주로 사용된 SCART 규격에는 채널별 색상 출력과 복합 동기 출력이 존재하며, 추가로 사운드 출력 핀이 달려있어 비디오/사운드를 한 단자로 해결되게 해놓았다.
일본의 RGB21 규격 역시 SCART 규격과 같은 단자를 사용하나 핀 배치가 다르다.
오락실 모니터 역시 VGA D-Sub 시대 이전까지는 SCART 규격처럼 채널별 색상 출력과 복합 동기 출력을 사용했으며, 이는 구 JAMMA 규격의 비디오 부분에 해당한다. JAMMA VIDEO STANDARD(JVS) 규격은 모니터에 따라 VGA D-Sub를 그대로 사용하거나 수평 동기 출력 부분을 복합 동기 출력으로 바꾼 방식이 존재하며, 하드웨어에 따라서는 이를 선택할 수 있게 해놓은 것도 있다.

게임메이커 스튜디오 2에서 실행할 오브젝트와 같은 depth값을 가진 오브젝트를 instance_create_depth 함수로 생성했을 때, 그리기 순서가 이상한 문제가 있다.
원래라면 depth 값이 같은 경우 나중에 그려진 오브젝트일수록 위에 보여야 하는데, 위 함수로 생성하면 depth 값이 같은 경우 나중에 그려진 오브젝트일수록 밑에 보인다는 것이다.
게임메이커 공식 매뉴얼에 따르면 depth 값을 직접 변경할 경우 이는 변경할 depth 값을 가진 임시 레이어를 생성한다는 내용이 있는 것으로 보아 이게 그리기 순서를 꼬이게 만드는 주범으로 추측할 수 있다.
가능한 해결 방법은 현재 오브젝트가 속한 레이어의 id를 구한 값(layer 변수)을 인자로 instance_create_layer 함수를 사용해 오브젝트를 생성하는 방법을 고려할 수 있지만, 확인해보진 못했다.

2026.01.06 수정: instance_create_layer도 동일한 문제가 발생한다.