Я – хакер! Хроника потерянного поколения

Я решил, что мне все-таки нужен компьютер в общежитии. На новый денег не хватало, пришлось покупать б/у. Конфиг был практически такой же, как и домашний — процессор Celeron, 20 Гб винчестер, монитор чуть побольше 17 дюймов. Монитор был с кинескопом, имел плоский экран, но и дефект — во включенном состоянии на экране постоянно светились две горизонтальные тонкие линии. Стоил этот компьютер 6000–7000 рублей. Недостающие деньги мне дали родители.

Подключение к сети в общаге стоило денег — нужно было оплатить стоимость сетевого кабеля и работу по его прокладке. Этот вариант мне не подходил — денег не было совсем. Я жил на то, что давали родители, а на выходных мотался домой за продуктами. Поэтому вопрос с подключением я решил через Валю, моего соседа из другого блока. Он был подключен к общей сети, и в его компе было два сетевых адаптера. Через окно мы кинули сетевой провод, он воткнул его в свой системник и настроил мост. Я же прикупил себе дешевую сетевую карту PCI и вставил в свой блок.

Интернет у нас был дорогой штукой с оплатой за мегабайты, поэтому фильмы, музыку и программы мы искали в общей сети. Для размещения файлов использовали протокол Samba (виндовская шара). Каждый пользователь задавал имя своего компьютера и рабочую группу. Группы именовались по номерам общежитий: 14, 15, 16 и т. д. Заходя в группу № 15, можно было видеть компьютеры из 15-го общежития, а на компьютерах в открытых папках лежали фильмы, музыка, программы и т. п.

Для общения пользователей в сети использовался Windows Messenger Service, работавший по протоколу NetBEUI over TCP/IP. Под него писали различные мессенджеры сами студенты. Отправлять сообщения можно было как на конкретную машину, так и на всю группу.

А для поиска файлов по расшаренным каталогам в сети были свои поисковые машины. Такая поисковая машина представляла собой сервис, который последовательно перебирал все компьютеры из каждой группы и заносил в свою базу данных названия всех файлов. А также это был веб-интерфейс, позволяющий искать файл по маске названия и выдавать конечные пути на файлы.

Один из таких поисковиков ради интереса написал и я, на C++. Название я выбрал броское — НихуЯндекс, с соответствующим слоганом «Нихуя не найдется».

Мой сканирующий сервис не использовал сторонние базы данных, такие как MySQL, а просто писал все данные в файл на диске. Серверное приложение было написано на том же C++ под Apache. Конечно, топорное решение, но изучать PHP или подобный язык для небольшого сервиса тогда сильно не хотелось.

От других поисковиков мой отличался еще одной функцией: он читал сообщения, приходящие из сети, и, сверяясь со словарем, выделял в них мат и составлял рейтинг самых матерящихся машин в сети. Штука малополезная, зато смешная. Графика

Начиная с последних классов школы, я увлекся компьютерной графикой. Меня очень интересовало, как отрисовываются объекты в таких играх как Doom, Quake, Half-Life. Ведь экран компьютера — это просто область памяти, в которой последовательно хранятся цвета пикселей. Компьютер не знает, что этот шар находится ближе к наблюдателю, чем тот куб. Более того, на игровой сцене могут быть тысячи статических и двигающихся объектов. Если рисовать их все, даже те, что не видны из данного ракурса, отрисовка одного кадра с ними может занять продолжительное время. А для нормального восприятия виртуального мира нужно обеспечить хотя бы 25–30 кадров в секунду.

Кроме того, отрисовка виртуального мира — это не единственная задача, которую решает компьютер. Еще нужно подумать за противников, передвинуть предметы, а если игра с реалистичной физикой, так еще и пересчитать весь физический мир. Как все это возможно?

Изучать разработку игр я начал с библиотеки OpenGL. Она позволяет достаточно просто рисовать трехмерные объекты на двухмерном экране. Настраиваете камеру (изометрическую или перспективу), загружаете текстуры, передаете в библиотеку трехмерные координаты граней, и она отрисовывает их на экране. Все преобразования в таких библиотеках (то же самое Direct 3D) в конечном итоге сводятся к перемножению матриц. Поэтому трехмерная графика так хорошо распараллеливается и рассчитывается на графических процессорах, как раз и заточенных под операции с матрицами.

Возвращаясь к примеру иллюстрации сверху — если сначала отрисовать куб, а потом сферу, все будет так, как надо. А вот если сделать это наоборот, то куб перекроет сферу, хоть и находится позади нее. Все это потому, что компьютер не знает, кто дальше находится от наблюдателя и кого нужно рисовать первым. Конечно, мы можем рассчитывать расстояния до объектов на каждом кадре, но что делать, если объектов слишком много, расчет расстояний для них становится затратным или объекты пересекаются (на рисунке куб заслонил сферу — возникнет артефакт)?