Записи участника (warzes) - Форум игроделов

Дата: Четверг, 25 Октября 2012, 06:54 | Сообщение # 61 | Тема: Мануал по созданию игры

участник

Сейчас нет на сайте

Quote (Modelkin)

Вот скажи, где я тут агитировал бросить изучение OpenGL или DirectX? Где я агитировал за Unity?

А вот это чьи слова?

Quote

Ну вот - твой скил повышен. И теперь, ты становишься настоящим начинающим программистом-игроделом. В доказательство - на лбу шишка.
И выбираешь себе свой первый игровой движок (из написанных профессионалами для игроделов) и начинаешь спешно изучать его API и язык, C# - там, Python - ли.
(Либо делаешься писателем движков, редакторов и утилит, и мучаешь DirectX SDK)

Quote (Faeton)

В общем, DirectX - это лучше потом, когда окрепнешь и сможешь ему противостоять.

Потом не будет, человек привыкнет к легкому и сразу умрет на первом же треугольнике. Надо закаляться, пройти через ад, чтобы потом было легче и комфортней. Ах, да GAPI (DX или OGL) - это всего 10 (а то и 5)% от игры

Quote (Modelkin)

warzes, А где эти люди, самостоятельно изучившие DirectX и работающие в ААА конторе программерами движков? А тебя там ждут? А сколько таких контор в СНГ? Что-то мне пока ни попадались такие люди на просторах инета

Saber Interactive. Сделали TimeShift, работали над какой-то частью Halo. Расположены в Санкт-Петербурге. Меня звали, к сожалению не смог переехать.
Ubisoft Kiev - очень много брали юниоров
Создатели движка Unigine расположенные в Томске тоже ищут людей хорошо понимающих GAPI

Quote (Modelkin)

Почему ты его делаешь программистом движков? Даже не уточнив у него данный вопрос?

Я этого не говорил, я сказал - просто пусть садится и делает игру не заморачиваясь движками

Quote (Faeton)

А вот если спустя какое то время попадёшь в контору которая сама пишет себе мощный движок (либо очень мощная контора либо непродуманный ход руководства) вот тогда и исользуешь навыки приобретённые при работе с другими движками

Какие навыки? Я уже писал про портирование - это работа для джуниора, но откуда человек юзающий готовые движки получит эти навыки?
Или вот шейдеры об которых так расписывает Modelkin, знаешь какой есть прикол? А то что на одну модель может быть только один пиксельный и один вершинный шейдер. То есть ты НИКАК не подключишь десяток шейдеров (освещение, материал, тени, бамп, паралакс) к модели. Решение есть - убершейдеры и микрошейдеры, в готовых движках все уже решено, но вот придешь и тебе скажут это сделать - откуда ты будешь знать как это делать и вообще зачем это надо?
Элементарно, будешь писать игру в конторе, а она виснет на компьютерах следующего поколения, и тебе говорят, делай что хочешь, но игра должна летать на древних машинах, что ты будешь делать совершенно не зная об всяких алгоритмах квадтри, батчах, инстансинге, лодах, а ведь это самые примитивные техники оптимизации, но готовый движок конечно же их имеет и ты даже не знаешь об этом

Quote

Есть желание писать эпичные РПГ и ММОРПГ

Вот именно, чтобы делать эпичные РПГ и MMORPG, нужно как раз уметь писать движок а не в редакторе набросать десяток моделей, и отписать скрипты.

Quote (Modelkin)

Типа C#- этого не позволяет, и вообще спросом не пользуется?

И че? Без разницы на чем ты пишешь, хоть на С++ (как в CryEngine), это именно что скрипты а не код, потому что ты ограничен возможностями движка.

Дата: Среда, 24 Октября 2012, 08:37 | Сообщение # 62 | Тема: Мануал по созданию игры

участник

Сейчас нет на сайте

Quote (Modelkin)

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

И? Что по твоему делается первые два месяца проекта? Геймдизайнеры пишут диздок, и если команда не школоло, то диздок даже первый набросок, это месяцев 2-3 и страниц от 200 до 1000, за день не написать. Можешь убедиться, поищи doom bible. Это одна из первых концепций первого doom. То есть это даже еще не диздок (тем более Кармак отказался от того что там написано), это концепция (то есть виденье) одного из разработчиков, и она на 79 страниц А4. Ты всерьез считаешь что такое можно за день написать? А ведь с этого теперь надо диздок писать. А с диздока - технические спецификации одну для программистов и одну для моделеров/художников. Все это - время которое вполне хватит набросать движок игры программистам, а сценаристам написать сюжет.

Quote (Modelkin)

Для хорошего специалиста по Unity найти работу - раз плюнуть. А работая в отрасли, двигаться в ней гораздо легче, чем мечтая и возясь со своим никому не нужным движком. Знать технологию чистого API это немалый плюс и лучше знать, но это еще не повод брать тебя на работу.

Сама наивность... Вот только чего это на собеседованиях спрашивают не количество игр сделанных на конструкторе или псевдодвижке, а что такое О() или какой контейнер использовать при таких-то условиях, или различия между стеком и очередью. Все просто - скриптовики (а именно так называются программисты, пишущие на готовых движках, потому что пишут они не код а скрипты которые выполняются движком) мало востребованы и среди каких-нибудь модмекеров (так, чтоб ты не доказывал что типа никакие на юнити не скрипты - warcraft 3 имеет свой язык jass, он на столько мощный, что позволяет выполнять любую задачу, и даже юзать ООП, но вот скриптом он от этого не перестал быть) их больше и при этом ЧСВ у них пониже (ибо программистами себя не считают).

Это рынок, никого не волнует сколько ты там игр на юнити наделал, работодателя волнует только то как ты будешь справляться с ЕГО работой. Потому что если фирма серьезная, то у нее давно есть своя база наработок, и ты тут приходишь такой весь с десятком игр на юнити, а тебе дают задание - "мы расширяемся, вот игра на DX9, портируй ее на линукс (или там андроид), ничего больше не надо, лишь бы запускалась..." Ну и? Что ты будешь делать со своими десятками сделанных на юнити игр? С нуля на юнити соберешь? Тебе за это не заплатят, а знаний как это все работает изнутри у тебя нет, за тебя все это юнити делал

Добавлено (24.10.2012, 08:33)
---------------------------------------------

Quote (Modelkin)

В общем, не хочу тут разводить лишнего как маленький. Жаль только, что помешали наставить человека на путь, и оставили его вновь разминать ноги на распутье, просто из желания поспорить, увидев что-то, что противоречит собственным представлениям, знаниям и заблуждениям.

истинный путь, это всегда самый сложный. То что на юнити игру можно собрать за месяц - это не истинный путь... Разработчики игр умнее школоло которое ведется на рекламу unity. Наисание своего движка - это как минимум еще один человек в штате команды (на самом деле больше - один с шейдерами работает, второй портированием, третий инструментарием). Лишние люди, это лишние убытки, зарплату ведь надо платить, и движкописатели, это часто очень опытные люди, а значит и зарплата у них от 3000 $. Движкописательство это долго. Допустим у нас 3 чела, платим 2000 за 6 месяцев, это если перевести в рубли 1080000 рублей. То есть один миллион за один только движок. И несмотря на такие расходы, что-то мало кто из ААА игр лицензируют движок. Или вон для чего в TES Skyrim был написан свой движок, если и движок Oblivion можно было чуть подкрасить и использовать?

Возможно в другой вселенной и будут делать игры только в unity, но сейчас, если хочешь заниматься чем-то большим в будущем, чем фермами для вконтакта и мобильным мусором, не стоит думать что одного unity достаточно чтобы стать крутым разработчиком

Добавлено (24.10.2012, 08:37)
---------------------------------------------
Хотя, да, пусть изучает unity, меньше конкуренции будет, чем меньше толковых программистов, тем больше на них цена, а то с 2005 (когда еще не было бесплатных движков) слишком их что-то много стало, надо уменьшить

Дата: Среда, 24 Октября 2012, 05:30 | Сообщение # 63 | Тема: Мануал по созданию игры

участник

Сейчас нет на сайте

Quote (Modelkin)

Для начала, выброси книги по изготовлению игр на OpenGL или DirectX. Что взять с книги, в которой автор врет уже на обложке. На OpenGL и DirectX сурьезные игры не делают.

А особенно не слушай людей которые врут в ответе темы. Серьезные игры как раз таки делают не на готовых движках а на чистом OGL и DX, просто во время этой работы появляется нечто что называют движком. Скачай Doom 3 и посмотри как там смешан код игры и движка, скачай исходники Arx Fatalis там вообще такого понятия как движок нет, есть несколько модулей выполняющих определенную работу. Это только шлак и казуал делают на юнити и UDK (не unreal engine, это разные вещи)

Quote (Modelkin)

Забей на "Microsoft DirectX SDK", на ближайшие полгода.

Я когда-то тоже забил, теперь жалею о потраченном годе и имею религиозную ненависть к OGL, а не забил бы, сейчас бы оба юзал, потому что OGL 3 и DX11 очень подобны по принципу работы...
Ну и коронный ответ для новичков ломающий им мозги - OpenGL, это не библиотека а спецификация и ее скачать нельзя, очень бесит (кстати С++, это тоже спецификация в виде книги, но почему-то никто так не отвечает, и когда спрашивают где скачать, дают сайты на компиляторы). А DX SDK, пошел, скачал и не надо мучаться со всякими glext.h, что для новичков вообще непосильно - ибо требует знаний спеков, которых у них еще нет. Ах да, бесполезная литература где везде и всюду рисуют через glBegin-glEnd, ничему кроме повреждения мозга не научит, потому что основы компьютерной математики надо учить общно, через специальные книги (так и называются - компьютерная математика)

Quote (Modelkin)

Скачай и начни с RenderMonkey

ну и зачем ему это? Крайзисы писать еще рано, паперы он еще не сможет читать, так что шейдеры ему особо и не нужны

Quote (Modelkin)

Думаешь удастся избежать знакомства с готовыми движками? Можно ли стать писателем не читая книг? Придется присмотреться к готовым движкам и убедиться в убогости своего.

угу-угу. Только нужно не движки сравнивать а игры писать, а то доходит до глупости у некоторых - делать крестики нолики на UDK или шутеры на Unity, только потому что UDK/unity - это круто.

Вообще дам такой совет, не заморачивайся над движками...Для создания игры вообще не нужны такие монстры как UDK/unity. Просто садись и пиши игру, если будешь правильно соблюдать ООП, то часть кода сама превратиться в будущий движок, и да - он на фоне UDK/unity будет казаться убогим, но вот свою задачу он будет выполнять на 125% круче чем они, потому что свой, и потому что полностью заточен под игру с учетом всех игровых фишек.

Quote (Modelkin)

И выбираешь себе свой первый игровой движок (из написанных профессионалами для игроделов) и начинаешь спешно изучать его API и язык, C# - там, Python - ли.

Вот так и появляется очередной никому не нужный игростроевец, потому что в серьезных компаниях как раз таки никому не нужны unity специалисты, там свои собственные движки, порой до такой степени убогие что без хороших навыков написания движка с нуля, просто нереально с ними работать. У меня есть один знакомый, устроился в одно отделение юбисофта, там юзали лицензированный Unreal Engine (не UDK, кстати, легко можно нагуглить за 2004 год исходники этого движка), так он такое писал об коде движка с которым ему приходилось работать... а ведь был простым junior

Дата: Воскресенье, 21 Октября 2012, 16:00 | Сообщение # 64 | Тема: Wiki по OpenGL :)

участник

Сейчас нет на сайте

автор, куда пропал? Не бросай это нужное дело cool

Дата: Воскресенье, 07 Октября 2012, 14:17 | Сообщение # 65 | Тема: Wiki по OpenGL :)

участник

Сейчас нет на сайте

Quote (Archido)

Вообще не принципиально, не вижу ничего плохого.

принципиально. в OGL 3.2+ этих команд нет, о чем и написано в FAQ. То есть человек будет учиться, юзать эти команды, потом начнет писать свой проект используя самые современные средства OGL 4, и вот облом, там нет таких функций, а если даже и есть - они больше не поддерживаются аппаратно, а это скорее всего ударит по производительности игры. Хотя с другой стороны как вводные статьи, может и нормально, потом просто где-то написать как надо делать. Вообщем все в руках автора.

