Menu
▾
▴
openpref-devel — Development of OpenPref
You can subscribe to this list here.
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(27) |
Sep
(73) |
Oct
(2) |
Nov
|
Dec
(2) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2011 |
Jan
|
Feb
|
Mar
(1) |
Apr
(1) |
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: dodikk.reg <dod...@gm...> - 2010-09-15 09:22:40
|
> Тогда сказать делегату (или вьюшке) что рендерить карты этих игроков вообще не надо Это даже мне понятно :). Как реализовать, в смысле. Просто идея как дополнение к твоему ASCII art. Ещё одна идея для feature. Складывать игры в БД (sqlite или firebird embedded какой-нибудь). А потом давать user-у просматривать replay. (по крайней мере, мне было бы интересно). ** читать и собирать вывод консоли не шибко прикольно. Он конечно классный, но с GUI гораздо занимательнее. Кроме того, это может пригодиться при debug-е, а также как примеры для последующего обучения AI (типа модель обучения с учителем). |
|
From: Konstantin T. <an...@ya...> - 2010-09-15 09:17:21
|
>ASCII art rulez. Блин, похоже пробелы съелись :( Отправляю еще раз в аттаче -- Regards, Konstantin |
|
From: Konstantin T. <an...@ya...> - 2010-09-15 08:56:37
|
>Есть ещё идея - для совсем мелких игрок видит только свои карты и то что сходили (3 или 4 карты, лежащие на столе). Остальное можно вообще убрать - особенно когда АНТУРАЖ МЕШАЕТ Usability. Тогда сказать делегату (или вьюшке) что рендерить карты этих игроков вообще не надо -- Regards, Konstantin |
|
From: Antony D. <to...@da...> - 2010-09-15 08:53:40
|
On 09/15/2010 12:44 PM, Konstantin Tokarev wrote: > > > 15.09.10, 12:39, "Antony Dovgal" <to...@da...>: > >> Я, кстати, патч подточил и merge request уже послал. > > Спасибо, гляну вечерком > >> Есть, но её слабо видно.Там где-то в маленьком квадратике есть цифра и некий знак, который я всё время путаю - то ли это пика, то ли это трефа.Зависит от шрифта, конечно, но от шрифта _системного_ > > ЕМНИП, там вообще графика :) Не-а, там текст. -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP |
|
From: dodikk.reg <dod...@gm...> - 2010-09-15 08:49:37
|
> Поясню с помощью ASCII-арта: > ASCII art rulez. Есть ещё идея - для совсем мелких игрок видит только свои карты и то что сходили (3 или 4 карты, лежащие на столе). Остальное можно вообще убрать - особенно когда АНТУРАЖ МЕШАЕТ Usability. |
|
From: Konstantin T. <an...@ya...> - 2010-09-15 08:44:38
|
15.09.10, 12:39, "Antony Dovgal" <to...@da...>: > Я, кстати, патч подточил и merge request уже послал. Спасибо, гляну вечерком > Есть, но её слабо видно.Там где-то в маленьком квадратике есть цифра и некий знак, который я всё время путаю - то ли это пика, то ли это трефа.Зависит от шрифта, конечно, но от шрифта _системного_ ЕМНИП, там вообще графика :) Если надо, шрифты можно в программе подкрутить, не обязательно использовать системный -- Regards, Konstantin |
|
From: Antony D. <to...@da...> - 2010-09-15 08:39:47
|
On 09/15/2010 11:33 AM, Konstantin Tokarev wrote: > > > 14.09.10, 17:50, "Antony Dovgal" <to...@da...>: > >> * смена тайтла окна для доп. информативности в стиле "Player XXX plays 6♦". > > А "OpenPref" в начале останется? Да, конечно, этот префикс есть всегда. Я, кстати, патч подточил и merge request уже послал. > Иначе пользователю, свернувшему окно, может быть труднее его найти. > Но тогда заголовк будет длинноват. Все-таки это тайтл окна, а не веб-страницы, поэтому лучше соблюдать краткость Ну, это не 10 слов, а всего букв 20 максимум. У меня сейчас в тайтле окна с письмом в несколько раз больше. > К тому же, эта информация есть в окне игры. Есть, но её слабо видно. Там где-то в маленьком квадратике есть цифра и некий знак, который я всё время путаю - то ли это пика, то ли это трефа. Зависит от шрифта, конечно, но от шрифта _системного_, а я его в системе ради префа менять не буду. -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP |
|
From: Konstantin T. <an...@ya...> - 2010-09-15 08:38:19
|
Идея проста. Создается класс "делегата" игрока (см. в доках Qt Item Views, если вдруг непонятно о чем речь). Для делегата задается положение на столе в виде одной из условных точек, исходя из которого он выбирает расположение карт и рисует их в правильном месте стола Поясню с помощью ASCII-арта: _______________ | * * | | | Три игрока, раскладка как сейчас | | | | | | | * | ---------------- _______________ | * | | | Два игрока напротив, карты горизонтально | | | | | | | * | ---------------- _______________ | * * | | | Четыре игрока напротив, карты горизонтально | | | | | | | * * | ---------------- _______________ | * | | | Четыре игрока по краям стола | | |* *| | | | | | * | ---------------- _______________ | | | | У игрока внизу карты горизонтально, у игроков сбоку - вертикально | | |* *| | | | | | * | ---------------- _______________ |* *| | | У игрока внизу карты горизонтально, у игроков сбоку - компактно расположены в три ряда | | | | | | | | | * | ---------------- Сначала я думал сделать выбор оптимальной раскладки автоматическим, но потом решил, что лучше он будет жестко контролироваться пользователем движка (на префе свет клином не сошелся же;), а автоматически будет высчитыватсья размер карт (если на экране не хватает места, уменьшать их) Смену раскладки карт думаю сделать доступной для пользователя через гуи Насчет гуи на других языках - пока не планируется, более важна задача "AI на других языках" (хотя если делать обертки, думаю можно сделать для всех апишных классов сразу) -- Regards, Konstantin |
|
From: dodikk.reg <dod...@gm...> - 2010-09-15 08:20:55
|
>> на сайте проекта (http://openpref.sourceforge.net/development/projects/mobile/) уже описаны возможные грабли такой "портируемости". > Вообще-то это я писал :) > Я догадался. Просто иногда питаю слабость к безличным оборотам речи :) А если вкратце, то какова идея? Вычитывать Layout-ы и размеры из config-а (уж не знаю в каком виде - xml, ini или свой велосипед) или ресурса? А затем динамически resize-ить всё на свете? Не знаю. По-моему, написать отдельно для desctop и pda легче будет. Да и не C++ GUI можно будет прикручивать при наличии модульности. Хотя я уже понял что это не есть приоритетно. |
|
From: Konstantin T. <an...@ya...> - 2010-09-15 08:14:35
|
15.09.10, 11:38, "dodikk.reg" <dod...@gm...>: > Оно и так портируемо на Нокиевские платформы. Не думаю, что народ сейчас же накинется писать GUI под АндроидНу да, конечно (*sarcasm*). Константин, на сайте проекта (http://openpref.sourceforge.net/development/projects/mobile/) уже описаны возможные грабли такой "портируемости".Я про "Screen size", и "Screen orientation". Так что GUI будет целесообразно переписать всё равно. Как разделение на библиотеки этому поможет, надеюсь, объяснять не стоит ибо это и так понятно. Хотя ты это можешь причислить к "альтернативным клиентам".GUI под Android при нынешнем состоянии проекта никто точно писать не накинется. > Согласен, пока QT Android не поддерживает (а существующий порт пока сыроват). QtCore портирован, гуи насколько я понимаю надо писать на яве. Для этого я намереваюсь выделить модель в качестве бибилотеки, зависящей только от QtCore, а дальше пусть желающие пишут морды с их любимыми тулкитами > Однако сие может поменяться. Да и заменить в самом ядре ИИ контейнеры QT на контейнеры STL не должно быть большой проблемой. Как я уже сказал, для модели нужен только QtCore (если какие-то хвосты из QtGui и остались, они уйдут при дальнейшем рефакторинге) > Да и под WinMobile (знаю что его считают трупом, но всё же..) с Symbian написать GUI будет в разы легче чем нынче. Думаю лучше минимизировать число велосипедов и не писать новое view для каждой платформы, если на ней уже поддерживается QtGui. И документацию расширять -- Regards, Konstantin |
|
From: Konstantin T. <an...@ya...> - 2010-09-15 08:02:38
|
15.09.10, 11:38, "dodikk.reg" <dod...@gm...>: > на сайте проекта (http://openpref.sourceforge.net/development/projects/mobile/) уже описаны возможные грабли такой "портируемости". Вообще-то это я писал :) -- Regards, Konstantin |
|
From: Konstantin T. <an...@ya...> - 2010-09-15 07:59:51
|
15.09.10, 11:38, "dodikk.reg" <dod...@gm...>: > Я про "Screen size", и "Screen orientation". Так что GUI будет целесообразно переписать всё равно. Возможно. Но лично мне хотелось бы попробовать добиться масштабируемости размера на имеющемся движке (и есть идеи как это сделать) -- Regards, Konstantin |
|
From: dodikk.reg <dod...@gm...> - 2010-09-15 07:39:55
|
> Оно и так портируемо на Нокиевские платформы. Не думаю, что народ сейчас же накинется писать GUI под Андроид Ну да, конечно (*sarcasm*). Константин, на сайте проекта (http://openpref.sourceforge.net/development/projects/mobile/) уже описаны возможные грабли такой "портируемости". Я про "Screen size", и "Screen orientation". Так что GUI будет целесообразно переписать всё равно. Как разделение на библиотеки этому поможет, надеюсь, объяснять не стоит ибо это и так понятно. Хотя ты это можешь причислить к "альтернативным клиентам". GUI под Android при нынешнем состоянии проекта никто точно писать не накинется. Согласен, пока QT Android не поддерживает (а существующий порт пока сыроват). Однако сие может поменяться. Да и заменить в самом ядре ИИ контейнеры QT на контейнеры STL не должно быть большой проблемой. Так что как знать. Может, кто и возьмётся. Да и под WinMobile (знаю что его считают трупом, но всё же..) с Symbian написать GUI будет в разы легче чем нынче. >> Мне можно уже начинать merge с вашим trunk (в смысле, скачать trunk и >> раскидать эти исходники)? > > Можно. Заодно посмотришь, как я их раскидал :) > |
|
From: Konstantin T. <an...@ya...> - 2010-09-15 07:33:38
|
14.09.10, 17:50, "Antony Dovgal" <to...@da...>: > * смена тайтла окна для доп. информативности в стиле "Player XXX plays 6♦". А "OpenPref" в начале останется? Иначе пользователю, свернувшему окно, может быть труднее его найти. Но тогда заголовк будет длинноват. Все-таки это тайтл окна, а не веб-страницы, поэтому лучше соблюдать краткость К тому же, эта информация есть в окне игры. Может лучше создать уведомление в трее, если какое-то решение было принято когда окно свернуто? >* в полу-готовом состоянии так же кнопка "Вернуть снос". Смотри в src/logic/human.cpp строки 73-79 - это реализовано, просто недоступно из интерфейса. Еще, как видно выше, при мезере тоже недоступно (по-идее снос должен делаться одной функцией в обоих случаях, а тип игры браться из модели внутри нее) -- Regards, Konstantin |
|
From: Konstantin T. <an...@ya...> - 2010-09-14 19:30:04
|
2Antony: >Во-первых, там много бардака. А кто соприт :) Просто я стараюсь разгребать его поэтапно >И да, это должно облегчить разработку сетевой версии. Как разделение проекта на части может облегчить разработку сетевой версии? Для сетевой версии требуется разделение модели, представления и логики в коде, это не связано с тем, в каком месте находятся конкретные символы. Конечно, я пока не говорю о создании "альтернативных" клиентов. >Ну и с помощью разделения на части можно заинтересовать людей с других платформ >(PDA, интернет-таблетки и т.п.) Оно и так портируемо на Нокиевские платформы. Не думаю, что народ сейчас же накинется писать GUI под Андроид 2Alexander: >Мне можно уже начинать merge с вашим trunk (в смысле, скачать trunk и >раскидать эти исходники)? Можно. Заодно посмотришь, как я их раскидал :) -- Regards, Konstantin |
|
From: dodikk.reg <dod...@gm...> - 2010-09-14 19:09:51
|
Hello, Antony. Hello, Konstantin. > Мне кажется, это как раз одна из первоочередных задач. > Во-первых, там много бардака. Во-вторых, отделение зерен от плевел - вообще хорошее дело. > И да, это должно облегчить разработку сетевой версии. > Ну и с помощью разделения на части можно заинтересовать людей с других платформ > (PDA, интернет-таблетки и т.п.) и, таким образом, увеличить базу юзеров-тестеров. > Да. Об этом и я вёл речь. Только не очень умело. Итак, вопрос к Константину. Не совсем понял фразу "про CMake я позабочусь". Мне можно уже начинать merge с вашим trunk (в смысле, скачать trunk и раскидать эти исходники)? Или этим займется Константин на основании присланного мной (возможно, немного поломанного для чистого консольного qmake) tarball? -------------------------------------- Best Regards, Alexander Dodatko. |
|
From: Antony D. <to...@da...> - 2010-09-14 18:53:44
|
On 09/14/2010 09:21 PM, Konstantin Tokarev wrote: > 14.09.10, 20:55, "dodikk.reg" <dod...@gm...>: > >> Hello, Konstantin. Покрутил немного Ваш проектик. Попытался распилить его на GUI и библиотеки, собственно, с логикой. Это облегчило бы портирование надругие платформы (которое свелось бы к только главного проекта целиком,не затрагивая логики). > > > 1. Давай на ты > > 2. С момента 0.1.3 проект претерпел достаточно серьезные изменения в > расположении/наименованиях файлов и символов, так что работать нужно > с текущей гитовой версией (если гит не работает, можно скачать .tar.gz > из Гиториуса) > > 3. Я не думаю, что разделение проекта на части актуально на данном > этапе Мне кажется, это как раз одна из первоочередных задач. Во-первых, там много бардака. Во-вторых, отделение зерен от плевел - вообще хорошее дело. И да, это должно облегчить разработку сетевой версии. Ну и с помощью разделения на части можно заинтересовать людей с других платформ (PDA, интернет-таблетки и т.п.) и, таким образом, увеличить базу юзеров-тестеров. -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP |
|
From: Antony D. <to...@da...> - 2010-09-14 18:49:55
|
On 09/14/2010 08:00 PM, Konstantin Tokarev wrote: > > >> Кроме того, у меня лично есть некая манера "выбирать" снос кликая на картах и смотря на то, что получается. > > У меня тоже. Я даже подумываю о "поднятии" выбранных карт перед окончательным сносом Ну да, как на Гамблере. > В таком случае кнопка подтверждения сброса должна появляться прямо на поле Да, что-то типа "Снести/Вернуть". > Правда, все эти выкрутасы с картами будут возможны только после доработки движка. Там, насколько я заметил, много мест, где неплохо бы порядок навести. -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP |
|
From: Konstantin T. <an...@ya...> - 2010-09-14 18:25:59
|
<BLOCKQUOTE style="border-left:1px solid #CCCCCC;margin:0pt 0pt 0pt 0.8ex;padding-left:1em;" mce_style="border-left:1px solid #CCCCCC;margin:0pt 0pt 0pt 0.8ex;padding-left:1em;" ><br />
<PRE wrap="" >А может, дождёмся показаний профайлера? Код должен быть понятен. И только потом быстр. Чёрт, да ты же и без меня это прекрасно знаешь !!!
Тем более что создание этих интерфейсов будет выполнено в самом начале игры (там где у тебя нынче выбор между alphabeta и другим ботом). Сами вызовы будут те же. Просто будет разделена ответственнность класса Player. Не вижу никаких причин для тормозов (кроме, возможно, своих кривых рук).
Опять же удобства для добавления сети и новых типов ботов.
</PRE></BLOCKQUOTE><br />Или моих :)<br />Мое отношение к этому коду такое: <br />а) оно не очень понятно<br />б) оно работает (значит не трожь)<br />в) оно не мешает развитию<br />г) оно содержит компоненты, которые должны быть в классе делегата игрока, но не в самом игроке<br /><br /><META http-equiv="content-type" content="text/html; charset=utf-8" style="" id="" ></META><BLOCKQUOTE mce_style="border-left:1px solid #CCCCCC;margin:0pt 0pt 0pt 0.8ex;padding-left:1em;" style="" id="" ><PRE wrap="" style="" >=======================================================
</PRE><BLOCKQUOTE type="cite" style="" ><PRE wrap="" style="" >Card<SPAN mce_style="color: #c0c0c0;" style="" > </SPAN><SPAN mce_style="color: #000000;" style="" >*</SPAN>CardList<SPAN mce_style="color: #000000;" style="" >::</SPAN>exists<SPAN mce_style="color: #c0c0c0;" style="" > </SPAN><SPAN mce_style="color: #000000;" style="" >(</SPAN><SPAN mce_style="color: #808000;" style="" >int</SPAN><SPAN mce_style="color: #c0c0c0;" style="" > </SPAN>aFace<SPAN mce_style="color: #000000;" style="" >,</SPAN><SPAN mce_style="color: #c0c0c0;" style="" > </SPAN><SPAN mce_style="color: #808000;" style="" >int</SPAN><SPAN mce_style="color: #c0c0c0;" style="" > </SPAN>aSuit<SPAN mce_style="color: #000000;" style="" >)</SPAN><SPAN mce_style="color: #c0c0c0;" style="" > </SPAN><SPAN mce_style="color: #808000;" style="" >const</SPAN><SPAN mce_style="color: #c0c0c0;" style="" > </SPAN><SPAN mce_style="color: #000000;" style="" >{</SPAN>
<SPAN mce_style="color: #c0c0c0;" style="" > </SPAN>Card<SPAN mce_style="color: #c0c0c0;" style="" > </SPAN><SPAN mce_style="color: #000000;" style="" >*</SPAN>c<SPAN mce_style="color: #c0c0c0;" style="" > </SPAN><SPAN mce_style="color: #000000;" style="" >=</SPAN><SPAN mce_style="color: #c0c0c0;" style="" > </SPAN>newCard<SPAN mce_style="color: #000000;" style="" >(</SPAN>aFace<SPAN mce_style="color: #000000;" style="" >,</SPAN><SPAN mce_style="color: #c0c0c0;" style="" > </SPAN>aSuit<SPAN mce_style="color: #000000;" style="" >);</SPAN>
<SPAN mce_style="color: #c0c0c0;" style="" > </SPAN>Card<SPAN mce_style="color: #000000;" style="" >*</SPAN><SPAN mce_style="color: #c0c0c0;" style="" > </SPAN>ret<SPAN mce_style="color: #c0c0c0;" style="" > </SPAN><SPAN mce_style="color: #000000;" style="" >=</SPAN><SPAN mce_style="color: #c0c0c0;" style="" > </SPAN>exists<SPAN mce_style="color: #000000;" style="" >(</SPAN>c<SPAN mce_style="color: #000000;" style="" >);</SPAN>
<SPAN mce_style="color: #c0c0c0;" style="" > </SPAN><SPAN mce_style="color: #008000;" style="" >//</SPAN><SPAN mce_style="color: #c0c0c0;" style="" > </SPAN><SPAN mce_style="color: #008000;" style="" >delete</SPAN><SPAN mce_style="color: #c0c0c0;" style="" > </SPAN><SPAN mce_style="color: #008000;" style="" >c;</SPAN><SPAN mce_style="color: #c0c0c0;" style="" > </SPAN><SPAN mce_style="color: #008000;" style="" >//</SPAN><SPAN mce_style="color: #c0c0c0;" style="" > </SPAN><SPAN mce_style="color: #008000;" style="" >TODO</SPAN><SPAN mce_style="color: #c0c0c0;" style="" > </SPAN><SPAN mce_style="color: #008000;" style="" >:</SPAN><SPAN mce_style="color: #c0c0c0;" style="" > </SPAN><SPAN mce_style="color: #008000;" style="" >memory</SPAN><SPAN mce_style="color: #c0c0c0;" style="" > </SPAN><SPAN mce_style="color: #008000;" style="" >leak.</SPAN>
<SPAN mce_style="color: #c0c0c0;" style="" > </SPAN><SPAN mce_style="color: #808000;" style="" >return</SPAN><SPAN mce_style="color: #c0c0c0;" style="" > </SPAN>ret<SPAN mce_style="color: #000000;" style="" >;</SPAN>
<SPAN mce_style="color: #000000;" style="" >}</SPAN></PRE></BLOCKQUOTE><PRE wrap="" style="" >Напоминает memory leak. Поглядел потом внутрь exists и понял что ошибся. Однако не стоит ли перейти на QSharedPointer<SPAN mce_style="color: #000000;" style="" > или хранить структуры просто как ValueType (без указателя)? Или снова боязнь замедления всего сущего?
</SPAN>=======================================================
Кроме того, вместо CardUtils, по-моему, имеет смысл сразу при сдаче делить карты на 4 масти и работать уже с этими мастями. А не делать по линейному массиву карт постоянные выборки типа minInSuit(1..4).
Вот это как раз и будет замедлять программу, а не ООП.
=======================================================
P.S. Ещё раз прошу извинений за возможные обиды.
P.P.S. Так где можно на roadmap проекта глянуть?
</PRE></BLOCKQUOTE><br />На сайте, <A href="http://openpref.sourceforge.net/ru/development/" style="" id="" >openpref.sourceforge.net/ru/development/</A><br /><META http-equiv="content-type" content="text/html; charset=utf-8" style="" id="" ></META>-- <br />Regards,<br />Konstantin<br />
|
|
From: Konstantin T. <an...@ya...> - 2010-09-14 18:21:46
|
>
>
> Заранее извините за возможную резкость дальнейших ответов. Я понимаю что я для проекта человек чужой и не должен лезть со своим уставом.
> Однако проект мне весьма понравился. И я не хочу дабы его постигла печальная участь.
>
>
> > > Также это упростит написание Unit tests, коим я собираюсь заняться.
> > Это дело я одобряю, самому влом пока :) Думаю, следует сосредоточится на интерфейсах DeskView, PrefModel и Player
> И как вы себе видите написание оных тестов без разделения на библиотеки? (не вполне привык ещё на "ты". скоро исправлю)
> Включением соответствующих *.h; *.cpp в другой прожект? Да ведь это костыль.
>
> Скорее всего именно поэтому тестов у тебя и нет. Ведь их трудно добавлять.
Верно. Просто не хотелось бы перед выпуском 0.1.4 заморачиваться с разбиением, но если хочешь, можешь помочь.
По-хорошему, бибилотек должно быть больше: 1)модель 2)представление 3)AI в плагинах, каждый - отдельная либа
>
> > 3. Я не думаю, что разделение проекта на части актуально на данном этапе
> Лучше дождаться когда он станет большим, страшным и непонятным? Если и разделять, то как можно раньше. Согласен, структура каталогов - вещь хорошая. Но ведь библиотеки куда лучше. Я даже с CMake готов пообщаться (хотя лучше бы меня избавили от сей участи).
Думаю, он в обозримом будущем станет только проще и понятнее - я работаю над этим
>
> P.S. ну да. новые фичи (баги? ) писать куда веселее.
> =======================================================
>
>
>
>
>
>
> > > Настройки проекта заточил под QT Creator (ибо с CMake пока не владах).
> > В данный момент основная система сборки OpenPref - qmake, CMake поддерживается для удобства мейнтейнеров пакетов в дистрибутивах Linux (ибо более распространен)
> Насколько я помню, QT Creator с помощью qmake и собирает.
Ага, им самым.
> Я на досуге проверю свои изменения просто из консоли (без IDE). Возможно, пару ключей в *.pro не учёл.
Параметры для qmake есть на сайте, хотя для Windows нет ничего ценного
> Вот с CMake у меня дела обстоят хуже (да, я об этом уже писал).
О cmake я позабочусь :)
> >
Card *CardList::exists (int aFace, int aSuit) const {
Card *c = newCard(aFace, aSuit);
Card* ret = exists(c);
// delete c;
// TODO : memory leak.
return ret;
}
> Напоминает memory leak. Поглядел потом внутрь exists и понял что ошибся. Однако не стоит ли перейти на QSharedPointer или хранить структуры просто как ValueType (без указателя)? Или снова боязнь замедления всего сущего?
Разгадка проще: не копал я еще этот код. Значительная часть кода - дремучее legacy из 2000 и 2004 годов
--
Regards,
Konstantin
|
|
From: dodikk.reg <dod...@gm...> - 2010-09-14 18:05:49
|
14.09.10, 20:55, "dodikk.reg" <dod...@gm...>: > > Hello, Konstantin. Покрутил немного Ваш проектик. Попытался распилить его на GUI и библиотеки, собственно, с логикой. Это облегчило бы портирование надругие платформы (которое свелось бы к только главного проекта целиком,не затрагивая логики). 1. Давай на ты 2. С момента 0.1.3 проект претерпел достаточно серьезные изменения в расположении/наименованиях файлов и символов, так что работать нужно с текущей гитовой версией (если гит не работает, можно скачать .tar.gz из Гиториуса) 3. Я не думаю, что разделение проекта на части актуально на данном этапе > > Также это упростит написание Unit tests, коим я собираюсь заняться. Это дело я одобряю, самому влом пока :) Думаю, следует сосредоточится на интерфейсах DeskView, PrefModel и Player > > Настройки проекта заточил под QT Creator (ибо с CMake пока не владах). В данный момент основная система сборки OpenPref - qmake, CMake поддерживается для удобства мейнтейнеров пакетов в дистрибутивах Linux (ибо более распространен) > > Подружить GIT со своей виндой у меня не совсем получилось (rtfm практиковал :) ) . А вот это: http://help.github.com/win-git-installation/ ? > > Посему высылаю исходник. Надеюсь, это Вас не сильнозатруднит. Дифф сделать не получится, так как файлы "переехали". Опиши в кратце суть изменений > > Не получилось вынести классы из logic и desc ввиду их взаимной завязанности друг на друге и на GUI. Однако этим займусь попозже когда(если) руки дойдут. Я об этом знаю. Можно было написать и спросить, над чем ведется работа и т.п. > > Также было бы круто распилить функции MiserCatch1, MiserCatch2 итп.на маленькие аккуратные стратегии и не накапливать их в классе Player. Влюбом случае, наличие функций, ответственных за мизер, обычную игру ираспасы в одном классе считаю не совсем правильным. Дело в том, что этот вариант AI малоперспективен (в лучшем случае, из него получится хороший "рентген"), поэтому вкладывать в него много сил не хочется. Я его допиливаю исключительно ради дальнейшего использования в тренировке нейронных сетей. "Альфабета" более перспективен, но играет не "человекоподобно" Мое мнение - пусть будет как есть. Есть универсальный API для всех видов игроков, при разработке новых ботов можно сделать что-то более высокоорганизованное, модель игры все равно не видит внутреннего устройства игрока Переусердствовать с ООП и особенно сигнал-слотовыми соединениями внутри игроков мне кажется не стоит - скорость работы будет уменьшаться -- Regards, Konstantin ====================================================================================================================== ====================================================================================================================== ====================================================================================================================== Hello, Konstantin. Заранее извините за возможную резкость дальнейших ответов. Я понимаю что я для проекта человек чужой и не должен лезть со своим уставом. Однако проект мне весьма понравился. И я не хочу дабы его постигла печальная участь. >> Также это упростит написание Unit tests, коим я собираюсь заняться. > Это дело я одобряю, самому влом пока :) > Думаю, следует сосредоточится на интерфейсах DeskView, PrefModel и Player И как вы себе видите написание оных тестов без разделения на библиотеки? (не вполне привык ещё на "ты". скоро исправлю) Включением соответствующих *.h; *.cpp в другой прожект? Да ведь это костыль. Скорее всего именно поэтому тестов у тебя и нет. Ведь их трудно добавлять. > 3. Я не думаю, что разделение проекта на части актуально на данном > этапе Лучше дождаться когда он станет большим, страшным и непонятным? Если и разделять, то как можно раньше. Согласен, структура каталогов - вещь хорошая. Но ведь библиотеки куда лучше. Я даже с CMake готов пообщаться (хотя лучше бы меня избавили от сей участи). P.S. ну да. новые фичи (баги? ) писать куда веселее. ======================================================= >> Настройки проекта заточил под QT Creator (ибо с CMake пока не владах). > В данный момент основная система сборки OpenPref - qmake, CMake поддерживается > для удобства мейнтейнеров пакетов в дистрибутивах Linux (ибо более распространен) Насколько я помню, QT Creator с помощью qmake и собирает. Я на досуге проверю свои изменения просто из консоли (без IDE). Возможно, пару ключей в *.pro не учёл. Вот с CMake у меня дела обстоят хуже (да, я об этом уже писал). ======================================================= >> Подружить GIT со своей виндой у меня не совсем получилось (rtfm практиковал :) ) . > А вот это: http://help.github.com/win-git-installation/ Это и ставил. Что самое смешное, по этому же мануалу. Не получается ни с gitorious, ни с github работать. Проблемы с SSH (подробности опущу). Короче, разберусь позже. Думаю, данная проблема не стоит обсуждения здесь. ======================================================= > Дифф сделать не получится, так как файлы "переехали". Опиши в кратце суть изменений В файлах ничего не трогал. Просто сделал переезд и соответствующие изменения в *.pro файлах. Я пока только начал разбираться с проектом. ======================================================= >> Не получилось вынести классы из logic и desc ввиду их взаимной завязанности друг на друге и на GUI. Однако этим займусь попозже когда(если) руки дойдут. > Я об этом знаю. Можно было написать и спросить, над чем ведется работа и т.п. ======================================================= > Мое мнение - пусть будет как есть. Есть универсальный API для всех видов игроков, при разработке новых ботов > можно сделать что-то более высокоорганизованное, модель игры все равно не видит внутреннего устройства игрока > Переусердствовать с ООП и особенно сигнал-слотовыми соединениями внутри игроков мне кажется не стоит - скорость > работы будет уменьшаться А может, дождёмся показаний профайлера? Код должен быть понятен. И только потом быстр. Чёрт, да ты же и без меня это прекрасно знаешь !!! Тем более что создание этих интерфейсов будет выполнено в самом начале игры (там где у тебя нынче выбор между alphabeta и другим ботом). Сами вызовы будут те же. Просто будет разделена ответственнность класса Player. Не вижу никаких причин для тормозов (кроме, возможно, своих кривых рук). Опять же удобства для добавления сети и новых типов ботов. ======================================================= > Card *CardList::exists (int aFace, int aSuit) const { > > Card *c = newCard(aFace, aSuit); > Card* ret = exists(c); > // delete c; // TODO : memory leak. > return ret; > } Напоминает memory leak. Поглядел потом внутрь exists и понял что ошибся. Однако не стоит ли перейти на QSharedPointer или хранить структуры просто как ValueType (без указателя)? Или снова боязнь замедления всего сущего? ======================================================= Кроме того, вместо CardUtils, по-моему, имеет смысл сразу при сдаче делить карты на 4 масти и работать уже с этими мастями. А не делать по линейному массиву карт постоянные выборки типа minInSuit(1..4). Вот это как раз и будет замедлять программу, а не ООП. ======================================================= P.S. Ещё раз прошу извинений за возможные обиды. P.P.S. Так где можно на roadmap проекта глянуть? -------------------------------------- Best regards, Alexander Dodatko. |
|
From: Konstantin T. <an...@ya...> - 2010-09-14 17:25:48
|
Привет всем, Напоминаю, что документация API транка OpenPref выложена на сайте (http://openpref.sourceforge.net) Однако, до выхода версии 0.2.0 стабильность API не гарантируется. Следите за изменениями Спасибо за внимание! -- Regards, Konstantin |
|
From: Konstantin T. <an...@ya...> - 2010-09-14 17:21:50
|
14.09.10, 20:55, "dodikk.reg" <dod...@gm...>: > Hello, Konstantin. Покрутил немного Ваш проектик. Попытался распилить его на GUI и библиотеки, собственно, с логикой. Это облегчило бы портирование надругие платформы (которое свелось бы к только главного проекта целиком,не затрагивая логики). 1. Давай на ты 2. С момента 0.1.3 проект претерпел достаточно серьезные изменения в расположении/наименованиях файлов и символов, так что работать нужно с текущей гитовой версией (если гит не работает, можно скачать .tar.gz из Гиториуса) 3. Я не думаю, что разделение проекта на части актуально на данном этапе > Также это упростит написание Unit tests, коим я собираюсь заняться. Это дело я одобряю, самому влом пока :) Думаю, следует сосредоточится на интерфейсах DeskView, PrefModel и Player > Настройки проекта заточил под QT Creator (ибо с CMake пока не владах). В данный момент основная система сборки OpenPref - qmake, CMake поддерживается для удобства мейнтейнеров пакетов в дистрибутивах Linux (ибо более распространен) > Подружить GIT со своей виндой у меня не совсем получилось (rtfm практиковал :) ) . А вот это: http://help.github.com/win-git-installation/ ? > Посему высылаю исходник. Надеюсь, это Вас не сильнозатруднит. Дифф сделать не получится, так как файлы "переехали". Опиши в кратце суть изменений > Не получилось вынести классы из logic и desc ввиду их взаимной завязанности друг на друге и на GUI. Однако этим займусь попозже когда(если) руки дойдут. Я об этом знаю. Можно было написать и спросить, над чем ведется работа и т.п. > Также было бы круто распилить функции MiserCatch1, MiserCatch2 итп.на маленькие аккуратные стратегии и не накапливать их в классе Player. Влюбом случае, наличие функций, ответственных за мизер, обычную игру ираспасы в одном классе считаю не совсем правильным. Дело в том, что этот вариант AI малоперспективен (в лучшем случае, из него получится хороший "рентген"), поэтому вкладывать в него много сил не хочется. Я его допиливаю исключительно ради дальнейшего использования в тренировке нейронных сетей. "Альфабета" более перспективен, но играет не "человекоподобно" Мое мнение - пусть будет как есть. Есть универсальный API для всех видов игроков, при разработке новых ботов можно сделать что-то более высокоорганизованное, модель игры все равно не видит внутреннего устройства игрока Переусердствовать с ООП и особенно сигнал-слотовыми соединениями внутри игроков мне кажется не стоит - скорость работы будет уменьшаться -- Regards, Konstantin |
|
From: Konstantin T. <an...@ya...> - 2010-09-14 16:00:21
|
> Кроме того, у меня лично есть некая манера "выбирать" снос кликая на картах и смотря на то, что получается. У меня тоже. Я даже подумываю о "поднятии" выбранных карт перед окончательным сносом или их неснимающемся выделении желтым. Или даже буквально переносить выбранные карты в сторону. В таком случае кнопка подтверждения сброса должна появляться прямо на поле Правда, все эти выкрутасы с картами будут возможны только после доработки движка. -- Regards, Konstantin |
|
From: Antony D. <to...@da...> - 2010-09-14 15:31:31
|
On 09/14/2010 07:25 PM, Konstantin Tokarev wrote: >> Я поэтому, собсно, и решил спросить сначала. Проблемы не гигантские и в "свободное от отдыха время" (с) решаемые. >>Так что вопрос только в том надо ли оно кому-нибудь? Просто мне лично этого функционала явно не хватало после Гамблера. > Патч, на который ты дал ссылку, я внедрил. Ок. > Насчет остального - вещи вполне нужные. Гут. > Работать будет проще, если ты создашь форк на Гиториусе (ничего, что я на ты?). Нет проблем. > Единственное, возможность возврата карт уже реализована, я просто кнопку убрал, > так как думал, что это не нужно и лучше думать сразу (на ее месте сейчас кнопка "без трех") А, это хорошо. Я считаю, что кнопка нужна, т.к. это не реальная жизнь и можно просто не туда кликнуть (что я периодически и делаю). Кроме того, у меня лично есть некая манера "выбирать" снос кликая на картах и смотря на то, что получается. -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP |
