이것이 뭐냐하면 퀘이크 3 소스코드에 있는 함수다
정확히는 
를 계산하는 함수인데, 광원 효과에 쓰이는 함수라서 굉장히 빨라야 한다
(빛의 반사 계산하는 데 쓰는데, 단위벡터가 어쩌구 반사벡터가 저쩌구 하는 건 생략)
중요한 건 느리면 60 프레임을 못맞추고, 빨라도 값의 정확하지 않으면 빛이 이상하게 표현된다
나눗셈이랑 제곱근을 쓰는 방법은 정확한 대신 리소스도 많이 필요하고 줜나 느려서 60프레임을 못맞춘다
그래서 퀘이크 3 개발진은 저런 함수를 만들어 를 빠르고 정확하게 계산했다
일단 보면 주석에 왓더뻑이라고 적힌 것처럼 씨1발 이게 뭐야 어캐 하는건데 싶어진다
그래도 하나 하나 뜯어보면 이해가 되긴 된다
우선 맨 앞에 변수의 자료형 두 개가 나온다
long은 숫자를 이진법으로 00000000 00000000 00000000 00000000으로 표시한다
long형에서 특별히 봐야할 건 없으니 넘어가자
float은 소숫점을 포함한 실수를 0 00000000 00000000000000000000000으로 표현한다
첫 자리는 부호를 나타낸다
0이면 양수 또는 0, 1이면 음수를 뜻한다
뒤의 8자리는 지수(2E)를 나타낸다
E = -127를 00000000으로 하고 E = +128을 11111111로 사용한다
마지막 23자리는 가수부(M)를 나타낸다
이진법으로 1.00000000000000000000000부터 1.11111111111111111111111까지 소숫점을 나타내는 데 사용한다
float형을 수식으로 표현하면 이런 꼴이 된다
저 수식을 2의 로그로 감싸고 정리하면 
가 된다
뜬금없이 나온 뮤(μ)는 log2의 근사값을 구하는 데 쓰인 숫자다
1보다 작은 x에 대해 
인데 적당한 수를 더하면(
) 전반적인 정확도를 높일 수 있다
실험적으로 찾아낸 적절한 값은 μ≒0.0430357이다
그런데 float형의 비트값은 E*223 + M 꼴의 형태가 되는 것을 알고 있다
(여기서 음수는 생각하지 않는다)
앞에서 구한 로그값이랑 비교하여 생각해보면 float형의 비트값을 그대로 하나의 정수로 생각하면 이 정수는 원래 값에 log2를 취한 것과 같다고 생각할 수 있다
변수 정의 뒤에 나오는 i = * ( long * ) &y; 가 바로 float형으로 받은 비트값을 그대로 숫자로 받는 줄인 것이다
어찌저찌하여 중간까지는 왔는데 그 다음 줄이 문제다
앞서 
였고 
를 구해야 하는데, 로그의 특성에 따라 
가 된다!
그리고 이진수에서 오른쪽으로 비트를 이동(bit shift)하면 2로 나눈 것과 같은 효과를 얻는다
예를 들어 110(10진법으로 6)을 오른쪽으로 비트 이동시키면 11(10진법으로 3)이 된다
111(10진법으로 7)도 11(10진법으로 3)이 되는 문제가 있지만 어쩔 수 없이 받아들여야 한다
오른쪽으로 비트 이동이 >>니까 -0.5i는 -(i >> 1)이 된다
그러면 저 0x5f3759df(=1597463040)는 대체 뭔 수일까?
실제로 구해야 하는 해 를 감마(Γ)라고 하면 i와 Γ의 관계는 다음과 같다
이걸 좀전에 봤던 
꼴로 표현하면,
정리하면,
값을 계산하면, 3/2 * 223 * (127-μ) = 1597488309.57 ≒1597463040 = 0x5f3759df
그렇다, 오차를 보정하는 값이 바로 저 0x5f3759df였던 거다!
값을 다 구했으니 구한 값을 float형으로 되돌리고 → y = * (float *) &i;
f(x) = 0을 정확하게 구할 때 쓰는 뉴턴-랩슨법을 이용해 정확도를 높여주면 → y = y * (threehalfs - (x2 * y * y));
그리하여 나눗셈도, 제곱근 계산도 없이 포인트 참조, 비트 이동, 뺄셈, 그리고 곱하기만 가지고 빠르고 비교적 정확하게 를 구할 수 있었다!
수포자가 게임 개발자가 되겠다는걸 비웃는 이유
일반 프로그래머는 저런걸 만들지 않고 만들어진 함수를 그냥 가져다 쓴다. 내가 죽도록 노력해봐야 기존에 만든것보다 못하거든..
저런 코드들이 모여서 최적화가 되는거라... 최적화 못 하는 게임들은 저런 코드 못 만드는 개발팀으로 보면 될듯
퀘이크정도면 기존에 만들어진 게 없을 때지 ㅋㅋㅋ
의외로 이산수학으로 수식을 쉽게 정리해서 최적화하는 거 많음 영상처리에서 미분을 a[n]-a[n-1]로 정리해버린다거나
수학 안하고 게임 만드는건 힘들긴하겠구나
왜냐먄 존 카멕도 퍼온거라서그럼 https://ko.m.wikipedia.org/wiki/%EA%B3%A0%EC%86%8D_%EC%97%AD_%EC%A0%9C%EA%B3%B1%EA%B7%BC 실리콘 그래픽스라는 회사에서만든 알고리즘 다만 이걸 인터넷도 없던시절에 찾아서 넣은건대단한거맞음
코?딩
의외로 이산수학으로 수식을 쉽게 정리해서 최적화하는 거 많음 영상처리에서 미분을 a[n]-a[n-1]로 정리해버린다거나
사실 수식보다는 복잡한 연산은 미리 계산해서 때려박는 경우가 많죠. 저기있는 값도 그렇고... 요구되는 정확도 수준의 계산결과를 아예 값으로 미리 넣어두고(아주 러프한 예 : 루트2를 굳이 구하지 않고 1.41421356... 이런값으로 넣어둔다거나. 삼각함수같은건 필요한 input값에 따른 적정 precision의 output을 matrix에 각각의 값을 넣어둔다거나) 비단 그래픽스에 국한된 것은 아니지만, 특히나 실시간성이 중요한 게임 그래픽스에서는 저런 최적화들을 아주 필수적으로 많이 합니다. 리얼타임성이 없다면 굳이 굳이 할 필요 없는 최적화들은 안하긴 하지만. 아무튼 이건 game 개발 분야라기보단 computer graphics, 그중에서도 game(=real-time) graphics 분야죠. 뭐 본문 시기에는 game/graphics engine이라는 개념자체가 정착하기도 전이니까 게임개발의 영역으로 분류해도 무방하지만 지금은 확실히 아님ㅋㅋ
확실히 지금 게임개발자란 사람들이 저런 함수 짜고있지 않긴 하죠 ㅋㅋ
가끔 최적화 코드에 저런 방식을 쓰긴하는데, 그건 뭐 엔진 개발자들이 다함..
수학 안하고 게임 만드는건 힘들긴하겠구나
수인
수포자가 게임 개발자가 되겠다는걸 비웃는 이유
보통 프밍에서 수학 쓴다고 하면 데이터, 신호처리, 3D 세 분야가 대표적이지 그거 다들어가는 게 게임이고.. 웹프론트같은 거 하면 사칙연산만 잘해도 되긴 함
수인
저런 코드들이 모여서 최적화가 되는거라... 최적화 못 하는 게임들은 저런 코드 못 만드는 개발팀으로 보면 될듯
인디게임 : 그래서 우리가 최적화가 구려요
프로그래머들도 다 공업수학 듣잖아, 미적분 테일러급수 다 나오는데 수포자가 가능함?
고등학교가서 수포자 게임개발자 손들라고 하면 몇명있어
기획도 사실 수학(어렵진 않음) 많이 써야해서 ㅋㅋ
요즘 게임은 규모가 영화제작 급이라 참여하고 싶으면 여러 분야에서 가능 하긴함 기획팀, 제작팀, 디자인팀, 마케팅팀 등등
가능함 하지만 한계가 명확하지 특히 인디나 1인개발이라면 만들 수 있는 퀄리티가 더더욱 제한됨
삼각함수가 테일러급수로 구현되어있긴 한데 테일러급수를 몰라도 삼각함수를 쓸 수 있으니까
아니 요즘은 하드웨어가 빨라져서 저렇게까지 할일은 없음. 그냥 뻘짓거리 코드만 없어도 속도는 충분히 나옴.
밸런싱 잡는것도 사실 수학이들감.. 수학포기하는건 힘듬 나중이든 처음이든 수학의벽에 막힐뿐
공업수학말고 이산수학 들음
사실 필요 없음. 저런거는 그래픽 엔진 관련된 부분인데 현재 게임개발자중 그래픽 엔진 다뤄야 하는 사람이 1%는 되려나... 저런게 있는지도 모르는 개발자(프로그래머)가 대다수고 실제로 몰라도 됩니다. 그래픽스 다뤄야 하는 인력이 아닌데 저런거 최적화 할 일도 없고요, 하겠다고 나설 일도 없겠지만 혹시 수정하겠다고 나서면 당연히 말립니다.
ㅎㅎ.. ㅋㅋ.. ㅈㅅ..
??? : 달리기 하는데 보법이 왜 필요해요. 그건 걷는 방법인데 대충 바꿔서 표현하면 이런거?
요새 겜개발자들은 수포자구나!
심지어 웃기는 건 바로 옆동내 QA도 필요합니다. 바로 통계 부문인데, 여기에 미적분이 들어갑니다. 미적분이 왜 들어가냐면, 지금 버그 상태로는 몇개월 내로는 출시 가능이 아니라, 출시하면 안되요 라는 날짜가 산정됩니다. 그래서 QA가 제시한 날짜 이내로 출시하는 회사는 리스크를 안고 출시하겠다는 뜻이죠. 보통은 QA가 반대합니다. 아, 가끔 이거 할 줄 모르는 QA가 있긴 함. 그런건 QA가 아니고 STE라고 테스터입니다. QA는 이거 할 줄 알아야해요. 그리고 페어와이즈도 그렇고, 온갖 QA 스킬의 알고리즘이 수학투성이입니다. 테스트 케이스가 무한대이거 수십 수백만인데, 이걸 3000개이내로 압축하고 전체 테스트 95%을 한 효율을 내는 걸 뽑는 게 QA의 역활입니다. 이거? STE는 못합니다. QA만 할 수 있어요.
요샌 아님.. 요샌 저런 식의 최적화 코드를 거의 짜지도 않을 뿐더러(저거 짜는 시간에 버그 없게 만들어라...소리함) 짤 일이 있다한들 대부분 엔진에서 하지 개발자가 직접할 일은 거의 없음.
나 수포자인데 개발자함 저런건 어차피 창작이 아니라 변형이라 어떻게든 굴러가게 만들면 인터넷에 최적화 하는건 널려있음. 어떻게든 굴러가게 하는게 더 중요한거라 최적화는 닝기미 그래서 사이버펑크 잘 팔아먹고 그런거잖아?
??? : 최적화?? 그게 대체 뭐에요? 시대는!!! 모듈화!!! 객체지향!!! 복붙!!! 유저가 컴터 바꿔야죠!!!
저건 당시의 극악한 환경에서 하는 일이고 대부분은 저런거 신경 쓸 일이 없음
어떤 QA를 하냐에 따라 요구조건이 달라서 미적분같은건 꼭 필요하다고 말하긴 어렵죠. 플랫폼이냐 게임이냐 등등에 따라 조건이 다르다보니.
QA 스킬중 더 발전된 테스트/ 통계 / 분석 부문이 있는데 통계 부문에서 필요한거라 필수입니다. 그리고 미적분이 어떻게 쓰이냐면, 전체 이슈/ 해결 되어가는 이슈의 속도/ 미 해결 이슈 를 통해서 기울기가 나와요. 기울기인거에서 눈치 챘겠지만, 네 그 미적분입니다. 말이 미적분이 정확히는 버그들이 고쳐지는 평균 속도에요. 한달 발생하는 버그 추이가 10개이고, 고쳐지는 버그의 속도가 20개인데, 현재 총 버그수가 50개이다? 최소한 이 추이대로라면 5개월은 지나야 버그가 0에 수렴한다는 걸 알겠죠. 이게 장기 관측일수록 부적확한데, 어차피 중간에 계속 수정합니다. 그 주기는 매번 테스트 완료 후 보고서 작성때 마다입니다. 이런건 그냥 이슈 보고서에 숫자만 넣으면 자동으로 계산되게 툴이나 엑셀파일이나 직접 만들어놔야 합니다. 이런 정보를 제공 조차 못하는 QA는 제대로 안 배운거에요. 엄청나게 중요한 정보거든요. 당신 제품은 최소한 이 기간 동안은 출시하면 리스크가 있다고 알려주는 정보인데. 이걸 못하면 안 되니까 알아야 하는 이유에요. 변화량 / 델타T 죠. 뭐. 항상 다 아는 그거
써주신 내용으로 볼땐 기계같은 제품QA에 가까워 보이는군요. 그리고 버그 숫자에 미적분학을 적용하여 출시 일을 산정하는건 게임을 테스트 할 경우 별로 쓸모없어 보입니다. 고치는건 개발자인 사람일텐데 그게 딱딱 맞아 떨어질꺼라 생각되진 않아서요.
신기하게도 님의 예상과는 달리 수십년 이상 된거에요... 그게 심지어 지금까지도 쓰이죠 이 주장은 제가 한게 아니라 NASA 쪽 사람들이 시작한 걸 오랜 세월 경험 하고 만든 것들이 지금 까지 이어져 온겁니다. 이게 가장 보수적인 QA에요 기계적인게 아니라. 일반적인 QA 커리큘럼 그것도 가장 기초적인 커리큘럼에 담겨 있어요. 이게 ISTQB A/L이나 E/L (전문가 과정)이 아닌 ISTQB F/L(기초과정)인 이유는 이게 아주 초보적인 내용이에요. 솔직히 말하면 말이 미적분이지 통계 결과만 가지고 그 안의 내용은 고1도 배우면 할 수 있는 내용입니다. IEEE 829 1998 STD 같은 거나 여러가지 아주 전통적인 그리고 무척이나 보수 적인 지금까지 온건 지금도 통하지만, 다른 문제로는 잘 지키지 않아서 그래요 특히 한국 게임 QA 왜 한국 게임이 버그가 많은데. 이런 보수적인거에서 자기 필요한것만 꺼내서 써야 하는데 다 무시하고 우리회사는 달라.. 우리는 게임회사니까 달라. 그러는 거에요. 무슨 우주선 만드는 소프트웨어도 잘만 지켜서 하고 있는데 게임이라고 이거보다 얼마나 대단하다고... 제가 게임 회사 잠시 가봤을때도 수석개발 엔지니어가 QA랑 TEST의 차이도 모르고 있던데. 아니 test와 testing의 차이도 모르고 있었어요. 제가 직접 물어보고 얼마나 여기 루리웹에서 욕을 먹었는지, 근데 게임 나오고 버그 투성이였죠. 괜히 저만 억울했어요. 그게 한국 굴지의 유명 게임사라니.. 하고 놀란 기억이 나네요. 그리고 언제 출시하면 얼만큼의 리스크가 있는지는 각자의 부서에서 내놔야 하는 최중요 정보중 하나인데 이걸 무시한다고요? 정상적인 경영진이면 무시해서는 안되는 정보에요. 그리고 무슨 소프트웨어 회사이던 개발 절차가 인크리즈먼트한 방법이던, 그놈의 에자일 방식이던(맨날 개발자가 문서 안 만들겠다고 주장하는 그 빌어먹을 이해도 못하면서 주장하는 프로세스) 출시 일자 예상 이나 리스크 계산이 무시 되는 정보라는 건 들어 본적 없어요.
제가 STEN 쪽 거기 권대표님 과도 이야기 해봤을때도 이걸 기계적이라고 칭하지는 않았어요. 너무 보수적이라고 표현했지. 네 맞아요 이건 보수 적인것이지 기계적인게 아니에요. 보통은 어떻게 하냐면 그건 전체가 다 들어간거니, 거기에서 필요 없는걸 빼거나 최적화를 시키지 이걸 기계적이라고 안해요. 심지어 저조차도 13년 동안 대부분의 경우 거의 그대로 써도 문제가 없을 판이였어요. (수십년이나 써먹어뎄는데, 조금만 손보는 정도지, 그거 보다 더 잘할려면 각종 알고리즘이나 논문을 써대야하는 두뇌 정도는 되야 하는 거에요. 이게 전문 분야가 또 따로 있더군요. 거긴 진짜 수학을 함 우리같이 대학 1학년 수준의 수학으로 해먹는 얼치기가 아니라.) 저는 페어와이즈에 무슨 XXXX알고리즘이라느니 하면서 증명하는 논문 같은 내용이 나와서 식겁한 적 있어요. 어째서 이게 전체 테스트의 9x%효율이 나오는가를 증명하는 게 나오더군요. 보고도 이해를 못해먹겠음. 대부분 조합에서 나온다는 그런 설명만 대충 하지 그게 왜 증명되는지는 설명 안한다고요. 나는 그런 사람들 보다 머리가 좋다고 자랑 하지는 않음. 기계적이라느니, 우리 회사에는 안 맞는다느니 하는 그런거요.
그리고 그렇게 불필요햇으면 이슈 트레킹 도구에서 자동 생성되는 정보로 제공을 안해요 네 그냥 이슈트레킹 툴에 있어요, 손으로 만들때나 엑셀에서 만드는 거지. 보통은 이슈트레킹 도구 다들 아는 그 맨티스라던가.. 거기에 그냥 떡하니 기본으로 박혀 있어요. 날짜랑 프로젝트같은 범주만 정해주면 어떻게 만드는 몰라도 그냥 자동으로 만들어준다고요. 5분이면 만들어주는 정보를 그냥 무시하는 회사라는건.. 도대체... 이렇게 중요하고 강력한 정보를.. 무시하고 기계적이라니... 정보 자체는 기계적으로 뽑히긴 하죠. 툴에서 클릭질하면 뽑히니까...
댓글은 잘 읽어봤는데 개인적으론 필수라고 하기엔 과하다 싶네요. 이런걸 아는 인력이 있으면 좋겠지만요. 우주선 만드는 소프트웨어야 당연히 거기서 버그가 나오면 엄청난 돈이 깨지니까 말씀하신 부분이 맞을 수 있고 수백,수천만원 하는 제품 QA라면 필수는 아니더라도 그런 리딩자가 있으면 좋겠지만 게임QA에 저정도 필요한진 역시 모르겠네요. 그리고 소프트웨어QA라면 모를까 게임QA에 ISTQB역시 필요한지도 모르겠네요.
간단하게 특정 행동을 한다를 Pass로 잡는다면 소프트웨어QA라면 Pass일 수 있으나 게임QA의 경우 그 행동이 재미없다면 Pass로 끝나는게 아니라 피드백이 들어가야 하죠. 올Pass라고 해도 재미가 없다면 QA를 잘했다 할 수 없고 Fail이 더 생기더라도 유저들이 더 재미있게 만드는게 중요하니까요. 이런걸 수치상으로 보여줄 수 있을까요? 그래서 의미없다고 말하는겁니다.
왜 필수이냐면, 자원 산정 때문이에요. QA 커리큘럼에서 가장 앞부분에서 강조하죠. QA의 역활은 한마디로 말하면 잔체 프로젝트의 비용과 리스크을 줄이는 거라고. 게임의 재미는 다른 팀에서 담당하는거에요. 상층부에서 정하는거에요. QA가 디자인을 바꾸라고 하나요? QA 역활 자체도 이해를 못하셨으면 안되요. 이거 기초 커리큘럼에 있어요. 그것도 상당히 앞줄에 있고. 제가 QA 기초 서적을 5권 가지고 있는데, 전부다 QA가 그런 역활을 한다는 건 들어보지도 못했어요. 게임이 재미있나 없나는 의견 까지는 낼 수 있어도 그건 QA의 역활이 아닙니다. ISTQB 에서 정하는 품질의 정의는 요구사항의 준수 여부이지, 재미있네 없네, 보안 능력이 높네 낮네 효율적으로 돌아가네가 아니에요. 의견이야 연관 부서니까 낼수는 있지만 그건 QA의 역활이 아닙니다. 재미를 관장하는 부서가 있고, 그걸 요구사항과 디자인으로 만들어주면 우리고 가글 제대로 만들었는지 확인하는게 QA이고. 개발자가 그런한걸 만드는데 프로세스와 요구사항을 준수 했는지 확인하는게 QA이고. 재미있냐는 다른 부서에서 디자인 하는거에요. 우리의 주 역활은 아닙니다. QA가 그렇게 재미를 잘 알았음 게임 디자인 하고, 계획 하고 스케쥴 짰겠죠. 요구사항의 제작은 우리 역활이 아닙니다. 우리는 검수 하는 자들입니다. 그리고 QA는 특히 내부 QA는 독립단계 3의 부서입니다. 우리가 독립단계 4나 5이상의 자들 또는 1에서 일하는 자들의 역활을 해야 할 필요는 없어요. 마지막으로 재미 요소를 변경 하는 건 QA의 월권 행위입니다. 작은 회사면 모르겠지만. 아니 작아도 그렇게 하면 안될 것 같긴 하지만. 그리고 소프트웨어의 성공은 항상 모르는 겁니다. 우리는 소프트웨어를 성공 시키는 부서가 아니라, 실패하지 않게 하는 부서고, 자원을 절약하게 하는 부서지. 재미 요소를 디자인하거나, 평가하거나, 알아오는 부서가 아니에요. (저 역활은 각각 따로 부서나 팀이 있습니다. 결국 QA가 아니에요.) 우리 본연의 역활인 품질 검수를 해야죠. QA의 약자가 뭐의 약자인데요.? 그리고 님이 말하는 건 비 정량적 요소의 측정이라고, QA스킬에 있습니다. 안배우셨나요? 이것 조차 억지로 정량화 시켜서 재출 할 수 있습니다. 내 바로 그 재미 요소에요. 이것도 수학이 들어갑니다. 억지로 CTM으로 만들어 버리기까지 하고 저도 해봤는데. QA쪽 통계 기술을 전혀 안 배워보셨다면.. 뭐... 알수 없는 내용이겠죠.
정확히 말하면 없어도 돌아는 가는 정보지만, QA 본연의 업무에 총실하지 않았다는게 제 의견입니다. 아시는지 모르겠지만, 테스트 자체는 개발자만으로도 돌아가요. 이걸 독립단계 1과 2에서 하는 테스트입니다. 하지만 그들은 이런 통계를 내서 전체 팀에 공유 하는 스킬은 배우지 않아요. 이게 QA의 역활이기도 하고.
회사마다 케바케겠지만 강요는 안해도 의견은 냅니다. 그리고 저희쪽은 주요업무 중 하나입니다. 우리의 주 역할이 아니다 등은 본인 혹은 다니는 회사, 일 기준이 아닐까요? 검수라는거에 재미에 대한 검수가 들어갈 수 있는 부분이죠. 재미 요소 변경을 강제하는건 월권이겠지만 의견을 내는게 월권은 아닐겁니다. QA의 약자를 언급하셨는데 Quality Assurance. 품질검수. 근데 게임의 품질검수에서 재미부분을 빼면 안된다고 생각하는데 이건 개인마다 생각이 다를 수 있는 부분이니 패스하겠습니다. 그런데 말투에서 은근히 사람을 무시하는 부분이 있군요.(안배우셨나요? 알수 없는 내용이겠죠 등) 배운게 많으셔서 자부심이 있어서 그런진 모르겠지만 저라면 차라리 위 내용 모르는 분과 일하겠습니다. 이론이 다는 아니니까요.
아는게 많은 분일 것 같아서 의견을 내봤던건데 왜 보수적이라는지도 알 것 같고 제가 배울것은 없어보이는군요. 의견이 다르니 평행선을 달리듯하니 전 차단을하고 제 방식대로 QA를 하겠습니다. 아이퐁7님은 본인 방식대로 하시면 되겠죠.
어떤놈이 와서 아무생각 없이 변수형 바꾸면 대참사
수학이 신의 언어라고 하는게 진짜 맞나벼
일반 프로그래머는 저런걸 만들지 않고 만들어진 함수를 그냥 가져다 쓴다. 내가 죽도록 노력해봐야 기존에 만든것보다 못하거든..
Diamajil
퀘이크정도면 기존에 만들어진 게 없을 때지 ㅋㅋㅋ
저런 걸 갖다 쓰는 거지 뭐
ㄹㅇ 내가 죽어라고 최적화시켜만들어도 저런거 발끝이나갈려나싶은 코드가있음
하드웨어 리소스 자체가 옛날보다 월등하게 좋아진것도 있기도 하고 저런거 만들던 사람이 라이브러리 함수 다 만둘어준건데 괜히 내가 최적화한답시고 첨부터 짜는거보다 더 효율적이니 ㅋㅋ
cpp 정렬 알고리즘 공부하다보면 그냥 std sort가 최고더라...
ㄹㅇㅋㅋ 그냥 똑똑한 애들이 만들어 논거 가져다가 씀 물론 그냥 가져다가 복붙하면 공부가 안되니까 적당히 수박겉핥기식으로라도 이해하면 공부도 되면서 좋음 물론 몇주지나면 까먹지만
근데 로직 보면.. ㄹㅇ 월클급 프로그래머들은 '저걸 저렇게 만들었다고?!!!!!' 싶음 뭐 와우 할때, 해외 공대들 보면서 '저게 어떻게 가능함??'하는거 보는 느낌
사양은 빡빡한데 요구사항은 많을 시절이라 더 그랬을듯. 롬 용량이 kb단위일때부터 게임만들던 인간들이라 최적화에는 도가 텃지..
퀘이크3 정품 있는데 사놓고 아직도 안해봤네. 설치 되려나...
What the f■ck?!
https://youtu.be/i2Yf6Uwe9do 이거 말하는건줄 알았네 ㅋㅋ
내가 이거보고 유튜버는 아무나 하는거 아니라고 느꼈음 ㅋㅋ 거짓말은 하나도 없는데, 뭐랄까 포장하는 능력이 진짜 대단들 한것 같음 ㅎ
휴 아트라서 다행이야
으윽 이과놈들....
[삭제된 댓글의 댓글입니다.]
루리웹-5928044566
왜냐먄 존 카멕도 퍼온거라서그럼 https://ko.m.wikipedia.org/wiki/%EA%B3%A0%EC%86%8D_%EC%97%AD_%EC%A0%9C%EA%B3%B1%EA%B7%BC 실리콘 그래픽스라는 회사에서만든 알고리즘 다만 이걸 인터넷도 없던시절에 찾아서 넣은건대단한거맞음
퍼온게 카맥조차 아니네 ====================== 버클리의 William Kahan 과 KC Ng는 1986년 5월에 뉴턴 반복이 뒤따르는 비트 조작 기술을 사용하여 제곱근을 계산하는 방법을 설명하는 미발표 논문을 작성했습니다. [22] 1980년대 후반, Ardent Computer 의 Cleve Moler 는 이 기술에 대해 배웠고 [23] 동료인 Greg Walsh에게 전달했습니다. Greg Walsh는 현재 유명한 상수 및 빠른 역 제곱근 알고리즘을 고안했습니다. Gary Tarolli는 당시 Ardent에 자금을 지원하는 회사인 Kubota의 컨설팅을 담당했으며 1994년경 3dfx Interactive 에 알고리즘을 도입했을 가능성이 높습니다. [24] [6] Jim Blinn 은 IEEE Computer Graphics and Applications 의 1997년 칼럼에서 역 제곱근의 간단한 근사치를 시연했습니다 . 다른 현대 3D 비디오 게임 의 리버스 엔지니어링은 Activision 의 1997년 Interstate '76 에서 알고리즘의 변형을 발견했습니다 . [26] 1999년 id Software 에서 출시 한 1인칭 슈팅 비디오 게임인 Quake III Arena 는 이 알고리즘을 사용했습니다. Brian Hook은 알고리즘을 3dfx에서 id Software로 가져왔을 수 있습니다. [24] 빠른 역 제곱근 코드의 사본은 빠르면 2002년 또는 2003년에 유즈넷 및 기타 포럼에 나타났습니다. 누가 알고리즘을 작성했으며 상수가 어떻게 파생되었는지에 대한 추측이 일어났습니다. 일부는 John Carmack 을 추측 했습니다. [6] Quake III의 전체 소스 코드는 QuakeCon 2005 에서 공개 되었지만 답변을 제공하지 않았습니다. 저자 질문은 2006년에 답변되었습니다. [24] 2007년에 이 알고리즘은 FPGA(Field Programmable Gate Array ) 를 사용하는 일부 전용 하드웨어 버텍스 셰이더 에서 구현되었습니다.
대단한데
음 그렇군(이해못함)
저거 퀘3 에 쓰이기 전에도 인터넷 구전(?) 코드로 유명 하던거
구글에 고속 역제곱근이라고 검색해보면 위키피디아에 보다 상세한 설명을 볼 수 있는데 거기에 의하면 저 방식이 제곱근표 참조하는 방법보다 빨랐다고 함
프로그래머 하려면 대학에서 수학을 전공해야하나 ㄷㄷ
실력 있는 프로그래머가 되려면 당연. 컴공 교육과정에 수학과목이 필수로 들어있는 이유이기도 하지
수학없이 프로그래밍을 어케해ㅋㅋ
ㄴㄴ 윗댓도 틀린말인게 수학 전공할 시간에 프로그래밍을 공부하는게 맞음. 수학전공하면 플밍으로 안쓰는 대수학 기하학 배울텐데 그건 아님. 물론 공대수학은 잘해야좋겠고 그마저도 게임프로그래밍(솔직히 요구기술에 비해 박봉임)안하면 그닥 큰 필요없음.
플머가 수학을 잘한다와 수학을 전공한다는 엄청난 차이기에...
프로그래밍 대부분은 수학과 논리의 집합체임 그걸 인간 언어와 컴퓨터 동작 원리를 이용해서 표현하는 거라고 보면 됨
엔진 만들거 아니면 내공없어도 외공으로 충분함 ㅎㅎ
ㄴㄴ. 프로그래밍에서 필수적으로 필요하다고 할 수 있는 수학은 이산수학 딱 하나뿐입니다. 어... 물론 중/고등학교 수준의 수학은 항상 필요할 순 있으니까 거기서부터 수포자면 힘들가능성이 꽤 높긴 하겠네요... 그래도 전공지식 수준은 단언컨대 필요없어요. 본문같은 내용의 수학이 필요한 부분은 딱 2부분, 물리 엔진/그래픽스 엔진(그러니까 현실에 대한 일종의 시뮬레이션이 필요한 경우) 이 2가지인데 이부분은 실제로 수학과, 물리학 전공하신 분들도 많이 있고 그분들이 잘해요. 일단 잘한다기 보다도 그분들이 꼭 필요함. 그래서 그 분들이 실제로 코드를 짤 수 있는 개발자일 필요도 없는 경우도 있고요.
수학을 모르냐 아냐에 따라 미래의 연봉 숫자가 달라질거임
요오즘 개발자들은~ 하면서 오들오들하는것도 하드웨어 제약이 큰 환경을 겪을일이 비교적 적어지니 최적화는 개나 줘버린 쓰레기 코드가 난립하는것도 있지
그것보단 그냥 머리가 딸리는거 아닐까
확장성과의 저울질을 한 결과 최적화를 희생한거면 모를까. 아무리 봐도 둘다 거지같은 반복 비효율 코드를 생산하는게 저질 개발자들
머리가 딸려고 코드가 돌아가니까 고민할일이 없지. 콘솔겜 같은거면 그냥 기기가 뻗는다고
이순신하고 현시대 좃밥 장군을 비교 하는 격 현시대에도 뛰어난 개발자들 많고 그 시절에도 멍청한 개발자들 많았음.
문제는 그시절에 멍청한 개발자들은 설데가 없어서 대부분 다른일하러 사라졌지만 지금은 서있다는거지 우리나라 1세대 프로그래머 분들만 해도 심하게 3D업종이였어서 의사나 변호사로 직종변경한 경우가 많았으니..
프로젝트 하면 입만터는 늙은 개발자 아직 존나 많음
.....프로그래머는 걍 포기해야겄네..... 저걸 어떻게 해....
html은 저런거 안 해도됨
저런 최적화 방식을 모두가 짜야만 하는 건 아니에요 프로그래밍도 어느 분야로 가느냐에 따라서 천차만별이고 오픈소스가 내가 짠거보다 좋을 때가 많을 수 있고, 어려운 문제를 풀 때 도움이 되는 구글, 스택오버플로 같은 곳에서 질문하면서 배워나갈 수도 있고, GPT-3 코파일럿 같은 인공지능을 도구로 쓸 수도 있어요 잘 할 수 있는 분야에서부터 하나씩 배워나가면 됩니다
저것도 논문 보고 만든거라 실제로 저런거 만드는 사람은 석박 연구원일껄 프로그래머는 찾아서 읽고 이해만 하면 됨
프로그래머가 저런 알고리즘 일일이 하나씩 짜는거 아님... 대부분은 그냥 누가 만들어놓은거 잘 조합해서 짜는게 대부분 저런 것들은 대부분 석박들이 열심히 만드는거지 그걸 가져다가 잘 조합해서 튼튼하게 만드는게 일반적인 프로그래머 역할임
아 그렇군 (점심 뭐먹지?)
연산횟수 줄이는 기술이 진짜 프로그래밍 천재의 능력이지
(스크롤) (스크롤) (스크롤)
근데 저런 방식이 이른바 레퍼런스임? 다른 게임의 개발중에도 쓸수있는 호환성이 있나
비공식 레퍼런스 api같은거임.. 복잡하게 생각하고 시간 끌것 없이 그냥 갖다 쓰면 최적화되는거
저정도는 당연히 쓸 수 있는 방식임
지금으로 말하면 저게 요즘 핫한 레이트레이싱 같은 기술이라고 보시면 됩니다 레이트레이싱은 많은 연산을 전용 칩을 사용해서 빠르게 처리한거고 저건 범용칩에서 빠르게 처리하기 위해 수학공식을 때려박아서 필요한 연산량 자체를 줄여버린거임
요새는 더 발전된 것이 나와서 쓰이지 않는다고 하지. 수학적 사고능력이 없으면 남이 해놓은 거 찾아서 받아먹거나 비효율적으로 삽질하고 똥 치우고 해야되는데 이런 얘기 지망생들한테 할 때 마다 그냥 돌아가면 되는 거 아니냐면서 요즘 컴퓨팅 자원이 어쩌고 저쩌고 하지. 그럴 때 마다 해주는 말이 돌아가건 말건 결국 그 능력 없어서 꼴받는 건 그 작업 하는 본인이라는거임 ㅋㅋㅋ 그 다음으로 꼴받는 건 같이 일할 팀원과 관리자니, 결국 업무평가 나락가는 것도 본인이고 말이야.
뭐래 씝덕이