Войти
ФлеймФорумПроЭкты

Floating Islands (6 стр)

Страницы: 15 6 7 853 Следующая »
#75
17:54, 5 авг. 2018

mr.DIMAS
++


#76
8:03, 6 авг. 2018

Vlad2001_MFS
> И снова все по кругу...
А оно потому что нет идеала. В чужом вечные фатальные недостатки. Свое писать - долго (идеально, а не тяп-ляп за неделю)

Такс, отделил юрхо. Но вот что это за ошибки:

1>kNet.lib(MessageConnection.obj) : error LNK2005: "void * __cdecl operator new(unsigned int)" (??2@YAPAXI@Z) уже определен в MSVCRTD.lib(new_scalar.obj)
1>kNet.lib(MessageConnection.obj) : error LNK2005: "void __cdecl operator delete(void *)" (??3@YAXPAX@Z) уже определен в MSVCRTD.lib(delete_scalar.obj)
1>kNet.lib(MessageConnection.obj) : error LNK2005: "void * __cdecl operator new[](unsigned int)" (??_U@YAPAXI@Z) уже определен в MSVCRTD.lib(new_array.obj)
1>kNet.lib(MessageConnection.obj) : error LNK2005: "void __cdecl operator delete[](void *)" (??_V@YAXPAX@Z) уже определен в MSVCRTD.lib(delete_array.obj)
1>kNet.lib(NetworkServer.obj) : error LNK2005: "void * __cdecl operator new(unsigned int)" (??2@YAPAXI@Z) уже определен в MSVCRTD.lib(new_scalar.obj)
1>kNet.lib(NetworkServer.obj) : error LNK2005: "void __cdecl operator delete(void *)" (??3@YAXPAX@Z) уже определен в MSVCRTD.lib(delete_scalar.obj)
1>kNet.lib(NetworkServer.obj) : error LNK2005: "void * __cdecl operator new[](unsigned int)" (??_U@YAPAXI@Z) уже определен в MSVCRTD.lib(new_array.obj)
1>kNet.lib(NetworkServer.obj) : error LNK2005: "void __cdecl operator delete[](void *)" (??_V@YAXPAX@Z) уже определен в MSVCRTD.lib(delete_array.obj)
1>kNet.lib(Network.obj) : error LNK2005: "void * __cdecl operator new(unsigned int)" (??2@YAPAXI@Z) уже определен в MSVCRTD.lib(new_scalar.obj)
1>kNet.lib(Network.obj) : error LNK2005: "void __cdecl operator delete(void *)" (??3@YAXPAX@Z) уже определен в MSVCRTD.lib(delete_scalar.obj)
1>kNet.lib(Network.obj) : error LNK2005: "void * __cdecl operator new[](unsigned int)" (??_U@YAPAXI@Z) уже определен в MSVCRTD.lib(new_array.obj)
1>kNet.lib(Network.obj) : error LNK2005: "void __cdecl operator delete[](void *)" (??_V@YAXPAX@Z) уже определен в MSVCRTD.lib(delete_array.obj)
1>kNet.lib(W32Event.obj) : error LNK2005: "void * __cdecl operator new(unsigned int)" (??2@YAPAXI@Z) уже определен в MSVCRTD.lib(new_scalar.obj)
1>kNet.lib(W32Event.obj) : error LNK2005: "void __cdecl operator delete(void *)" (??3@YAXPAX@Z) уже определен в MSVCRTD.lib(delete_scalar.obj)
1>kNet.lib(W32Event.obj) : error LNK2005: "void * __cdecl operator new[](unsigned int)" (??_U@YAPAXI@Z) уже определен в MSVCRTD.lib(new_array.obj)
1>kNet.lib(W32Event.obj) : error LNK2005: "void __cdecl operator delete[](void *)" (??_V@YAXPAX@Z) уже определен в MSVCRTD.lib(delete_array.obj)
1>kNet.lib(Socket.obj) : error LNK2005: "void * __cdecl operator new(unsigned int)" (??2@YAPAXI@Z) уже определен в MSVCRTD.lib(new_scalar.obj)
1>kNet.lib(Socket.obj) : error LNK2005: "void __cdecl operator delete(void *)" (??3@YAXPAX@Z) уже определен в MSVCRTD.lib(delete_scalar.obj)
1>kNet.lib(Socket.obj) : error LNK2005: "void * __cdecl operator new[](unsigned int)" (??_U@YAPAXI@Z) уже определен в MSVCRTD.lib(new_array.obj)
1>kNet.lib(Socket.obj) : error LNK2005: "void __cdecl operator delete[](void *)" (??_V@YAXPAX@Z) уже определен в MSVCRTD.lib(delete_array.obj)
1>kNet.lib(NetworkLogging.obj) : error LNK2005: "void * __cdecl operator new(unsigned int)" (??2@YAPAXI@Z) уже определен в MSVCRTD.lib(new_scalar.obj)
1>kNet.lib(NetworkLogging.obj) : error LNK2005: "void __cdecl operator delete(void *)" (??3@YAXPAX@Z) уже определен в MSVCRTD.lib(delete_scalar.obj)
1>kNet.lib(NetworkLogging.obj) : error LNK2005: "void * __cdecl operator new[](unsigned int)" (??_U@YAPAXI@Z) уже определен в MSVCRTD.lib(new_array.obj)
1>kNet.lib(NetworkLogging.obj) : error LNK2005: "void __cdecl operator delete[](void *)" (??_V@YAXPAX@Z) уже определен в MSVCRTD.lib(delete_array.obj)
1>kNet.lib(FragmentedTransferManager.obj) : error LNK2005: "void * __cdecl operator new(unsigned int)" (??2@YAPAXI@Z) уже определен в MSVCRTD.lib(new_scalar.obj)
.....

