HLFX.Ru Forum
профиль •  правила •  регистрация •  календарь •  народ •  FAQ •  поиск •  новое •  сутки •  главная •  выход  
HLFX.Ru Forum HLFX.Ru Forum > Разработка игр > Наши проекты > XashNT: блог разработчика
Часть I
Страницы (240): « Первая ... « 19 20 21 22 [23] 24 25 26 27 » ... Последняя »   Предыдущая тема   Следующая тема
Автор
Тема Новая тема    Ответить
 Дядя Миша
racing for fish

Дата регистрации: Oct 2005
Проживает: Кубань
Сообщений: 32189
Нанёс повреждений: 392 ед.

Рейтинг



thambs это мои материалы такие. К С++ это отношения не имеет.

Добавлено 19-10-2019 в 00:14:

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

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Сообщить модератору | | IP: Записан
Сообщение: 184899

Старое сообщение 18-10-2019 21:14
-
 XaeroX
Crystice Softworks

Дата регистрации: Oct 2005
Проживает: Торонто
Сообщений: 34498
Нанёс повреждений: 514 ед.
Возраст: 37

Рейтинг



Награды
 
[1 награда]


Цитата:
Дядя Миша писал:
Скажем вот в том же ку3, если шейдер не был прописан явным образом, он генерировался в коде из каких-то дефолтных настроек.

Кажется, настал Великий день, когда Дядя Миша наконец-то разобрался, что в ку3 (и в Волатиле) вовсе не обязательно "прописывать для каждой текстуры шейдер". И перестанет пугать этим выдуманным фактом потенциальных пользователей Волатилы до полусмерти.
Ура, товарищи! Свершилось!!!

__________________
Правдой дорожить, лжи не потакать,
Дальних не судить, ближним помогать,
С тишиной сойтись на исходе дня
Научи меня, Родина моя!

Сообщить модератору | | IP: Записан
Сообщение: 184900

Старое сообщение 19-10-2019 07:06
-
 Дядя Миша
racing for fish

Дата регистрации: Oct 2005
Проживает: Кубань
Сообщений: 32189
Нанёс повреждений: 392 ед.

Рейтинг



Цитата:
XaeroX писал:
наконец-то разобрался, что в ку3 (и в Волатиле) вовсе не обязательно "прописывать для каждой текстуры шейдер"

Всегда знал, но хорошего в этом мало. Дефолты не перегрузишь, не переопределишь никак.

Добавлено 19-10-2019 в 11:13:

К тому же сам язык кутришных шейдеров устарел, это язык для FFP-фунционала, он просто не нужен в таком виде. Ну хотя Волатила и так неявно использует FFP-модель.

Добавлено 19-10-2019 в 11:22:

Вот вам кстати наглядный пример как программы усложняются со временем на ровном месте. В квейке для парсинга текстовых файлов использовалась простейшая функция COM_ParseFile и этого хватало для всех случаев. А теперь в новомодных движках все скрипты пытаются сделать на базе XML.
Уже не говоря о том, что лично мне представляется небесспорной сама идя XML, так его пытаются использовать для простейших вещей, типа сохранения тех же конфигов. На мой взгляд смысла в подобных скриптах нет никакого, интерпретаторы тех же крестов спокойно разбирают вполне человеческий код, без всяких идиотских тэгов. То есть оно по сути не нужно никому, ни человеку, который в блокноте XML уже не отредактирует, ни парсеру, который справится с любым форматом текста. Очевидно что под эти скрипты надо еще и свой редактор писать. Из вики мне особенно понравилась вот эта строчка:
Цитата:
− Примитивная библиотека может делать неоптимальный XML (например, <tag></tag> вместо <tag /> ). Работающая оптимально намного сложнее в программировании.

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

Добавлено 19-10-2019 в 11:46:

Кстати вот к вопросу парсинга. Я учёт приходов\расходов веду в обычных .txt файлах. Пробовал когда-то программы для учёта финансов, но эти прогаммы все устроены по идиотски, там какие-то поля надо заполнять, причём именно так, как того хочет сам автор программы, т.е. надо как минимум разбираться, что он там имел в виду. Я в своё время выработал свой формат записи, не предназначенный для парсинга вообще, просто обычные записи в блокноте, примерно такого плана:

C++ Source Code:
1
Месяц Год
2
 
3
Доходы:
4
 
5
дата
6
источник     - сумма
7
 
8
дата
9
источник     - сумма
10
 
11
...
12
 
13
дата
14
источник     - сумма
15
 
16
Расходы:
17
 
18
дата
19
цель     - сумма
20
 
21
дата
22
цель     - сумма
23
 
24
...
25
 
26
дата
27
цель     - сумма
28
 
29
Итого:

Должно быть понятно, что основную сложность представляло подведение баланса, считал вручную на калькуляторе, но это отнимало порядочно времени. В какой-то момент мне это надоело, я сел и написал маленькую консольную утилитку, которая не только парсит такой формат файлов, но еще и находит в них некоторые ошибки (например, если месяц с годом в шапке указан один, а в списке дата неверная), подбивает баланс и выводит итоговый отчёт, причём баланс за месяц она пишет в тот же самый файлик, сверяясь с текущей датой и убедившись, что месяц завершен, аналогично формируется промежуточный и годовой отчёт.
У нее нет никаких параметров, очередная кнопка сделать круто. Запустил и через полсекунды всё готово. Писал я её где-то часа четыре, весит 20 килобайт, отвечает всем поставленным задачам, прекрасно разбирает обычный человеческий текст, который вообще не предназначался для парсинга никогда. Так вот и какой смысл городить все огороды, спрашивается. Очевидный ответ - несолидно, надо больше всего, надо чтоб место занимало, надо чтоб интерфейс красивый, надо чтоб кнопок всяких и побольше. Главная цель за всем этим куда-то исчезла.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Сообщить модератору | | IP: Записан
Сообщение: 184901

Старое сообщение 19-10-2019 08:46
-
 XaeroX
Crystice Softworks

Дата регистрации: Oct 2005
Проживает: Торонто
Сообщений: 34498
Нанёс повреждений: 514 ед.
Возраст: 37

Рейтинг



Награды
 
[1 награда]


Цитата:
Дядя Миша писал:
А теперь в новомодных движках все скрипты пытаются сделать на базе XML.

Я в старой волатиле тоже повёлся на это, и сделал XML-конфиги (для HUD). Даже tinyxml-парсер прикрутил. И всё время меня что-то беспокоило, но я не мог понять, что именно. Вроде и модно, и молодёжно, и современно - но кошки на душе скребут.
А потом я разобрался. Удалил в новой волатиле все эти xml-ы нафиг и сделал обычные парсеры на основе COM_Parse. И тут же стало легко и приятно на душе. И конфиги стали выглядеть прилично, а не как говно, пестрящее угловыми скобками.
Цитата:
Дядя Миша писал:
Ну хотя Волатила и так неявно использует FFP-модель.

Я больше скажу - абсолютно все движки неявно используют FFP-модель. Просто раньше они напрямую использовали функции OpenGL (типа glTexGen и TNT combiners), а теперь пытаются всё это эмулировать через шейдеры. А по сути это тот же набор fixed-функций, ну разве что чуть более расширенный - например, не одна, а три модели освещения на выбор.

Добавлено 19-10-2019 в 15:50:

Цитата:
Дядя Миша писал:
Пробовал когда-то программы для учёта финансов, но эти прогаммы все устроены по идиотски, там какие-то поля надо заполнять, причём именно так, как того хочет сам автор программы, т.е. надо как минимум разбираться, что он там имел в виду.

Открой для себя Microsoft Excel...

__________________
Правдой дорожить, лжи не потакать,
Дальних не судить, ближним помогать,
С тишиной сойтись на исходе дня
Научи меня, Родина моя!

Сообщить модератору | | IP: Записан
Сообщение: 184902

Старое сообщение 19-10-2019 08:50
-
 Дядя Миша
racing for fish

Дата регистрации: Oct 2005
Проживает: Кубань
Сообщений: 32189
Нанёс повреждений: 392 ед.

Рейтинг



Цитата:
XaeroX писал:
И конфиги стали выглядеть прилично, а не как говно, пестрящее угловыми скобками.

С этими тэгами вообще вопрос очень интересный. Если их надо закрывать ровно в той же последовательности, в которой открывал, то чем это лучше фигурных скобок? Очевидно здесь выполняется бессмысленная работа, к тому же еще и увеличивающая размер файлов. Кому это надо? Да никому.
Зачем это сделано? А хрен его знает. Мне больше всего нравится, что эти тэги пользователь еще и вручную определяет, то есть вместо именованного блока, типа:
C++ Source Code:
blockname
{
}