Quote (Archido)

но статья будет проще - не нужно ничего знать про матрицы.. и объяснять не нужно, иначе копипаст и непонятки как оно работает.

Матрицы это же самое главное что нужно знать biggrin

На самом деле там тоже ничего сложного, по крайней мере в DX 11 это одна-три строчки в шейдере, плюс немного в коде - умножение и транстформации матриц

Дата: Воскресенье, 07 Октября 2012, 10:58 | Сообщение # 66 | Тема: Wiki по OpenGL :)

участник

Сейчас нет на сайте

Я бы не стал юзать GLUT, есть более современные вещи, glfw к примеру
а на чистом OGL, так вообще круть будет:)

Еще один момент, ты юзаешь glTranslate/glRotate/glScale, это плохо
http://www.opengl.org/wiki....ated.3F
Нужно уже избавляться от наследства OGL 1-2 и переходить на хотя бы OGL 3 (при текущем OGL 4). Кста, по этой же причине и нехе перестали рекомендовать, ибо сейчас уже так не делают, и ничего полезного знание этих функций не даст. Будет очень хорошо, если ты учтешь этот момент и будет держать статьи в современном состоянии, потому что те кто их будут читать, начнут работу когда OGL будет 5 или даже 6 версии, и им тем более не нужны будут знания OGL 1 (да и вырежут, если еще не вырезали, эти функции)

вот трехмерный куб без этих функций - http://openglbook.com/the-book/chapter-4-entering-the-third-dimension/
(хм, они юзают freeglut)

Сообщение отредактировал warzes - Воскресенье, 07 Октября 2012, 11:12

Дата: Воскресенье, 07 Октября 2012, 05:13 | Сообщение # 67 | Тема: Wiki по OpenGL :)

участник

Сейчас нет на сайте

Кстати, потихоньку можно и вот это переводить - http://www.opengl.org/wiki/Main_Page
многие, думаю, будут благодарны:)

Дата: Суббота, 06 Октября 2012, 05:40 | Сообщение # 68 | Тема: Wiki по OpenGL :)

участник

Сейчас нет на сайте

главное не забрасывай, собрат по вики smile

Вот, возможно пригодится - http://rastertek.com/tutgl40.html когда начнут заканчиваться идеи - а что писать дальше:)

Также советую свои статьи поместить в отдельный раздел (как сделал я) а не делать центром вики, в будущем, если появится сообщество, или решишь другие статьи писать - очень пригодится.

Ну и чуть больше теории не помешает, я сам собираюсь наполнить свои статьи кучей теории, ибо код это хорошо, но знания и понимание лучше

Добавил себе на главную ссылку на вашу вики.

Удачи!

Сообщение отредактировал warzes - Суббота, 06 Октября 2012, 05:54

Дата: Воскресенье, 30 Сентября 2012, 16:36 | Сообщение # 69 | Тема: Вики по DirectX 11

участник

Сейчас нет на сайте

Quote (Archido)

Еще раз, у тебя объект - текстура, которая используется в куче других мест. Как определять момент, когда ее нужно удалить (и чтобы все остальные об этом узнали) и отследить момент передачи невалидного указателя в какой-нить SetTexture, иначе все упадет.

есть куча выделенная malloc, она используется в куче других мест. Как определять момент, когда ее нужно удалить (и чтобы все остальные об этом узнали) и отследить момент передачи невалидного указателя в какую-нибудь функцию... Так Си тогда тоже ООП cool

Я к тому что работа с памятью это уж точно не ООП, подсчет ссылок и сборщик мусора можно спокойно реализовать процедурно (например через статические переменные). От того что все интерфейсы DX унаследованы от IUnknown конечному пользователю ни холодно, ни жарко, для изучения об этом вообще можно не знать, а для серьезной работы понимание ООП уже придет

Quote (Archido)

Это не в кассу и WinApi не построено на COM.