Ужас. что там надо настоить чтобы исправить?

#77
(Правка: 10:21) 10:08, 6 авг. 2018

war_zes
Ты изменял настройки оригинального проекта? Может что-то не так сделал? Менял тип линковки?(статическая, динамическая)
Попробуй добавить библиотеку "MSVCRTD.lib" в исключения: Настройки проекта — Компоновщик — Ввод — Игнорировать указанные библиотеки. Правда, скорее всего это не поможет.

Вероятное решение:
Сам файл с перегрузками new/delete - Urho3D\Source\ThirdParty\kNet\include\kNet\DebugMemoryLeakCheck.h. Можно просто отключить эту фигню и возможно ошибки уйдут. Чтобы отключить надо"раздефайнить" KNET_MEMORY_LEAK_CHECK - просто удали его из настроек проекта.

#78
14:14, 6 авг. 2018

Vlad2001_MFS
> Ты изменял настройки оригинального проекта? Может что-то не так сделал? Менял
> тип линковки?(статическая, динамическая)
ну я восоздал свой проект (мне не нравится высер cmake). но вроде потом сверял все настройки приложения и библиотеки, но не помогло

Vlad2001_MFS
> Попробуй добавить библиотеку "MSVCRTD.lib
пробовал, не помогло

Vlad2001_MFS
> Вероятное решение:
это попробую.... ну или отпилю сеть, не особо-то и нужна

#79
3:24, 8 авг. 2018

Так, пока еще ковыряю юрхо. закинул код в https://github.com/warzes/GameEngine
(старый репозиторий пока оставлю)

#80
5:37, 8 авг. 2018

Кому интересно, то что я меняю в оригинальном юрхо, я описываю тут
https://github.com/warzes/GameEngine/blob/master/engine/Urho3D.txt

Забавный момент. В урхо в CMake есть опция для включения PCH. Но у меня она почему-то не работает и проект генерируется без нее (Precompiled.h не имеет пары Precompiled.cpp, в настройках не указано использование и создание PCH).

В таком виде на моем компьютере движок компилируется где-то около 96329мс.