нас заставляют писать
C++ Source Code:
<blockname></blockname>

И сразу же появляется вопрос оптимальности, оказывается можно еще писать
C++ Source Code:
<blockname />

я так понимаю на тот случай, если у нас всё умещается в одну строку. С фигурными скобками этой проблемы не возникает вообще. Я понимаю, что оно от SVG кажется наследуется, а тот в свою очередь был сделан гораздо раньше, но зачем было вообще плодить эти сущности?

Цитата:
XaeroX писал:
Я больше скажу - абсолютно все движки неявно используют FFP-модель

Фиксированный функционал = мультипроходный рендеринг, он в первую очередь завязан на расположении текстурных юнитов. Потом добавили мультитекстурность и стало чуть попроще, но всё равно ты должен располагать эти юниты в определённом порядке, чтобы они правильно смешались между собой. В шейдерах это теряет всякий смысл, нам больше не надо городить блоки
{
map
}
в строго определённой последовательности в описании шейдера. Ну разве что мы будем эмулировать кутришный функционал.

Цитата:
XaeroX писал:
Открой для себя Microsoft Excel...

Ну Эксель как минимум надо поставить, а то еще и купить, мы же чесные программисты и против пиратства? А блокнот изкаропки есть.

Добавлено 19-10-2019 в 12:41:

Материалы-материалами, но походу возникла потребность сделать еще какое-то описание для шейдеров.

C++ Source Code:
frag u_ShaderFrag = "glsl/<rendertype>/bmodelSolid_vp.glsl";
vert u_ShaderVert = "glsl/<rendertype>/bmodelSolid_fp.glsl";

Вот так писать каждый раз в шаблоне еще нормально, а скажем в описании материала уже будет напрягать. К тому же этот объект скорее всего сможет переиспользовать одни и те же шейдеры множество раз, но с разными настройками #define, которые неплохо бы указать общими для такой сущности. То есть сделать для шейдерного объекта генеричное описание, с собственным именем. К тому же мне вероятно понадобится собрать в такой объект не один, а несколько шейдеров, понятно почему - для форварда основной проход, для форварда - освещение, для отложки построение G_BUffer, финальный рендеринг. Т.е. некая сущность над описанием шейдеров. И назвать её, ну скажем shaders.def, навряд ли их там будет слишком много, чтобы городить множество файликов.

Добавлено 19-10-2019 в 12:43:

Причём, я так полагаю формат описания логично унаследовать от описания материалов и шаблонов, чтобы получился настоящий полиморфизм. Это даст возможность конструировать любые типы объектов и перегружать любой параметр для отдельно взятого материала.

Добавлено 19-10-2019 в 13:09:

Посмотрел как в последнем крае это устроено. Ну там все техники, объявленные в шейдерах, жестко привязаны к вызовам этих имён из кода.
Это не то, что мне нужно.

Добавлено 19-10-2019 в 13:11:

То есть вот для примера technique SunShaftsDisplay - она жёстко объявлена в коде в движка, её нельзя переопределить или создать новую технику.
Можно только отредактировать сам шейдер.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Сообщить модератору | | IP: Записан
Сообщение: 184904

Старое сообщение 19-10-2019 10:11
-
a1batross
Житель форума

Дата регистрации: May 2016
Проживает: Москва
Сообщений: 516
Возраст: 26

Рейтинг



Дядя Миша а что если как раз дать переопределять дефолты? А то и разрешать наследование материалов:

default { /* default materials opts */ }

material1 { ... }

material2 : material1 { ... }

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

XaeroX нынче модно молодёжно это JSON.
Который кстати тем же COM_ParseFile в теории можно распарсить.

__________________
Xash3D FWGS форк

Сообщить модератору | | IP: Записан
Сообщение: 184905

Старое сообщение 19-10-2019 10:15
- За что?
nemyax
Нёмыч

Дата регистрации: Jul 2011
Проживает: (void)
Сообщений: 4133

Рейтинг



Цитата:
Дядя Миша писал:
Эксель как минимум надо поставить, а то еще и купить

LibreOffice Calc, да и всё.

Сообщить модератору | | IP: Записан
Сообщение: 184908

Старое сообщение 19-10-2019 10:30
- За что?
thambs
мразь конченная

Дата регистрации: Mar 2006
Проживает: -
Сообщений: 6417

Рейтинг



