Когда-то давно я игрался с программированием модов для Unreal Tournament — UnrealScript, отсутствие доступной документации, все дела. Так вот, я был до предела поражен обнаружив в языке поддержку FSM. Натуральных FSM, на уровне рантайма. А еще поддержку достаточно прозрачной сетевой репликации. Вероятно, чего-то еще, не помню уже.
При этом — Java-подобный язык, который читался легко и просто, не ломая глаз. При том, что я тогда не знал ни одного C-подобного языка. Я почитал код два-три дня и сел писать свой первый мутатор. И написал.
Это пример того, что я считаю реально хорошим языком для разработки игр. Не маркетинговый bullshit типа «смотрите, как тут все просто», когда ничего на самом деле не просто, а крутой и упрощающий жизнь функционал при легком вхождении в язык.
>> инди-девелоперу, который придумал классный концепт 2D-игры
Бред какой-то. Во-первых, если он не умеет программировать — какой из него «девелопер»? Во-вторых — он идет в места тусовки около-геймдевных прогеров и ищет там кого-то подходящего, кто умеет. Типа, «Пипл, у меня есть клевый концепт, но нет бабок. С вас реализация, с меня процент прибыли».
В-третьих, этот ваш бэйсик нисколько не избавляет от необходимости оперировать абстракциями типа «объект», «цикл», «условие». Соответственно, человек должен быть УЖЕ сколько-то программистом, чтобы что-то делать.
Ок, можно просто сгруппировать материал по сложности, если хочется расширить аудиторию.
В процессе написания и обсуждения крутой технической статьи автор узнает гораздо больше нового, проясняя для себя(или для других) какие-то аспекты темы — несомненный профит. А если найдутся таки эти самые «полтора гика» — это вообще отлично.
Я что-то увлекся и забыл две ссылки, с которых нужно начинать, чтобы понять, как вообще дело доходит до KeInsertQueue/KeRemoveQueue и KQUEUE/DISPATCHER_OBJECT: web.archive.org/web/20101101112358/http://doc.sch130.nsc.ru/www.sysinternals.com/ntw2k/info/comport.shtml habrahabr.ru/post/59282/ раздел «Внутреннее устройство» — перевод предыдущей, довольно вялый.
>> Как после их появления поток «оживет» совершенно не понятно
Вкратце — так же, как он оживает при выходе из WaitForSingleObject. Ожидание объекта синхронизации уровня ядра.
Чуть подробнее:
— поток, вызвавший GetQueuedCompletionStatus или WaitForSingleObject помечается как waiting,
— добавляется в список ожидающих потоков объекта синхронизации,
— выкидывается из планирования на указанный timeout или до активации объекта синхронизации.
В нашем случае объект синхронизации активируется вызовом PostQueuedCompletionStatus, например.
>> компромисс между простотой восприятия и техническими подробностями.
Этот компромисс не нужен. Простота восприятия не важна, если вы хотите написать действительно крутую техническую статью.
Вообще, реализуемо. Вспомнить, Singularity от MS — драйвера там были вполне себе managed. Правда, для этого придутся втащить в ядро JVM, но это уже так, мелочи. =)
>> ведь мне нужно иметь доступ к огромным общим коллекциям
А можно и здесь поподробнее? Я не совсем понял, откуда берутся большие объемы shared данных.
перекрытие чанков?
У нас, кмк, уже установилась достаточно доверительная обстановка, чтобы я мог напрямую спросить — а что в этом такого-то, в этом есть какой-то смысл?..
Алсо, предположение, что я читаю Лебедева, оскорбительно. =)
Долго медитировал на оба варианта…
Ок, вы склонили меня к бессмысленному задротству.
Заявляю — на предлагаемом логотипе вертикальные линии кажутся непропорционально тонкими. Кажущаяся непропорциональность вертикальных линий вносит дисгармонию в логотип и смятение в умы клиентов — подсознательно это воспринимается чем-то неустойчивым, колосс на глиняных ногах. Несущая должна быть массивной, символизируя незыблемость и глубокий, основательный подход к делу.
/* надеюсь, я достаточно емко передал свой взгляд на проблему */
При этом — Java-подобный язык, который читался легко и просто, не ломая глаз. При том, что я тогда не знал ни одного C-подобного языка. Я почитал код два-три дня и сел писать свой первый мутатор. И написал.
Это пример того, что я считаю реально хорошим языком для разработки игр. Не маркетинговый bullshit типа «смотрите, как тут все просто», когда ничего на самом деле не просто, а крутой и упрощающий жизнь функционал при легком вхождении в язык.
Бред какой-то. Во-первых, если он не умеет программировать — какой из него «девелопер»? Во-вторых — он идет в места тусовки около-геймдевных прогеров и ищет там кого-то подходящего, кто умеет. Типа, «Пипл, у меня есть клевый концепт, но нет бабок. С вас реализация, с меня процент прибыли».
В-третьих, этот ваш бэйсик нисколько не избавляет от необходимости оперировать абстракциями типа «объект», «цикл», «условие». Соответственно, человек должен быть УЖЕ сколько-то программистом, чтобы что-то делать.
В процессе написания и обсуждения крутой технической статьи автор узнает гораздо больше нового, проясняя для себя(или для других) какие-то аспекты темы — несомненный профит. А если найдутся таки эти самые «полтора гика» — это вообще отлично.
web.archive.org/web/20101101112358/http://doc.sch130.nsc.ru/www.sysinternals.com/ntw2k/info/comport.shtml
habrahabr.ru/post/59282/ раздел «Внутреннее устройство» — перевод предыдущей, довольно вялый.
Вкратце — так же, как он оживает при выходе из WaitForSingleObject. Ожидание объекта синхронизации уровня ядра.
Чуть подробнее:
— поток, вызвавший GetQueuedCompletionStatus или WaitForSingleObject помечается как waiting,
— добавляется в список ожидающих потоков объекта синхронизации,
— выкидывается из планирования на указанный timeout или до активации объекта синхронизации.
В нашем случае объект синхронизации активируется вызовом PostQueuedCompletionStatus, например.
Читать:
blogs.msdn.com/b/ntdebugging/archive/2008/05/07/work-queues-and-dispatcher-headers.aspx и оттуда по ссылкам
computer.forensikblog.de/en/2006/02/dispatcher-header.html (типы объектов синхронизации уровня ядра)
исходники ReactOS.
Этот компромисс не нужен. Простота восприятия не важна, если вы хотите написать действительно крутую техническую статью.
А можно и здесь поподробнее? Я не совсем понял, откуда берутся большие объемы shared данных.
перекрытие чанков?
И вообще — не подскажете толковое описание игровой механики?
Что за наркоман это придумал?..
У меня слов, кроме «вон из профессии!» нет.
Алсо, предположение, что я читаю Лебедева, оскорбительно. =)
Ок, вы склонили меня к бессмысленному задротству.
Заявляю — на предлагаемом логотипе вертикальные линии кажутся непропорционально тонкими. Кажущаяся непропорциональность вертикальных линий вносит дисгармонию в логотип и смятение в умы клиентов — подсознательно это воспринимается чем-то неустойчивым, колосс на глиняных ногах. Несущая должна быть массивной, символизируя незыблемость и глубокий, основательный подход к делу.
/* надеюсь, я достаточно емко передал свой взгляд на проблему */