Я тоже так думаю, но мне оно уже не очень подходит - поэтому хотелось бы знать насколько серьезна разница между этими вариантами при большом количестве трупов по отношению к фпс движка
Вот только что, как и YURA_111 задумался об оптимизации и возник вопрос: насколько сложнее для движка обработать простенькие 3D модели (лишь немногим превосходящие гздумные - по части многоэтажности, например) чем обрабатывать сектора из гздумбилдера?
Понятно, что разница есть, вопрос в том, насколько она существенна, и критична ли вообще?
Или стоит для многоэтажности с незаметными порталами мутить дичь?)))
Добавлено спустя 7 часов 40 минут 48 секунд:
Данный эктор при XDeath порождает самого себя со скоростью в 0.8 раз меньшую, чем имел порождающий актёр(т.е. снаряд останавливается об прошиваемых им монстров, НО!
Проблема в том, что этот код работает "раз через раз": иногда как надо, а иногда игра зависает(обычно это бывает, когда код заходит в loop, длина которого 0, т.е. требуется бесконечность операций в секунду )
В чем может заключаться проблема?
actor RailForGaussator
{
Decal "SVDChip"
Speed 160
Damage 300
Radius 3
mass 20
Height 8
PROJECTILE
-NOGRAVITY
+STRIFEDAMAGE
-NOEXTREMEDEATH
+SOLID
RENDERSTYLE NORMAL
Scale 0.07
ALPHA 0.7
GRAVITY 0.2
States
{
Spawn:
RFGR A 1 Bright
Loop
XDeath:
TNT1 A 0 A_SpawnItemEx("RailForGaussator",0,0,0,0.8,0,0,0,SXF_MULTIPLYSPEED)
Death:
stop
}
}
Вот только что, как и YURA_111 задумался об оптимизации и возник вопрос: насколько сложнее для движка обработать простенькие 3D модели (лишь немногим превосходящие гздумные - по части многоэтажности, например) чем обрабатывать сектора из гздумбилдера?
Понятно, что разница есть, вопрос в том, насколько она существенна, и критична ли вообще?
Да по большому счёту пофигу. Емнип, опенГЛ абсолютно всё переводит в кучу полигонов, и потом с ней уже работает.
- 3д-полы геморройно складывать в сложные конструкции, но для простых ситуаций типа "поделить комнату на два этажа" они удобнее и выглядят они как "плоть от плоти" карты, и проблем с хитбоксами не имеют.
- Модели в чём-то более гибкие, в чём-то наоборот. Модели сложнее заставить не выделяться из общей геометрии карты, они нуждаются в ZBridge, чтобы по ним ходить. Зато позволяют легко и непринуждённо сделать какую-нибудь хитрожопую лестницу или купол с окошками. Без openGL не работают.
- Отдельная история - воксели. Воксели визуально безупречны среди лоурезных дум-текстур, работают на софтварном рендерере, в обычном Zdoom и его поздней реинкарнации LZdoom. В гоззе превращаются в полигональную модель с огромным количеством лишних вершин, поэтому вызывают жуткие тормоза. Причём чтобы в гоззе включить "честный" софтварный рендерер - надо долго искать то-не-знаю-что в неочевидном меню, иначе воксели начнут тормозить ещё сильнее.
Короче, универсально хороших решений нет, только ситуационные.
Я попытался импортировать модель, и вот что получилось:
В декорэйте написал это
ACTOR BlueZabor 9002
{
Radius 16
Height 42
ProjectilePassHeight -16
+SOLID
States
{
Spawn:
TNT1 A -1
STOP
}
}
В моделдефе вот это
Model BlueZabor
{
Path "BlueZabor"
Model 0 "BlueZabor.md3"
Skin 0 "insanecancer.png"
Scale 1.0 1.0 1.0
FrameIndex TNT1 A 1 1
}
В той же папке (исходной) находятся insanecancer.png и BlueZabor.md3
Но в самой игре физически объект существует(не пропускает дальше однако это скорее всего связано с его радиусом) но фактически его не видно
В чм моя ошибка?
PS Извиняюсь за знаки препинание и отсутствие некоторых букв - у меня раскладка клавы в данный момент не соответствует системной
Добавлено спустя 2 часа 26 минут 35 секунд:
Насколько сложно написать баллистический вычислитель для оружия?)
Так это же должно быть ссылкой на фрейм в одноимённом экторе в декорейте, а туда я решил пустоту закинуть...
Как раз-таки по материалам здумвики.(в том смысле что фреймы в экторе и в можелдефе одни и те же)
Добавлено спустя 35 секунд:
А этот фрэйм вообще обязан существовать в файле?
Он же фактически не используется.
Модели не инициализированы. MODELDEF использует крайне неочевидный синтаксис. Например, вот код для сложносоставной модели САУ на два фрейма. Модель состоит из четырёх субмоделей (корпус, катки, траки, кулемёт), составляющих единое целое. Фреймы отличаются положением катков и текстурой траков, чтобы во время их попеременной смены гусеницы как бы вращались, корпус при этом не меняется.
Скрытый текст:
Model Elefant_Visual //"Elefant_Visual" это имя конкретного актора. Модель привязывается не к спрайту, а к актору. Актор с тем же кодом и другим названием будет без модели.
{
Path "MODELS/Elefant" //путь к папке
Model 0 "hull_1.md2" //субмодель1
Skin 0 "Hull.jpg" //текстура1
Model 1 "Twheels1.md2" //субмодель2
Skin 1 "Twheel.PNG" //текстура2
Model 2 "tracks.md2" //субмодель3
Skin 2 "track1.PNG" //текстура3
Model 3 "mg34.md2" //субмодель4
Skin 3 "mg34.jpg" //текстура4
Scale 31.6 -31.6 38.0 //zscale*1.2 //какого-то лешего по дефолту движок жмёт модели по высоте
Offset 0 0 0
AngleOffset 0
Frame 4ERD A 0 "frame0" //инициация субмодели1 во фрейме A
Frame 4ERD A 1 "frame0" //инициация субмодели2 во фрейме A
Frame 4ERD A 2 "frame0" //инициация субмодели3 во фрейме A
Frame 4ERD A 3 "frame0" //инициация субмодели4 во фрейме A
}
Model Elefant_Visual
{
Path "MODELS/Elefant"
Model 0 "hull_2.md2"
Skin 0 "Hull.jpg"
Model 1 "Twheels2.md2"
Skin 1 "Twheel.PNG"
Model 2 "tracks.md2"
Skin 2 "track2.PNG"
Model 3 "mg34.md2"
Skin 3 "mg34.jpg"
Scale 31.6 -31.6 38.0 //zscale*1.2
Offset 0 0 0
AngleOffset 0
Frame 4ERD B 0 "frame0" //инициация субмодели1 во фрейме B
Frame 4ERD B 1 "frame0" //инициация субмодели2 во фрейме B
Frame 4ERD B 2 "frame0" //инициация субмодели3 во фрейме B
Frame 4ERD B 3 "frame0" //инициация субмодели4 во фрейме B
}
Насколько сложно написать баллистический вычислитель для оружия?)
Проще всего - методом последовательных приближений. Итераций за 10 попадает даже с очень больших дистанций. Преимущество метода - нам наплевать на перепад высот между пушкой и целью, т.е. не нужно считать отдельно каждую полупараболу и маяться со степенными уравнениями.
1. Лупим на 45 градусов.
2. По косинусу получаем константу Vel.x.
3. По дистанции находим время T.
4. По H = (Uy>>16)*T - T*T/2 + T/2 + height находим абсолютную Z-координату в точке предполагаемого попадания.
5. Сравниваем с абсолютной Z-координатой цели, определяем промах.
6. Применяем шаг на пол-угла, поправшяя ошибку. С каждой итерацией шаг уменьшается вдвое.
7. Goto 1, пока промах не станет меньше какого-то числа.
А вот если делать баллистический вычислитель с проверкой доступности цели (на траектории могут быть препятствия) - вот там реально геморрой. Ещё есть нюанс, что стрелять по-миномётному на думовском движке мешает "небесная твердь" сектора, которая часто находится очень низко, хотя при должном изврате и это тоже преодолимо.
Проще всего - методом последовательных приближений.
А я вот ещё заметил небольшой "прЕкол", заколючающийся в том, что отметки от пуль при стрельбе выше горизонта немного ниже выстрела, а при стрельбе ниже горизонта - выше.
Стоит хардрендер, Open GL.
Это как-то лечится, или болезнь гоззы?
В брутале такого вроде не замечал.
Миллион причин может быть. Может где-то какие-то autoaim-костыли проявляются, начиная с исконного ванильно-думовского. Может какие-то очередные костыли для хитсканов. Может какие-то чудеса расчудесные с несовпадением точки выстрела и высотой камеры. Чем больше в механизме всякого абстрактного - тем больше эзотерических ошибок.
Может где-то какие-то autoaim-костыли проявляются, начиная с исконного ванильно-думовского.
Снаряды и "внешне"(отображается так) и "физически"(задевают монстров) именно там, где должны, исходя из прицела, а вот отметины от - как говорилось ранее.
Снаряды и "внешне"(отображается так) и "физически"(задевают монстров) именно там, где должны, исходя из прицела, а вот отметины от - как говорилось ранее.
Я это не кодил и не дебажил, поэтому ничего не могу сказать на тему механизма отображения декалей. Там сколько угодно промежуточных конструкций может быть задействовано. Поэтому - в багтрекер на zdoom.org. Могу только посоветовать SpawnDecal (ACS) или A_SprayDecal (декорейт), чтобы городить огород вручную.
Можно разделить экран таким образом, чтобы в разных его частях был разный зум?
Ведь если оверлеем ZoomFactor задавать он его применит ко всему экрану.
Хочу создать такой новомодный эффект:
[/img]
Добавлено спустя 6 минут 34 секунды:
Ещё вопрос:
Как сделать трассер от снаряда?
На ZdoomWiki я нашёл что-то подобное для самонаводящегося снаряда, а для обычного что-то не вышло.
Добавлено спустя 2 часа 22 секунды:
Вопрос по оптимизации:
Что нагружает сильнее сдвиг картинки, или подгрузка новой?
(как бы напрашивается, что подгрузка нагружает больше, но ведь не зря же многие вместо A_weaponoffset юзают копии, которые передвинуты, или им просто лень?)
По в чём может быть причина того, что это оружие не удаляет пистолет.
Пытался на это воздействовать путём изменения Player startItem (заменой DoomPlayer) - тоже ничего, к тому же теперь уже не понятно почему и эта замена не работает(в конце код "альтернативного" игрока)
Скрытый текст:
actor TulskyTokarev: Weapon replaces Pistol
{
Weapon.slotnumber 2
States
{
Select:
TNT1 A 0 A_SetInventory("TTSelected",1)
TNT1 A 0 A_SetInventory("SelectingCheker",1)
TNT1 A 1 A_Raise(1000)
loop
Selecting:
TNT1 A 0 A_SetInventory("SelectingCheker",0)
TT1S ABC 3
TT1F A 3 offset (-32,0)
TT1F A 3 offset (-68,0)
Ready:
TNT1 A 0 A_JumpIfInventory("SelectingCheker",1,"Selecting")
TT0G A 2 A_WeaponReady
loop
Fire:
TT0F ABCB 1 A_Fire
goto Ready
DeSelect:
TNT1 A 1 A_Lower
loop
}
}
ACTOR RDoomPlayer : PlayerPawn Replaces DoomPlayer
{ Speed 1
Health 100
Radius 16
Height 56
Mass 100
PainChance 255
Player.DisplayName "Marine"
Player.CrouchSprite "PLYC"
Player.StartItem "TulskyTokarev"
Player.StartItem "Fist"
Player.StartItem "Clip", 100
Player.WeaponSlot 1, Fist, Chainsaw
Player.WeaponSlot 2, TulskyTokarev
Player.WeaponSlot 3, Shotgun, SuperShotgun
Player.WeaponSlot 4, Chaingun
Player.WeaponSlot 5, RocketLauncher
Player.WeaponSlot 6, PlasmaRifle
Player.WeaponSlot 7, BFG9000
Player.ColorRange 112, 127
Player.ColorSet 0, "Green", 0x70, 0x7F, 0x72
Player.ColorSet 1, "Gray", 0x60, 0x6F, 0x62 // Called "Indigo" originally so as to have a unique initial
Player.ColorSet 2, "Brown", 0x40, 0x4F, 0x42
Player.ColorSet 3, "Red", 0x20, 0x2F, 0x22
// Doom Legacy additions
Player.ColorSet 4, "Light Gray", 0x58, 0x67, 0x5A
Player.ColorSet 5, "Light Brown", 0x38, 0x47, 0x3A
Player.ColorSet 6, "Light Red", 0xB0, 0xBF, 0xB2
Player.ColorSet 7, "Light Blue", 0xC0, 0xCF, 0xC2
States
{
Spawn:
PLAY A -1
Loop
See:
PLAY ABCD 4
Loop
Missile:
PLAY E 12
Goto Spawn
Melee:
PLAY F 6 BRIGHT
Goto Missile
Pain:
PLAY G 4
PLAY G 4 A_Pain
Goto Spawn
Death:
PLAY H 0 A_PlayerSkinCheck("AltSkinDeath")
Death1:
PLAY H 10
PLAY I 10 A_PlayerScream
PLAY J 10 A_NoBlocking
PLAY KLM 10
PLAY N -1
Stop
XDeath:
PLAY O 0 A_PlayerSkinCheck("AltSkinXDeath")
XDeath1:
PLAY O 5
PLAY P 5 A_XScream
PLAY Q 5 A_NoBlocking
PLAY RSTUV 5
PLAY W -1
Stop
AltSkinDeath:
PLAY H 6
PLAY I 6 A_PlayerScream
PLAY JK 6
PLAY L 6 A_NoBlocking
PLAY MNO 6
PLAY P -1
Stop
AltSkinXDeath:
PLAY Q 5 A_PlayerScream
PLAY R 0 A_NoBlocking
PLAY R 5 A_SkullPop
PLAY STUVWX 5
PLAY Y -1
Stop
}
}
Просьба в будущем при вставке большого количества технического текста прятать его под спойлер. BeeWen
Почему не удаляет -- понятно, оно заменяет именно актор пистолета, а не наследованный от Inventory StateProvider ("DECORATE format specification", см. "replaceclassname"). Если попробуешь ввести "summon pistol" в консоли, оно у тебя появится на карте, в виде "TNT1 A -1" (невидимый), так как наследование идёт от класса Weapon, который наследуется от класса Actor, в котором прописан стандартный стейт "Spawn", и как раз этот стейт у тебя отсутствует.
А вот насчёт альтернативного игрока -- странно, у меня твой же код, подправленный буквально на чуть, без критических исправлений, работает: