좋은 여행자 되기

또는, 당신의 Allegro 프로그램이 이식이 쉽도록 유지하기

1999년 11월, Shawn Hargreaves.

이 글을 쓰는 시점에서의 버전인 3.9.x WIP 버전에서와 같이, Allegro는 도스 (djgpp, Watcom), 윈도우즈 (MSVC, mingw32, RSXNTDJ), 리눅스 (콘솔, X), BeOS에 이식되었습니다. 당신이 이것을 읽을 때까지는 버전 4.0이 아마도 발표되었거나 더 많은 다른 플랫폼을 지원하는 이후 버전이 발표되었을 것입니다. Allegro는 어디에서 실행시키건 정확히 똑같은 라이브러리 함수를 제공하며, 이것은 다른 지원 시스템을 위한 프로그램의 버전을 매우 쉽게 만들도록 합니다: 이론적으로, 간단한 재컴파일만이 필요한 작업이 됩니다. 하지만 실제 세상에서는 모든 일이 그렇게 간단하지는 않으므로, 각 새로운 프랫폼에서 프로그램이 동작하도록 하려면 몇가지 조작이 아마도 필요할 것입니다. 이 문서는 나중에 수많은 삽질을 해야 하는 상황을 만나는 대신 올바르게 시작할 수 있기를 바라는 마음에서, 가장 있을법한 문제점이 어떤 것이 될 것인지를 생각해 보려는 시도로 작성된 것입니다. 이들 중 몇몇은 Allegro에 관련된 것이지만, 대부분은 일반적인 C 관련 문제입니다: 두가지 경우 모두에 대하여, 제가 빠트린 어떠한 다른 문제점에 대한 생각을 제게 알려 주십시오!