Почему же не в кассу? Для того чтобы изучить GAPI, можно совершенно спокойно не знать как оно там внутри построено (точно также как и для изучения Unity можно спойкойно не думать о например том как там архитектурно работает менеджер ресурсов) Да, вон я до сих пор не понимаю как работают VA_arg что мне совершенно не мешает юзать printf() и писать свои реализации с переменным числом аргументов.
То есть чтобы изучать DX, надо знать только что такое классы, да и то не обязательно - спокойно можно писать процедурно. Потому что мы не наследуем сами ни один из интерфейсов DX

Добавлено (30.09.2012, 16:36)
---------------------------------------------
Вот сделал простенько подсчет ссылок на Си, процедурно:

Code

#include <stdio.h>
#include <stdlib.h>
#include <malloc.h>

struct Foo
{
    int i;
};

static int FooNum = 0;
static Foo *FooParrent = 0;

Foo* Create()
{
    if (!FooNum)
     FooParrent = (Foo*)malloc(sizeof(Foo));

    FooNum++;
    printf("Foo num %d\n",FooNum);

    return FooParrent;
}

void Free()
{
    FooNum--;
    printf("Foo num %d\n",FooNum);
    if (!FooNum)
     free(FooParrent);
}

int main(int argc, char* argv[])
{
    Foo *foo = Create();
    Foo *foo2 = Create();

    Free();
    Free();

    system ("PAUSE");
    return 0;
}

Так причем здесь ООП? А ведь тоже самое, считаем количество ссылок. Если один объект был уничтожен, но кто-то еще это юзает, то не удаляем память
ООП, это как раз наследование, полиморфизм и инкапсуляция. А так как мы не должны ни от чего наследоваться, не должны ничео полиморфировать и ничего от нас в DX не скрыто - это значит что мы спокойно можем писать в любой другой парадигме (вот например в движке Ogre нельзя без ООП, потому что там надо наследоваться и есть инкапсуляция внутреней архитектуры_

Сообщение отредактировал warzes - Воскресенье, 30 Сентября 2012, 16:40

Дата: Воскресенье, 30 Сентября 2012, 15:52 | Сообщение # 70 | Тема: Вики по DirectX 11

участник

Сейчас нет на сайте

Quote (Archido)

Банально - если ты не в курсе, то COM с помощью подсчета сылок умеет контролировать владение объектами

Это все скрыто от обычного пользователя. Все WinAPI построено на COM, но это не мешает мне его юзать например на ассемблере или Си.

Quote (Archido)

Один и тот же объект может использоваться в разных местах и если одному из них сделать Release, то в другом месте будет обращение по невалидному указателю

Это не ООП, точно также в процедурном Си можно в одном месте удалить кучу а в другом к ней обратиться. Просто тут нужно понимать что если ты что-то создал, это нужно потом будет удалить, и если ты это удалил то не нужно больше к этому обращаться, но только вместо new/delete - CreateX/Release.

А вообще к теме это не относится. А OGL я не люблю, да, но возможно причины могут, как я писал, быть даже банальней - не осилил biggrin

Дата: Воскресенье, 30 Сентября 2012, 15:32 | Сообщение # 71 | Тема: Вопрос-Ответ (C++)

участник

Сейчас нет на сайте

Quote (Drac)

мне нужны окна, кнопки и тому подобное ! Так как азы уже давно позади.

Это тебе не формошлепство:). Изучай теперь WinAPI (те самые окна, кнопки), MFC (никогда не изучал и вообще сторонюсь этого монстра). Qt или WxWidget (в отличие от первых двух - мультиплатформа, да и код более понятный, но доки на русском нет)

Дата: Воскресенье, 30 Сентября 2012, 15:09 | Сообщение # 72 | Тема: Вики по DirectX 11

участник

Сейчас нет на сайте

Quote (Archido)

Не понял о чем ты

Я как раз о glEnable() с их тысячами параметров и не только z-буфер, альфа и т.д. А также о тысяче других вещей - толщине линии, наложении текстуры (если ее предварительно самостоятельно не выключить, она будет рисоваться везде, тогда как в DX только до команды Draw...()) матрицах (возможно в OGL3+ уже и не проблема с переносом матриц в шейдеры, но вот часто забудешь про какой-нибудь сдвиг или вращение и потом удивляешься тому что видишь на экране)

