Wolfenstein3D

Наскоро намерих ето това нещо: os-js.org. Влязох в демо версията и от менюто "games" стартирах играта Wolfenstein3D.
Оригиналната игра е много стара - създадена е 1992, но това което споменах по-горе че се отваря всъщност е web версия на същата игра. При това става дума не за емулация на оригиналния написан на C продукт, а чиста и прегледна javascript версия. Изглежда, че последната разработка е създадена от самия производител на играта id Software по случай 20 години от издаването й, т. е. web версията е пусната 2012.
Намерих в git някаква модифицирана версия на играта: https://github.com/dariusk/wolf3d, но нещо не се стартира както трябва. Затова копирах само js файловете от споменатото място в os-js.org. Оказа се, че и това не е съвсем достатъчно. Липсваха много файлове, които копирах.
Най-важното предимство на играта е това, че е на javascript, което прави трасирането на изпълнението, спирането по време на игра за да се нанесат промени на практика удобно начинание. За да е възможно това, обаче, трябва играта да се зареди след като сме отворили ивицата на Crome в която се извършва разработка (development tools).

До тук всичко което представям е само въведение. Идеята, която имам желание да реализирам е да развия собствен енжин, който в последствие да интегрираме директно в играта. Така минавайки в нова стая се сменя не само обстановката, но и започва да се визуализира с моя енжин.

Вече имам значителен напредък, а не е само гола идея. Моя енжин изобразява само две стени засега, но нещата горе-долу се получават. Работя и по преходната част. Когато се влиза в новото пространство ще трябва и двата енджина да работят, което поражда известни проблеми. Оказа се, че предметите в оригиналното пространство използват z буфер, който лесно се постига с zIndex на div обектите, но пък така скрити предмети се появяват на мястото, където трябва да е новото пространство което да рендирам с новия енжин. И при това не всички обекти трябва да се трият от тази зона - някои са отпред и трябва да са видими. Този проблем вече е решен, като доработих оригиналната игра.

Цялата идея на начинанието за новия енжин е да го направя по много по-различен начин, но да е в духа на разработките през 92. Т. е. все пак ще се мисли и за вариант ако се реализира по оригиналния начин.

Ако някой проявява интерес да се включи в разработката да пише в темата или на лично. Връщам към програмиране, за да доизграждам започнатото.

Т.е. открил си, че ID са пуснали open source на 1-вият 3D енджин? Може да ти е интересно и друго, Кармак пусна и няколко от следващите: https://github.com/id-Software

Отделно съм виждал поне 3 различни javascript разработки по 1-вият, така че според мен е загубена кауза, но за упражнение има хляб.

Това мнение е било редактирано от PxL на 11-10-2019, 06:08

Това, че оригиналния engine е open source е нещо, което знае всеки от обща култура, защото това е практика на фирмата производител. Откритието е за web разработката, защото последната носи наистина съществен потенциал, който е в следното:
1. Нямаме емулация на оригинала. Т. е. нещата не са затворени.
2. Не се ползва canvas техника, дори и за самото рендиране. Т. е. нещата се представят с html DOM обекти, което ги прави удобни за манипулиране.
3. Избегнати са само досадните механични технологични процедури, като например скалиране и извличане на части от изображение за показване. За целта в DIV обектите се слага стил "overflow:hidden;", който изрязването на съдържаното.
4. Сорсът е много прегледно написан.
Последното всъщност не е точно конкретно предимство, защото вероятно се отнася за всички web версии.

Накратко точно тази web реализация има съществени предимства пред останалите такива. Така с помощта на Chrome DevTools може да се експериментира много ефективно и достатъчно удобно при по-нататъшната разработка.

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

Дублирано...

Това мнение е било редактирано от РЇРІРѕСЂ1 на 11-10-2019, 07:03

Само ще добавя, че идеята за вкарването на новия engine е да се ползва техниката "Binary space partitioning", но приложена за пространство на един етаж, както е в оригиналната игра. Между другото преди малко научих за това наименование на техниката.

Т.е. направили са website. Няма лошо, но пак не разбирам как ще е по-производително от webgl версия.

Идеята за тея енджини, дето говориш нещо не я схванах, защо ти е BSP във Wolf3D? Има ли го някъде пуснато да го видим?

Това мнение е било редактирано от PxL на 11-10-2019, 15:40

Ако питаш за версията от която стартирам, тя е тук:
https://demo.os-js.org/packages/games/Wolfe...data/index.html
Това, което правя не е завършено. За момента все още всичко е на ранен етап.

Идеята не е свързана с това да се прави нещо производително, защото колкото и ефективно да стане, то няма какво да го правиш. А и е чужд продукт, така че едва ли ще впечатлиш някого. Идеята е да се направи нещо НОВО не като технология, а като имплементиране, като фокусът е върху основните технологии при задвижването на нещата. Системните технологии са нещо, което е друга тема.

Планът накратко е горе долу следният:
Първо се доработва web версията на играта, което както споменах е много по-лесно, сравнено с други варианти на разработката. И може да се тества също така много лесно, защото няма нужда някой да инсталира каквото и да е. И е достатъчно ефективно за такава проста игра.
Следващата стъпка е да се прехвърли направеното към някоя съвременна микрокотролерна система, която да поддържа графика и език за програмиране C. Тук естествено остава прехвърлянето на javascript-а, а и вече ще трябва да се извършат и системните технологии, но тази техническа задача вече е много по-лесна за тестване и осъществяване.

Главната цел на начинанието е да се тренира практически модел на работа, при които се комбинират съвсем различни технологии по природа. BSP ми е необходимо, защото отдавна преди години съм го измислил как да го правя по този начин. Това е технология, която е съвсем различна от рендиращата техника на играта. Т. е. правят се две коренно различни неща...

Струва ми се, че говориш за ID Tech 2 game engine-a, там доволно се ползва BSP, Същият е за Quake 2 и за Return to castle Wolfenstein. Т.е. така както го разбирам (което е малко трудно) искаш да пренапишеш Wolf3D с ID2 bsp картите?

Това мнение е било редактирано от PxL на 11-10-2019, 20:03

Грешиш. Става дума за много по-прост модел engine, който е правен наново. Поради пространството в което работи (на един етаж както се казва) той (BSP) е напълно достатъчен за пълно рендиране, без нужда от z буфер. Резултатната реализация трябва да е поне толкова ефективна колкото оригиналния engine на Wolfenstein3D при стартиране на оригиналната за играта платформа (не говорим тук за web версията, където нещата ще бъдат реализирани първоначално).

И горното е само по отношение на техническата страна на нещата. Организационно web версията дава големи предимства по отношение на ефективността на разработването.

Е да де. Искаш да ползваш ID2 технология за ID1 игра. Няма лошо. Има си инструменти (Radiant, Hammer...) и ще стане. За производителност не знам, но ще е по-добре визуално със сигурност, тъй като Wolf3D не е реално 3D. И пак, губи ми се смисъла на занятието, защо просто не направиш карта за Quake II, която да прилича на Wolf3D и готово... Както и да е де, като имаш резултат покажи.

И при визуализацията не е само BSP-то, самата технология е тотално различна при ID2. Там реално имаш mesh, с който работиш, BSP-то ти е заради culling-a иначе тея щайги, които ползвахме тогава нямаше да могат да го подкарат с 1M триъгълника и само frustum culling.

За Wolf3D разбирам как ще нашлякат div-oве, ама да визуализираш и сортираш mesh не разбирам как DOM-а ще влезне в употреба по-добре от *GL

Това мнение е било редактирано от PxL на 12-10-2019, 05:39