도스 소스를 다른 플랫폼에서 동작하도록 하는데 필요한 대부분의 분명한 변화는 END_OF_MAIN()을 main() 함수 뒤에 넣는 것입니다. 이 매크로는 도스 버전의 라이브러리에서는 아무 동작도 하지 않는 것이지만, 윈도우즈 버전에서는 표준 main() 함수를 마이크로소프트 스타일의 WinMain()으로 바꾸며, 유닉스 플랫폼에서는 Allegro가 argv[0] 파라미터 값을 가져오도록 하는 마법을 수행합니다 (이것은 config 파일을 찾는데 필요합니다).
main() 함수의 정확한 프로토타입을 제공하십시오. ANSI C는 'int main()'과 'int main(int argc, char *argv[])' 두가지 모두를 허용하며, 성공일 경우 0을 리턴하고, 실패인 경우에는 0이 아닌 exit 코드를 리턴합니다. main에서 그냥 return만으로 종료하거나 어떠한 리턴 값도 없이 함수가 끝나도록 선언하는 것은 올바르지 않습니다.
어떠한 비표준 라이브러리 함수도 사용하지 마십시오. DirectX 함수를 호출한다면 분명히 윈도우즈에서만 동작할 것이며, DPMI 함수를 호출한다면 djgpp와 같은 DPMI 시스템에서만 동작할 것입니다. 그러므로 conio.h와 같은 플랫폼에 특화된 헤더를 사용하거나, GDI 인터페이스 함수와 같은 Allegro의 특정 플랫폼 전용 부분을 사용하는 것을 피해야 합니다. ANSI 표준 함수와 Allegro 라이브러리 함수, 그리고 지원을 원하는 모든 플랫폼에서 사용 가능한 다른 라이브러리만을 사용하십시오. 예를 들어, rand() 함수는 ANSI에서 libc의 일부로 정의되어 있는 것이지만, random()은 그렇지 않으므로, 이식 가능한 코드에서는 random() 대신 rand()를 사용하여야 합니다.
위와 관련하여: 몇몇 플랫폼에서는 rand()는 16비트 값만을 리턴하므로, 그 이상의 비트가 사용 가능한 값을 가지고 있다고 가정하지 마십시오 (djgpp의 rand()는 32비트의 결과를 리턴하지만, 이것에 의존하지는 마십시오).
libc의 가장 약한 표준화 중의 하나는 디렉토리에 저장된 파일을 읽는 방법입니다. 대부분의 도스와 윈도우즈 컴파일러는 findfirst()와 findnext() 함수와 같은 종류를 가지고 있지만, 호출하는 함수와 파라미터가 같지는 않습니다. Posix 시스템 (유닉스, djgpp)에는 opendir()와 readdir() 함수가 있지만, 이들은 MSVC에는 없습니다. 그러므로 이러한 일을 아예 하지 않거나, 모든 플랫폼에서 지원되는 Allegro의 for_each_file() 함수를 사용하십시오.
gcc 문서의 "C 확장 (Extensions)" 페이지를 읽어 보십시오. 여기에는 a) 매우 훌륭하며, b) gcc 이외에늬 컴파일러에서는 지원되지 않는 많은 것들이 있으므로, 이식 가능한 코드를 작성하려면 불행히도 그것을 사용할 수 없습니다. __stdcall, __declspec 등의 MSVC에서 사용하는 것들도 사용하여서는 않됩니다. 그렇지만 이것들은 gcc가 할 수 있는 모든 재미 있는 일들 같이 매력적이지는 않습니다 :-)
모든 컴파일러가 인라인을 지원하는 것은 아니므로, C 함수를 인라인으로 선언하지 마십시오. 성능 최적화를 위해 인라인을 사용하고 싶다면 Allegro의 INLINE 매크로를 대신 사용하십시오. 이것은 인라인을 지원하는 컴파일러에 대히서는 inline으로 정의되며, 특수 문자를 좋아하는 MSVC와 같은 바보같은 컴파일러에 대해서는 __inline으로, 또 전혀 인라인을 사용할 수 없는 컴파일러에 대해서는 무시하도록 정의됩니다. 인라인 함수를 헤더 파일에서 선언하려면 매우 주의하여야 합니다. Allegro는 모든 컴파일러에 대해서 AL_INLINE() 매크로와 inline.c 라이브러리 소스 파일의 조합으로 이것을 처리하지만, 이것은 지저분한 작업이며 모든 최적화와 디버그 빌드에서 동작하도록 하는 것은 쉽지 않습니다. 그러므로 가능한한 이런 작업은 피하는 것이 좋다고 말씀드리고 싶습니다. 구지 사용하고 싶다면 Allegro에서 사용하는 방법을 그대로 사용할 수 있습니다. 하지만 inline.c에 대항하는 자신의 파일을 프로젝트에 추가하여야 할 것이며, 모든 추가되는 인라인 함수의 정적 복사본을 생성하도록 하면서 allegro.h의 인라인 함수의 정적 복사본 (이미 inline.c에서 생성되도록 되어 있는 것)은 생성하지 않도록 하는 정리 작업을 어떻게든 해 주어야 할 것입니다. inline.c와 관련된 작업을 하지 않을 수는 있지만, 이 경우에는 최적화를 하지 않는 디버그 빌드나, 인라인 함수를 지원하지 않는 Watcom과 같은 컴파일러에서는 실패할 경우가 많을 것입니다.
인라인 어셈블러를 사용하지 마십시오! (이것은 매우 명백합니다). 반드시 어셈블리어로 작성하여야 한다면, C로 프로토타입 버전을 먼저 만들고 나서 최적화된 어셈블리어 버전을 시작하기 전에 주석문으로 만드십시오. 이렇게 하면, 나중에 다른 플랫폼에서 동작하도록 하고 싶은 경우에, 어셈블리어 부분을 주석문으로 묶고, 원래의 C 버전을 복구하면, 모든 것을 재작성할 필요가 없습니다. 어셈블리어 코드를 C 소스에서 인라인으로 작성하는 것이 아니라, 외부의 .s 파일로 작성하여 NASM 등을 이용하도록 한다면, 보다 이식하기 쉬워 지는 것을 알 수 있을 것입니다. 아직 플랫폼 사이의 차이점이 존재하고 있지만 (예를 들어, djgpp에서는 심볼 이름 앞에 밑줄이 붙지만 리눅스에서는 그렇지 않습니다), 이런 문제점은 몇가지 전처리 매크로를 사용하여 해결될 수 있습니다. 외부의 어셈블리어 소스 파일을 djgpp와 인텔 리눅스, 인텔 BeOS 플랫폼에서 공유하는 것은 매우 간단한 일이며, Allegro는 심지어 같은 소스를 MSVC와 Watcom에서도 사용하도록 합니다! 이것은 새로운 컴파일러가 적용될 때마다 모두 새로 작성하여야 하는 인라인 어셈블러에 비해 매우 좋은 방법입니다. 하지만 인텔의 어셈블리어는 PPC, MIPS, Alpha 프로세서에서는 올바르게 동작하지 않을 것이므로 진정으로 이식 가능하기에는 아직 매우 부족한 것임에는 틀림 없습니다 :-)
C++로 작성하는 경우에는 조심하여야 합니다. 모든 컴파일러가 아직까지 전체 언어 스펙을 지원하는 것은 아니므로, 특히 새로운 언어 특성과 관련된 내용에 대하여 주의하십시오. 이름 영역과 예외 처리는 특히 문제가 많은 것이지만, 템플리트 인스턴스도 어떤 시스템에서는 다르게 동작할 수 있습니다. 시간이 지나면 이러한 문제들이 점차 해결될 것이고, 2년 전보다 현재가 훨씬 덜 어색해 졌지만, C++의 원래 핵심만을 사용한다면 (클래스, 상속, 가상 함수 등) 더욱 이식성이 높아질 것입니다.
컴파일러의 엄격한 경고 모드(strict warning mode)를 켜고 나오는 모든 메시지를 살펴 보도록 하십시오. 종종 하나의 플랫폼에서의 경고가 다른 플랫폼에서 에러가 되는 경우가 있으며, 이것을 해결했다고 하여도 컴파일러 경고는 의심스러운 코드의 신호이므로 항상 정정될 가치가 있습니다.
디버깅 버전의 Allegro 라이브러리는 문제의 소지가 있는 부분에 대한 경고를 제공하는 몇가지 추가 점검 기능을 포함하고 있으므로, 디버깅 버전의 라이브러리를 링크하십시오. 하지만 디버깅 버전은 매우 느리므로 최종 프로그램을 공개하기 전에 최적화된 라이브러리로 교체하는 것을 잊지는 마십시오.
몇가지 컴파일러에서는 char 변수가 부호가 있는 값이며, 어떤 컴파일러에서는 부호 없는 값이 됩니다. 이것에 대해 다루려면 (즉, 수학 계산을 하거나 1바이트에 음수 값을 저장하려면), 변수형을 signed char나 unsigned char로 항상 명시하여 주어야 합니다. short, int, long 변수는 다르게 지정하지 않는 이상 부호 있는 값이 되므로, 그냥 사용하여도 문제가 없습니다.
스택이 가상 메모리를 사용하여 동적으로 확장되는 유닉스와는 달리, 도스 컴파일러 (윈도우즈용도 마찬가지일 것으로 생각하지만)는 제한된 스택 사이즈를 갖고 있음을 기억하십시오. 그러므로 스택에 커다란 지역 배열을 선언하지 마십시오: 리눅스에서는 동작하겠지만 다를 곳에서는 그렇지 않습니다.
윈도우즈에서 도스 프로그램을 개발중인 경우, 자주 깨끗한 도스 모드에서 CWSDPMI를 DPMI 서버로 사용하여 동작하는가를 테스트하여야 합니다. 이것은 CWSDPMI가 마이크로소프트 DPMI 구현에서 빠트린 몇가지 DPMI 1.0 함수를 지원하며, 이것이 djgpp가 NULL 포인터 참조를 제거하려는 경우에 메모리 억세스 에러를 유발할 수 있기 때문입니다. 윈도우즈에서 프로그램이 동작하지만 CWSDPMI에서는 동작하지 않는다면, 분명 몇가지 포인터 버그가 있을 것이며, 차후에 더욱 좋지 않은 상황을 만들 수 있으며, 다른 플랫폼으로 코드를 이식시킬 때 끝없는 혼란을 유발할 수 있으므로, 반드시 고쳐 주어야 합니다.
컴파일러가 구조체를 메모리에 배치하는 방법에 대한 가정을 하지 마십시오. 예를 들어 다음과 같이 작성한 경우:
```
   typedef struct MYSTRUCT
   {
      char a;
      short b;
      int c;
   };
```
sizeof(MYSTRUCT)가 7이 될 것으로 예상할 수 있겠지만, 실제로 대부분의 인텔 컴파일러는 8바이트로 만들 것입니다. 또한 12바이트의 영역을 차지하게 되는 경우도 많으며, 미래의 64비트 플랫폼은 int 변수를 예상하는 것보다 두배로 사용할 수 있습니다. 그러므로 이와 같은 변동 가능한 사항을 사용하는 코드의 사용은 피하도록 하여야 하며, 데이터 구조체를 위한 공간을 할당할 때에 반드시 sizeof()를 사용하여야 합니다.
fread()나 pack_fread() 함수를 단일 바이트 단위의 데이터 스티림이 아닌 다른 것을 로딩하는데 사용하지 마십시오. 마찬가지로 fwrite()나 pack_fwrite()를 단일 바이트 데이터 이외의 것을 저장하는데 사용하지 마십시오. 그렇지 않을 경우, 저장된 파일은 컴파일러의 메모리 구조체 생성 방식에 따라 바뀌게 될 것이며, 프로세서의 엔디안 방식이 다른 시스템에 대하여 이식이 되지 않을 것입니다. 바이너리 파일을 이식 가능한 방식으로 읽으려면, 각 16비트, 32비트 값을 차례로 pack_igetw()와 pack_igetl() (디스크 파일 포맷의 엔디안 방식에 따라서는 pack_mgetw()와 pack_mgetl())을 사용하여 전달할 필요가 있습니다. Allegro의 src/bmp.c 파일은 올바르게 이 일을 수행하는 방법을 보여주는 아주 좋은 예입니다.
Allegro의 dat2s 유틸리티는 asm 소스 파일을 생성시켜 전혀 다른 asm 문법을 사용하는 플랫폼에서는 동작하지 않도록 할 수 있으므로, 이식 가능한 코드에서는 사용하는 것을 피하여야 합니다 (C 코드 출력이라면 훨씬 더 이식성이 높을 것이지만, gcc나 MSVC 모두 초기화된 커다란 배열을 포함하는 C 소스를 컴파일할 수 없으므로, 실제로는 반드시 그렇지만은 않습니다). 이상하게도 exedat 유틸리티는 다른 플랫폼들에서 훨씬 더 신뢰성있게 동작하는 것으로 보이므로, 데이터 리소스를 실행 파일에 합치는 경우 첫번째 이식을 위한 호출이 될 것입니다. 하지만 이식성이 가장 중요한 경우라면, 가장 안전한 방법은 이들 모두를 사용하지 않고 외부 파일에서 데이터를 읽도록 하는 것입니다.
도스에서 파일 이름은 8.3 형식이며, 대소문자 구별이 없습니다. 윈도우즈에서는 더 긴 파일이름을 사용하며 대소문자가 유지되도록 기억되지만 대소문자가 다르게 인식되지는 않으므로, "MyFile"은 "myfILe"과 같은 것입니다. 유닉스에서는 긴 파일 이름을 사용할 수 있으며, 대소문자도 구별하여 사용하므로, "MyFile"과 "myfILe"은 완전히 다른 것입니다. 이식성이 유지되기를 바란다면 8.3 포맷의 소문자 이름만을 사용하고, 정규 알파벳 문자 이외의 것은 사용하지 마십시오. 이러한 이름은 어느 곳에서나 동작될 것임을 확신할 수 있습니다.
도스와 윈도우즈는 '\'를 파일 패스의 구분자로 사용하지만, '/'도 인식합니다. 유닉스는 오직 '/'만을 사용하므로, 이식성을 보장하려면 항상 '/'를 사용하여야 할 것입니다.
파일 이름을 조작하는 경우, 다른 시스템에서는 완전히 다른 의미가 될 수도 있으므로, 조심하여야 합니다. Allegro는 이러한 작업을 위해 다른 플랫폼에서의 약간의 차이에 영향받지 않는 fix_filename_case(), fix_filename_path()와 같은 몇가지 함수를 제공합니다.
대부분의 도스와 윈도우즈 컴파일러는 와일드카드 커맨드라인 인수를 프로그램에 그대로 전달할 것이지만, 유닉스에서는 프로그램이 실행되기 젼에 셸에 의해 와일드카드가 독립적 파일의 리스트로 확장됩니다. djgpp에서는 __crt0_glob_function()으로 와일드카드 자동 확장 기능을 오버라이드하지 않는다면, 유닉스 셸의 기능을 에뮬레이트합니다. 이식 가능한 프로그램은 반드시 와일드카드 인수가 확장되어 전달되거나 그대로 전달되는 것에 관계 없이 동작하여야 하므로, 두가지 경우 모두에 대비하여 설계되어야 합니다. 예를 들어, dat 유틸리티는 유닉스 셸 방식의 파일 리스트를 전달받을 수 있도록 구성되었지만, 내부적으로 for_each_file()을 각 인수에 대하여 호출하여 와일드카드가 그대로 전달된 경우에도 확장이 일어나도록 합니다.
도스와 윈도우즈에서는 프로그램이 하나의 디렉토리에 설치되는 경향이 있지만, 유닉스에서는 다중 사용자 환경을 인식하며 파일 구조 표준(FHS)을 따르는 프로그램을 시스템 관리자가 선호할 것입니다. 자세한 내용은 http://www.pathname.com/fhs/에서 읽어볼 수 있지만, 다음과 같이 요약할 수 있습니다:
가장 중요한 것은, 읽기 전용 데이터, 전역 가변 데이터, 사용자 관련 데이터를 구분하는 것입니다. 누군가가 당신의 게임을 다운로드하여 압축을 풀고 컴파일하여 실행시킨다고 가정하는 경우, 그것이 설치된 디렉토리를 게임이 전혀 수정하지 않아, 디렉토리가 읽기 전용으로 마운트될 수 있다면 문제가 없습니다. 하이스코어 테이블과 같은 가변 데이터를 저장하려면, 이것을 /var/games 디렉토리에 넣으십시오 (또는 많은 파일을 저장시키는 것이 필요한 경우 /var/games/mygame 서브디렉토리를 생성시키고 데이터를 그곳에 저장하십시오). 같은 시스템에 많은 사용자가 있을 수 있으며, 같은 저장된 정보를 공유할 수도 있음을 잊지 마십시오! 현재 사용자에 한정되는 어떤 것이든 (게임 파일 저장이나 컨트롤러 설정 등) HOME 환경 변수를 읽어 찾을 수 있는 (예: char *mydir = getenv("HOME")) 사용자의 홈 디렉토리에 저장하여야 합니다. 역시, 많은 파일을 저장할 필요가 있다면, 서브디렉토리를 직접 생성할 수 있습니다.
다중 사용자 환경에서 게임이 동작하도로고 하기에는 이것으로 충분하지만, 정말로 아름다운 설정을 원한다면 (예를 들어, 정규 컴파일 규칙과 함께 "make install"을 제공하려면), 다음의 장소를 알고 있어야 합니다:
대부분의 바이너리는 /usr/local/bin에 저장되지만, 게임은 /usr/local/games에 저장되어야 합니다. 이 디렉토리는 현재 시스템에서 사용자에 의해 직접 실행시킬 수 있는 실행파일 자체만을 위한 곳입니다.
공유 라이브러리와 다른 실행 코드는 /usr/local/lib에 저장됩니다. 이 디렉토리의 내용은 역시 하나의 시스템에 대한 것이지만, 사용자는 이것을 직접 실행시키지는 않습니다 (예를 들어, Allegro 공유 라이브러리는 이곳에 저장됩니다).
실행파일이 아닌 리소스는 /usr/local/share/에 저장되거나, 게임에 대하여는, /usr/local/share/games/ 저장될 수 있습니다. 이 디렉토리는 어떠한 타입의 컴퓨터에서 게임이 실행되어도 동일하게 유지되는 정보가 저장되는 것입니다. 그러므로 i386 시스템과 Alpha 박스, PPC 시스템이 혼용되는 네트워크에서 사용되는 경우, 같은 데이터를 모든 하드웨어에서 네트워크를 통해 마운트할 수 있습니다. 하나 이상의 파일을 저장하여야 한다면 서브디렉토리를 만들어 그곳에 모두 저장하십시오.
특정 드라이버 이름을 프로그램에서 사용하지 마십시오. 예를 들어, GFX_VESA2L은 윈도우즈 버전에는 없으며, MIDI_WIN32는 리눅스에서는 사용하지 않습니다. 매우 특별한 환경 (예를 들어, 셋업 프로그램을 작성하는 경우 :-)을 제외하고는 항상 자동 검출 파라미터를 사용하여야 하며, 사용자가 셋업 프로그램을 사용하거나 설정 파일을 수정하여 자동 검출을 오버라이드할 수 있도록 해 주어야 합니다. 이식성 관련된 내용을 제쳐두더라도, 드라이버 선택을 하드코딩하는 것은 모든 사람이 동일한 하드웨어를 사용하는 것은 아니므로 좋지 않은 생각입니다. 특정 그래픽 드라이버가 당신의 시스템에서 가장 잘 동작한다고 하더라도 다른 사람의 시스템에서는 동작하지 않을 수도 있습니다.
특정 하드웨어 드라이버에 의존하는 특별한 코드를 작성할 필요가 있는 경우에는 현재 플래폼에서 사용 가능한가를 테스트하는 전처리를 사용하십시오. 예를 들어, 모드-X 그래픽 모드와 다른 그래픽 모드에서 서로 다른 일을 하는 루틴을 작성하고 싶다면, 다음과 같이 작성할 수 있습니다:
```
   #ifdef GFX_MODEX
      if (gfx_driver->id == GFX_MODEX) {
	 /* 모드-X 그래픽 모드를 위한 작업을 하시오 */
      }
      else
   #endif
      {
	 /* 일반적인 그래픽 모드를 위한 작업을 하시오 */
      }
```
모드-X 드라이버가 현재 플랫폼에서 지원되지 않는 경우, 이 코드는 모드-X 루틴을 컴파일하지 않도록 합니다. 이러한 방식은 모드-X가 지원되거나 지원되지 않을 수 있는 리눅스와 같은 시스템에서 설정 스크립트의 옵션에 따라 적응될 것이므로, 플랫폼 자체를 체크하는 것보다 좋은 방법입니다.
320x200, 640x480, 800x600과 같은 표준 스크린 해상도만을 사용하십시오 (512x384, 640x400과 같이 모든 하드웨어에서 지원하지는 않는 모드는 사용하지 마십시오). 최적화된 이식성을 위해서는, 하나의 해상도가 동작하지 않을 것에 대비하여, 서로 다른 두 개의 해상도를 지원하도록 준비하십시오.
프로그램에서 하이컬러나 트루컬러 모드를 사용하는 경우 (즉, 8비트 컬러 모드 이상의 어떤 것이나), 가능한 모든 하이컬러와 트루컬러 모드를 지원하여야 합니다. 모든 시스템이 모든 컬러 모드를 지원하는 것은 아니지만, Allegro는 다중 컬러 모드를 사용하는 것을 단순하게 하므로, 적어도 15, 16, 24, 32비트 컬러 중의 하나가 가능할 것으로 확신할 수 있습니다 (저해상도 모드의 예외: 많은 도스 드라이버는 640x480보다 낮은 해상도에서는 8비트 컬러만을 지원합니다).
페이지 플리핑과 트리플 버퍼링은 매우 훌륭한 것이며, 회면에 보이지 않는 vram에 저장된 그래픽의 하드웨어 가속 블리팅도 매우 좋습니다. 하지만 이 방법들은 메모리 비트맵에 그려서 단순히 그 결과를 스크린에 뿌리는 것보다 이식성이 매우 떨어집니다. 보다 최적화된 방식을 사용하고 싶은 경우에는, Allegro 데모 게임과 exupdate 예제 프로그램에서 사용한 것과 같이, 단순한 더블 버퍼링을 함께 지원되는 옵션으로 구현할 것을 제안합니다.
그래픽 모드로 전환은 하지만 특정한 모드로 한정하지 않는 경우에는 (예를 들어, 실제 사용할 해상도를 선택하기 위한 다이얼로그 박스롤 표시하기 위해), GFX_SAFE 드라이버를 사용하십시오. GFX_SAFE 모드를 요구하면 Allegro는 현재 시스템에서 지원되는 어떠한 모드이던 검색을 시도하며, 어떠한 모드도 찾지 못한 경우에는 (바라건대 설명적인 :-) 에러 메시지와 함께 프로그램을 종료할 것이므로, 에러를 스스로 검사할 필요는 없습니다.
모든 플랫폼이 Allegro의 외부에서 어떠한 독립 동작을 하도록 되어 있지 않음을 기억하십시오. 예를 들어, 윈도우즈 프로그램은 하나의 윈도우를 열기 전에는 출력을 생성하거나 키보드 입력을 읽을 수 없으며, 마찬가지로 X 프로그램의 stdout은 GUI 인터페이스 내부에서 사용된 경우 보이지 않을 수 있습니다. 그러므로 Allegro 입력 함수를 사용하기 전에 그래픽 모드를 설정해 주어야 하며, printf()를 호출하지 말고 그래픽 모드 스크린에 모든 출력을 구현하여야 합니다. 그래픽 모드가 아닌 경우에 메시지를 출력할 절대적인 필요가 있다면, allegro_message() 함수를 사용하십시오. 이것은 어떤 플랫폼에서는 printf()로 구현되며, 다른 플랫폼에서는 메시지 박스로 구현됩니다.
vsync() 함수는 위험하므로 중요한 부분에서는 사용하지 마십시오. 몇가지 플랫폼 (예: 리눅스 fbcon)은 이 기능을 전혀 지원하지 않으며, 다른 플랫폼 (예: 다양한 부적절하게 작성된 도스 VESA 드라이버들)은 올바르지 못하게 지원합니다. 또한 이것이 의도된 대로 동작하는 경우에도 리트레이스 속도는 그래픽 하드웨어와 사용되는 디스플레이 모드에 따라 달라지므로, 게임 속도를 제어하는 좋은 방법은 아닙니다. 원한다면 그리기를 모니터와 동기시키기 위해 이것을 사용하십시오. 하지만 몇몇 시스템에서는 호출 즉시 리턴되어 버리는 것에 대비하여야 합니다. 버그 있는 VESA 구현에서 실제로 동작하지 않으면서도 그렇지 않은 것처럼 보이게 되는 경우가 매우 많으므로, 불행히도 이 호출이 올바르게 동작하는지 쉽게 검사할 방법은 없습니다.
윈도우즈에서 모든 비디오 메모리와 시스템 비트맵은 그리기 전에 미리 획득되어져야 하며, 작업을 마치자마자 되돌려 주어야 합니다 (하나의 비트맵이 잠겨져 있는 경우에 그래픽 관련 함수가 아닌 다른 함수들을 호출할 수 없기 때문입니다). 이것을 스스로 획득하지 않는다면, Allegro는 그리기 함수 내부에서 자동으로 해주게 되어 있으므로, 많은 그리기 작업을 연속적으로 행하는 경우에는 비효율적이 될 수 있습니다. 예를 들어, 별 모양을 그리기 위해 1000개의 putpixel() 호출을 한다면, acquire_bitmap()을 전체 그리기 코드 블럭의 시작 부분에서 호출하여 속도를 크게 높일 수 있으며, 이 경우 그리기 루틴 마지막에는 release_bitmap()을 호출하여야 합니다.
윈도우즈에서 스크린 오브젝트와 비디오 비트맵 오브젝트는 사용자가 당신의 프로그램에서 다른 프로그램으로 전환할 때마다 모든 것을 잃어버리므로, 다시 제어권이 넘어올 때 모든 화면을 다시 그리도록 준비되어 있어야 합니다 (즉, 항상 SWITCH_AMNESIA 모드에서 작업합니다). set_display_switch_mode()를 호출하여 모드를 변경하려고 할 수 있지만, 현재 이 호출은 윈도우즈에서는 항상 실패할 것입니다. 이것은 매우 불행한 것이지만, DirectX 디자인 상의 결점에 원인이 있으므로, 다른 개선의 여지가 없습니다. 애니메이션 시스템이 항상 전체 스크린을 매 프레임마다 다시 그리도록 되어 있는 게임에서는 문제가 되지 않지만, 이것이 문제가 된다면, set_display_switch_callback()을 SWITCH_IN 이벤트를 후킹하도록 호출하여 특수한 다시 그리기 루틴이 필요할 때마다 실행되도록 하거나, 사용자에게 게임중 프로그램의 전환을 하지 말도록 이야기하여 이 문제를 무시하도록 하여도 될 것입니다 :-)
비디오 메모리에 직접 쓰기를 이용한다면, 이것을 위해 사용되는 old_farpokeb() 메서드는 이식 가능하지 않는 것이므로, 매우 조심하여야 합니다 (djgpp 프로그램에서는 동작할 것입니다). 메모리 비트맵을 직접 조작하기 위해 line 포인터를 사용할 수 있습니다. 하지만 비디오 비트맵에 대해서는 다음과 같은 작업을 수행할 필요가 있습니다:
```
   // 그리기 작업의 맨 처음에서 bmp_select()를 한번 호출
   bmp_select(bmp);

   for (y=top; y<bottom; y++) {
      // 각 가로 라인마다 bmp_write_line() 호출
      unsigned long address = bmp_write_line(bmp, y);

      for (x=left; x<right; x++) {
	 // 픽셀 데이터를 쓰기 위해 bmp_write*() 매크로를 사용
	 bmp_write8(address+x, color);
      }
   }

   // 그리기 작업의 맨 마지막에 bmp_unwrite_line()을 한번 호출
   bmp_unwrite_line(bmp);
```
그렇습니다. 이것은 좀 좋지 않아 보입니다만, 이들 매크로의 절반은 어떤 플랫폼에 대해서는 단순히 아무 동작을 하지 않는 것으로 변환될 것이며, 나머지 반은 1비트의 포인터 조작이나 인라인 어셈블러로 바뀌므로, 그렇게 나쁜 것은 아닙니다. 그리고 이것은 어느 플랫폼으로든 이식 가능한 방법으로 메모리를 직접 억세스하는 작업을 구현하는 유일한 방법입니다.
더 높은 색상 비트를 사용하는 경우에는, bmp_write8()을 bmp_write15(), bmp_write16() 등으로 바꾸어 사용하며, 목적 어드레스에 x축 값을 더하는 경우에 얼마를 곱해 주어야 합니다. 15와 16비트 모드에서는 sizeof(short)를 곱하며, 24비트 모드에서는 3을, 32비트 모드에서는 sizeof(long)을 곱합니다.
현재 Allegro가 지원하는 모든 플랫폼은 비동기 입력, 즉, key[] 어레이와 마우스 위치 변수가 데이터가 바뀔 때마다 자동으로 업데이트 되는 기능을 제공합니다. 미래에 지원될 어떤 플랫폼에서는 이것을 지원하지 않을 수 있으며, 이 경우에는 하드웨어 장치의 정보를 상태 변수로 가져올 필요가 있을 때마다 폴링 함수 (poll_mouse()와 poll_keyboard())를 호출하여야 할 필요가 있을 것입니다 (readkey()나 get_mouse_mickeys()와 같은 데이터 읽기 함수를 사용할 경우에는 폴링을 할 필요가 없습니다). 모든 플랫폼에서 폴링을 하지 않아도 될 가능성이 있으므로, 폴링을 사용하는 수고를 할 것인가 하지 않을 것인가는 당신의 선택에 달려 있습니다. 하지만 매우 안전함을 추구한다면 새로운 입력을 요구할 때마다 폴링을 하여야 할 것입니다. 폴링을 요구하지 않는 플랫폼에서 이러한 종류의 코드를 테스트하는 것을 간단하게 하기 위해, 첫번째 폴링 함수의 호출 후에, Allegro는 특수한 폴링 에뮬레이션 모드로 들어가서, 폴링을 하지 않는 경우에는 어떠한 입력도 제공하지 않도록 동작할 것입니다. 그러므로 중요한 장소에서 폴링 호출을 하는 것을 잊지 않도록 하십시오.
도스에서 인터럽트 관련 루틴 (타이머 핸들러, 마우스 이동 콜백, 미디 이벤트 콜백 등)에서 사용되는 모든 메모리는 잠그어 주어야 할 필요가 있습니다. 변수는 LOCK_VARIABLE() 매크로를 사용하며, 함수는 END_OF_FINCTION()과 LOCK_FUNCTION() 매크로를 사용하고, 할당된 메모리 블록을 잠그려면 LOCK_DATA() 매크로를 사용합니다 (모든 인터럽트의 스택은 이미 잠겨져 있으므로, 지역 변수는 잠글 필요가 없습니다). 다른 플랫폼에서는 이와 같은 작업을 하지 않아도 되지만, 도스에서 동작시키도록 할 경우를 대비하는 것이 좋습니다. 또한 인터럽트 루틴에서 라이브러리 함수를 호출하는 것은 피해야 하며 (라이브러리 함수를 잠글 방법이 없으며, 어떤 경우에라도 그것이 동작하지 않기 쉽기 때문입니다), 어떠한 부동소수점 연산도 사용하지 않아야 합니다.
고정도 타이머에 의존하지 마십시오. 어떠한 플랫폼에서도 적어도 10 ms (1초의 1/100)의 정확도는 믿을 수 있지만, 어떤 시스템에서는 더 높은 정확도가 가능하다 하여도, 다른 시스템에서는 그렇지 않습니다. 현재 플랫폼에서 지원하는 것보다 빠른 타이머를 설치한다면, 요구된 속도의 평균은 유지될 것이지만, 각 시스템 타이머 단위시간에 모두 뭉쳐 호출될 수 있으므로, 실제로는 그다지 유용하지 않습니다.