make는 표준 djgpp 배포본의 일부이며, v2gnu/mak*b.zip(*에는 최신 버전의
번호가 들어갑니다) 파일에 포함되어 있습니다. 이것은
http://www.delorie.com/djgpp/에서 구할 수 있습니다.
djgpp를 정말 정확히 설치하셨습니까? djgpp의 readme.1st 파일의 지시 사항을
점검해 보고, 특히 DJGPP 환경 변수가 설정되어 있으며 djgpp\bin 디렉토리가
path에 포함디어 있는지 확인하십시오.
GNU make 프로그램을 사용하고 있는지 확인하십시오. Borland의 make와 같은
다른 버전을 사용하고 있는 것은 아닙니까? 의심이 간다면 "make -v"를
실행시켜 GNU의 저작권 메시지가 표시되는 것을 확인하십시오.
윈도우즈 95의 윈도우즈 탐색기에서 make를 실행시키면 안됩니다! DOS 박스를
띄우고 Allegro 디렉토리로 옮긴 후 명령 프롬프트에 "make"라고
입력하십시오.
시스템의 시간과 날짜가 정확하게 맞춰져 있습니까?
Alternatively you may have downloaded a fresh file made by someone in a
more eastern timezone. In the latter case you can either wait a few
hours, temporarily set your clock forward, or use a utility such as
"touch" to change the timestamp of the files.
오류 메시지가 제시하는 것과 같이, 컴파일러가 사용할 메모리를 더 많이
확보해 주어야 합니다. go32-v2 프로그램은 현재 사용 가능한 메모리의 양을
보여줄 것입니다. DOS에서 실행시키고 있다면 swapfile로 사용할 수 있도록
디스크의 빈 공간을 더 확보하도록 하십시오. 윈도우즈 95를 사용하고 있다면
DOS 세션의 등록정보에서 DPMI 메모리 한계를 65535까지 늘려 주십시오(풀다운
리스트에는 16384까지밖에 나와있지 않으므로 이것을 손으로 입력하여야 할
것입니다).
메시지가 제시하는 바대로, 새로운 버전의 gcc와 구버전의 libc의
충돌입니다. gcc*b.zip 파일에 포함된 readme.DJGPP를 읽어보십시오
(수정 사항은 파일 맨 끝에 붙습니다).
C:\TEMP\ccdaaaaa(.text+0x9):x.c: undefined reference to `allegro_init'
C:\TEMP\ccdaaaaa(.text+0xe):x.c: undefined reference to `install_keyboard'
문서들을 읽어보지 않았군요. 그렇지 않아요? :-) 프로그램을 라이브러리
파일인 liballeg.a와 링크시켜야 합니다. 먼저 모든 것이 올바르게 설치된
것을 확인하십시오(make를 실행시키면 알 수 있습니다). 그리고 나서 명령어
프롬프트나 makefile을 이용하여 컴파일하고 있다면 -lalleg를 gcc 명령어행
뒤에 추가하십시오. Rhide를 이용한다면 Option/Libraries 메뉴에서
'alleg'를 첫번째 비어있는 필드에 입력하시고 옆에 있는 상자가 체크되어
있도록 하십시오.
아니오. 죄송합니다. liballeg.a는 약 450k 정도이지만 grabber, 사운드
설정과 같은 많은 유틸리티도 필요할 것입니다. 그리고 예제 프로그램들은
어떤가요? 모두 컴파일된 버전을 포함시킨다면 바이너리 배포본은 아마 7메가
이상이 될 것입니다: 실용적으로 너무나도 큽니다! 더욱 심각한 것은 당신
스스로 빌드하지 못할 이유가 없다는 것입니다. 컴파일러는 정해진 결과만이
나오는 것입니다: 특정 입력 파일과 명령어를 주면 항상 같은 결과가
나옵니다. 제대로 동작하지 않는다면 잘못된 입력 파일을 넣었거나(예를
들어 Allegro의 복사본이 어찌된 일인지 손상되어 있다거나), 잘못된 명령을
입력하였거나 ("make"를 입력하기만 하면 되기 때문에 이것이 실제로 원인이
되기는 어렵습니다), 컴파일러가 손상되었거나, 그러니까 djgpp를 제대로
설치하지 못하였거나 하였을 것입니다. 다른 사람에게 Allegro를 대신
컴파일하게 하여 문제를 카페트 아래에 쓸어 넣지만 하지 마시고, 직접 문제를
찾아 해결해 보십시오...
GNU 도구들은 오류 메시지를 오류 스트림인 stderr에 씁니다. 불행하게도
command.com은 이것을 리다이렉트하지 못합니다만, 다행히도 DJ는 현명하게
이것을 해결하고 있습니다. redir 프로그램을 이용하여 출력 메시지를
갈무리할 수 있습니다. "redir -eo make > logfile.txt"와 같이 하면
됩니다.
어디까지 동작할 것인가는 상황에 따라 다릅니다. 어떤 사람들은 문제가
있다고 하는데, 또 다른 사람들은 잘 동작한다고 합니다. 저는 NT를 사용할
수 없으므로 제가 그것에 대해 할 수 있는 일은 없으며, 솔직히 말하면 크게
관심이 있지는 않습니다. 윈도우즈 버전의 프로그램을 만들려면 Allegro의
윈도우즈 버전을 사용하시고, DOS 프로그램을 만들려면 DOS를 사용하십시오!
그렇습니다. 하지만 몇가지 경고가 있습니다. EMM386의 OpenDOS 버전을
사용하고 있다면 DPMI 구현을 금지시켜야 합니다 (config.sys 파일의
EMM386.EXE의 DEVICE 행에서 DPMI=OFF를 넣으십시오). 또한 PIC=OFF 플래그가
설정되어 있는지 확인하여야 하는데, 이것은 디폴트 설정이므로 특별히 그것을
허용하지 않았었다면 문제가 되지 않을 것입니다.
저의 비디오 카드의 메모리는 2메가입니다.
할 수 없습니다. 이 한계는 VGA 하드웨어에 의해 결정되는 것이지 Allegro에
의한 것은 아닙니다. 256k 이상의 비디오 메모리를 사용하려면 SVGA 모드를
이용하여야 합니다. 이것은 더 높은 해상도로 전환하거나, 저해상도 SVGA
모드를 지원하는 SciTech Display Doctor를 구하여야 한다는 말입니다.
어떤 사람에게는 가능하지만 다른 사람에게는 그렇지 않습니다. 문제는
Creative Labs가 SB-Live 카드의 스펙을 공개하는 것을 거부하였기 때문에
드라이버를 작성할 수 없다는 것입니다. 제조사에 항의하거나 더 현명한
제조사로부터 다른 카드를 구입하십시오.
이것은 아마도 음량을 매우 낮게 설정하였기 때문일 것입니다: setup
프로그램에서 음량을 바꾸어 보십시오. 또한 윈도우즈 사운드 플레이어가
한번에 하나의 샘플을 플레이하는 것과는 달리, Allegro에서는 몇개의
사운드를 하나의 출력 버퍼로 믹싱하여 출력하므로 각각의 사운드는 전체
출력 음량의 작은 비율을 차지하기 때문이기도 합니다. 이것은 다중 출력
채널을 지원받는대 대한 대가일 뿐입니다. 이것이 마음에 들지 않는다면
setup 프로그램을 사용하여 채널의 개수를 조정하십시오: 채널의 개수는 64
이하의 2의 거듭제곱이 될 수 있으며, 이 값을 작게 할 수록 사운드는 더
커질 것입니다. 또는 set_volume_per_voice()를 사용하십시오. 문서에서
설명되어 있습니다. 이 함수는 Allegro 디지털 사운드 출력의 전체
음량을 조정하게 합니다.
FreeBE/AF 드라이버 (http://www.talula.demon.co.uk/freebe/)
를 사용하거나 상용 프로그램인 SciTech Display Doctor
(http://www.scitechsoft.com/)
를 사용하여 보십시오. 그래도 문제가 해결되지 않는다면 Allegro 메일링 리스트에
afinfo와 vesainfo를 실행시켰을 때의 화면과 함께 문제의 설명을 게시하십시오.
VBE/AF 인터페이스는 비디오 드라이버에 이미 동적 연결을 사용하고 있습니다:
http://www.talula.demon.co.uk/freebe/에서 FreeBE/AF 프로젝트를
보십시오. 사운드, VESA, 모드-X 루틴과 같이 보다 일반적인 것에 대해서는
그것들의 드라이버가 라이브러리 코어의 수많은 보조 함수(helper function)를
이용하고 있기 때문에 동적 연결을 사용하는 것이 매우 어렵습니다. djgpp의
DXE 형식은 동적 연결을 지원하는데 충분할 정도록 유연하며, 저는 Allegro를
다른 동적 연결 패키지에 종속되도록 만들고 싶지는 않습니다.
오류가 나옵니다!
글쎄요. 환경 변수의 크기를 늘려야 할 것입니다 :-) DOS 상자에서
(시스템 메뉴를 클릭하고 "등록정보"를 선택하여) 세팅을 변경시키거나,
config.sys 파일에서 세팅을 변경시키면 됩니다 ("shell=c:\command.com
/e:8192"과 같이 추가합니다).
grabber는 datedit.c에 포함된 코드와 링크되어야 합니다. 하지만 손으로
직접 이것을 할 필요는 없습니다: 그냥 "make"를 실행시키면 모든 것을
빌드해 줍니다.
386 instruction' 또는 `Error: no such instruction `maskmovq %mm3,
%mm1''과 같은 에러를 내며 make가 실패합니다.
GNU binutil의 버전을 업데이트하여야 합니다. 최하 어떤 버전이 필요한지
readme.txt에서 찾아 보십시오.
<아무이름>이 readme.txt에 있는 지원 플랫폼 중의 하나가 아니라면
안됩니다. 만약 <아무이름>이 볼랜드 C와 같은 16비트 DOS 컴파일러라면
이것으로 컴파일하려는 생각은 잊어버리는 것이 좋습니다 :-)
WIP는 "개발중(work in progress)"을 의미하는 약자이며, 최신 공식 배포
버전보다 나중에 변경된 것을 의미합니다. Allegro의 WIP 버전은 Allegro
웹사이트(http://alleg.sourceforge.net/)에서 패치의
형태로 구할 수 있으며, 최종 배포 버전으로 테스트된 것 정도는 아니지만
그래도 보통은 상당히 안정적입니다.
patch.exe를 가지고 있습니까? 그렇지 않다면 djgpp를 다운로드한 곳에서
patch.exe를 가져오십시오: 이 도구는 djgpp 컴파일러 배포판의 표준 구성의
일부입니다. patch 프로그램을 가지고 있지만 잘 동작하지 않을 경우에는
업데이트하려는 Allegro 버전이 수정되지 않은 상태로 최종적으로 설치되어
있는가 확인하십시오 (이것은 보통 WIP가 만들어지기 전의 최신 공식 배포
버전이 될 것이지만, 확실히 하기 위해 WIP에 포함된 텍스트 파일을
점검하십시오).
이 파일은 WIP 버전과는 별도로 배포됩니다. 다음에서 다운로드하십시오:
http://alleg.sourceforge.net/wip.html. (alldata.zip)
두번째 이미지를 표시하면 첫번째 이미지의 팔레트가 엉망이 됩니다.
이것은 단지 비디오 하드웨어가 동작하는 방식입니다: 한 시점에서는 하나의
팔레트만을 사용할 수 있습니다. 이미지를 하나의 동일한 팔레트를 사용하도록
변환하거나, 트루컬러 그래픽 모드로 전환하십시오.
Allegro.cc 홈페이지(http://www.allegro.cc/)에서
FixPal나 Smacker 같은 유틸리티를 찾아 보십시오.
그레이스케일 팔레트를 만듭니까?
VGA 하드웨어는 각 색상 요소당 6비트만을 사용하므로, 팔레트의 적색, 녹색,
청색의 값 은 0에서 63까지만 가능하며 255까지는 사용할 수 없습니다. 그러므로
2^18 = 262144 색상을 사용하거나 64개의 그레이 단계를 사용할 수 있습니다.
이것 이상의 색상을 이용하려면 VESA 함수 0x4F08을 이용하여 8비트 DAC를
선택하도록 할 수 있지만, Allegro는 이것을 직접적으로 지원하지 않으며, 저는
서로 다른 하드웨어에 대하여 얼마나 신뢰할 수 있는지 모르겠습니다.
256색 모드를 이용하는 경우 VGA 카느는 0번 색상을 표시 영역의 경계에
표시합니다 ( 트루컬러 모드에서는 검은색입니다). 0번 색을 검은색이 되도록
팔레트를 변경하면 이상한 색의 테두리는 없어질 것입니다.
매우 어렵습니다 :-) 팔레트를 바꾸는 것과 같은 쉬운 트릭은 없으므로,
이미지를 더 밝게 하거나 어두운 형태로 다시 그리는 것을 반복하여야 합니다.
검은색의 투과성 직사각형을 스크린에 덮어 그려서 어둡게 하거나
draw_lit_sprit()를 이용하여 스크린에 복사될 때 음영을 줄 수도 있지만,
이러한 동작은 많은 계산과 리소스가 필요하므로 빠른 PC에서만 가능할
것입니다!
어떤 일도 일어나지 않습니다. 무엇이 잘못된 것일까요?
fade_in()과 fade_out()은 8비트 팔레트 모드에서만 동작합니다. 비트맵의
밝기를 변화시키는 한가지 방법은 모든 픽셀을 사용하는 루프에서 각 점을
변화시키는 것이고, 다른 한가지 방법은 스크린에 많은 반투명 검은 사각형을
그리는 것입니다. 그렇지만 이들 방법은 동작이 빠르지 않을 것입니다.
exxfade.c 예제는 두 개의 비트맵이 오버랩되는 방법을 보여줍니다. 이것을
변형시켜 검은 스크린으로부터 또는 검은 스크린이 되도록 변하게 할 수 있을
것입니다. 앞의 질문을 참고하십시오.
Allegro 홈페이지(http://www.talula.demon.co.uk/allegro/)에서
DTA나 Smacker와 같은 유틸리티를 찾아 보십시오.
문서에 나오는 "밝은 핑크"의 의미를 모르겠습니다...
당신이 주로 이용하는 페인트 프로그램에서 RGB 조정 도구를 이용하여 적색과
청색을 최대값으로 하고(보통은 255이지만 사용하는 소프트웨어에 따라 다를
수 있습니다) 녹색을 0으로 설정하십시오. 이 결과의 색상이 바로 마법의
"핑크"입니다. 또 어떤 사람들은 이것을 마젠타(magenta)라고 합니다.
꼭지점 위치는 고정 소수점 형식으로 저장된다는 것을 명심하십시오. 그러므로
itofix() 매크로를 사용하거나 좌표를 16비트 왼쪽으로 시프트하여야 합니다.
회전의 각도는 고정 소수점 형식으로 저장된다는 것을 명심하십시오.
그러므로 itofix() 매크로를 이용하거나 좌표를 16비트 왼쪽으로
시프트하여야 합니다. 예를 들어, rotate_sprite(bmp, spr, x, y, itofix(32))
와 같이 하면 그래픽을 45도 회전시킬 것입니다.
아마도 당신은 비트맵 포인터를 가지고 다이얼로그 구조체를 초기화하려 하고
있을 것입니다. 다이얼로그는 컴파일 시간에 생성되지만, 비트맵은 실행
시간에만 만들어지므로 컴파일러는 그것이 어디에 위치하게 될지를 알지 못하기
때문에 이것은 동작하지 않을 것입니다. 다이얼로그 구조체를 NULL 포인터를
가지고 완성시키고나서, 비트맵을 메모리로 읽어들인 후에 실제 비트맵
포인터를 dp 필드에 초기화 코드 부분에서 넣으십시오.
그것은 무엇을 하려는가에 따라 달라집니다. 완전 불투명한 이미지를
사용한다면 RLE 스프라이트를 사용하여 얻을 수 있는 이득은 없으며, 일반
비트맵을 blit() 함수와 함께 사용하는 것이 아마도 더 빠를 것입니다.
마스크 영역을 가지고 있는 그래픽이라면 RLE 스프라이트가 거의 항상 크기도
작고 draw_sprite() 함수보다 빠를 것입니다. 컴파일 스프라이트는 일반적으로
마스크 이미지의 경우에 위의 두가지보다 상당히 빠르게 동작하며, 불투명
크래픽의 경우에도 조금 빠릅니다. 하지만 이것은 여러가지 변수가 있습니다.
컴파일 스프라이트는 구형 PC의 모드-X에서의 작은 스프라이트에 대하여 가장
잘 동작하며, 펜티엄의 SVGA 모드에서는 blit()보다 약간 느릴 수 있습니다
(큰 사이즈의 컴파일 스프라이트는 캐시의 성능에 매우 나쁘게 작용합니다).
게임 로직이 정해진 정규 속도로 갱신되도록 하여야 하지만, 컴퓨터가 속도를
유지하기에 너무 느린 경우에는 스크린을 다시 그리는 것을 이따금 건더 뛰도록
하십시오.이것은 타이머 핸들러를 설치하고 이것에 의해 전역 변수가 게임 로직
속도에 맞춰 증가하도록 하면 가능합니다. 예를 들면:
volatile int speed_counter = 0;
void increment_speed_counter()
{
speed_counter++;
}
END_OF_FUNCTION(increment_speed_counter);
void play_the_game()
{
LOCK_VARIABLE(speed_counter);
LOCK_FUNCTION(increment_speed_counter);
install_int_ex(increment_speed_counter, BPS_TO_TIMER(60));
while (!game_over) {
while (speed_counter > 0) {
update_game_logic();
speed_counter--;
}
update_display();
}
}
save_bitmap()을 호출하는 코드를 어딘가에 추가하십시오. save_bitmap()
문서에 나오는 일반적인 사용 방법과 예제 코드를 참고하십시오.
srand(time(NULL))을 프로그램의 시작 부분에서 호출하고, rand()%limit를
사용하여 0에서 limit-1 사이의 랜덤 숫자를 얻습니다.
저는 사운드, 수학 계산, 혹은 GUI 루틴은 필요하지 않습니다...
그럴 필요가 없습니다. 링커가 라이브러리에서 실제로 사용되는 부분만을
포함시킬 것이므로 호출되지 않는 것은, 말하자면 텍스쳐 매핑이나 FLIC 재생
함수와 같은 것을 호출하지 않는다면, 그것들은 실행 파일에 포함되지
않습니다. 이것이 완벽하게 동작하는 것은 아닙니다. Allegro의 코드의 많은
부분이 함수 포인터의 테이블을 이용하고 있으므로 불필요한 루틴이 링크될
수도 있습니다. 그러므로 대부분의 그래픽 함수들은 모든 실행 파일에 포함될
것이지만, 이러한 것을 최소화 하도록 도력하여 왔습니다. allegro.txt에서
그래픽과 사운드 드라이버의 일부를 제거하는 보다 정확한 방법에 대한 정보를
읽어 보십시오.
없습니다. 저는 이러한 종류의 하드웨어 지원은 Allegro가 아닌 더욱 적절한
3D API의 일부로 하는 것이 가장 효과적이라고 생각하며, 앞으로로 변함 없을
것입니다. 이것을 위한 작업을 원한다면 저의 소견으로는 MESA 라이브러리
(OpenGL의 공개 구현) 가 시발점이 될 수 있을 것입니다.
JGMOD 패키지와 같은 몇개의 아주 좋은 것들이 이미 존재합니다. Allegro.cc
웹사이트(http://www.allegro.cc/)의 오디오 라이브러리 확장 섹션을
참고하십시오. 이들 라이브러리를 Allegro에 포함시키는 제안은 허용하지
않습니다. 이 주제에 대한 토론은 이미 메일링 리스트에서 종결되었으며,
저는 그건에 지쳐버렸습니다.
그것은 매우 많은 작업을 필요로 할 것이고, 저는 직접 할 시간이 없습니다.
네트워크상에서 개발되고 있거나 돌아다니는 네트워킹 패키지가 몇개
있습니다만, 저의 의젼으로는 이러한 종류의 코느는 Allegro의 일부가 아닌
외부 라이브러리인 경우에 더 유용한 것 같습니다.
Unisys에서 GIF 형식에 사용되는 LZW 압축 알고리듬의 특허를 갖고 있습니다.
저는 Allegro의 모든 부분이 아무런 제한 없이 자유롭게 사용되어지기를
바라므로, 저는 로얄티의 지불이나 라이센스에 구속되는 코드는 포함시킬
수 없습니다.
그럴 수도 있습니다. 문제를 발생시키는 부분을 가장 작게 축소시켜 분리된
코드로 만들어 주시면 제가 점검해 보겠습니다. 저에게 10행의 프로그램을
보내면 그것을 고칠 것이고, 100행이라면 아마 고칠 수도 있을 것입니다.
1000라인이라면 어찌할 수가 없습니다 :-)
물론입니다. readme.txt의 giftware 규정을 참고하십시오. 저는 Allegro를
가지고 당신이 무엇을 하던지 신경쓰지 않으며, 상업용으로 사용하는 것에도
아무런 문제가 없습니다.
그것이 끝나면 입니다! 약간의 격려는 언제나 환영이지만, 저는 어떠한 완성
일자도 정하지 않습니다 :-) 작업이 끝나면 곧 바로 공개될 것입니다.
grabber에서 GRX나 BIOS 형식의 .fnt 파일을 직접 가져올 수 있으며, 페인트
프로그램을 이용하여 폰트를 .pcx 영상에 그려도 됩니다.
http://www.talula.demon.co.uk/ttf2pcx/에서 윈도우즈
트루타입폰트를 .pcx 형식으로 변환하는 유틸리티를 찾아 보십시오.
Allegro 홈페이지(http://alleg.sourceforge.net/)의
링크를 찾아 보십시오. Gravis 패치(.pat 형식)이나 SoundFont 2.0(.sf2)
파일을 사용할 수 있지만, 후자의 것은 pat2dat 유틸리티를 이용하여
patches.dat 파일로 변환하여야 합니다.
makertf 변환 유틸리티 (ftp://ftp.coast.net/Coast/win3/winhelp/mkrtf104.zip)
와 윈도우즈 도움말 컴파일러 (ftp://ftp.microsoft.com/Softlib/MSLFILES/HC505.EXE)를
다운로드하여야 합니다. 임시 디렉토리를 만들고 allegro/docs 디렉토리에서
allegro.txi 파일을 복사한 후에 "makertf --no-warn allegro.txi -o allegro.rtf
-J allegro.hpj" 명령을 실행시키고 "hcp allegro.hpj"와 같이 하면 됩니다.
두번째 명령은 많은 경고를 표시할 것이지만 무시하여도 됩니다.
allegro.rtf 파일은 마이크로소프트 워드에서 읽어서 프린트하면 되는데,
먼저 오른쪽 버튼을 클릭하여 목차와 인덱스 필드를 수정하여 정확한 데이터로
채워지도록 하여야 합니다. 다른 방법으로는 TeX 패키지를 설치하고 tex과
dvips 프로그램으로 allegro.txt를 포스트스크립트 형식으로 변환할 수도
있습니다.
Allegro.cc 홈페이지 http://www.allegro.cc/에서
찾아 보십시오. 여기에 추가하고 싶은 것이 있다면 URL을 게시하여 주십시오!
코딩 습관입니까?
PI의 값이 변경되어야할 필요가 있을 경우, 프로그램의 유지보수를
단순화합니다. 또한 이것은 PI에 다른 값을 이용하는 다른 컴파일러로
포팅하기 쉽게 만들 것입니다.
많은 그래픽 카드들은 버그를 갖고 있으며, VESA 구현이 완전하지 않고, 또
vsync() 함수가 구현되어 있지 않은 경우도 종종 있습니다. 깜박임 없이
그리기 예제로서, 자신을 그리기 위해 여러 가지 방법을 사용하는 데모
게임의 코드를 보십시오.
"while (!key[KEY_ENTER]);"가 동작하지 않습니다.
최적화를 하지 않은 상태로 코드가 동작한다면, 그것은 컴파일러의 잘못일 수
있습니다! 컴파일러가 말을 잘 듣게 하기 위해 다음과 같이 시도할 수
있습니다:
while (!key[KEY_ENTER])
yield_timeslice();
그렇지만 이 경우, readkey()를 대신 사용하는 것이 좋을 것입니다.
또는 컴파일러의 버전을 바꾸는 것을 고려하여 보십시오.
http://alleg.sourceforge.net/maillist.html를 보십시오.