Quote

потому что там нет ООП

Где там в DX ООП?. Инкапсуляция, Наследование, Полиморфизм - этого нет. А от того что интерфейсы там в виде классов - это не ООП (и даже то что они наследуются от интерфейсов COM - ведь мы то этого не замечаем).

Кста, как раз и урок тут написал про состояния рендера
Урок

Дата: Воскресенье, 30 Сентября 2012, 12:36 | Сообщение # 73 | Тема: Вики по DirectX 11

участник

Сейчас нет на сайте

Quote

А если нет, то что тогда?

Ничего, дальше писать буду, но просто интересно:)

Quote (Archido)

а для новичков он слишком сложен

не знаю, ИМХО OpenGL сложнее, хотя бы тем что в OGL надо помнить тыщу и один параметр (ну там текстура, параметры смешивания и т.д.) которые у тебя установлены. В DX такого нет вообще, можно свободно переключать что угодно зная что потом это не вылезет где-нибудь в другом месте от того что ты забыл это отключить. Синтаксис тоже простой, термины четко озвучены (в отличие опять же от OGL). И не надо доказывать что OGL лучше, я именно с него начинал поверив когда-то что он типа легче для новичков, только время зря потратил:) Хотя, может быть причины были и немного в другом - не знаю

Quote (Archido)

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

Ну да, это возможно

Quote (Archido)

Мм, наверное это (написание таких статей) полезно в первую очередь для тебя самого.

Ага, я и сам неплохо руку набил по DX во время их написания.

Дата: Воскресенье, 30 Сентября 2012, 09:00 | Сообщение # 74 | Тема: Вики по DirectX 11

участник

Сейчас нет на сайте

написан новый урок - вывод треугольника. Следующий урок будет про вывод трехмерного куба :D, а также про систему координат и матрицы
Следующий урок будет чуть позже - я так сказать решил отдохнуть и поработать над проектами

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

Добавлено (07.09.2012, 13:02)
---------------------------------------------
Написан новый урок -про мировое пространство. Пока пометил что он в доработке - надо дописать теорию

Далее будет урок про текстуры и загрузку модели из файла

Добавлено (08.09.2012, 15:48)
---------------------------------------------
Чето как-то тихо:)

Поэтому опишу будущее развитие - так как я пока с вики работаю в одиночку (люди, а ведь вы тоже можете писать статьи, даже регистрироваться не нужно, хотя желательно) то буду развивать только такие направления - вопервых основной цикл "DirectX шаг за шагом" в нем будет изучение работы с самим дирексом, все примеры - это абстрактные кубики и шарики. Еще один раздел - математика, там только теория будет. Третий раздел - HLSL, изучение синтаксиса шейдеров, на тех же абстрактных примерах (но не самих алгоритмов, только синтаксис). А вот четвертый, наверное самый вкусный - создание трехмерного мира. Он будет базироваться на трех предыдущих. Вот так выглядят первые 4 урока из него:
1 урок
Подготовка, игровая камера и перемещение по миру

2 урок
Геометрия ландшафта, ее загрузка из файла

3 урок
Освещение ландшафта

4 урок
Текстурирование ландшафта

Код этих уроков уже написан, осталось оформить в статью. Но это из будущего:) Потому что я пока не расммотрел нужные разделы - текстурирование и освещение в "DirectX шаг за шагом". Но думаю, к концу месяца эти уроки будут опубликованы.

Добавлено (14.09.2012, 13:11)
---------------------------------------------
Новая статья
Кроме того сильно переработана навигация вики http://ru.directx.wikia.com/wiki/DirectX_вики
Пока многие разделы пусты, я ведь считай в одиночку веду это дело. Если кто желает поделится своим опытом по DirectX - приветствую, вход свободный, создавайте свои разделы и пишите cool

Добавлено (14.09.2012, 16:39)
---------------------------------------------
И следом еще один урок - http://ru.directx.wikia.com/wiki/DirectX_11_шаг_за_шагом:Простое_освещение

