Почитал Ваши замечения по С++ и Венгерскому стилю.... Мда... Вроде Вы и старше меня на 10 лет и в графике вроде как сильны. И книжки пишите, а извините какой-то детский лепет. Всё в кучу собрали.
Я знаю несколько языков программирования. И для каждого найду в любое время своё применение. Судя по всему - не очень то хорошо Вы знаете С++. А 2 эти статьи больше похожи на "почему все на иномарках ездят, ведь наши жигули,москвичи,волги так хороши".
В общем однозначный бред - и как-то это не совпадает с неплохим качеством статей по графике.

Вышла очередная версия GameBase.

Наиболее важные изменения:
- введена система меню (теперь, например, можно изменить разрешение игры во время её выполнения)
- введена подсистема сохранения параметров игры (последние изменения разрешения сохранятся при следующем запуске)
- введены режимы отладки, включаемые клавишами F1, F2
- повышена производительность отображения поля за счёт более рационального использования виртуальных размеров вселенной
- в исходниках задокументированы все подсистемы и системы GameBase

Здравствуйте. Когда наконец выйдет книга???

2Ravent:
Какие модели Вы имеете в виду ?
Если сами уровни - то их практически нет, поскольку нет редактора(конвертера).
Если каке-то mesh-и - то берите любые из списка загружаемых форматов

Насчет форума - это есть в планах, но скорее всего сначала нужно будет сменить хостинг - стандартные возможности на народе несколько ограничивают

2Ivan:
Насчет дельфей - http://www.delphigl.com/
И давайте не будет устраивать flame wars C++ vs Delphi
На дельфи можно писать графику и есть примеры этого, но мне лично больше нравится для этого использовать С/С++

2ALX:
Я выскажу свои соображения чуть позже.

Здраствуйте.
Очень хотелось бы узнать где можно скачать ВСЕ модели к движку Arwen.
И я считаю что пора уже завести форум, а то гостевая уже слишком большая.

Хех... может уже давно не актуально, но я сегодня прикололся.
У кого есть Quake 3 Arena, можете воочию насладится незримой работой, проделанной ID Software по "удалению невидимых полигонов из BSP карты", со всеми вытекающими.

В первых - устанавливаем и запускаем Q3 и заходим в главное меню.
Во вторых выходим в командную строку (нажать тильду - ~) и вводим там:
/devmap q3dm1
После этого загрузится первая карта без ботов в режиме читов (разработчика).

Сперва убедимся насколько хорошо работает механизм предварительного отсечения Potentially Visible Set (PVS). Зайдём в какую нибудь комнату и введем в командной строке:
/r_lockpvs 1
Это строка запрещает движку кваки перестраивать список PVS - фиксирует его.
Теперь попробуем выйти из комнаты и убедимся что PVS работает отлично! :D
введем
/r_lockpvs 0
Это отменит фиксацию PVS.

Далее можно побаловаться с
/r_shownormals 1
, но больше всего меня порадовал режим
/r_showtris 1
Видно ВСЁ! И количество треугольников из которых состоит сцена, и как при движении на заднем плане подключаются и отключаются PVS. Если внимательно наблюдать за контуром своей тени на полу, видно как она рассекается на части чтобы "улечся" в BSP карты (то же самое справедливо для любых тайлов на стенах - например следов от пуль или взрывов). Причём модельки призов и монстров такому рассечению не подвергаются - видимо оттого, что они "подвешены" далеко от стен карты и дешевле их подвергать z-буферизации. А вот тайлы видимо настолько близко прилегают к стенам, что их дешевле рассечь и подключить к рабочему BSP, чем полагаться на z-буфер). С другой стороны подвижные части лабиринта, такие как двери, тоже не рассекаются, может быть поэтому их в q3 на всех 19-уровнях от силы 4-5 штук? :)
В общем наглядное пояснение к статьям квейкоделов. =)

C/C++ доминируют в мире программирования. Юниксоиды с основ написаны на сях, в винде в Пуск->Программы 85% программ написано на MS VC++, 10% на Borland C++ и оставшиеся 5% - на чём то другом. Так уж повелось. Почему так можно рассуждать долго. C/C++ как правило действительно генерирует более компактный и быстрый код, чем Delphi, но мне кажется тут скорее дело привычки.

Здраствуйте. Где можно скачать уроки Опен ЖЛ под Делфи. И еще вопрос, почему так любят Си. Проги под Делфи, мне кажется, более читабельны, а писать под графику так вообще резона нет, объясните, чем Делфи хуже. То, что Си -это для системного программирования - согласен, но для Опен ЖЛ - думаю Паскаля хватит. Неужели Си под Виндовс формирует более компактный код от Делфи , что ради этого стоит страдать. Спасибо.

Здравствуйте!

Прежде всего спасибо автору за полезнейший ресурс!

Сам я не так давно от безделья занялся открытым проектом GameBase, не самые последние исходники,

ресурсы и наполовину написанную сейчас документацию которого можно взять на

www.nvkz.net/adav/programs.html

Цели проекта:

- Создать программный инструментарий, позволяющий разработать любую 3D-игру,
концентрируясь на особенностях этой конкретной игры, оставив реализацию самых
общих игровых решений данной библиотеке. Количество сцеплений с кодом конкретной игры
минимизировано, однако там, где его не удалось избежать вставляется комментарий,
содержащий строку:
GAME DEPENDED CODE (GDC)!!!

- использовать миниммум платформо-зависимых ф-й, чтобы дать предпосылки
для облегчения переноса игры на другие ОС (изначально разработка ведется для ОС Windows).
Однако это не всегда удавалось и там, где пришлось использовать
Windows-ориентированный код вставляется комментарий, содержащий строку:
PLATFORM DEPENDED CODE (PDC)!!!

Этот сайт уже многим помог мне!

Чувствую что во многом изобретаю велосипеды, хотя и имею длительный опыт программирования на C/C++

и кучу прочитанных книжек а-ля "как сделать 3D-игру под DirectX 5.0". Да и общими принципами

игроделания (типа BSP) знаком. Тем не менее буду рад любым замечаниям и напутствиям.
Их можно оставлять здесь, если они представляют ценность для публики, или непосредственно отправлять

на моё мыло: aa_davСОБАКАmail.ru. (СОБАКА заменить на @) Так же хотелось бы оставить ссылку на мою страничку на этом сайте.


Ну и конечно же не могу не обойти стороной статью автора о C++! :D
Читая её постоянно вскакивал с кресла и бродил по комнате бормоча нечленораздельные опровержения,

пугая тем самых окружающих. :))) Такой смеси

Во первых, все программисты C/C++ MUST READ Алена Голуба, которая есть на этом сайте. Много вопросов

и граблей отпадут сами собой, вы научитесь контролировать такой без сомнения сложный язык как C++. В

этом я с автором согласен - ЯЗЫК ДЕЙСТВИТЕЛЬНО СЛОЖЕН. Замечю сразу что в этой книге

рассматриваются и общие для всех языков грабли (треть книги) и грабли, присущие C, и только потом -

грабли C++, так что C++ не корень зла, а лишь логическое продолжение

Во вторых, хотелось бы заметить что в программировании существует разделение на

объектно-ориентированные языки (C++, Delphi, Java) и объектные языки (Perl, JavaScript, возможно

objective-c, что собственно следует из его названия). Если вкратце, то различие между ООП и простым

"объективизмом" в том что объектные языки ориентированы на объекты, а ООП языки - на классы. Другими

словами у ООП языков в отличие от объектных строгая типизация данных. Возможно это послужило

причиной ряда необоснованных обвинений. У объектных язков свои преимущества, но и свои грабли - в

метод легко можно передать неверный объект, что обнаружится только в рантайме, например. Проверять

постоянно есть ли у объекта те или иные методы обременительно как для программиста, так и для

производительности программы.

Насчёт C# здесь распространятся не буду, но можно мой спор с его противниками и мои сравнительные

тесты C# с MS C++ и Borland C++ посмотреть в одном форуме, начиная с этой ссылки и далее:
http://forum.nvkz.net/index.php?showtopic=5000&st=15
Там я - =A=L=X=
В целом я на C# возлагаю большие надежды.

Впервые слышу что к парадигме ООП относят такие "фишки" как persistance или делегирование. Всюду

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

в статье серьезных обоснований чтобы утверждать что C++ с этими вещами не справляется. Наследование

есть даже множественное, чего не встречал ни в одном другом языке! В других языках этот момент

обходят множественным наследованием интерфейсов, которое впрочем сталкивается с теми же самыми

проблемами, что и множественное наследование. Виртуальные ф--ии есть. Инкапсуляция данных - это уже

совесть программиста. Замечу только что инкапсуляцию не надо путать с тотальным "упрятыванием"

данных. Инкапсуляция значит что объекты общаются друг с другом по строго установленному интерфейсу,

не собираясь даже разбираться с тем как этот интерфейс реализован другим классом на внутреннем

уровное. Отсюда растут ноги тому факту что все данные объекта уходят в private и protected секции.
Так что ООП C++ реализует в полной мере.

Насчёт АТД. САМ СТРАУСТРУП ТАК И ПИШЕТ что "одной из целью создания C++ была возможность

создания программистом своих собственных типов данных, с которыми можно было бы работать так же

просто как и с примитивными типами, но при этом чтобы они не уступали им в своей эффективности".

Пример - complex. Просто в языке отсутствует ключевое слово final (как в яве) или sealed (как в C#),

запрещающее наследовать от класса, чтобы закрепить этот момент в умах неопытных программистов.
Все эти "конструкторы копирования" и "операторы присваивания" нужны в языке ТОЛЬКО и ТОЛЬКО для

реализации АТД. Реальные программы, как правило состоят из объектов совсем другого рода, которые

используют АТД наряду с примитивными типами данных. Реальные объекты как правило создаются в куче

и никогда друг другу не присваиваются и не копируются в параметр по значению - посмотрите на MFC или

VCL. Ведь только храня объекты в куче по указателю на них мы имеем в полной мере а) динамические

данные б) "полиморфизм без затыков". Для этого в языке и созданы new и delete - единственные