a1batross
Ну джонсон-то человекочитаем и человекоредактируем в отличие от.

__________________
http://www.moddb.com/mods/monorail-quest

Сообщить модератору | | IP: Записан
Сообщение: 184909

Старое сообщение 19-10-2019 10:35
- За что?
a1batross
Житель форума

Дата регистрации: May 2016
Проживает: Москва
Сообщений: 516
Возраст: 26

Рейтинг



thambs да, так и есть.

__________________
Xash3D FWGS форк

Сообщить модератору | | IP: Записан
Сообщение: 184910

Старое сообщение 19-10-2019 10:36
- За что?
thambs
мразь конченная

Дата регистрации: Mar 2006
Проживает: -
Сообщений: 6417

Рейтинг



Дядя Миша
А материал можно будет автоматически вывести из имени используемой текстуры? Например есть шаблон *wood*, и все текстуры содержащие *wood*, что отдельно не описаны, наследуют этот шаблон?

__________________
http://www.moddb.com/mods/monorail-quest

Сообщить модератору | | IP: Записан
Сообщение: 184911

Старое сообщение 19-10-2019 10:37
- За что?
 Дядя Миша
racing for fish

Дата регистрации: Oct 2005
Проживает: Кубань
Сообщений: 32189
Нанёс повреждений: 392 ед.

Рейтинг



Цитата:
a1batross писал:
а что если как раз дать переопределять дефолты?

ну я про это и говорю. Система наполовину существует в моём воображении, поэтому что-то будет скорее всего меняться, но пока концепция следующая:
1. мы можем создавать шаблоны для определённого типа моделей, типично это спрайты, студиомодели и брашы. Если придумаете по каким еще критериям можно отсортировать объекты на группы, то я могу включить и другие варианты в качестве хинтов, но пока что мне этот кажется наиболее логичным.

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

3. шаблон материалу можно указывать явным образом или не указывать совсем, если присутствуют шаблоны с подсказкой.

4. всё что указано в шаблоне можно переопределить в самом материале, но в большинстве случаев это просто не нужно.

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

Цитата:
thambs писал:
А материал можно будет автоматически вывести из имени используемой текстуры?

нет, такого нет. Мне не нравится эта идея, эти фильтры принципиально неконтролируемы юзером, как поиск по маске почти никогда не находит точно то, что требуется. Он всегда находит либо больше либо меньше, а остальное человек уже должен сам вычленить из списка.

Для описания шейдеров навскидку сделал вот такой формат. Это ни в коем случае не окончательный вариант, это первое приближение.

Добавлено 19-10-2019 в 14:05:

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

Добавлено 19-10-2019 в 14:26:

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

Вложение: scripts.rar (2.0 кб)
Этот файл был скачан 30 раз.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Сообщить модератору | | IP: Записан
Сообщение: 184912

Старое сообщение 19-10-2019 11:26
-
 XaeroX
Crystice Softworks

Дата регистрации: Oct 2005
Проживает: Торонто
Сообщений: 34498
Нанёс повреждений: 514 ед.
Возраст: 37

Рейтинг



Награды
 
[1 награда]


Цитата:
a1batross писал:
нынче модно молодёжно это JSON.
Который кстати тем же COM_ParseFile в теории можно распарсить.

Вот-вот. Поумнел народ с годами. Это радует.
Зато теперь появилось новое ругательство - "парсить джейсоны". Например, сделал человеку плохо, а он тебе - "шоб ты на работе парсил джейсоны!"

__________________
Правдой дорожить, лжи не потакать,
Дальних не судить, ближним помогать,
С тишиной сойтись на исходе дня
Научи меня, Родина моя!

Сообщить модератору | | IP: Записан
Сообщение: 184914

Старое сообщение 19-10-2019 11:49
-
 Дядя Миша
racing for fish

Дата регистрации: Oct 2005
Проживает: Кубань
Сообщений: 32189
Нанёс повреждений: 392 ед.

Рейтинг



Цитата:
За счёт своей лаконичности по сравнению с XML, формат JSON может быть более подходящим для сериализации сложных структур

МБУГОГА. Изобрели новый формат и тут же облили грязью старый, да мол XML этот ваш - гавно. Слышали?

Цитата:
Запись — это неупорядоченное множество пар ключ:значение, заключённое в фигурные скобки «{ }»