Надеюсь что успею также написать урок про текстуры

Добавлено (15.09.2012, 11:22)
---------------------------------------------
Еще одно, про текстуры - http://ru.directx.wikia.com/wiki/DirectX_11_шаг_за_шагом:Текстуры

Добавлено (29.09.2012, 08:28)
---------------------------------------------
Новый урок - загрузка модели из файла
статья

Добавлено (30.09.2012, 09:00)
---------------------------------------------
Еще один урок 2D

Кроме собственно рисования изображений рассмотрено отключение и включение Z буфера, а также работа с динамическими вершинными буферами

Люди, тут вообще кому-то интересны эти уроки? Или одни только unity программисты здесь?

Сообщение отредактировал warzes - Суббота, 08 Сентября 2012, 15:51

Дата: Вторник, 11 Сентября 2012, 16:02 | Сообщение # 75 | Тема: Проблема с MVC++ 2005

участник

Сейчас нет на сайте

Ммм, еще вот что попробуй. В Solution Explorer левой щелкни по проекту (то есть выбери проект), затем правой и через контекстное меню добавляй.
Если так и делал, то тогда фиг знает

Дата: Понедельник, 10 Сентября 2012, 04:20 | Сообщение # 76 | Тема: Проблема с MVC++ 2005

участник

Сейчас нет на сайте

Quote (goldsphere)

Зря...Я знаю людей работающих ещё в 6 версии, но в 5, я не встречал..

глупость написал - 2005 более поздняя чем шестая, между ними еще две версии

автор, ты откуда студию скачал? Либо у тебя не был установлен сам С++ (то есть басик и шарп установились а С++ нет), что врядли, потому что ты создал проект С++, либо она покоцана пиратами... Либо ты что-то в настройках намудрил

Добавлено (10.09.2012, 04:20)
---------------------------------------------

Quote (AllRadin)

Ввиду того, что в учебниках (стареньких) вся работа ведется в среде MVC++ версии 2005 года

и вообще плюнь на это, ставь новую студию, С++ что в 2005 что сейчас почти один и тот же (просто в 2005 старый стандарт, а в 2010 появился новый стандарт, но каких то изменений в базовых вещах все равно там нет, да и потом если что давно уже перевели Прата "Язык программирования С++. Лекции и упражнения" за 2011 год, там и новый стандарт рассматривают)

Дата: Пятница, 07 Сентября 2012, 12:55 | Сообщение # 77 | Тема: Вопрос-Ответ (C++)

участник

Сейчас нет на сайте

Quote (MrAkakuy)

Простите, что?

я кажется понял про что он. gansterm, гугли SVN, в любой доке написано как патчить файлы в репозиториях. если это оно. Никаких других патчеваний по отношению к коду не бывает

Дата: Пятница, 31 Августа 2012, 17:00 | Сообщение # 78 | Тема: Войны Хаоса [2D]

участник

Сейчас нет на сайте

Пришла мне тут одна идейка - сделать простенький варгейм с механикой построенной полностью на удаче. То есть вот шахматы не имеют фактора удачи, только тактика. А здесь наоборот - нельзя ничего предсказать и если ты проигрывал то в следующий ход вполне можешь оказаться победителем cool

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

Ну а теперь

понятия:
- камень, то чем управляет игрок. Если у игрока нет камней - он проигрывает. Камни бывают трех типов. Каждый тип имеет определенную силу - 6,12,20. 6 - это число от 1 до 6, 12 - от 1 до 12, 20 - от 1 до 20. Сила - это единственная характеристика камня
- узел, клетка дающая преимущества или штрафы тому игроку, чей камень на ней стоит. Обычно это возможность создавать камни, добыча эфира, либо ловушка убивающая камень или ворующая эфир, а также меняющая сторону камня
- поле, собственно область по которой перемещаются камни и в которой создаются узлы

Игровой ход
Игра состоит из раундов. Раунд состоит из двух фаз - влияние Хаоса и ходы игроков.
В течение одного раунда каждый игрок совершает только один ход. Очередность определяется в начале игры. В течение хода игрок совершает действия на очки действий.

