Сообщение Re[23]: А на каком уровне накосячили в WPF от 24.02.2016 13:21
Изменено 24.02.2016 14:15 alexzzzz
Здравствуйте, alex_public, Вы писали:
_>Дело не в этом, а в том, что собственно игровые скрипты (которые пишутся на C# или JS) занимают очень маленькую часть исполняемого кода игры.
Скажем, 5 Мб IL-кода — это много или мало? Это типичный размер кода, написанного для конкретной игры, после компиляции. Без учёта стандартных библиотек (которыми этот код пользуется) и без учёта вспомогательных внешних библиотек, типа SharpZipLib, Json-тра-та-та и прочих (которыми этот код тоже пользуется, иначе бы не потащил за собой в игру).
Глянул на Paint.NET, установленный на моём компьютере. Там все существующие .exe и .dll в сумме занимают в два раза меньше.
_>Я немного не об этом. Я имел в виду, что если кто-то напишет игру только на JavaScript, то может ему не надо будет тащить с собой все эти мегабайты ради поддержки работы C#?
JavaScript/UnityScript — такой же .Net-язык, как C#, просто чуть урезанный в возможностях и чуть менее строго типизированный — примерно как Visual Basic. Только синтаксис похож не на VB, а на Java/JavaScript/ActionScript. Он не имеет отношения к тому JavaScript, который в браузерах.
Почему этот язык официально называют JavaScript, я не знаю. На гитхабе он зовётся UnityScript. Откомпилированный код попадает в библиотеки с именами Assembly-UnityScript-xxx.dll
Соответственно, UnityScript тоже требует наличия рантайма Mono со стандартными библиотеками, плюс тянет с собой одну-две маленьких управляемых библиотечки с типами, специфичными конкретно для UnityScript и отсутствующими при разработке на C#.
_>Или там нельзя так почистить движок и он по любому тащит всё, даже если оно не используется?
Кстати, на мобилках должна работать оптимизация кода по размеру. И для нативного кода движка, и для управляемого пользовательского кода. Для последнего должен работать стрип — все типы/метода/данные, которые не используются пользовательским кодом, вырезаются. В т.ч. так же обрезаются стандартные библиотеки. Это накладывает некоторые ограничения на программистов, но уменьшает размер билдов.
Но поскольку я в мобилках нихрена не понимаю, проверить это не могу. На десктопах Unity, похоже, такой фигнёй не заморачивается, тут ±10 Мб ничего не решают.
_>Дело не в этом, а в том, что собственно игровые скрипты (которые пишутся на C# или JS) занимают очень маленькую часть исполняемого кода игры.
Скажем, 5 Мб IL-кода — это много или мало? Это типичный размер кода, написанного для конкретной игры, после компиляции. Без учёта стандартных библиотек (которыми этот код пользуется) и без учёта вспомогательных внешних библиотек, типа SharpZipLib, Json-тра-та-та и прочих (которыми этот код тоже пользуется, иначе бы не потащил за собой в игру).
Глянул на Paint.NET, установленный на моём компьютере. Там все существующие .exe и .dll в сумме занимают в два раза меньше.
_>Я немного не об этом. Я имел в виду, что если кто-то напишет игру только на JavaScript, то может ему не надо будет тащить с собой все эти мегабайты ради поддержки работы C#?
JavaScript/UnityScript — такой же .Net-язык, как C#, просто чуть урезанный в возможностях и чуть менее строго типизированный — примерно как Visual Basic. Только синтаксис похож не на VB, а на Java/JavaScript/ActionScript. Он не имеет отношения к тому JavaScript, который в браузерах.
Почему этот язык официально называют JavaScript, я не знаю. На гитхабе он зовётся UnityScript. Откомпилированный код попадает в библиотеки с именами Assembly-UnityScript-xxx.dll
Соответственно, UnityScript тоже требует наличия рантайма Mono со стандартными библиотеками, плюс тянет с собой одну-две маленьких управляемых библиотечки с типами, специфичными конкретно для UnityScript и отсутствующими при разработке на C#.
_>Или там нельзя так почистить движок и он по любому тащит всё, даже если оно не используется?
Кстати, на мобилках должна работать оптимизация кода по размеру. И для нативного кода движка, и для управляемого пользовательского кода. Для последнего должен работать стрип — все типы/метода/данные, которые не используются пользовательским кодом, вырезаются. В т.ч. так же обрезаются стандартные библиотеки. Это накладывает некоторые ограничения на программистов, но уменьшает размер билдов.
Но поскольку я в мобилках нихрена не понимаю, проверить это не могу. На десктопах Unity, похоже, такой фигнёй не заморачивается, тут ±10 Мб ничего не решают.
Здравствуйте, alex_public, Вы писали:
_>Дело не в этом, а в том, что собственно игровые скрипты (которые пишутся на C# или JS) занимают очень маленькую часть исполняемого кода игры.
Скажем, 5 Мб IL-кода — это много или мало? Это типичный размер кода, написанного для конкретной игры, после компиляции. Без учёта стандартных библиотек (которыми этот код пользуется) и без учёта вспомогательных внешних библиотек, типа SharpZipLib, Json-тра-та-та и прочих (которыми этот код тоже пользуется, иначе бы не потащил за собой в игру).
Глянул на Paint.NET, установленный на моём компьютере. Там все существующие .exe и .dll в сумме занимают в два раза меньше.
_>Я немного не об этом. Я имел в виду, что если кто-то напишет игру только на JavaScript, то может ему не надо будет тащить с собой все эти мегабайты ради поддержки работы C#?
JavaScript/UnityScript — такой же .Net-язык, как C#, просто чуть урезанный в возможностях и чуть менее строго типизированный — примерно как Visual Basic. Только синтаксис похож не на VB, а на Java/JavaScript/ActionScript. Он не имеет отношения к тому JavaScript, который в браузерах.
Почему этот язык официально называют JavaScript, я не знаю. На гитхабе он зовётся UnityScript. Откомпилированный код попадает в библиотеки с именами Assembly-UnityScript-xxx.dll
Соответственно, UnityScript тоже требует наличия рантайма Mono со стандартными библиотеками, плюс тянет с собой одну-две маленьких управляемых библиотечки с типами, специфичными конкретно для UnityScript и отсутствующими при разработке на C#.
_>Или там нельзя так почистить движок и он по любому тащит всё, даже если оно не используется?
Кстати, на мобилках должна работать оптимизация кода по размеру. И для нативного кода движка, и для управляемого пользовательского кода. Для последнего должен работать стрип — все типы/методы/данные, которые не используются пользовательским кодом, вырезаются. В т.ч. так же обрезаются стандартные библиотеки. Это накладывает некоторые ограничения на программистов, но уменьшает размер билдов.
Но поскольку я в мобилках нихрена не понимаю, проверить это не могу. На десктопах Unity, похоже, такой фигнёй не заморачивается, тут ±10 Мб ничего не решают.
_>Дело не в этом, а в том, что собственно игровые скрипты (которые пишутся на C# или JS) занимают очень маленькую часть исполняемого кода игры.
Скажем, 5 Мб IL-кода — это много или мало? Это типичный размер кода, написанного для конкретной игры, после компиляции. Без учёта стандартных библиотек (которыми этот код пользуется) и без учёта вспомогательных внешних библиотек, типа SharpZipLib, Json-тра-та-та и прочих (которыми этот код тоже пользуется, иначе бы не потащил за собой в игру).
Глянул на Paint.NET, установленный на моём компьютере. Там все существующие .exe и .dll в сумме занимают в два раза меньше.
_>Я немного не об этом. Я имел в виду, что если кто-то напишет игру только на JavaScript, то может ему не надо будет тащить с собой все эти мегабайты ради поддержки работы C#?
JavaScript/UnityScript — такой же .Net-язык, как C#, просто чуть урезанный в возможностях и чуть менее строго типизированный — примерно как Visual Basic. Только синтаксис похож не на VB, а на Java/JavaScript/ActionScript. Он не имеет отношения к тому JavaScript, который в браузерах.
Почему этот язык официально называют JavaScript, я не знаю. На гитхабе он зовётся UnityScript. Откомпилированный код попадает в библиотеки с именами Assembly-UnityScript-xxx.dll
Соответственно, UnityScript тоже требует наличия рантайма Mono со стандартными библиотеками, плюс тянет с собой одну-две маленьких управляемых библиотечки с типами, специфичными конкретно для UnityScript и отсутствующими при разработке на C#.
_>Или там нельзя так почистить движок и он по любому тащит всё, даже если оно не используется?
Кстати, на мобилках должна работать оптимизация кода по размеру. И для нативного кода движка, и для управляемого пользовательского кода. Для последнего должен работать стрип — все типы/методы/данные, которые не используются пользовательским кодом, вырезаются. В т.ч. так же обрезаются стандартные библиотеки. Это накладывает некоторые ограничения на программистов, но уменьшает размер билдов.
Но поскольку я в мобилках нихрена не понимаю, проверить это не могу. На десктопах Unity, похоже, такой фигнёй не заморачивается, тут ±10 Мб ничего не решают.