Ребята взяли описание энтити от кваки, но чтобы у них всё было "совершенно по другому", добавили еще двоеточие. Впрочем для "сериализации сложных структур" это всё равно не годится. Помните ad_sepulcher для ArcaneDimensions? Ну где 8 тысяч энтить? А в кваке сейвы устроены что твой JSON, ну только без двоеточия. Корочи на этой карте сейв грузится секунд 20. Надо ли говорить что в кувраппере на этой же карте сейв грузится пару секунд? Скрипты для сериализации не годятся абсолютно. Суть скрипта именно вот в том, чтобы их человек мог писать и редактировать. А сохранять в них что-то дурацкая затея. Скажем в той же кваке можно было открыть скрипт в блокноте и написать себе сколько угодно здоровья и пушек. Или там шаблера удолить из сейва, если вы его пройти не можете.

Добавлено 19-10-2019 в 15:15:

Вообще самая быстрая парсилка это fgets + sscanf, я када был молодой и неопытный, то переделал studiomdl со sscanf на COM_ParseFile, ну типо так красивше. И очень удивился, что у меня время на чтение .smd выросло, ну так раз в 10.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Сообщить модератору | | IP: Записан
Сообщение: 184915

Старое сообщение 19-10-2019 12:15
-
thambs
мразь конченная

Дата регистрации: Mar 2006
Проживает: -
Сообщений: 6417

Рейтинг



XaeroX
А зачем их "на работе парсить", когда этим библиотека занимается?

Добавлено 19-10-2019 в 15:34:

Цитата:
Дядя Миша писал:
scripts.rar

А в shaders.def в одни строки заканчиваются на ";\r\n", другие — просто "\r\n". Как оно будет в финале?

__________________
http://www.moddb.com/mods/monorail-quest

Сообщить модератору | | IP: Записан
Сообщение: 184916

Старое сообщение 19-10-2019 12:34
- За что?
 Дядя Миша
racing for fish

Дата регистрации: Oct 2005
Проживает: Кубань
Сообщений: 32189
Нанёс повреждений: 392 ед.

Рейтинг



Мне стало интересно что вообще творится со скриптами в остальных движках, ибо, как известно, современный движок этими самыми скриптами и силён. В этом его главное отличие от кваки, где наоборот всё захардкодено и крутись как хочешь. Ну вот открыл UnrealScript:

Вот к примеру структурки:

C++ Source Code:
1
struct {DOUBLE} double
2
{
3
  var native const int		A;
4
  var native const int		B;
5
};
6
 
7
struct BitArray_Mirror
8
{
9
  var native const pointer IndirectData;
10
  var native const int InlineData[4];
11
  var native const int NumBits;
12
  var native const int MaxBits;
13
};

Ну это то ладно. Вот АТД Vector
C++ Source Code:
1
struct immutable Vector
2
{
3
  var() float X, Y, Z;
4
};

Что такое var я не знаю. А вот насчёт immulatble тоже непонятно. Разве это не тоже самое что final?
А вот наследование:
C++ Source Code:
1
struct immutable Plane extends Vector
2
{
3
  var() float W;
4
};

Константы
C++ Source Code:
const MaxInt = 0x7fffffff;
const Pi = 3.1415926535897932;

Здесь другая крайность - у констант почему-то не указан тип.
Но самая жэсть начинается далее:

C++ Source Code:
1
native(133) static final operator(34) byte *= ( out byte A, byte B );
2
native(198) static final operator(34) byte *= ( out byte A, float B );
3
native(134) static final operator(34) byte /= ( out byte A, byte B );
4
native(135) static final operator(34) byte += ( out byte A, byte B );
5
native(136) static final operator(34) byte -= ( out byte A, byte B );
6
native(137) static final preoperator  byte ++ ( out byte A );
7
native(138) static final preoperator  byte -- ( out byte A );
8
native(139) static final postoperator byte ++ ( out byte A );
9
native(140) static final postoperator byte -- ( out byte A );
10
native(129) static final preoperator  bool  !  ( bool A );
11
native(242) static final k2pure operator(24) bool  == ( bool A, bool B );
12
native(243) static final operator(26) bool  != ( bool A, bool B );
13
native(130) static final operator(30) bool  && ( bool A, skip bool B );
14
native(131) static final operator(30) bool  ^^ ( bool A, bool B );
15
native(132) static final operator(32) bool  || ( bool A, skip bool B );

Вот что это за хрень? Я плохо знаю С++, я даже не знаю, можно ли там перегружать постинскрмент, ну просто не возникало такой надобности, а проверять лениво. Ну здесь как мы видим можно. Но вот эти нативные номера смущают. Это типо как буллетины в первокваке штоли?
И что такое k2pure наконец?

Но вот мы добрались и до функций:
C++ Source Code:
1
static final function float FInterpEaseIn(float A, float B, float Alpha, float Exp)
2
{
3
  return Lerp(A, B, Alpha**Exp);
4
}
5
 
6
static final simulated function k2pure float RandRange( float InMin, float InMax )
7
{
8
  return InMin + (InMax - InMin) * FRand();
9
}

Опять загадочный k2pure. Обратите внимание, что интерпретатор даже не в состоянии догадаться что перед ним функция, ему надо прямо словами написать function. К тому же есть еще загадочный модификатор simulated. Ну вероятно есть и emulated. И вон там двойное умножение, не то взятие адреса, хотя из самой функции вообще непонятно зачем там брать адрес. Ну в принципе достаточно. А теперь ответьте мне на простой вопрос - неужели ВОТ ЭТО легче в освоении, чем кресты?
Мне кажется это тепичная подмена понятий по Конфуцию. Низкоуровневые языки сложны в освоении в первую очередь из-за необходимости "прямой" работы с памятью, в кавычках, потому что там минмум два слоя абстракции - защищеный режим процессора и ядро самой винды. Этож не 286-й, где можно было биосу тень херачить из паскаля. Ну не суть. Народ вообщем не любит когда исключения бросаются. Ну на то и песочница, чтобы разрулить проблемы с памятью. А вот зачем так усложнять синтаксис? Причём этих модификаторов там гораздо больше чем я показал, есть еще interface, event, cpptext, virtual кстати есть, transient, inherits. На кого это вообще рассчитано?
на дезигнеров? Не, ну серъезно.
Как бы на таком фоне неудивительно что они UC дропнули и замутили блупринты. Я их правда не видел, но они вероятно проще, раз с ними даже наш Жэка освоился.

Добавлено 19-10-2019 в 15:51:

Цитата:
thambs писал:
А в shaders.def в одни строки заканчиваются на ";\r\n", другие — просто "\r\n". Как оно будет в финале?

ну щас парсер напишу и посмотрим.

Добавлено 19-10-2019 в 16:02:

C++ Source Code:
1
/** @return the name of the package this object resides in */
2
final function name GetPackageName()
3
{
4
  local Object O;
5
 
6
  O = self;
7
  while (O.Outer != None)
8
  {
9
    O = O.Outer;
10
  }
11
  return O.Name;
12
}
13
 

А тут прямо квакой дыхнуло. local, self

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Сообщить модератору | | IP: Записан
Сообщение: 184917

Старое сообщение 19-10-2019 13:02
-
Тема: (Опционально)
Ваш ответ:



Переводчик транслита


[проверить длину сообщения]
Опции: Автоматическое формирование ссылок: автоматически добавлять [url] и [/url] вокруг интернет адресов.
Уведомление по E-Mail: отправить вам уведомление, если кто-то ответил в тему (только для зарегистрированных пользователей).
Отключить смайлики в сообщении: не преобразовывать текстовые смайлики в картинки.
Показать подпись: добавить вашу подпись в конец сообщения (только зарегистрированные пользователи могут иметь подписи).

Временная зона GMT. Текущее время 07:41. Новая тема    Ответить
Страницы (240): « Первая ... « 19 20 21 22 [23] 24 25 26 27 » ... Последняя »   Предыдущая тема   Следующая тема
HLFX.Ru Forum HLFX.Ru Forum > Разработка игр > Наши проекты > XashNT: блог разработчика
Часть I
Версия для печати | Отправить тему по E-Mail | Подписаться на эту тему

Быстрый переход:
Оцените эту тему:

Правила Форума:
Вы not можете создавать новые темы
Вы not можете отвечать в темы
Вы not можете прикреплять вложения
Вы not можете редактировать ваши сообщения
HTML Код ВЫКЛ
vB Код ВКЛ
Смайлики ВКЛ
[IMG] Код ВКЛ
 

< Обратная связь - HLFX.ru >

На основе vBulletin
Авторское право © 2000 - 2002, Jelsoft Enterprises Limited.
Дизайн и программирование: Crystice Softworks © 2005 - 2024