Влияние Хаоса
- с некоторой вероятностью типы камней могут сменить силу, и те камни что были сильными станут слабыми, а слабые сильными. Думаю сделать вероятность так - берется первый тип, совершается бросок силы, если выпало 1, этот камень меняет тип на следующий(6 на 12, 12 на 20, 20 на 6). При этом тот тип который ранее имел такую силу получает от изменяющего силу (то есть если тип меняет силу с 6 на 12, то другой тип который ранее имел 12, теперь получает 6). Всего три броска для каждого типа. Ни при каких условиях не может быть двух разных типов камней с одинаковой силой.
- переход камней. каждый ход каждый камень имеет вероятность перейти на сторону противника, если выпадет 1 на броске силы (то есть слабые с большей вероятностью перейдут)
- непостоянство узлов. каждый ход нейтральные узлы (те, на которых нет камней) могут сменить свою позицию на поле, кроме того их количество тоже может измениться. Управляемые узлы имеют вероятность (то есть 1 из броска силы) сменить свое свойство, эта вероятность равна силе камня стоящего на нем (то есть приносило эфир и внезапно стало ловушкой)

Очки действий
Каждый игрок имеет столько очков действий, сколько у него камней + количество принадлежащих ему узлов приносящих эфир - количество узлов ворующих эфир.

За одно очко действия можно:
- сдвинуть камень на шаг
- совершить атаку камнем
- использовать способность любого принадлежащего игроку узла, если это возможно

Кроме того игрок может применить заклинания. Каждое заклинание требует определенное число очков действия в зависимости от силы заклинания.

Шаг
Каждый камень может совершить шаг в любом из восьми направлений, но только если на конечной клетке не стоит другой камень. За один раунд камень может совершить только один шаг

Атака
Если враждебные камни стоят по соседству, можно совершить атаку. За каждого близкого союзника камень получает бонус равный броску силы этого союзника. Для совершения атаки, оба игрока совершают бросок силы атакующего и защищающего камня а также всех союзных камней которые стоят по соседству. Тот, чей бросок больше - убивает врага (камень убирается с поля). Союзники при этом не страдают. Так можно спокойно напасть тремя камнями силой 6 на камень силой 20. То есть ваш бросок будет в таком случае 3-18, а вражеский 1-20 (так как у него рядом нет союзника).

Способности узлов

Еще я пока не знаю, стоит ли делать разный ландшафт (то есть в одном месте сложнее двигаться, во-втором труднее атаковать и т.д.)

Обсуждаем:)

Добавлено (31.08.2012, 17:00)
---------------------------------------------
Кстати, если вдруг появится художник желающий нарисовать графику и композитор который напишет музыку - я буду рад

Дата: Понедельник, 20 Августа 2012, 13:11 | Сообщение # 79 | Тема: Вики по DirectX 11

участник

Сейчас нет на сайте

Quote (Undead)

Код неудобно читать, сделай подсветку синтаксиса.

тут надо проверять, как-то неудобно в вики сделана подсветка. Попробую пошаманить но не уверен что получится.

Дата: Понедельник, 20 Августа 2012, 12:34 | Сообщение # 80 | Тема: Вики по DirectX 11

участник

Сейчас нет на сайте

Quote (Нохчи)

если лезть в такие подробности как immediate/deffered context

если честно, я сам не до конца понял подробности о deffered context

Quote (Нохчи)

нужно написать про подбор оптимального feature level

D3D11CreateDeviceAndSwapChain() же сам подбирает наиболее оптимальный. Я вообще думаю, что стоит это место убрать. А если расписывать что при каком будет работать - то это вообще долго, да и не особо нужно.

Quote (Нохчи)

если придираться, двойная буферизация - это наверное все-таки double buffering

В DX11 нет понятия - двойная буферизация, по той простой причине что буферов может быть несколько. По официальной документации это называется swap chain's buffers. Когда же нужно более определенно - front buffer и back buffer. То есть после перевода - передний буфер и задний буфер.
А вот в начале, где я написал "Данная технология называется backbuffer.". я ошибся и сейчас исправлю

Quote (Нохчи)

Плюс еще всякие очепятки.

буду благодарен за указание на них