HLFX.Ru Forum Страницы (255): « Первая ... « 23 24 25 26 [27] 28 29 30 31 » ... Последняя »
Показать все 3825 сообщений этой темы на одной странице

HLFX.Ru Forum (https://hlfx.ru/forum/index.php)
- Наши проекты (https://hlfx.ru/forum/forumdisplay.php?forumid=1)
-- XashNT: блог разработчика (https://hlfx.ru/forum/showthread.php?threadid=5297)

Отправлено Дядя Миша 24-10-2019 в 15:23:

Цитата:
XaeroX писал:
Никто не мешает перегрузить для любого АТД new и delete.

Это да, но мне не даёт покоя мысль, почему Кармак это отключил для д3. Сделал и выключил.

Добавлено 24-10-2019 в 18:23:

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

__________________
My Projects: download page

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

Цитата:

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

Отправлено XaeroX 24-10-2019 в 15:30:

Цитата:
Дядя Миша писал:
что мол опытные программисты, до сих пор имеют о процессорах представление, застывшее на уровне суперскалярной архитектуры первого пня

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

__________________

xaerox on Vivino

Отправлено Дядя Миша 24-10-2019 в 15:31:

XaeroX обижаешь. Это был перевод с английского, на Хабре только их и можно читать.

__________________
My Projects: download page

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

Цитата:

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

Отправлено thambs 25-10-2019 в 03:43:

Дядя Миша

Цитата:
Для остального считаю излишним.

Звуки?

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

Отправлено XaeroX 25-10-2019 в 05:25:

А где асинхронные модели, там и асинхронные текстуры, так-то.

__________________

xaerox on Vivino

Отправлено Дядя Миша 27-10-2019 в 09:06:

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

__________________
My Projects: download page

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

Цитата:

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

Отправлено Дядя Миша 27-10-2019 в 20:28:

Текущий вариант организации скриптов. Здесь всё рабочее, все условия, параметры. всё рулит процессом. Работать становится всё удобнее, я к примеру добавил освещение на брашы, дописав несколько строчек в shaders.def

__________________
My Projects: download page

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

Цитата:

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

Отправлено thambs 27-10-2019 в 20:57:

Дядя Миша
А как порядок наложения декаль-моделей будет рулиться?

code:
"duct_flr02a"
{
	#material vent
}

А такие штуки можно будет в одну строчку писать?

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

Отправлено Дядя Миша 27-10-2019 в 21:36:

thambs не, нельзя.

Этож не просто key-value. Если бы ты дальше промотал. то увидел бы вот например такое:

C++ Source Code:
1
"{gratestep3"
2
{
3
#material grate
4
 
5
  AlphaFunc( GL_GREATER, 0.25f );
6
}

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

__________________
My Projects: download page

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

Цитата:

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

Отправлено thambs 27-10-2019 в 21:41:

Дядя Миша
Это да, понимаю. Я имел ввиду синтаксический сахар для тривиальных текстур.

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

Отправлено Дядя Миша 27-10-2019 в 22:51:

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

вот типа такого:
#define MATERIAL( tex, mat ) \
tex
{ \
#material mat\
}

ЗЫ, дополнил немного технику бмоделей

C++ Source Code:
1
technique "bmodelSolidLightmapPass"
2
{
3
  vertShader( "glsl/forward/scene_bmodel_vp.glsl" );
4
  fragShader( "glsl/forward/scene_bmodel_fp.glsl" );
5
 
6
  image u_LightMap = "entity->$LightmapTexture";
7
  float u_LightStyleValues[64] = "globals->lightStyles";
8
 
9
#if r_fullbright || !MODEL_HAS_LIGHTMAP
10
#define LIGHTING_FULLBRIGHT
11
#endif
12
 
13
#if r_lightmap == 1
14
#define LIGHTMAP_DEBUG
15
#endif
16
 
17
#if r_lightmap == 2 && MODEL_HAS_DELUXMAP
18
#define LIGHTVEC_DEBUG
19
#endif
20
 
21
  depthMask( GL_TRUE );
22
}

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

Добавлено 28-10-2019 в 01:42:

Вот примерчег чуть посложнее

C++ Source Code:
#if r_detailtextures && u_DetailMap
#define HAS_DETAIL
#endif

Что проверяется здесь? Во первых, чтобы квар r_detailtextures был установлен в состояние, отличное от нуля. Во вторых юнит u_DetailMap проверяется на заданный путь (причём неважно где вы его задали, в технике, в шейдеробъекте или в самом материале) и только если текстура действительно существует - применяется #define HAS_DETAIL. Т.е. система способна выполнять реальные проверки на валидность пользовательских данных. Ну и с бампом аналогично.

Добавлено 28-10-2019 в 01:46:

Может у кого-то вопрос возникнет, почему это именно препроцессинг. Отвечу, потому что эти условия выполняются только перед компиляцией шейдера. А квары, типа r_lightmap имеют теперь особый флажок FCVAR_RELOAD_SHADERS, который провоцирует ребилд шейдеров у всех моделей. Т.е. проверка идёт именно на этапе сборки. Условия, которые выполняются всё время, очевидно находятся в самих GLSL-шейдерах.
Ну впрочем, функции gl-state тоже часть реального кода, но условий там нету.

Добавлено 28-10-2019 в 01:51:

Кстати говоря, заведомо статичные условия выполняются еще на стадии парсинга всех этих скриптов.

__________________
My Projects: download page

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

Цитата:

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

Отправлено nemyax 28-10-2019 в 08:53:

Дядя Миша
Я правильно понимаю, что к моделькам уже можно вязать ключ-значения и что они могут передаваться как параметры в шейдер? И для каждой модельки эффект будет зависеть от значений параметров?

Отправлено Дядя Миша 28-10-2019 в 09:40:

nemyax через скрипты да. Вкомпиливать это внутрь модели смысла не вижу. Как тогда редактировать?

__________________
My Projects: download page

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

Цитата:

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

Отправлено nemyax 28-10-2019 в 10:29:

А в какой момент изменения значений на модельке прорастают в шейдер?

Отправлено Crystallize 28-10-2019 в 10:38:

Цитата:
Дядя Миша писал:
Может у кого-то вопрос возникнет, почему это именно препроцессинг. Отвечу, потому что эти условия выполняются только перед компиляцией шейдера. А квары, типа r_lightmap имеют теперь особый флажок FCVAR_RELOAD_SHADERS, который провоцирует ребилд шейдеров у всех моделей. Т.е. проверка идёт именно на этапе сборки. Условия, которые выполняются всё время, очевидно находятся в самих GLSL-шейдерах.
Ну впрочем, функции gl-state тоже часть реального кода, но условий там нету.

По-моему ты с ума сойдёшь всё это документировать.
GL_GREATER это научное название альфатеста?
Временная зона GMT. Текущее время 18:14. Страницы (255): « Первая ... « 23 24 25 26 [27] 28 29 30 31 » ... Последняя »
Показать все 3825 сообщений этой темы на одной странице

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