Так вот, когда я сам искусственно создал stdafx.[cpp/h] и включил PCH, скорость компиляции изменилась до 56125 мс. То есть практически в два раза быстрее. Сейчас занялся переносом стороних инклюдов в stdafx, теоретически должно еще быстрее компилировать, но посмотрим.

И я до сих пор не понимаю почему большинство пренебрегает этой фичей в своих проектах.

#81
9:25, 8 авг. 2018

war_zes
> И я до сих пор не понимаю почему большинство пренебрегает этой фичей в своих
> проектах.
Может делают игры на готовом движке?)

#82
9:41, 8 авг. 2018

war_zes
>Так вот, когда я сам искусственно создал stdafx.[cpp/h] и включил PCH, скорость компиляции изменилась до 56125 мс.
Конечно, это очень важно для проекта из 10 файлов.

#83
12:10, 8 авг. 2018

nes
> Конечно, это очень важно для проекта из 10 файлов.
когда проект после изменения кода сразу запускается и когда он запускается через 10 секунд - да, важно.

#84
14:07, 8 авг. 2018

war_zes
Если при изменении в одном файле у тебя пересобирается весь прожыхт,
значит у тебя что-то не так с зависимостями.

> когда он запускается через 10 секунд - да, важно.
А это в перлы.

#85
14:39, 8 авг. 2018

nes
> Если при изменении в одном файле у тебя пересобирается весь прожыхт,
> значит у тебя что-то не так с зависимостями.
Ты забываешь про рефакторинг и переделывание. Сейчас речь не о моем велосипеде, а о новом для меня пути (ну не очень новом, но....) - переписать урхо.

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

Так вот, я рефакторю код urho3D, часто автоматизировано. Иногда что-то ломается (не я же писал, иногда ломается от банальной перестановки инклудов - как же там все хрупко), поэтому приходится тестировать практически после каждого изменения, чтобы вовремя откатить поломку или своевременно пофиксить.
Каждая такая компиляция занимает 50 секунд. А не сделал бы такое просто изменение - занимала бы 90 секунд. 40 секунд - ощутимая разница, учитывая что ее можно было избежать всего лишь парой кликов мышки.

#86
14:41, 8 авг. 2018

Раньше было движкопейсательство, а сейчас новый уровень, движкопереписательство.
В общем что угодно, лишь бы не делать игры)

#87
16:21, 8 авг. 2018

war_zes
> это фатальные недостатки.
> переписать урхо.
Изображение

#88
2:15, 9 авг. 2018

emptiness_rain
> В общем что угодно, лишь бы не делать игры)
не, ну правильно Шабордин сказал (тут https://www.youtube.com/watch?v=CT77PY9yrZE), есть программисты, а есть девелоперы. И я не отношусь к последним.

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

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

#89
2:28, 9 авг. 2018

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

А если серьезно, вот что я хочу сейчас переделать:
- отрефакторить Object класс и все связанное - в Urho3D для меня это самый большой фатальный недостаток. И ладно бы если бы оно было внутри, черным ящиком, но оно торчит наружу. Хотя это и самое сложное - это узкое место кода, которое сложно изменить не сломав весь движок (короче, нельзя так делать архитектуру движка). И первой же задачей будет избавиться от уродливого макроса URHO3D_OBJECT
- самописная математика vs glm/DirectXMath - хочу проверить, так ли выгодно оставлять их велосипед, или переделать готовое (буду тестить)
- унифицировать обертку над GAPI, то что там сейчас - сделано на коленке, выглядит страшненько, и совсем не пригодно под новые фичи
- очень давно хочу попробовать Clustered Shading - но пока было не на чем. попробую на юрхо
- переделать рендер под более нужный для моих проектов вид (то есть освещение, тени и т.д.)
- добавить возможность грузить модели из их форматов, а не внутреннего движкового. 2018 год, а движкописатели до сих пор пишут свои форматы и заставляют пользоваться кривыми и глючными плагинами для экспорта. Нафиг так делать? возьму assimp и встрою в движок


Ну и конечно про игру не забываю

Страницы: 15 6 7 853 Следующая »
ФлеймФорумПроЭкты