"узаконенные" RTL ф-ии.
Вся STL - это по сути ядрёная и действительно труднопонятная реализация кучи АТД через шаблоны.

Причем эта куча АТД действительно главным образом предназначена для работы с подобными же АТД! С

этим вряд ли кто то будет спорить, и не вижу в чём тут негатив, кроме того, что действительно хорошего

способа хранить список указателей на объекты с автоматической деструкцией оных в STL действительно

нет. Раз нет - сделай сам, невелик труд...

Бла бла бла... Устал спорить, слишком много спорных моментов, да и не люблю споры, не проходящие в

личном общении за кружечкой-другой пивца, просто попытаюсь дать своё видение суммирования

негативных черт C++, как их подытожил сам автор:

> 1. Переход с на С++ очнь сложен, многие специалитсы считают,
> что лучше учить С++ с нуля. В С++ масса хитрых ловушек,
> просто непонятных для пользователей С++.

Согласен. Все дружно читаем хорошую литературу и ОБЯЗАТЕЛЬНО Алена Голуба, который или ссылка на

которого есть на этом сайте. Даже если вы программируете на C или любом другом ЯВУ первые главы

книги будут крайне полезны.

>> 2. Неявно добавляемый самим компилятором код может убить эффективность полностью.

Может. Вывод из первого пункта - сперва разберись, потом программируй. Пример с путаницей передачи

по значению с передачей по ссылке мне тоже не понравился - это есть во всех языках, C++ тут ни при чём.

Кстати из того же Голуба - передача по ссылке в C++ является альтернативой передачи указателя на

переменную, и не должна применятся нигде кроме как в конструкторах копирования, перегрузки

операторов и т.п. Т.е. там, для чего передача по ссылке вообще была введена в язык. Естественнее вместо

&a + &b писать a + b, или еще чего хуже: a.operator+( &b ). В прочих методах передавайте указатель на

объект/переменную если хотите самозадокументировать ф-ю.

>> 3. Известен способ, как заставить компилятор не выдавать ошибку
>> на неверное количество параметров, передаваемых функции.

В C для этого достаточно было просто не подключать заголовочный файл модуля, где ф-я определена.
При этом компилятор, не видя определения ф-ии полагает что ф-я имеет произвольное число параметров,

каждый из которых - int (по умолчанию).
Именно поэтому мы можем определять ф-ю main как void main(), как int main() или как int main( char *... ),

RTL всё равно вызовет её, передав все параметры.
Связь ф-ий происходит линкером исключительно ориентируясь на имя ф-ии, без учёта сколько у неё

аргументов и какое у неё возвращаемое значение.
Это известная фишка всего семейства C/C++, думаю что C++ просто унаследовал это поведение от C,

который в свою очередь унаследовал это поведение от ассемблера, на который равнялся. Так что

собственно C++ обвинять не в чем. Это общая проблема концепции заголовочных файлов, компилируемых

в *.obj файлы модулей, которые потом будут линковаться друг с другом линкером исходя только из

мнемонических имён идентификаторов, которые с точки зрения линкера являются просто адресами в

адресном пространстве целевого EXE, DLL или LIB. Проверка типов и ф-ий происходит только в момент

компиляции на основании заголовочных файлов. Это можно выставлять как минус - долгая сборка

заголовочных файлов и потенциальные грабли зашитые в неверной декларации ф-ий, так и как плюс - C++

был совместим со всеми языками, генерирующими *.OBJ файлы. В то время когда язык создавался второе,

очевидно, было важнее.

Что касается в целом контроля корректности введенных программистом выражений попробуйте в C,

например, такое: ((void (*)())0)(); :)))

Ладно, в целом вечности не хватит чтобы спорить на подобные как их метко Ален Голуб назвал

"религиозные" темы, но не мог не высказаться, распирало. ;)

А вообще надеюсь что то полезное из моего начинания тоже выйдет.

Насчет D не знаю, никогда не пробовал.
Но с очень большим подозрением отношусь к языкам с жесткой типизацией (как я понял D именно такой) и без нормальной поддержки метаинформации (не знаю как у D дела здесь)

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

http://www.digitalmars.com/d/

Здравствуйте. Посмотрел на оглавление Вашей книги о расширениях и не нашел ничего о GL_KTX_buffer_region. Если вы с ним знакомы, может быть знаете, почему оно упорно отказывается работать на ATI Radeon-ах?

Не знаю на счет ссылки, но когда учился сайты делать, читал про дизайн - четко запомнил, что выполненый сайт в светлых тонах (не ярких) намного легче воспринимается психически, причем должна быть соблюдена уветовая гамма - но это уже дело дизайнера, а не программиста. Вот.

СПасибо за программистский юмор.

Насчет изменения цвета фона - мне кажется, что слишком яркий фон будет просто утомлять глаза.
А насчет - считается - не могли бы Вы дать ссылку, мне будет интересно прочитать доводы против черного фона.

Привет, я смотрю ваш сайт сильно развился - просто круто. есть что почитать (и очень много :)). Хотел спросить, может стоит дизайн немного изменить - считается, что черный фон не благоприятен. Вот допустим если сделать белый.. но это чисто мое ИМО.