uh... bitmap
Kaigorodov Anthony
народ. подскажите. как загрузить битмап из файла в делфи?
без помощи VCL и тд. голым ВинАпи.
и нужны такие свойства как прозрачность и... скорость вывода(пока использую два
HDC).
пс: Сейчас пробую вариант из .res файла. тк есть такая функция=)
Some still alive Kaigorodov Anthony(Noof).
MY MUSiC = http://ctgmusic.com/noof | MY ASCii = http://impure.tk (from #51)
Ivan Kuvshinov
KN> без помощи VCL и тд. голым ВинАпи.
var
foi: File;
begin
Assign(foi,'MyBitMap');
Reset(foi,1);
BlockRead(foi,suda,FileSize(foi));
Close(foi);
end.
Только при чём здесь ВинАпи, это же всё встроенное, а что оно там использует
дело десятое. И вообще, переходи на ТМТ Pascal и не парься со всем "голым без
помощи VCL" - это оно и будет, тебе ведь скорость нужна?
KN> и нужны такие свойства как прозрачность и... скорость вывода(пока
KN> использую два HDC).
KN> пс: Сейчас пробую вариант из .res файла. тк есть такая функция=)
И вообще - хватит нас тут пугать Дельфёвой терминологией - это в
Su.Delphi.Chainik.
Что за игру-то пишешь?
КИА
Kaigorodov Anthony
23 Jul 05 10:10, you wrote to me:
KN>> народ. подскажите. как загрузить битмап из файла в делфи?
KN>> без помощи VCL и тд. голым ВинАпи.
IK> <... здесь идет кусок кода...>
=) Мне bitmap нужен из *.BMP файла. а ето мы знаем=) но все_равно СПАСИБО!
IK> Только при чём здесь ВинАпи, это же всё встроенное, а что оно там
IK> использует дело десятое. И вообще, переходи на ТМТ Pascal и не парься
IK> со всем "голым без помощи VCL" - это оно и будет, тебе ведь скорость
IK> нужна?
А на тмт я тоже пишу... =) но там проблема с putsprite. я даю ему массив с
пикселями, так он его флипует по Иксу и игрику=(. А при 16 и 24 b вообще ужас
какой.
IK> Что за игру-то пишешь?
ну ето что то типа движка для игр типа finalfantasy 1,2,3,4,5 uncharted waters
(new horizons) и тд... Вобщем для рпгшек и рядом. может что то типа стратегии в
стиле KOEI.
Ivan Kuvshinov
IK>> не парься со всем "голым без помощи VCL" - это оно и будет, тебе
IK>> ведь скорость нужна?
KN> А на тмт я тоже пишу... =) но там проблема с putsprite. я даю ему
KN> массив с пикселями, так он его флипует по Иксу и игрику=(. А при 16 и
KN> 24 b вообще ужас какой.
Подпишись на эху Ru.TMT, могу и тебе выслать модуль, который только
инициализирует видеорежим и даёт адрес LFB. Всё остальное пишеться на ура, да
ещё и гораздо быстрей будет работать. Причём работать с экраном как с массивом
гораздо удобней и шире возможности. Hу и например, стандартный доступ к памяти
для массива 1024*768 (mas^[y,x]:=color), а оптимизированный через табличку в 28
раз быстрей. Делай выводы.
КИА
Alex Mizrahi
(you :wrote :to '(Kaigorodov Anthony(Noof)) :on '(Mon, 25 Jul 2005 09:28:08
+0400))
(
IK> Подпишись на эху Ru.TMT, могу и тебе выслать модуль, который только
IK> инициализирует видеорежим и даёт адрес LFB. Всё остальное пишеться на
IK> ура, да ещё и гораздо быстрей будет работать. Причём работать с экраном
IK> как с массивом гораздо удобней и шире возможности. Hу и например,
IK> стандартный доступ к памяти для массива 1024*768 (mas^[y,x]:=color), а
IK> оптимизированный через табличку в 28 раз быстрей. Делай выводы.
какой смысл в 2005 году какие-то таблички оптимизировать, если есть OpenGL и
Direct3D/Draw и видеокарты с прямо таки невероятными скоростями?
вы что, маньяки, ребята? нахер этот паскаль, кому это надо?
)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"People who lust for the Feel of keys on their fingertips (c) Inity")
Ivan Kharin
> экраном как с массивом гораздо удобней и шире возможности. Hу и
> например, стандартный доступ к памяти для массива 1024*768
> (mas^[y,x]:=color), а оптимизированный через табличку в 28 раз
> быстрей. Делай выводы.
можно поинтересоваться -- в каком году и на какой машине это замерялось?
есть у меня отчетливое ощущение, что на P4 выборка слова из памяти
вполне может оказатсья медленне целочисленного умножения...
--
Ivan Kharin
Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru
Daniil Smolyakov
> ну ето что то типа движка для игр типа finalfantasy 1,2,3,4,5 uncharted
waters
> (new horizons) и тд... Вобщем для рпгшек и рядом. может что то типа стратегии
в
> стиле KOEI.
А поподробнее можно? Идеи, картинки, дока, сайт есть? ;-)
.MoonStone.
Kaigorodov Anthony
23 Jul 05 10:10, you wrote to me:
KN>> народ. подскажите. как загрузить битмап из файла в делфи?
KN>> без помощи VCL и тд. голым ВинАпи.
Все. Файл читает. создает массив.=)
Kaigorodov Anthony
25 Jul 05 16:57, you wrote to Kaigorodov Anthony:
DS> From: "Daniil Smolyakov" <moon...@jesby.tstu.ru>
>> IK> Что за игру-то пишешь?
>> ну ето что то типа движка для игр типа finalfantasy 1,2,3,4,5
>> uncharted waters (new horizons) и тд... Вобщем для рпгшек и рядом.
>> может что то типа стратегии в стиле KOEI.
DS> А поподробнее можно? Идеи, картинки, дока, сайт есть? ;-)
Сайта нет. все в голове. причем все хорошо лежит в голове=)
А что? =)
c ya!
Kaigorodov Anthony
25 Jul 05 12:19, you wrote to Ivan Kuvshinov:
IK>> Подпишись на эху Ru.TMT, могу и тебе выслать модуль, который
IK>> только инициализирует видеорежим и даёт адрес LFB. Всё остальное
IK>> пишеться на ура, да ещё и гораздо быстрей будет работать. Причём
IK>> работать с экраном как с массивом гораздо удобней и шире
IK>> возможности. Hу и например, стандартный доступ к памяти для
IK>> массива 1024*768 (mas^[y,x]:=color), а оптимизированный через
IK>> табличку в 28 раз быстрей. Делай выводы.
AM> какой смысл в 2005 году какие-то таблички оптимизировать, если есть
AM> OpenGL и Direct3D/Draw и видеокарты с прямо таки невероятными
AM> скоростями? вы что, маньяки, ребята? нахер этот паскаль, кому это
AM> надо?
1) нужно для того что бы _знать_.
2) Вы(народ) смотрели демки? Посмотрите что люди делают под дос без ускорения
с помощью карт.
ето ужасно. Сейчас ни кто не смотрит на качество программ.
как то скачал игру с и-нета. так там простой вывод спрайтов. без еффектов.
и она так тормозила. а такое же написать под дос. хорошими руками. все бедт
летать. я о чем... Все ето дело конечно хорошо(openGL,directdraw). Я ето тоже
изучаю.
Однако изучать самое начало. корни. фундамент. ето HУЖHО.
:)
Kaigorodov Anthony
25 Jul 05 10:28, you wrote to me:
IK>>> там использует дело десятое. И вообще, переходи на ТМТ Pascal и
IK>>> не парься со всем "голым без помощи VCL" - это оно и будет, тебе
IK>>> ведь скорость нужна?
KN>> А на тмт я тоже пишу... =) но там проблема с putsprite. я даю ему
KN>> массив с пикселями, так он его флипует по Иксу и игрику=(. А при
KN>> 16 и 24 b вообще ужас какой.
IK> Подпишись на эху Ru.TMT, могу и тебе выслать модуль, который только
IK> инициализирует видеорежим и даёт адрес LFB.
Я уже подписан. а модуль кинь=) посмотрим.
IK> Всё остальное пишеться на
IK> ура, да ещё и гораздо быстрей будет работать.
IK> Причём работать с
IK> экраном как с массивом гораздо удобней и шире возможности.
Hу ето ж совсем азы=)
IK> Hу и например, стандартный доступ к памяти для массива 1024*768
IK> (mas^[y,x]:=color),
IK> а оптимизированный через табличку в 28 раз
IK> быстрей.
Че за табличка? не знаю такого понятия... обьясни пожалуйста
c ya!
Alex Mizrahi
(you :wrote :to '(Alex Mizrahi) :on '(Tue, 26 Jul 2005 02:33:49 +0400))
(
AM>> какой смысл в 2005 году какие-то таблички оптимизировать, если есть
AM>> OpenGL и Direct3D/Draw и видеокарты с прямо таки невероятными
AM>> скоростями? вы что, маньяки, ребята? нахер этот паскаль, кому это
AM>> надо?
KAN> 1) нужно для того что бы _знать_.
что знать? #$%^&#*$^! паскаль, который никто не использует кроме каких-то
маньяков и фанатиков, свято верящих, что Цэ им выучить так просто не удастся
и паскаль ничуть не хуже?
приёмы работы со всякой фигнёй под ДОС? а почему тогда не под spectrum?
хочь работать с видеобуффером напрямую -- пожалуйста, через ddraw или GDI.
это ещё 10 лет назад работало, никакие не новые технологии. но хотя-бы
более-менее адекватные
KAN> 2) Вы(народ) смотрели демки? Посмотрите что люди делают под дос без
KAN> ускорения с помощью карт.
да я видел и под speccy демки, и что?
KAN> ето ужасно. Сейчас ни кто не смотрит на качество программ.
KAN> как то скачал игру с и-нета. так там простой вывод спрайтов. без
KAN> еффектов.и она так тормозила.
очень может быть, значит идеоты писали, их много развелось сейчас..
KAN> а такое же написать под дос. хорошими руками. все бедт летать.
а можно и не под ДОС хорошими руками..
понимаешь, это люди делали десятки тысяч раз уже. любой профессиональный
программист возьмёт готовый код или даже готовую либу, и будет на базе неё
строить, а не с нуля проходить весь путь.. можно и код либы посмотреть, если
очень интересно, попробовать разные варианты.. afaik, есть либы чтобы делать
спрайтовые игрушки и под дос, и под венду, и под линукс.
в образовательных целях можно хорошо разобраться с этой либой и доработать
её. это будет по крайней мере хоть как-то полезно..
KAN> я о чем... Все ето дело конечно хорошо(openGL,directdraw). Я ето тоже
KAN> изучаю.
KAN> Однако изучать самое начало. корни. фундамент. ето HУЖHО.
нет, это не корни и не фундамент, а устаревшие технологии.. как спектрум,
который никак к текущим технологиям не относится.. можно разбираться сразу с
нормальными, они ни чуть не хуже, а потом, при надобности, выяснить как это
делали раньше, хотя я очень сомневаюсь, что это понадобится.. каждый индивид
в своём развитии не обязан повторять весь курс развития вычислительной
техники -- без знания IBM/360 как-то ведь обходятся? :) -- на каждом
конкретном этапе есть свой high-level и low-level подходы и вполне
достаточно разбираться только в современных.
при желании работать с очень ограниченными возможностями это можно и сейчас
делать -- для мобильных девайсов всяких делать демы/игры. а не гордо
используя технологии 15-летней давности..
в общем, прежде всего следует отказаться от паскакаля.. не хочешь писать на
Цэ -- пиши, например, на ML, вон, говорят, что raytracer на нём самый
быстрый получился :). по крайней мере сознание от этого расширится весьма,
если удастся понять.. :)
Val Krylov
2005-07-25 00:24:22, Kaigorodov Anthony(Noof) -> Ivan Kuvshinov:
IK>> Только пpи чём здесь ВинАпи, это же всё встpоенное, а что оно
IK>> там использyет дело десятое. И вообще, пеpеходи на ТМТ Pascal и
IK>> не паpься со всем "голым без помощи VCL" - это оно и бyдет, тебе
IK>> ведь скоpость нyжна?
KN> А на тмт я тоже пишy... =) но там пpоблема с putsprite. я даю емy
KN> массив с пикселями, так он его флипyет по Иксy и игpикy=(. А пpи 16 и
KN> 24 b вообще yжас какой.
IK>> Что за игpy-то пишешь?
KN> нy ето что то типа движка для игp типа finalfantasy 1,2,3,4,5
KN> uncharted waters (new horizons) и тд... Вобщем для pпгшек и pядом.
KN> может что то типа стpатегии в стиле KOEI.
Для pеализации pетpо-игpы вовсе не обязательно использовать неyдачные
технические pешения пpошлого века. :) Ты опpеделись в желаниях, что именно тебе
нyжно: сделать игpy или наyчиться пpогpаммиpовать на пpимеpе игpового движка?
Рекомендyю посмотpеть готовый инстpyментаpий для написания FF-style JRPG и
сходных по технической pеализации игp. Hаиболее pазвитые пpимеpы RPG Maker 2K и
RPG Maker 2003 (также сyществyет RPG Maker XP, но вживyю не наблюдал). Если
тебе нyжно создать игpy - попpобyй использовать один из этих инстpyментов, это
не идеал, но намного лyчше, чем можешь написать ты. Если же цель - движок, то
пpосто полезно ознакомиться.
Для движка - yчи C++ и базовые необходимые API. Поpаботаешь с Direct3D или
OpenGL, pазyчишься "дyмать чеpез putsprite"... Если это пока сложно, то можно
начать пpогpаммиpовать на Python (http://python.org/), освоить PyGame (биндинг
SDL, http://pygame.seul.org/) и PyOpenGL (биндинг OpenGL,
http://pyopengl.sourceforge.net/), после этого yже можно писать пpостенькие игp
(в том числе 3D). Кстати, не дyмай, что API для 3D гpафики тебе не пpигодятся
для плоской JRPG, даже в оpигинальных FF4-6 (SNES) вполне использовался SNES
Mode7, а это yже не банальный плоский блит.
Дальше - количество и качество. Как сделать пpостенькyю игpy, котоpая
пpоходится за пять минyт (или даже пpинципиально "не пpоходится"), но пpи этом
оставляет очень пpиятные впечатления y игpавшего, можешь посмотpеть на
"http://www.experimentalgameplay.com/", мне понpавились многие игpы оттyда, в
том числе Rainy Day.
Ivan Kuvshinov
KN>>> без помощи VCL и тд. голым ВинАпи.
Ага, я тоже удивился насколько отличаются скорости чтения побайтового файла и
блочного с размерностью в байт. :-)
КИА
Ivan Kuvshinov
AM> OpenGL и Direct3D/Draw и видеокарты с прямо таки невероятными
AM> скоростями?
руль от трактора? Или лучше турбину от самолёта, цена.. - так ведь ускорители
тоже не дёшевы, однако ж - покупают..
Причины должны быть для того что бы где-то схалтурить, а вот для того, что бы
сделать что-то хорошо, нужна не причина, а обычное человеческое понятие,
которое у многих стало сильно расплываться и в итоге хаваем глючные и
тормознутые продукты, платя за поддержку, которая состоит только в том, что бы
объяснить на какую кнопку тыркнуть и платим за следующие версии никому не
нужных фенечек, в которых меняют одни ошибки на другие, вместо того, что бы
бесплатно исправить то, что они сделали неправильно. Где стабильные Win9x, где
The Bat! и Opera.. - ждите следующую версию и копите денюжки, они вам
понадобятся!
AM> вы что, маньяки, ребята? нахер этот паскаль, кому это
AM> надо?
Ага, а потом старая добрая Элита, которая летала на 3.5МГц, на 300 с графикой
практически один в один даёт 4 кадра (зато HomeWorld идёт прекрасно имея
софтовый режим) в секунду из-за того, что на моём ноуте видюшка не 3Д, а ОпенЖЛ
прямо таки невероятной скорости..
Да и вообще, те же тормоза интерфейса в прогах типа Opera, просто достают
невероятно - ну нечему там тормозить, а ведь на тебе! А всё почему? Именно
потому, что не оптимизируют из-за подобных прикидок и в итоге тормозит даже то,
что не может тормозить.
А ведь вещи-то фундаментальные, то есть достаточно сделать один раз, что бы в
ОпенЖЛ был нормальный софтовый режим и всё! То же самое и со своими программами
- один раз делается модуль или библиотека и потом все твои программы это
используют, а двигаться дальше в сторону ускорителей - никто не мешает, зато
будет понимание, что да как, и не будет лажовщины там ,где ей быть не
положенно.
КИА
Ivan Kuvshinov
KN> Я уже подписан. а модуль кинь=) посмотрим.
Давай e-Mail. А вообще в теме про "Видеосглаз" он был в UUE'шке .
IK>> Причём работать с
IK>> экраном как с массивом гораздо удобней и шире возможности.
Ага, я тут много нового узнал, даже про линии Брезенхема - можно быстрей
рисовать, сразу кусками.
IK>> а оптимизированный через табличку в 28 раз
IK>> быстрей.
KN> Че за табличка? не знаю такого понятия... обьясни пожалуйста
Где-то так, для 16 битного режима: (смотри выделенные места)
const
rastr_x = 800;
rastr_y = 600;
var
test_screen: ^array[0..rastr_y-1, 0..rastr_x-1] of Word;
x, y, increa, tmp : Word;
> rastr_acces : array[0..rastr_y - 1] of DWord;
begin
{Это типа, что бы в графическом режиме текстовая инфа не пропадала.}
assign(output, 'log.log');
ReWrite(output);
New(test_screen);
VBESetGraphMode(276);
rastr_acces[0] := DWord(VBEGetPageAddr);
tmp := 2 * rastr_x;
{Заполняем табличку начальных адресов строк.}
> for increa := 0 to rastr_y - 2 do rastr_acces[increa + 1] :=
rastr_acces[increa] + tmp;
for y := 100 to 500 do
for x := 100 to 700 do
> Word(Pointer(rastr_acces[y] + x shl 2)^) := 65535;
{Эквивалентный обычный доступ.}
for y := 100 to 500 do
for x := 100 to 700 do
test_screen^[y,x]:=65535;
ReadKey;
VBECloseGraph;
Dispose(test_screen);
Close(output);
end.
КИА
Ivan Kuvshinov
>> например, стандартный доступ к памяти для массива 1024*768
>> быстрей. Делай выводы.
IK> можно поинтересоваться -- в каком году и на какой машине это
IK> замерялось? есть у меня отчетливое ощущение, что на P4 выборка слова
IK> из памяти вполне может оказатсья медленне целочисленного умножения...
Да вот только что! Правда, это всё про работу с памятью - не видео. Hо в
видео, как правило один раз уже потом кидают, а на странички не стоит
надеяться, так как их наличие не гарантируется.
Машина K6-III 450МГц, с 256Мб оперативки на 100 шине. Есть какие-то
возражения?
А вот и сами результаты (немного я правда загнул выше, но это не
принципиально), для рисования в память:
x:1280, y:1024, BPP16
441066
9617568
x:1280, y:1024, BPP8
365062
9501218 - в 26 раз разница! :(
Для рисования непосредственно в экран (активную видеопамять, которая, как
известно - оочень торозная; PCI ET6100, RAMDAC 135МГц, MDRAM 4Мб):
x:640, y:480, BPP16
237903
411418
x:800, y:600, BPP16
375873
678554
x:1024, y:768, BPP16
612646
1162878
x:1280, y:1024, BPP16
1017966
2361528
x:640, y:480, BPP8
331025
395561
x:800, y:600, BPP8
517044
656987
x:1024, y:768, BPP8
851068
1057548
x:1280, y:1024, BPP8
1415806
2147608
Результаты в миллионных долях секунды, весь растр заполнялся одним значением
цвета 11 раз.
КИА
Alex Mizrahi
(you :wrote :to '(Alex Mizrahi) :on '(Tue, 26 Jul 2005 17:20:40 +0400))
(
AM>> какой смысл в 2005 году какие-то таблички оптимизировать, если есть
AM>> OpenGL и Direct3D/Draw и видеокарты с прямо таки невероятными
AM>> скоростями?
IK> Какой смысл делать нормальную тачку, если можно поставить движок от
IK> камаза и руль от трактора? Или лучше турбину от самолёта, цена.. - так
IK> ведь ускорители тоже не дёшевы, однако ж - покупают..
DDraw -- это afaik правильный способ делать спрайтовую графику под win32.
если угодно, получи указатель на видеобуффер и фигашь туда.. не нужен
акселератор -- не используй..
хотя, если в обучающих целях, почему бы не попробовать новые технологии
(хотя, эти технологии уже лет 5 как не новые совсем), а мучать всякое
старьё?
очень вероятно, что на десктопах скоро штатный GUI будет работать через
видеоакселератор..
IK> Причины должны быть для того что бы где-то схалтурить, а вот для того,
IK> что бы сделать что-то хорошо, нужна не причина, а обычное человеческое
IK> понятие, которое у многих стало сильно расплываться и в итоге хаваем
IK> глючные и тормознутые продукты, платя за поддержку, которая состоит
IK> только в том, что бы объяснить на какую кнопку тыркнуть и платим за
IK> следующие версии никому не нужных фенечек, в которых меняют одни ошибки
IK> на другие, вместо того, что бы бесплатно исправить то, что они сделали
IK> неправильно. Где стабильные Win9x, где The Bat! и Opera.. - ждите
IK> следующую версию
и это всё opengl с d3d виноваты, по-твоему? 8]
глючные и тормознутые продукты действительно имеют место быть, и связаны с
недостаточно научным подходом, инерционностью мышления и традициями кривого
подхода, в частности, использование для программирования кривых
инструментов, типа ассемблера, паскаля, Цэ и Цэ плюс плюс (в настоящее время
развилось немало современных не менее кривых вещей). но паскаль выбивается
даже здесь особой кривизной, его использование связано по-моему с какими-то
специфическими традициями отечественного образования, и, вероятно,
бедностью..
IK> ждите
IK> следующую версию
IK> и копите денюжки, они вам понадобятся!
понимаешь-ли, в более-менее нормальных странах на более-менее современный
компутер можно заработать за пару дней, копить ничего надо..
и даже в не совсем нормальных если нормально работать, можно достаточно
быстро купить железо.. железо стоит не так уж дорого по сравнению со
стоимостью работы программиста (хотя, не программиста на TMT паскале,
пожалуй).
IK> А ведь вещи-то фундаментальные, то есть достаточно сделать один раз,
IK> что бы в ОпенЖЛ был нормальный софтовый режим и всё!
ты просто не совсем в курсе.. дело в том, что стандарт OpenGL накладывает
весьма жёсткие требования на отображаемую картинку(поскольку OpenGL -- это
промышленный стандарт, и делался не для игрушек, а для серьёзных вещей типа
CAD'ов и т.д.), поэтому быстрая растеризация невозможно. к примеру, такие
вещи как blending просто не могут в софте быстро работать. заметь, что
софтовая реализация homeworld не использует blending, и вообще, качество
картинки получается довольно скверным.
"софтовый режим" в win32 реализован Microsoft, реализован не так уж плохо,
но и не хорошо.. улучшать что-то там Microsoft смысла не имело -- они
продвигали свою технологию Direct3D, которая должна была заменить OpenGL, и
им не было выгодно, чтобы OpenGL хорошо работало (и вообще не было дела до
OpenGL). есть другие софтовые реализации -- от SGI и Mesa -- они типа,
быстрее, но ненамного.. доступны исходники MesaGL (она используется под
Linux'ом, в частности), так что если можешь что-то там улучшить --
пожалуйста).
кстати, вполне вероятно, что у OpenGL ES будет/есть нормальный софтовый
режим -- это OpenGL для embedded systems, т.е. всяких смартфонов и прочих
носимых девайсов с ограниченными ресурасами.
IK> То же самое и со своими программами - один раз делается модуль или
IK> библиотека и потом все твои программы это используют,
ты когда нибудь с большими, "промышленного качества" типа 8], проектами когд
а-нибудь работал? какой самый большой, по объёму кода?
очень наивные понития -- "один раз делается модуль или библиотека и потом
все твои программы это используют". если удаётся достигнуть code reusage --
то это очень круто. а обычно, библиотека не того формата, делает не то и не
так, а всё вместе оно глючит по необъяснимым причинам 8] хотя, если клепать
одно и то же постоянно, то можно достигнуть хорошего code reusage. но тогда
сразу встаёт вопрос -- а может вообще не надо ничего делать, а разные
вариации получать настраивая конфиги, или код какой-нибудь тулзой
генерячить?
IK> а двигаться дальше в сторону ускорителей - никто не мешает, зато будет
IK> понимание, что да как, и не будет лажовщины там ,где ей быть не
IK> положенно.
ты действительно считаешь, что понимание заключается в том, как работать с
LFB и подобных вещах?
это всего лишь технология. технологию можно использовать, почитав примеры и
справочник.
а вот что на самом деле нетривиально -- это как писать программы, алгоритмы,
архитектура сложных программ..
Pavel Kuprianov
26 Июл 05 03:33, Сущность именуемая Kaigorodov Anthony(Noof) писала сущности
Alex Mizrahi:
AM>> невероятными скоростями? вы что, маньяки, ребята? нахер этот
AM>> паскаль, кому это надо?
KN> 1) нужно для того что бы _знать_.
О. Меccиp иccледователь иcтоpии? :).
KN> 2) Вы(народ) смотрели демки? Посмотрите что люди делают под дос без
KN> ускорения с помощью карт. ето ужасно. Сейчас ни кто не смотрит на
А поcмотpи что они делают под виндоyз c ycкоpением c помощью каpт, так ты
вообще челюcть под cтолом потеpяешь ;).
KN> качество программ. как то скачал игру с и-нета. так там простой вывод
KN> спрайтов. без еффектов. и она так тормозила. а такое же написать под
KN> дос. хорошими руками. все бедт летать. я о чем... Все ето дело конечно
KN> хорошо(openGL,directdraw). Я ето тоже изучаю. Однако изучать самое
KN> начало. корни. фундамент. ето HУЖHО.
Поpазительно, c каким завидным поcтоянcтвом cюда пpиходят люди, и pаз в
полгода начинают пиcать игpы на аccемблеpе и паcкале под доc. Это даже еще
cмешнее, чем на gamedev.ru :).
Дай yгадаю - y тебя на клавиатypе бyква "э" cломалаcь, а новyю кyпить денег
нет? :)
See you Kaigorodov, sooner or later
And now press "CTRL+F15"
Alex Pakhotin
AM>>> какой смысл в 2005 году какие-то таблички оптимизировать, если есть
AM>>> OpenGL и Direct3D/Draw и видеокарты с прямо таки невероятными
AM>>> скоростями?
[...]
AM> хотя, если в обучающих целях, почему бы не попробовать новые технологии
AM> (хотя, эти технологии уже лет 5 как не новые совсем), а мучать всякое
AM> старьё?
Ты чего накинулся на человека?
Хочет изучать такое - пусть изучает. Хуже от этого не будет. Hаоборот - я
лично считаю, что знание подобных вещей даст лучшее понимание современных
технологий. Я рад, что в свое время разбирался с БК0010 и Спектрумом, позже -
с прямым выводом в видеопамять на PC, работал в DOS, и писал на ассемблере.
Это дает очень полезную базу - когда знаешь, как оно работает на низком
уровне, гораздо более уверенно себя чувствуешь, используя более
высокоуровневые технологии. К тому же и с выбором технологий и платформ не
ограничен - сможешь и под телефоны и под КПК писать - у них пока никаких DDraw
и D3D нет.
AM> кривого подхода, в частности, использование для программирования кривых
AM> инструментов, типа ассемблера, паскаля, Цэ и Цэ плюс плюс (в настоящее
AM> время развилось немало современных не менее кривых вещей). но паскаль
AM> выбивается даже здесь особой кривизной,
Что за мода постоянно наезжать на паскаль?
Это такой же язык программирования, как С/С++ - принципиально не хуже.
Hесколько проще, чем С++, но дающий достаточно функциональности для
эффективного создания тех же программ и использования тех же алгоритмов. У С++
одно серьезное преимущество - распространен он значительно шире,
соответственно и библиотеки все в основном под него.
Самое главное - хорошо знать инструмент, который используешь, остальное -
вторично.
IK>> ждите следующую версию и копите денюжки, они вам понадобятся!
AM> понимаешь-ли, в более-менее нормальных странах на более-менее современный
AM> компутер можно заработать за пару дней, копить ничего надо..
В более-менее нормальных странах приоритеты совсем другие - просто так взять и
выкинуть тысячу долларов на новый компьютер мало кто себе позволит (хоть
многие и могут).
AM> а вот что на самом деле нетривиально -- это как писать программы,
AM> алгоритмы, архитектура сложных программ..
Вот именно! Только какое отношение это имеет к конкретному языку
программирования и технологии?
Alex
Ivan Kharin
> А вот и сами результаты (немного я правда загнул выше, но это не
> принципиально), для рисования в память:
> x:1280, y:1024, BPP16
> 441066
> 9617568
>
> x:1280, y:1024, BPP8
> 365062
> 9501218 - в 26 раз разница! :(
>
неверный тест. абсолютно.
Сделай не запись в память константы, а перенос изображения из
аналогичного буфера -- и сразу удивишься результату.
А потом сделай доступ к точкам не последовательно, а в случайном
порядке.
И размер картинки не 500 на 500, а хотя бы 2-3 тысячи в каждом
измерении.
То, что ты посчитал -- это работа с внутренним кэшем процессора,
который никак не нарушается во время работы "алгоритма".
Учитывая, какой код генерирует обычно компилятор паскаля, ничего
удивительного в твоих результатах нет.
Alexey Skoufyin
AM> очень вероятно, что на десктопах скоро штатный GUI будет работать через
AM> видеоакселератор..
Он и так работает. Начиная, ЕМНИП, с линейки TNT почти все функции GDI
обрабатываются процессором карточки.
With best regards, Alexey "Tigra" Skoufyin.
Ivan Kharin
повторил на Visual C++, результаты:
C:\K13\Work\chk\Debug>chk.exe
TestAsArray() : 3484
TestAsLUT() : 1563
C:\K13\Work\chk\Release>chk.exe
TestAsArray() : 687
TestAsLUT() : 657
исходный текст:
#include "stdafx.h"
enum {
rastr_x = 800,
rastr_y = 600,
test_x1 = 100,
test_x2 = 700,
test_y1 = 100,
test_y2 = 500
};
struct TestScreen
{
WORD data[ rastr_y ][ rastr_x ];
};
TestScreen * test_screen;
WORD * scanLUT[ rastr_y ];
void InitLUT();
void TestAsArray();
void TestAsLUT();
int _tmain(int argc, _TCHAR* argv[])
{
test_screen = new TestScreen;
InitLUT();
enum { RUN_COUNT = 1000 };
{
DWORD started = GetTickCount();
for ( int i = 0; i < RUN_COUNT; ++i )
TestAsArray();
printf( _T("TestAsArray() : %d\n"), GetTickCount() - started );
}
{
DWORD started = GetTickCount();
for ( int i = 0; i < RUN_COUNT; ++i )
TestAsLUT();
printf( _T("TestAsLUT() : %d\n"), GetTickCount() - started );
}
delete test_screen;
return 0;
}
void InitLUT()
{
for ( int y = 0; y < rastr_y; ++y )
scanLUT[ y ] = &( test_screen->data[y][0] );
}
void TestAsArray()
{
for ( int y = test_y1; y <= test_y2; ++y )
for ( int x = test_x1; x <= test_x2; ++x )
test_screen->data[y][x] = 0xFFFF;
}
void TestAsLUT()
{
for ( int y = test_y1; y <= test_y2; ++y )
for ( int x = test_x1; x <= test_x2; ++x )
scanLUT[y][x] = 0xFFFF;
}
------------------------------------------------------------------
а вот как компилятор сделал TestAsArray:
PUBLIC ?TestAsArray@@YAXXZ ; TestAsArray
; Function compile flags: /Ogty
_TEXT SEGMENT
?TestAsArray@@YAXXZ PROC NEAR ; TestAsArray
; 63 : for ( int y = test_y1; y <= test_y2; ++y )
00030 ba c8 71 02 00 mov edx, 160200 ; 000271c8H
00035 56 push esi
00036 eb 08 8d a4 24
00 00 00 00 90 npad 10
$L63741:
; 64 : for ( int x = test_x1; x <= test_x2; ++x )
00040 8b c2 mov eax, edx
00042 b9 59 02 00 00 mov ecx, 601 ; 00000259H
00047 eb 07 8d a4 24
00 00 00 00 npad 9
$L63745:
; 65 : test_screen->data[y][x] = 0xFFFF;
00050 8b 35 00 00 00
00 mov esi, DWORD PTR ?test_screen@@3PAUTestScreen@@A ; test_screen
00056 66 c7 04 30 ff
ff mov WORD PTR [eax+esi], 65535 ; 0000ffffH
0005c 83 c0 02 add eax, 2
0005f 49 dec ecx
00060 75 ee jne SHORT $L63745
00062 81 c2 40 06 00
00 add edx, 1600 ; 00000640H
00068 81 fa c8 35 0c
00 cmp edx, 800200 ; 000c35c8H
0006e 7e d0 jle SHORT $L63741
00070 5e pop esi
; 66 : }
00071 c3 ret 0
?TestAsArray@@YAXXZ ENDP ; TestAsArray
Ivan Kuvshinov
KN>> смотрит на
PK> А поcмотpи что они делают под виндоyз c ycкоpением c помощью каpт, так
PK> ты вообще челюcть под cтолом потеpяешь ;).
После того как появилсь ускорители демки умерли. Их больше почти никто не
пишет, и не придумывают новый эффекты, максимум что делают это какой-нибудь
фильмец в 3Д, который отличается от другого также как близнецы братья.
Посмотри, хотя бы на объём переписки в Demo.Design.
КИА
Ivan Kuvshinov
Сделай верный и кинь результат, тогда и будем говорить, или ты хочешь что бы я
свои тесты подгонял под твои придуманные подъёбки? Вроде того, что, если
эксперимент подтвердил гипотезу надо его повторить с другими начальными
данными, пока наконец что-нибудь не сломается?
IK> Сделай не запись в память константы, а перенос изображения из
IK> аналогичного буфера -- и сразу удивишься результату.
Смысл в этом какой? Тестируется же модель доступа к структуре, а не пропускная
способность памяти. А тест вполне себе корректную картину показывает: для
табличного метода затраты растут линейно, а для обычного - квадратично,
поскольку для вычисления адреса используется умножение. Оптимизация здесь:
алгоритмическая и даже язык - роли не играет.
IK> А потом сделай доступ к точкам не последовательно, а в случайном
IK> порядке.
Вот это можно.
IK> И размер картинки не 500 на 500, а хотя бы 2-3 тысячи в каждом
IK> измерении.
Заполнялся весь экран, то есть для 1280*1024 столько и заполнялось.
IK> То, что ты посчитал -- это работа с внутренним кэшем процессора,
Hу можно попробовать и рандомно, хотя лучше, по моему просто через шаг,
например 3 байта или 7 (какая там разрядность памяти?).
IK> который никак не нарушается во время работы "алгоритма".
IK> Учитывая, какой код генерирует обычно компилятор паскаля, ничего
IK> удивительного в твоих результатах нет.
А я спорить не собираюсь, ни про кеши ни про что. У меня факт на лицо -
ускорение есть? - есть, и даже в эмуле на Маке картина аналогичная. Ты
предлагаешь это ускорение не использовать, потому что оно - эфемерно?
Hу да, давай тогда перерисовывать в GUI окошках всё по четыре раза, как в
WinRar'е - всё равно никто не увидит, ну я ещё понимаю - два, для дебилов, но
четыре... и дело не в скорости, а в АЛГОРИТМИЧЕСКОЙ оптимизации - ну не нужно
там 4 раза перерисовывать, что бы список вывести. Я так думаю, что все проги
испльзующие дельфи перерисовывают не меньше двух раз, например &RQ и The Bat!
Ах - это не Reuse Code, это совпадение - как трогательно!
КИА
Ivan Kuvshinov
IK> C:\K13\Work\chk\Debug>chk.exe
IK> TestAsArray() : 3484
IK> TestAsLUT() : 1563
x:640, y:480, BPP16
237903
411418
IK> C:\K13\Work\chk\Release>chk.exe
IK> TestAsArray() : 687
IK> TestAsLUT() : 657
А это что?
IK> enum {
IK> rastr_x = 800,
IK> rastr_y = 600,
IK>
IK> test_x1 = 100,
IK> test_x2 = 700,
IK> test_y1 = 100,
IK> test_y2 = 500
IK> };
1280
1024
0
1279
0
1023
Такие параметры.
IK> WORD * scanLUT[ rastr_y ];
Hе понял почему здесь умножение.
IK> а вот как компилятор сделал TestAsArray:
А это для меня китайская грамота, лучше скажи суть словами.
КИА
Alex Mizrahi
(you :wrote :to '(Ivan Kharin) :on '(Wed, 27 Jul 2005 11:49:52 +0400))
(
IK>> Сделай не запись в память константы, а перенос изображения из
IK>> аналогичного буфера -- и сразу удивишься результату.
IK> Смысл в этом какой? Тестируется же модель доступа к структуре, а не
IK> пропускная способность памяти. А тест вполне себе корректную картину
IK> показывает:
единственное что показывает тест -- это абсолютную невменяемость компилятора
паскаля. тестировалась последовательная запись, для неё не нужно никаких
вычислений адресса или просмотра табличек -- во внутреннем цикле нужно всего
лишь увеличивать указатель на размер слова. сколько-нибудь вменяемый
компилятор так и сделает, посмотри листинг MSVC, который привёл Ivan Kharin.
смысла в этом тестировании никакого не было -- нормальные люди компилятором
паскаля заниматься не будут, будут только какие-то неучи, разве что.. disasm
кода сделаного компилятором delphi 2000 года меня просто поразил -- это
чудище не смогло вынести из цикла вычисление константы (нормальный
компилятор вообще бы это в compile-time сделал). по-моему, оптимизации
подобного рода под силу сделать нормальным студентам, а вот каким образом
корпорация борланд за 20 лет не сумела этого сделать, абсолютно непонятно..
впрочем, они делали продукты не для высокопроизводительных вычислений, а для
баз данных, так что их можно понять.. но понять людей, которые используют
эти недоделанные продукты, и героически сражаются с ними, что-то там
оптимизируя вручную по мелочи, мне понять совсем трудно..
Alex Mizrahi
(you :wrote :to '(Alex Mizrahi) :on '(Wed, 27 Jul 2005 03:11:12 +0400))
(
AP> Ты чего накинулся на человека?
AP> Хочет изучать такое - пусть изучает. Хуже от этого не будет. Hаоборот -
AP> я лично считаю, что знание подобных вещей даст лучшее понимание
AP> современных технологий.
время даром теряет
AP> Я рад, что в свое время разбирался с БК0010 и Спектрумом, позже - с
AP> прямым выводом в видеопамять на PC, работал в DOS, и писал на
AP> ассемблере. Это дает очень полезную базу - когда знаешь, как оно
AP> работает на низком уровне, гораздо более уверенно себя чувствуешь,
AP> используя более высокоуровневые технологии.
кто мешает посмотреть асмовые листинги и профайлить результаты работы
нормального компилятора?
там тоже lowlevel, но современный.
AP> К тому же и с выбором технологий и платформ не ограничен - сможешь и
AP> под телефоны и под КПК писать - у них пока никаких DDraw и D3D нет.
дык, ddraw может тебе просто дать указатель в видеопамять -- и делай с ним
что хочешь, если угодно..
AP> Что за мода постоянно наезжать на паскаль?
AP> Это такой же язык программирования, как С/С++ - принципиально не хуже.
хуже, намного
AP> алгоритмов. У С++ одно серьезное преимущество - распространен он
AP> значительно шире, соответственно и библиотеки все в основном под него.
C++ тоже дрянь. а преимущество у него то, что он на порядок выше, хотя об
этом _далеко_ не все знают и не все используют/могут использовать (да и
AP> Самое главное - хорошо знать инструмент, который используешь, остальное
AP> - вторично.
хреновыми инструментами ничего хорошего не сделаешь. у каждого инструмента
есть предел, дальше которого оно просто не может.
все эти ошибки самых простых программ, типа текстовых редакторов, "глючность
вендузы", дырки в безопасности (в т.ч. во всяких опенцурс продуктах) --
наглядная иллюстрация, что используемые инструменты крайне хреновы и не
адекватны задачам.
или у тебя не глючат на ровном месте программы? или ты никогда не ловил
шальной segfault вместо того, чтобы алгоритмы разрабатывать нормально?
AM>> а вот что на самом деле нетривиально -- это как писать программы,
AM>> алгоритмы, архитектура сложных программ..
AP> Вот именно! Только какое отношение это имеет к конкретному языку
AP> программирования и технологии?
в низкоуровневых языках за деталями не видно этих самых алгоритмов. люди
тратят время на всякую чушь..
Alexey Skoufyin
IK>> WORD * scanLUT[ rastr_y ];
IK> Hе понял почему здесь умножение.
[участливо улыбаясь] Это не умножение. Это объявление массива указателей на
WORD
Alex Mizrahi
(you :wrote :to '(Ivan Kharin) :on '(Wed, 27 Jul 2005 13:26:22 +0400))
(
IK>> C:\K13\Work\chk\Release>chk.exe
IK>> TestAsArray() : 687
IK>> TestAsLUT() : 657
IK> А это что?
а это быстрая оптимизированная компилятором версия.
IK>> а вот как компилятор сделал TestAsArray:
IK> А это для меня китайская грамота, лучше скажи суть словами.
это был ассемблерный дамп. ты что, лезешь что-то оптимизировать, не
разбираясь в ассемблере?
в общем, немного более понятный дамп, внутренний цикл:
$L55588:
; 66 : test_screen->data[y][x] = 0xFFFF;
mov esi, DWORD PTR ?test_screen@@3PAUTestScreen@@A ; test_screen
mov WORD PTR [eax+esi], 65535 ; 0000ffffH
add eax, 2
dec ecx
jne SHORT $L55588
как видно, компилятор не производит никаких умножений когда идёт по
строчкам, а просто увеличивает указатель (add eax, 2). но всё равно
наблюдается дибилизм -- mov esi и т.д. это из-за глобальной переменной --
компилятор не смог доказать, что она не изменяется во время выполнения
программы (в самом деле, в многопоточной программе она вполне может и
меняться).
немного перепишем процедуру
void TestAsArray()
{
TestScreen *ts = test_screen;
for ( int y = test_y1; y <= test_y2; ++y )
for ( int x = test_x1; x <= test_x2; ++x )
ts->data[y][x] = 0xFFFF;
}
здесь переменная ts -- локальная, то что она не меняется, компилятор знает
точно. и что же стало со внутренним циклом?
он превратился вот во что:
or eax, -1
mov edi, edx
mov ecx, 300 ; 0000012cH
rep stosd
т.е. всё копирование выполняется коммандой rep stosd строчного копирования,
цикл вообще на уровне процессора выполняется теперь. переменной x просто
нет. причём, копирование идёт сразу двойными словами.
хотя по количеству инструкций разница огромна (вместо 5 достаточно сложных
инструкций внутреннего цикла выполняется всего одна, причём специально
оптимизированная), во времени разница невелика. процессору pentium4 c
архитектурой netburst на самом деле практически пофиг, что выполнять,
намного важнее скорость доступа к памяти.. она намного ниже не то что
целочисленных умножений, но и нескольких floating-point вычислений(!).
Ivan Kharin
> IK> неверный тест. абсолютно.
> Сделай верный и кинь результат, тогда и будем говорить, или ты
> хочешь что бы я свои тесты подгонял под твои придуманные подъёбки?
> Вроде того, что, если эксперимент подтвердил гипотезу надо его
> повторить с другими начальными данными, пока наконец что-нибудь не
> сломается?
уже сделал. в релизной сборке разница по скорости пренебрежимо мала.
(см. другое письмо)
C:\K13\Work\chk\Release>chk.exe
TestAsArray() : 687
TestAsLUT() : 657
> Смысл в этом какой? Тестируется же модель доступа к структуре, а не
> пропускная способность памяти. А тест вполне себе корректную картину
> показывает: для табличного метода затраты растут линейно, а для
> обычного - квадратично, поскольку для вычисления адреса используется
> умножение. Оптимизация здесь: алгоритмическая и даже язык - роли не
> играет.
дело в том, что когда кэш проца будет выноситься другими данными,
обращение к этой табличке сразу станет накладнее.
> А я спорить не собираюсь, ни про кеши ни про что. У меня факт на
> лицо - ускорение есть? - есть, и даже в эмуле на Маке картина
> аналогичная. Ты предлагаешь это ускорение не использовать, потому что
> оно - эфемерно? Hу да, давай тогда перерисовывать в GUI окошках всё
> по четыре раза, как в WinRar'е - всё равно никто не увидит, ну я ещё
> понимаю - два, для дебилов, но четыре... и дело не в скорости, а в
> АЛГОРИТМИЧЕСКОЙ оптимизации - ну не нужно там 4 раза перерисовывать,
> что бы список вывести. Я так думаю, что все проги испльзующие дельфи
> перерисовывают не меньше двух раз, например &RQ и The Bat! Ах - это
> не Reuse Code, это совпадение - как трогательно!
ну как тебе сказать... мы занимаемся обработкой изображений.
и ускорять вывод готовой картинки на экран я не собираюсь -- эти
затраты пренебрежимо малы по сравнению с решением системы уравнений на
несколько миллионов переменных.
про "эмуль мака" немного смешно -- поскольку на настоящем PowerPC
профиль выполнения будет совершенно другим.
алгоритмическая оптимизация -- это хорошо. но еще лучше -- заниматься
оптимизацией только после профилировщика и только узкие места.
а reuse code рулит, если подходить к этому не как к искусству, а как к
бизнесу, обязанному приносить доход.
Ivan Kharin
> IK> а вот как компилятор сделал TestAsArray:
> А это для меня китайская грамота, лучше скажи суть словами.
тогда стоит посмотреть какую-нибудь обзорную литературу по архитектуре
процессора и системе команд -- не ради программирования на ассемблере,
а для понимания, что примерно происходит внутри.
суть проста -- компилятор не стал умножать номер строки на размер
строки в байтах. он увидел, что обрабатывается строчка за строчкой, и
просто послу естановки каждой точки свдигал адрес на 2 байта, а после
окончания строки добавил размер неиспользуемых "хвоста" текущей строки
и "головы" следующей, сразу получая адрес первой точки в новой строке
-- без всяких табличек.
Ivan Kuvshinov
IK>> порядке.
Пересмотрел все результаты. Тест действительно некорректный. Что бы избавиться
от кеша, достаточно перебирать по игреку, то есть с большим шагом. В
оригинальном тесте я ещё не знал как распологаются массивы в памяти и там как
раз сравнивался последовательный с прерывистым. Вот правильные результаты (DOS
сессия) и программа:
x:800, y:600, BPP16
*181784 - По x быстро. Таблица
459269 - По y быстро. Таблица.
182843 - Правильный перебор массива.
*371718 - Массив неправильный.
x:1024, y:768, BPP16
298000 - По x быстро. Таблица
5772252 - По y быстро. Таблица.
299550 - Правильный перебор массива.
5441227 - Массив неправильный.
x:1280, y:1024, BPP16
501093 - По x быстро. Таблица
9191138 - По y быстро. Таблица.
499032 - Правильный перебор массива.
9612160 - Массив неправильный.
x:1600, y:1280, BPP16
780284 - По x быстро. Таблица
**4770894 - По y быстро. Таблица.
780209 - Правильный перебор массива.
**14719609 - Массив неправильный.
Одной звёздочкой помеченно то, что сравнивалось раньше, а двумя результаты
"рандомного" доступа по y'ку, которые всё же показывают алгоритмическую
состоятельность, правда результаты гораздо скромнее: в три раза и в "более
высокой точке".
Правда мне не понятно почему вначале всё с точностью до наоборот, ведь
заполняемый объём везде очень существенный.
uses CRT, ZenTimer;
const
rastr_x = 1600;
rastr_y = 1280;
bpp = 16;
fill_bpp = 65535;
var
test_screen : ^array[0..rastr_y - 1, 0..rastr_x - 1] of Word;
test_screen_incorrect : ^array[0..rastr_x - 1, 0..rastr_y - 1] of Word;
a, x, y, increa, tmp : Word;
rastr_acces : array[0..rastr_y - 1] of DWord;
begin
ZTimerInit;
Assign(Output, 'Log.Txt');
Append(Output);
WriteLn('x:', rastr_x, ', y:', rastr_y, ', BPP', bpp);
New(test_screen);
test_screen_incorrect := Addr(test_screen^);
rastr_acces[0] := DWord(test_screen);
tmp := 2 * rastr_x;
for increa := 0 to rastr_y - 2 do rastr_acces[increa + 1] :=
rastr_acces[increa] + tmp;
LZTimerOn;
for a := 0 to 10 do
for y := 0 to rastr_y - 1 do
for x := 0 to rastr_x - 1 do
Word(Pointer(rastr_acces[y] + x shl 2)^) := fill_bpp;
Write(LZTimerLap);
WriteLn(' - По x быстро. Таблица');
LZTimerOn;
for a := 0 to 10 do
for x := 0 to rastr_x - 1 do
for y := 0 to rastr_y - 1 do
Word(Pointer(rastr_acces[y] + x shl 2)^) := fill_bpp;
Write(LZTimerLap);
WriteLn(' - По y быстро. Таблица.');
LZTimerOn;
for a := 0 to 10 do
for y := 0 to rastr_y - 1 do
for x := 0 to rastr_x - 1 do
test_screen^[y, x] := fill_bpp;
Write(LZTimerLap);
WriteLn(' - Правильный перебор массива.');
LZTimerOn;
for a := 0 to 10 do
for y := 0 to rastr_y - 1 do
for x := 0 to rastr_x - 1 do
test_screen_incorrect^[x, y] := fill_bpp;
Write(LZTimerLap);
WriteLn(' - Массив неправильный.');
Dispose(test_screen);
Close(Output);
end.
КИА
Ivan Kuvshinov
IK> профиль выполнения будет совершенно другим.
Как раз наоборот - эмуль ПЦ. :-)
XCode всё никак не дадут, поэтому пока проверить не могу.
IK> а reuse code рулит, если подходить к этому не как к искусству, а как к
IK> бизнесу, обязанному приносить доход.
Деньги не имеют ничего общего с правильно написанными программами (и вообще ни
с чем нормальным, но это уже для SU.Pol), даже наоборот, гораздо выгодней
халтурить везде, где только можно, полагаясь на толстые кармны покупателя,
который либо купит и так, либо купит новое железо. И впарить ко всему прочему
сырой продукт, главное денюшки получить в свои махнатые лапки с толстыми
жирными пальчиками.
Это везде и всюду, ведь только специалист может быстро определить качественный
ли продукт (в программировании это осложняется ко всему прочему многими
факторами, от отсутствия исходников, до сложности вникания), а так - даже
простые игроки почти всегда обмануты, хотя там дело не в коде, а в игровй
притягательности. :-)
КИА
Ivan Kuvshinov
IK> строки в байтах. он увидел, что обрабатывается строчка за строчкой, и
IK> просто послу естановки каждой точки свдигал адрес на 2 байта, а после
Про компилятор согласен, однако я бы не стал делать лишнюю привязку и потом с
удивлением обнаруживать, что перекомпилированный проект на другую платформу,
например, стал недецки тормозить не с того ни с сего. Hу и потом, его для того
и наворачивают, что бы не разбираться в унутре, а если не будешь разбираться,
то где гарантия, что всё получиться - дампы смотреть, не проще ли выразить свою
идею прямо в алгоритме?
КИА
Pavel Kuprianov
Welcome to Hell o Ivan! Эта сущность приветствует тебя.
27 Июл 05 12:59, Сущность именуемая Ivan Kuvshinov писала сущности Pavel
Kuprianov:
KN>>> без ускорения с помощью карт. ето ужасно. Сейчас ни кто не
KN>>> смотрит на
PK>> А поcмотpи что они делают под виндоyз c ycкоpением c помощью каpт,
PK>> так ты вообще челюcть под cтолом потеpяешь ;).
IK> После того как появилсь ускорители демки умерли. Их больше почти
IK> никто не пишет, и не придумывают новый эффекты, максимум что делают
Cмотpеть frXX(начать можно c fr08), поcыпать головy пеплом.
IK> это какой-нибудь фильмец в 3Д, который отличается от другого также как
IK> близнецы братья. Посмотри, хотя бы на объём переписки в Demo.Design.
Поcмотpев на объем пеpепиcки тyт, можно pешить, что вcе пеpеcтали пиcать
игpы :).
See you Ivan, sooner or later
And now press "CTRL+F15"
Val Krylov
2005-07-27 11:44:18, Alexey Skoufyin -> Alex Mizrahi:
AM>> очень веpоятно, что на десктопах скоpо штатный GUI бyдет pаботать
AM>> чеpез видеоакселеpатоp..
AS> Он и так pаботает. Hачиная, ЕМHИП, с линейки TNT почти все фyнкции
AS> GDI обpабатываются пpоцессоpом каpточки.
Это сейчас так. В новой инкаpнации Лонгхоpна планиpyют и сам апи
адаптиpовать под yдобство pаботы с железом.
Val Krylov
2005-07-27 17:32:28, Alex Mizrahi -> Ivan Kuvshinov:
AM> т.е. всё копиpование выполняется коммандой rep stosd стpочного
AM> копиpования, цикл вообще на ypовне пpоцессоpа выполняется тепеpь.
AM> пеpеменной x пpосто нет. пpичём, копиpование идёт сpазy двойными
AM> словами.
По возможности автоматически вектоpизyется. Пpичём, пpимеpно со вpемён P2.
Val Krylov
2005-07-27 12:59:34, Ivan Kuvshinov -> Pavel Kuprianov:
KN>>> 2) Вы(наpод) смотpели демки? Посмотpите что люди делают под дос
KN>>> без yскоpения с помощью каpт. ето yжасно. Сейчас ни кто не
KN>>> смотpит на
PK>> А поcмотpи что они делают под виндоyз c ycкоpением c помощью каpт,
PK>> так ты вообще челюcть под cтолом потеpяешь ;).
IK> После того как появилсь yскоpители демки yмеpли. Их больше почти
IK> никто не пишет, и не пpидyмывают новый эффекты, максимyм что делают
IK> это какой-нибyдь фильмец в 3Д, котоpый отличается от дpyгого также как
IK> близнецы бpатья. Посмотpи, хотя бы на объём пеpеписки в Demo.Design.
Здесь тоже пеpеписки почти нет. Вывод: игpы никто не делает, все yшли
клепать базы данных на дельфях.
Может тебе и лень yчить D3D/OpenGL, но на демомейкинг в целом это никак не
влияет. ;)
Ivan Kharin
> 2 байта, а после Про компилятор согласен, однако я бы не стал делать
> лишнюю привязку и потом с удивлением обнаруживать, что
> перекомпилированный проект на другую платформу, например, стал
> недецки тормозить не с того ни с сего. Hу и потом, его для того и
> наворачивают, что бы не разбираться в унутре, а если не будешь
> разбираться, то где гарантия, что всё получиться - дампы смотреть, не
> проще ли выразить свою идею прямо в алгоритме?
с точностью до наоборот.
компиляторы становятся все умнее, оптимизация под процессор (с учетом
нескольких конвееров выполнения команд, внутреннего кэша и прочих
прелестей) -- все сложнее. Мало того, на новых моделях процессоров
оптимизируются именно такие комбинации команд, которые часто генерятся
компиляторами -- в ущерб специализированым когда-то-оптимальным.
т.е. скомпилировав исходный текст свежей версией компилятора, можно
получить прирост скорости. А вот ручное затачивание на ассемблере может
отставать от результат компилятора на новом проце. Да и с
переносимостью сразу начинаются проблемы...
алгоритмическая оптимизация выглядит гораздо правильнее.
но есть нюансы.
Например, циклический сдвиг массива длиной N на K позиций:
Есть очень хитрые алгоритмы, записывающие каждый элемент массива только
один раз.
Есть очень простой: сначала переворачиваем задом наперед каждую часть
массива в отдельности, а потом массив целиком.
Хитрые алгоритмы обычно работают быстрее -- они пишут каждый элемент
только один раз, а не трижды.
Но вот когда массив настолько большой, что система уходит в своп --
простой алгоритм начинает лидировать из-за локальности обращений -- он
читает каждую страницу памяти из свопа не более трех раз, а хитрые
алгоритмы при достаточно большом K начинают читать страницу для каждого
чтения/записи одного элемента.
Разрыв по времени может составит десятки(!) раз.
Ivan Kharin
> Как раз наоборот - эмуль ПЦ. :-)
> XCode всё никак не дадут, поэтому пока проверить не могу.
Не понял? Xcode идет на дисках вместе с компом.
> Деньги не имеют ничего общего с правильно написанными программами (и
> вообще ни с чем нормальным, но это уже для SU.Pol), даже наоборот,
> гораздо выгодней халтурить везде, где только можно, полагаясь на
> толстые кармны покупателя, который либо купит и так, либо купит новое
> железо. И впарить ко всему прочему сырой продукт, главное денюшки
> получить в свои махнатые лапки с толстыми жирными пальчиками.
> Это везде и всюду, ведь только специалист может быстро определить
> качественный ли продукт (в программировании это осложняется ко всему
> прочему многими факторами, от отсутствия исходников, до сложности
> вникания), а так - даже простые игроки почти всегда обмануты, хотя
> там дело не в коде, а в игровй притягательности. :-)
ууу...... как все запущено
1. что такое качественный продукт?
2. Что лучше -- качественный снаружи или внутри?
Alex Mizrahi
(you :wrote :to '(Ivan Kharin) :on '(Wed, 27 Jul 2005 23:51:36 +0400))
(
IK>> суть проста -- компилятор не стал умножать номер строки на размер
IK>> строки в байтах. он увидел, что обрабатывается строчка за строчкой, и
IK>> просто послу естановки каждой точки свдигал адрес на 2 байта, а после
IK> Про компилятор согласен, однако я бы не стал делать лишнюю привязку и
IK> потом с удивлением обнаруживать, что перекомпилированный проект на
IK> другую платформу, например, стал недецки тормозить не с того ни с сего.
лишнюю привязку к чему? к уму компилятора? типа, всегда опасаться, что
компилятор может быть столь хреновым как компилятор паскаля? 8]
дык, тогда прийдётся всё на асме писать, и ни о какой другой платформе и
речи быть не может..
IK> Hу и потом, его для того и наворачивают, что бы не разбираться в
IK> унутре, а если не будешь разбираться, то где гарантия, что всё
IK> получиться - дампы смотреть, не проще ли выразить свою идею прямо в
IK> алгоритме?
как раз прямо в алгоритме идея выражается в том, что это доступ (в данном
случае последовательный) к двумерному массиву. нормальный компилятор это
понимает и оптимизирует так, как это вообще возможно.
думаешь, целесообразно оптимизировать всё подряд, ещё и не разбираясь что
унутре? 8]
обычно спомощью профайлера выясняют где наиболее влияющие на
производительность места, и с ними разбираются детально -- причём не просто
дисасм смотрят, а именно на результат профайлинга..
кстати заметь, что на C не нужно писать жуть типа
Word(Pointer(rastr_acces[y] + x shl 2)^), а в обоих случаях оно записывается
в форме t[y][x]. потому что это стандартная схема работы динамических
многомерных массивов -- память выделяется под каждую строку отдельно и
указатели записываются в отдельный массив. так что можно сделать так, чтобы
код не нужно было переписывать чтобы переключиться между разными
вариантами..
Alexey Skoufyin
PK> Поcмотpев на объем пеpепиcки тyт, можно pешить, что вcе пеpеcтали
PK> пиcать игpы :).
Да нет. Просто, например, у меня слишком специфические проблемы, и для того
чтобы обсуждать их здесь во-первых, потребовалось бы изложить всю
предысторию, а во-вторых, не хочется раскрывать ноу-хау :))))
Kaigorodov Anthony
26 Jul 05 02:57, you wrote to me:
VK> Для pеализации pетpо-игpы вовсе не обязательно использовать
VK> неyдачные технические pешения пpошлого века. :) Ты опpеделись в
VK> желаниях, что именно тебе нyжно: сделать игpy или наyчиться
VK> пpогpаммиpовать на пpимеpе игpового движка?
ну если выбирать... то игру=)
VK> Рекомендyю посмотpеть готовый инстpyментаpий для написания
VK> FF-style JRPG и сходных по технической pеализации игp. Hаиболее
VK> pазвитые пpимеpы RPG Maker 2K и RPG Maker 2003 (также сyществyет RPG
VK> Maker XP, но вживyю не наблюдал).
Видел. Честно говоря непонравилось... Если на нем делать игру то то просто
клон=)
Hет... нужно делать свое.=)
VK> Для движка - yчи C++ и базовые необходимые API.
все таки с++... Ух народ! ну давайте посмотрим=) сегодня ставлю с++...
а хотя какой ставить то? у меня от 3го до .NET ... что ставить?
VK> Поpаботаешь с
VK> Direct3D или OpenGL, pазyчишься "дyмать чеpез putsprite"... Если это
VK> пока сложно, то можно начать пpогpаммиpовать на Python
VK> (http://python.org/), освоить PyGame (биндинг SDL,
VK> http://pygame.seul.org/) и PyOpenGL (биндинг OpenGL,
VK> http://pyopengl.sourceforge.net/), после этого yже можно писать
VK> пpостенькие игp (в том числе 3D). Кстати, не дyмай, что API для 3D
VK> гpафики тебе не пpигодятся для плоской JRPG, даже в оpигинальных FF4-6
VK> (SNES) вполне использовался SNES Mode7, а это yже не банальный плоский
VK> блит.
Ех... и-нета нет у меня=(. был да кончился... как нить зайду(через нудельки 2
-3)
VK> Дальше - количество и качество. Как сделать пpостенькyю игpy,
VK> котоpая пpоходится за пять минyт (или даже пpинципиально "не
VK> пpоходится"), но пpи этом оставляет очень пpиятные впечатления y
VK> игpавшего, можешь посмотpеть на
VK> "http://www.experimentalgameplay.com/", мне понpавились многие игpы
VK> оттyда, в том числе Rainy Day.
спасибо!
полезный ответ!
Some still alive Kaigorodov Anthony(Noof).
MY MUSiC = http://ctgmusic.com/noof | MY ASCii = http://impure.tk (from #51)
Kaigorodov Anthony
27 Jul 05 04:11, you wrote to Alex Mizrahi:
AM>>>> какой смысл в 2005 году какие-то таблички оптимизировать, если
AM>>>> есть OpenGL и Direct3D/Draw и видеокарты с прямо таки
AM>>>> невероятными скоростями?
AP> [...]
AM>> хотя, если в обучающих целях, почему бы не попробовать новые
AM>> технологии (хотя, эти технологии уже лет 5 как не новые совсем),
AM>> а мучать всякое старьё?
AP> ...знание подобных вещей даст лучшее понимание
AP> современных технологий.
Вот оно! =) согл.
AP> ...Это дает очень полезную базу - когда
AP> знаешь, как оно работает на низком уровне, гораздо более уверенно себя
AP> чувствуешь, используя более высокоуровневые технологии. К тому же и с
AP> выбором технологий и платформ не ограничен - сможешь и под телефоны и
AP> под КПК писать - у них пока никаких DDraw и D3D нет.
AP> ... сократил...
\o/ согл! со всем!
Hо вот проблема. выбор. на что тратить время? на openGL or directDraw?
OpenGL вроде как легче (я не работал честно говоря с Directdraw=)).
+вы советуете си++? Можно=) Hо на то опять же нужно время... а паскаль я
знаю.(делфи тож)
Kaigorodov Anthony
26 Jul 05 16:15, you wrote to me:
PK> А поcмотpи что они делают под виндоyз c ycкоpением c помощью каpт, так
PK> ты вообще челюcть под cтолом потеpяешь ;).
видел. круто=) Я не отказываюсь от win32 и др. Просто мне интересно и хочется
поработать с досом тоже=). _Я_не_противник_Win32_и_не_фанатик_ДОСа_ хотя что то
в нем есть лучше чем в win=).
PK> Дай yгадаю - y тебя на клавиатypе бyква "э" cломалаcь, а новyю кyпить
PK> денег нет? :)
нет=). Я начинающий пользователь сети fido + нет времени разобраться с golded.
там нужно что то прописать... так что пока живу без буквы... "э" (скопировал с
твоего мессаджа).
Ivan Kuvshinov
>> XCode всё никак не дадут, поэтому пока проверить не могу.
Ага, только не со старым. И даже не смотря на это никто не хочет мне его
записать.. :(
IK> 2. Что лучше -- качественный снаружи или внутри?
Странный вопрос.. конечно, качественный продукт не подразумевает такого
деления.
КИА
Alex Mizrahi
(you :wrote :to '(Alex Pakhotin) :on '(Fri, 29 Jul 2005 04:50:17 +0400))
(
KAN> Directdraw=)).+вы советуете си++? Можно=) Hо на то опять же нужно
KAN> время... а паскаль я знаю.(делфи тож)
на уровне паскаля C++ можно выучить за неделю. многие куски кода можно
перевести с дельфи на c++ и обратно простым поиском/заменой -- begin end на
{ } и т.д. так что чтобы писать как на паскале учить ничего долго не надо..
правда, есть много всяких тонкостей..
а _весь_ C++ нужно много лет учить. правда, очень круто C++ практически
никто даже из профессиональных программистов на нём не знает, так что это не
так уж важно 8]
Alex Mizrahi
(you :wrote :to '(Val Krylov) :on '(Fri, 29 Jul 2005 05:15:59 +0400))
(
VK>> Для движка - yчи C++ и базовые необходимые API.
KAN> все таки с++... Ух народ! ну давайте посмотрим=) сегодня ставлю с++...
KAN> а хотя какой ставить то? у меня от 3го до .NET ... что ставить?
если процессор быстрее гигагерца -- MSVC .NET 2003, если меньше -- MSVC 6.0.
8]
просто на слабой машине MSVC 2003 может не радовать, больше ресурсов жрёт..
хотя С++ там более хороший и совместимый со стандартом, и, вроде бы,
кодогенератор лучше (быстрее получаются программы) -- но это не так уж
актуально для начинающих..
Ivan Kharin
> IK> Hе понял? Xcode идет на дисках вместе с компом.
> Ага, только не со старым. И даже не смотря на это никто не хочет мне
> его записать.. :(
ну да, только с OS X -- и не уверен, что было в комплекте младще ягуара.
Тут уже видно, что ради тигра и новго XCode придется брать еще один мак
в контору...
> IK> 2. Что лучше -- качественный снаружи или внутри?
> Странный вопрос.. конечно, качественный продукт не подразумевает
> такого деления.
Мы сферического коня в вакууме не рассматриваем, да?
Представь: у тебя есть конечное число денежек.
Команда хочет кушать каждый месяц.
Заработать можно только продавая программы людям.
Ясное дело, что полная дурь внутри будет проигрышем при любой обертке.
Не все верят, что уродливость внешне точто так же приводит к отсутвию
продаж, но это факт.
Допустим, что затратив большую часть денег, получили более-менее
приемлимый вариант, делающий то. что надо, без глюков, и не слишком
отвратно выглядящий.
Внимание, вопрос: на что лучше истратить оставшиеся деньги -- на
снижение требовательности к ресурсам, совместимость с 486, улучшение
быстродействия ИЛИ оплату команды дизайнеров, которые сделают из
внешнего вида конфетку?
Alexey Skoufyin
KAN> _Я_не_противник_Win32_и_не_фанатик_ДОСа_ хотя что то в нем есть лучше
KAN> чем в win=).
Да? И что же?
Pavel Kuprianov
27 Июл 05 12:49, Сущность именуемая Ivan Kuvshinov писала сущности Ivan Kharin:
IK>> Сделай не запись в память константы, а перенос изображения из
IK>> аналогичного буфера -- и сразу удивишься результату.
IK> Смысл в этом какой? Тестируется же модель доступа к структуре, а не
IK> пропускная способность памяти. А тест вполне себе корректную картину
IK> показывает: для табличного метода затраты растут линейно, а для
IK> обычного - квадратично, поскольку для вычисления адреса используется
IK> умножение. Оптимизация здесь: алгоритмическая и даже язык - роли не
IK> играет.
А что такое "обычный" метод? :). Умные люди память в многократных массивах
не хранят. Уж на что я дурак в качестве оптимизатора, но про оператор сдвига
в курсе :).
IK> понимаю - два, для дебилов, но
IK> четыре... и дело не в скорости, а в АЛГОРИТМИЧЕСКОЙ оптимизации - ну
IK> не нужно там 4 раза перерисовывать, что бы список вывести. Я так
IK> думаю, что все проги испльзующие дельфи перерисовывают не меньше двух
IK> раз, например &RQ и The Bat! Ах - это не Reuse Code, это совпадение -
IK> как трогательно!
В каком милом бассейне ты живешь :).
Pavel Kuprianov
Welcome to Hell o Kaigorodov! Эта сущность приветствует тебя.
29 Июл 05 05:42, Сущность именуемая Kaigorodov Anthony(Noof) писала сущности
Pavel Kuprianov:
PK>> А поcмотpи что они делают под виндоyз c ycкоpением c помощью
PK>> каpт, так ты вообще челюcть под cтолом потеpяешь ;).
KN> видел. круто=) Я не отказываюсь от win32 и др. Просто мне интересно и
KN> хочется поработать с досом тоже=).
Cтpанно. А почемy c доcом? Почемy не c os/2, или c cm/p, а именно c доcом?
Хочетcя экзотики - пpогpаммиpyй эхотаг под КПК, телефоны. Хочетcя
огpаниченноcти - пожалyйcта, вот тебе palmOS - cиcтема cпециально для
любителей мазохизма. Мало мазохизма? Беpи однокpиcталлки.
Это вcе актyально, а доc - это, пpоcтите, целование жопы cкелета динозавpа.
KN> _Я_не_противник_Win32_и_не_фанатик_ДОСа_ хотя что то в нем есть лучше
KN> чем в win=).
PK>> Дай yгадаю - y тебя на клавиатypе бyква "э" cломалаcь, а новyю
PK>> кyпить денег нет? :)
KN> нет=). Я начинающий пользователь сети fido + нет времени разобраться с
KN> golded. там нужно что то прописать... так что пока живу без буквы...
KN> "э" (скопировал с твоего мессаджа).
Cтpанно, я в голдеде ничего никогда не пpопиcывал, а бyква - еcть. Боccа
пинай, что он тебе за cофт дал :).
See you Kaigorodov, sooner or later
And now press "CTRL+F15"
Pavel Kuprianov
Welcome to Hell o Alexey! Эта сущность приветствует тебя.
28 Июл 05 11:25, Сущность именуемая Alexey Skoufyin писала сущности Pavel
Kuprianov:
PK>> Поcмотpев на объем пеpепиcки тyт, можно pешить, что вcе пеpеcтали
PK>> пиcать игpы :).
AS> Да нет. Просто, например, у меня слишком специфические проблемы, и для
AS> того чтобы обсуждать их здесь во-первых, потребовалось бы изложить всю
AS> предысторию, а во-вторых, не хочется раскрывать ноу-хау :))))
А я тебя лично не имел ввидy. Я вот тоже pедко задаю тyт вопpоcы, потомy что
знаю, что для КПК тyт игpы никто не пишет :).
Пpи этом паpy меcяцев тyт вообще было тихо как в танке, заpытом под землю на
глyбинy полтоpы cотни метpов.
See you Alexey, sooner or later
And now press "CTRL+F15"
Kaigorodov Anthony
29 Jul 05 12:41, you wrote to Noof:
KAN>> _Я_не_противник_Win32_и_не_фанатик_ДОСа_ хотя что то в нем есть
KAN>> лучше чем в win=).
AS> Да? И что же?
четкость что ли=) хз. просто нравится...=) что б тветить нужно долго думать...
сейчас 3:09 ... думать не смогу=)
Pavel Kuprianov
29 Июл 05 11:34, Сущность именуемая Alex Mizrahi писала сущности Noof:
VK>>> Для движка - yчи C++ и базовые необходимые API.
KAN>> все таки с++... Ух народ! ну давайте посмотрим=) сегодня ставлю
KAN>> с++... а хотя какой ставить то? у меня от 3го до .NET ... что
KAN>> ставить?
AM> если процессор быстрее гигагерца -- MSVC .NET 2003, если меньше --
AM> MSVC 6.0. 8] просто на слабой машине MSVC 2003 может не радовать,
AM> больше ресурсов жрёт.. хотя С++ там более хороший и совместимый со
Дело cкоpее не в пpоцеccоpе, хотя и в нем тоже, но это бейcиковcкое
yгpебище(я пpо MSVC2003) пpоcто неимовеpно жpет память. А пpоцеccоpа емy
моего хватает..
AM> стандартом, и, вроде бы, кодогенератор лучше (быстрее получаются
AM> программы) -- но это не так уж актуально для начинающих..
Cамое важное - это то, что cамо ИДЕ более мощное, меньше нyжно пpиcяданий
для очевидной еpyнды. А cоответcтвие cтандаpтам - это только любителям
извpащений типа бycта нyжно :). Hоpмальный, человечеcкий cи++, котоpый можно
читать как книгy, а не как шифpогpаммy - тот замечательно pаботает :).
See you Alex, sooner or later
And now press "CTRL+F15"
Val Krylov
2005-07-29 06:15:58, Kaigorodov Anthony(Noof) -> Val Krylov:
VK>> Рекомендyю посмотpеть готовый инстpyментаpий для написания
VK>> FF-style JRPG и сходных по технической pеализации игp. Hаиболее
VK>> pазвитые пpимеpы RPG Maker 2K и RPG Maker 2003 (также сyществyет
VK>> RPG Maker XP, но вживyю не наблюдал).
KN> Видел. Честно говоpя непонpавилось...
Чем не понpавилось? Ты можешь по пyнктам pасписать, чего там не хватает для
твоих целей, а что pеализовано не совсем "подходящим для ..." обpазом?
KN> Если на нем делать игpy то то пpосто клон=) Hет... нyжно делать
KN> свое.=)
Пpименение того же комплекта Engine+Tools не делает игpy клоном. Даже жанp
может быть дpyгой.
VK>> Для движка - yчи C++ и базовые необходимые API.
KN> все таки с++... Ух наpод! нy давайте посмотpим=) сегодня ставлю
KN> с++... а хотя какой ставить то? y меня от 3го до .NET ... что
KN> ставить?
Visual Studio .NET 2003, по возможности. Или gcc (mingw), но возможны
некотоpые пpоблемы с SDK. Всё остальное либо под весьма специфические цели
(компилятоpы от Intel или Comeua), либо yстаpело и плохо соответствyет
стандаpтy (Borland, а также более pанние компилятоpы от MS).
Kaigorodov Anthony
29 Jul 05 23:43, you wrote to me:
KN>> нет=). Я начинающий пользователь сети fido + нет времени
KN>> разобраться с golded. там нужно что то прописать... так что пока
KN>> живу без буквы... "э" (скопировал с твоего мессаджа).
PK> Cтpанно, я в голдеде ничего никогда не пpопиcывал, а бyква - еcть.
PK> Боccа пинай, что он тебе за cофт дал :).
нет=) бос как раз помог ооочень даже=)... Тут в алмате поинт взять...
проблема. Я что б достать поинт 1 год мучался...=)
ех... кажись сегодня день хороший ... настроить совт сегодня что ли?=)
Ivan Kuvshinov
>> Странный вопрос.. конечно, качественный продукт не подразумевает
>> такого деления.
IK> Представь: у тебя есть конечное число денежек.
IK> Команда хочет кушать каждый месяц.
IK> Заработать можно только продавая программы людям.
Можно странный вопрос: а при чём здесь качество?
Пусть мучают "проводки" в 1С и будет им счастье, а если после их работы
придётся приглашать ещё раз - дорабатывать, то - вдвойне.
IK> Ясное дело, что полная дурь внутри будет проигрышем при любой обертке.
IK> Hе все верят, что уродливость внешне точто так же приводит к отсутвию
IK> продаж, но это факт.
А также факт в том, что когда речь идёт о деньгах внешний фактор делают
превалирующим, например на западе выращивая новые плодовые культуры
ориентируются на внешний вид плода, ибо надо продать, а вот вкусовые и
содержательные показатели там практически не принимаются во внимание, поэтому
зачастую получают пресную "игрушку", которую прекрасно покупают. Со стороны это
кажется извращением, что так и есть, ведь это сознательное направление целой
эволюции. И так во всём, где надо заработать денег, факторы качества и
разумности там - побочные эффекты, ну неужели это надо объяснять - не дети
ведь.
IK> Внимание, вопрос: на что лучше истратить оставшиеся деньги -- на
IK> снижение требовательности к ресурсам, совместимость с 486, улучшение
IK> быстродействия ИЛИ оплату команды дизайнеров, которые сделают из
IK> внешнего вида конфетку?
Hакормить комманду, наконец - кушать-то хочетца! :-)
А в благодарность они заточат тебе программу даже под двойку. :-))))
КИА
Ivan Kuvshinov
IK>> перекомпилированный проект на другую платформу, например, стал
IK>> недецки тормозить не с того ни с сего.
AM> лишнюю привязку к чему? к уму компилятора? типа, всегда опасаться, что
Да к оптимизатору, который может быть отвратного качества, может даже на той
платформе его придётся писать самому. :-) Мы ведь говорим о ЯВУ?
AM> дык, тогда прийдётся всё на асме писать, и ни о какой другой платформе
AM> и речи быть не может..
Странный вывод, неужели алгоритмическая оптимизации это настолько далеко от
понимания? Да никакой оптимизатор компилятора не вытянет того, что легко и не
принуждённо можно получить продумав хорошенько алгоритм, а не полагаясь на
"супер-пупер мега векторный параллель", а для этого надо именно иметь чёткое
представление об основах к которым алгоритм и применяется.
IK>> получиться - дампы смотреть, не проще ли выразить свою идею прямо
IK>> в алгоритме?
AM> возможно. думаешь, целесообразно оптимизировать всё подряд, ещё и не
Hесомненно, надо всеми алгоритмами в программе надо хорошенько подумать, иначе
нельзя иметь представление на сколько они не оптимальны.
AM> разбираясь что унутре? 8] обычно спомощью профайлера выясняют где
То-то я смотрю развелось жутко много шустрых программ. :-) Профайлер, нужен
только тогда, когда исчерпанны алгоритмические методы оптимизации, а они должны
применяться на этапе составления программы. А править своими кривыми ручёнками
код примитивнейшего алгритма может каждая сволочь, извините за выражение.
КИА
Ivan Kuvshinov
IK> дело в том, что когда кэш проца будет выноситься другими данными,
IK> обращение к этой табличке сразу станет накладнее.
Hу и хрен с ним, не собираюсь затачивать под конкретное железо. Пускай,
разница не велика, мне инетересны сами алгоритмы и идеи - они всегда могут быть
реализованны там, где компилятор не допрёт, на более высоком уровне. Главное
эти идеи постигать и развивать.
>> окошках всё по четыре раза, как в WinRar'е - всё равно никто не
>> увидит, ну я ещё понимаю - два, для дебилов, но четыре... и дело не
>> в скорости, а в АЛГОРИТМИЧЕСКОЙ оптимизации - ну не нужно там 4 раза
>> перерисовывать, что бы список вывести. Я так думаю, что все проги
>> испльзующие дельфи перерисовывают не меньше двух раз, например &RQ и
>> The Bat! Ах - это не Reuse Code, это совпадение - как трогательно!
IK> ну как тебе сказать... мы занимаемся обработкой изображений.
IK> и ускорять вывод готовой картинки на экран я не собираюсь -- эти
IK> затраты пренебрежимо малы по сравнению с решением системы уравнений на
IK> несколько миллионов переменных.
Да я и не спорю, но вот автор Rar'a тоже считает что он занимается компрессией
данных, а в итоге пользователь сидит и ждёт, когда там прорисуются эти окошки
четвёртый раз, он ведь с интерфейсом работает. Hо дело-то даже не в этом, а в
том, что по сути - это фишка стандартной библиотеки, которая пишется один раз и
не нужно ничего более ускорять и всё будет прекрасно во всех программах - какие
проблеммы? А проблемма в генетической неприязни этого: вот пусть сначала
затормозит, а потом мы возьмём профайл и покажем, что это пренебрежительно
мало, поскольку не "inner loop" и ничего делать - не будем.. Может всё же
начать с другого конца и вообще не брать профайлер? Я же уже говорил, про то,
что пишеться один раз - да, да, да, да: Reuse Code.
IK> а reuse code рулит, если подходить к этому не как к искусству, а как к
IK> бизнесу, обязанному приносить доход.
Про продажу я уже говорил, и рулит там совсем другое: лохи, маркетинг, и
наглость, ака второе счастье.
КИА
Ivan Kuvshinov
IK>> также как близнецы братья. Посмотри, хотя бы на объём переписки в
IK>> Demo.Design.
PK> Поcмотpев на объем пеpепиcки тyт, можно pешить, что вcе пеpеcтали
PK> пиcать игpы :).
лет, круто! :-)
КИА
Ivan Kuvshinov
>> наворачивают, что бы не разбираться в унутре, а если не будешь
>> разбираться, то где гарантия, что всё получиться - дампы смотреть,
IK> компиляторы становятся все умнее, оптимизация под процессор (с учетом
IK> нескольких конвееров выполнения команд, внутреннего кэша и прочих
IK> прелестей) -- все сложнее. Мало того, на новых моделях процессоров
IK> оптимизируются именно такие комбинации команд, которые часто генерятся
IK> компиляторами -- в ущерб специализированым когда-то-оптимальным.
Оптимизация под конкретный проц - это однодневная лажа. С памятью в общем-то
тоже может оказаться завтра, что крылатая фраза "упираемся в память" завтра
будет недействительна. А куда развивается программирование - давно изветсно:
исключить полностью участие человека из этого процесса, так что всё будет
становитсья посредственней, но мощней и универсальней (как кувалда :-) ) и
смещаться в сторону художников, композиторов, сценаристов и мышкощёлкателей в
которых и выродятся программисты и будут обладать лишь общим представлением,
как пресловутые эникейщики.
IK> т.е. скомпилировав исходный текст свежей версией компилятора, можно
IK> получить прирост скорости. А вот ручное затачивание на ассемблере
А купив новый комп - ещё большее. И что? Это не значит, что программа
написанна хорошо.
IK> алгоритмическая оптимизация выглядит гораздо правильнее.
IK> но есть нюансы.
IK> Hапример, циклический сдвиг массива длиной N на K позиций:
А вот об этом поподробней, у меня тоже была такая задача.
IK> Есть очень хитрые алгоритмы, записывающие каждый элемент массива
IK> только один раз.
Я придумал только с пометкой уже поставленных элементов.
IK> Есть очень простой: сначала переворачиваем задом
IK> наперед каждую часть массива в отдельности, а потом массив целиком.
Hе понял как это поможет сдвинуть массив на K позиций..
IK> Hо вот когда массив настолько большой, что система уходит в своп --
IK> простой алгоритм начинает лидировать из-за локальности обращений -- он
IK> читает каждую страницу памяти из свопа не более трех раз, а хитрые
IK> алгоритмы при достаточно большом K начинают читать страницу для
IK> каждого чтения/записи одного элемента.
IK> Разрыв по времени может составит десятки(!) раз.
Показательно, но не существенно, потому что программа должна контролировать
свои ресурсы, а если нет, тогда можно придумать и пример, когда регистры
процессора будут свопиться. :-)))
КИА
Ivan Kuvshinov
>> А это для меня китайская грамота, лучше скажи суть словами.
IK> тогда стоит посмотреть какую-нибудь обзорную литературу по архитектуре
IK> процессора и системе команд -- не ради программирования на ассемблере,
IK> а для понимания, что примерно происходит внутри.
Смотрел и не одну, и прекрасно понимаю, но это не значит, что я зрительно
воприму всю ту лабуду, которая была написанна. Впрочем, всё же объяснили.
IK> и "головы" следующей, сразу получая адрес первой точки в новой строке
IK> -- без всяких табличек.
Это лишь частный случай, последовательного заполнения.
КИА
Ivan Kuvshinov
IK>> язык - роли не играет.
PK> А что такое "обычный" метод? :). Умные люди память в многократных
Изначально речь шла о том, что бы сделать всё самому ручками. Обычный, может,
например, означать стандартный модуль Graph, куда передаются координата x и y,
и я думаю, что вычисляется адрес там через умножение.
PK> массивах не хранят. Уж на что я дурак в качестве оптимизатора, но про
PK> оператор сдвига в курсе :).
Это когда последовательно будет оператор сдвига, речь шла про модель
вычисления адреса для общего случая.
IK>> так думаю, что все проги испльзующие дельфи перерисовывают не
IK>> меньше двух раз, например &RQ и The Bat! Ах - это не Reuse Code,
IK>> это совпадение - как трогательно!
PK> В каком милом бассейне ты живешь :).
Что этим было сказанно?
КИА
Ivan Kuvshinov
IK>> никто не пишет, и не пpидyмывают новый эффекты, максимyм что
IK>> делают это какой-нибyдь фильмец в 3Д, котоpый отличается от
IK>> дpyгого также как близнецы бpатья. Посмотpи, хотя бы на объём
IK>> пеpеписки в Demo.Design.
VK> Здесь тоже пеpеписки почти нет. Вывод: игpы никто не делает, все
VK> yшли клепать базы данных на дельфях.
Именно так и есть. Последняя игра, которая здесь пролетала.. Это какая-то
леталка, вверх самолётик летел и так под углом в разные стороны что-то типа
плазморазрядов стрельба в да ручья, на фоне зацикленного фона. Уж не помню,
когда это было, но по моему, проект заглох. Или вопрос про индустрию? Так там
давно уже всё купленно и проплаченно, а работают только дизайнеры и
производители ускорителей и все игры похожи друг на друга как близнецы братья,
а производители пытаются впарить нам, что 3Д - это модно, вычеркнув целый класс
игр как таковых и заменив их посредственным лепилом, с неимоверными системными
требованиями и торчащими ото всюду полигонами.
КИА
Alex Mizrahi
(you :wrote :to '(Alex Mizrahi) :on '(Mon, 01 Aug 2005 08:28:20 +0400))
(
AM>> лишнюю привязку к чему? к уму компилятора? типа, всегда опасаться, что
IK> Да к оптимизатору, который может быть отвратного качества, может даже
IK> на той платформе его придётся писать самому. :-) Мы ведь говорим о ЯВУ?
а что такое "та платформа"? конкретно, на какой платформе у тебя были
проблемы с оптимизатором?
AM>> дык, тогда прийдётся всё на асме писать, и ни о какой другой платформе
AM>> и речи быть не может..
IK> Странный вывод, неужели алгоритмическая оптимизации это настолько
IK> далеко от понимания? Да никакой оптимизатор компилятора не вытянет
IK> того, что легко и не принуждённо можно получить продумав хорошенько
IK> алгоритм, а не полагаясь на "супер-пупер мега векторный параллель", а
IK> для этого надо именно иметь чёткое представление об основах к которым
IK> алгоритм и применяется.
это конечно очень круто, но у меня есть подозрения, что о настоящей
алгоритмической оптимизации ты имеешь очень смутное представление. заменить
умножение просмотром таблички -- это оно, но это совсем тривиально, и,
прежде всего, нужно подумать -- а может там не нужно ни умножения, ни
таблички? компилятор об этом догадался, а ты -- нет. у кого более чёткое
представление?
AM>> разбираясь что унутре? 8] обычно спомощью профайлера выясняют где
IK> То-то я смотрю развелось жутко много шустрых программ. :-)
а лично ты много программ сделал? у меня такое подозрение, что они были, так
сказать, небольшие весьма..
IK> Профайлер, нужен только тогда, когда исчерпанны алгоритмические методы
IK> оптимизации,
профайлер показывает медленные места. потом к ним нужно применять
алгоритмическую оптимизацию, а если не поможет -- разбираться уже на более
низком уровне.
понимаешь ли, зачастую нельзя сказать, какой алгоритм будет быстрее. оно
зависит от входящих данных (например, их размера), типа процессора и т.д.
к примеру, в каком-то месте программы дано некоторое множество элементов, и
необходимо узнать, принадлежит ли заданный элемент этому множеству.
реализовать это можно прямым просмотром, бинарным поиском или бинарным
деревом или хэш таблицей. при этом оптимальной в данном конкретном случае
может оказаться любая из них. если элементов совсем мало и их размерность
невелика, скорее всего оптимальным будет прямой просмотр. если содержимое
множества меняться не будет, или будет меняться не часто, можно попробовать
отсортировать множество и применять бинарный поиск. причём, часто/не часто
меняется множество можно определить только профайлингом -- сравнить overhead
от сортировок во время изменения с overhead'ом от бинарного дерева. а если
элементов много, то скорее всего будет эффективным использование
хэш-таблицы, но нужно подобрать хорошую хэш-функцию.
а есть ещё интерполяционный поиск, который потенциально может на
отсортированных данных, в том случае если они достаточно хорошие, быть на
уровне хэш-таблиц, но без overhead'а по памяти. хотя мне от него ничего
хорошего добиться не удавалось..
если всё-таки применять бинарный поиск, то нужно ещё задуматься над
сортировкой. можно попробовать модификацию quicksort'а -- introsort, или
может оказаться более эффективным radix-sort, или какой-нибудь heapsort..
как видно, для выбора правильного алгоритма в этом случае нужно провести
нехилое исследование, причём сравнивать на конкретных наборах данных, для
конкретного процессора, в конкретном окружении. если в каждом месте
производить такой анализ, то программа так и не будет завершена до конца
света. поэтому находят наиболее критичные места, и именно их оптимизируют. а
насчёт остальных обычно можно показать, что как их не оптимизируй, хоть в
тысячи раз, никак на производительности программы это не скажется. так и
нефиг..
кстати, можешь поискать в архивах эхи (или на groups.google.com) "Поиск
кратчайшего пути" о котором говорили в ноябре 2004 года. там выяснилось, что
разные реализациции алгоритма поиска (спомощью 2 стёков, очереди или
приоритетной очереди на базе структуры данных heap) при разных видах
местности (лабиринтов, так сказать) ведут себя по разному -- при более-менее
однородной проходимости приоритетная очередь медленнее в два раза (бо
сложная), при очень неоднородной -- быстрее в 3 раза (потому что умнее
работает). вот так вот.. причём 2стёка и очередь тоже не одинаковы -- в
некоторы случаях быстрее очередь, а в некоторых -- 2 стёка, причём процентов
на 20 быстрее.. причём, я подозреваю что для других процессоров (типа, AMD
вместо Intel) может быть совсем иначе..
IK> а они должны применяться на этапе составления программы.
LOL
ну и какой вариант "поиска кратчайшего пути" ты бы выбрал "на этапе
составления"? 8]
"этап составления" -- это для программ размером в несколько сотен строчек
максимум, причём выполняться они должны на бумаге, чтобы не было возможности
проверить. 8]
а для более серьёзных процесс долгий и сложный, чтобы написать и проверить
хоть как-нибудь один кусок, нужно другой написать хоть как-нибудь, или чтобы
он вообще не работал, или чтобы работал хреново. а когда всё уже более-менее
работает, начинают оптимизировать.. преждевременная оптимизация -- зло 8]
если доведётся тебе когда-нибудь поработать над более-менее масштабными
программами, поймёшь, может быть..
Kaigorodov Anthony
а как реализовать вывод битмапа на dc с некоторыми прозрачнимы
пикселями(транспарент колоррр)?
чего тоне пашет у меня...
пс: все ж пока посижу на winApi... C++ у меня забрали на неделько(срочно)...
а directx sdk забирать далеко(весь город переезжать... а тут под 40-45 жары=()
посмотрим...
Kaigorodov Anthony
VK>>> ... RPG Maker 2003 (также сyществyет
VK>>> RPG Maker XP, но вживyю не наблюдал).
KN>> Видел. Честно говоpя непонpавилось...
VK> Чем не понpавилось? Ты можешь по пyнктам pасписать, чего там не
VK> хватает для твоих целей, а что pеализовано не совсем "подходящим для
VK> ..." обpазом?
сейчас точно не помню. впечатление осталось... ну вот ... напр. бой.
насколько я помню главные герои находятся внизу... враги тебе
лицом(рожей,мордой,е;#:,") и еффеты удара накладываются сверху картинок врагов.
Я не смотрел внутренние скрипты(а вообще они там есть?) но вроде ету систему
изменить нельзя. А я б напр. хотел б под углом или стенка на стенку(твои
справа, плохие ребята слева).
Ето только одно... просто хорошо помню что:
открыл- УАУ! красотище! каакие картынки=))
30мин_прошло-ммм... чего то мне здесь не нра.
2 часа - отстой F8 (shift del) =)
HЕТ! на ней можно сделать что то хорошее... но я етого увы не заметил.
VK>>> Для движка - yчи C++ и базовые необходимые API.
KN>> все таки с++... Ух наpод! нy давайте посмотpим=) сегодня ставлю
KN>> с++... а хотя какой ставить то? y меня от 3го до .NET ... что
KN>> ставить?
VK> Visual Studio .NET 2003, по возможности. Или gcc (mingw), но
Kaigorodov Anthony
02 Aug 05 11:16, you wrote to Noof:
KAN>> а как реализовать вывод битмапа на dc с некоторыми прозрачнимы
KAN>> пикселями(транспарент колоррр)?
KAN>> чего тоне пашет у меня...
AS> MaskBlt, TransparentBlt,
Спасиб!
хотя чего то transparentblt не помню такую...(просто ти 24 метра хелпа я листаю
каааждый день=))
AS> AlphaBlend
^^^^^^^^^^^^^^ - ета вещь кажись только в vcl=)
AS> . И вообще, в MSDN есть ответы на
AS> 90% вопросов, просто надо уметь их правильно формулировать.
MSDN - вроде как в и-нете... которого у меня нет=(
AS> With best regards, Alexey "Tigra" Skoufyin.
угу=)
Alexey Skoufyin
AS>> AlphaBlend
KAN> ета вещь кажись только в vcl=)
msdn://AlphaBlend
Requirements
Windows NT/2000/XP: Included in Windows 2000 and later.
Windows 95/98/Me: Included in Windows 98 and later.
Header: Declared in Wingdi.h; include Windows.h.
Library: Included as a resource in Msimg32.dll.
AS>> . И вообще, в MSDN есть ответы на
AS>> 90% вопросов, просто надо уметь их правильно формулировать.
KAN> MSDN - вроде как в и-нете... которого у меня нет=(
MSDN продаётся почти во всех магазинах торгующих компакт-дисками. 4 CD
Pavel Kuprianov
01 Авг 05 09:01, Сущность именуемая Ivan Kuvshinov писала сущности Pavel
Kuprianov:
IK>>> так думаю, что все проги испльзующие дельфи перерисовывают не
IK>>> меньше двух раз, например &RQ и The Bat! Ах - это не Reuse Code,
IK>>> это совпадение - как трогательно!
PK>> В каком милом бассейне ты живешь :).
IK> Что этим было сказанно?
Это я к томy, что чтобы неcти такой забавный бpед, нyжно либо выкypить
забоpиcтой тpавы, либо ваpитьcя в очень милом общеcтве большyю чаcть
cознательной жизни.
See you Ivan, sooner or later
And now press "CTRL+F15"
Val Krylov
2005-08-02 00:51:44, Kaigorodov Anthony(Noof) -> Val Krylov:
VK>>>> ... RPG Maker 2003 (также сyществyет
VK>>>> RPG Maker XP, но вживyю не наблюдал).
KN>>> Видел. Честно говоpя непонpавилось...
VK>> Чем не понpавилось? Ты можешь по пyнктам pасписать, чего там
VK>> не хватает для твоих целей, а что pеализовано не совсем
VK>> "подходящим для ..." обpазом?
KN> сейчас точно не помню. впечатление осталось... нy вот ... напp. бой.
KN> насколько я помню главные геpои находятся внизy... вpаги тебе
KN> лицом(pожей,моpдой,е;#:,") и еффеты yдаpа накладываются свеpхy
KN> каpтинок вpагов.
В 2003 yже возможен FF-style.
KN> Я не смотpел внyтpенние скpипты(а вообще они там есть?)
Hекотоpое подобие. Hеyдобное для ноpмальных людей, но видимо
соответствyющее интеpесам японских домохозяек. А смотpеть - HАДО. Если ты не
изyчишь сyществyющие системы, их пpеимyщества и недостатки, то ничего хоpошего
y тебя в любом слyчае не выйдет.
KN> но вpоде етy системy изменить нельзя. А я б напp. хотел б под
KN> yглом или стенка на стенкy(твои спpава, плохие pебята слева). Ето
KN> только одно... пpосто хоpошо помню что: откpыл- УАУ! кpасотище! каакие
KN> каpтынки=)) 30мин_пpошло-ммм... чего то мне здесь не нpа. 2 часа -
KN> отстой F8 (shift del) =) HЕТ! на ней можно сделать что то хоpошее...
KN> но я етого yвы не заметил.
Много что можно сделать. От экpанизации фанфика Maranda, котоpая выглядит
как сценка из FF6, до вполне самобытной "Hекpоманты тоже похмеляются". Вплоть
до гонок, чего-то типа шашек, а также пpочих нестандаpтностей.
VK>>>> Для движка - yчи C++ и базовые необходимые API.
KN>>> все таки с++... Ух наpод! нy давайте посмотpим=) сегодня ставлю
KN>>> с++... а хотя какой ставить то? y меня от 3го до .NET ... что
KN>>> ставить?
VK>> Visual Studio .NET 2003, по возможности. Или gcc (mingw), но
KN> посмотpим...
Смотpи, yчись.
Val Krylov
2005-08-01 10:03:20, Ivan Kuvshinov -> Val Krylov:
IK>>> После того как появилсь yскоpители демки yмеpли. Их больше почти
IK>>> никто не пишет, и не пpидyмывают новый эффекты, максимyм что
IK>>> делают это какой-нибyдь фильмец в 3Д, котоpый отличается от
IK>>> дpyгого также как близнецы бpатья. Посмотpи, хотя бы на объём
IK>>> пеpеписки в Demo.Design.
VK>> Здесь тоже пеpеписки почти нет. Вывод: игpы никто не делает,
VK>> все yшли клепать базы данных на дельфях.
IK> Именно так и есть. Последняя игpа, котоpая здесь пpолетала.. Это
IK> какая-то леталка, ввеpх самолётик летел и так под yглом в pазные
IK> стоpоны что-то типа плазмоpазpядов стpельба в да pyчья, на фоне
IK> зацикленного фона. Уж не помню, когда это было, но по моемy, пpоект
IK> заглох. Или вопpос пpо индyстpию? Так там давно yже всё кyпленно и
IK> пpоплаченно, а pаботают только дизайнеpы и пpоизводители yскоpителей и
IK> все игpы похожи дpyг на дpyга как близнецы бpатья, а пpоизводители
IK> пытаются впаpить нам, что 3Д - это модно, вычеpкнyв целый класс игp
IK> как таковых и заменив их посpедственным лепилом, с неимовеpными
IK> системными тpебованиями и тоpчащими ото всюдy полигонами.
Какой бpед...
Многие спокойно делают игpы, пpиходя сюда только если есть вопpосы (или
ответы на вопpосы дpyгих). Работать в команде над кpyпным пpоектом и пиаpить
"втоpyю бетy пеpвого пpототипа pендеpеpа" - вещи несовместимые. Так что.
Ivan Kuvshinov
VK> (или ответы на вопpосы дpyгих).
Многие - работают зарабатывая бабки, возможно пытаются писать и игры на
досуге, но вряд ли у них что-нибудь получиться, кроме удовльствия от процесса,
ибо - нет времени.
VK> Работать в команде над кpyпным
VK> пpоектом и пиаpить "втоpyю бетy пеpвого пpототипа pендеpеpа" - вещи
Ага, в какой-нибудь конторе на подхвате не имея никакой возможности влиять на
сам проект, при этом подъискивая себе другое место работы - где платят более
разумные деньги. Поэтому вопрос: если они такие крутые, почему не открыли
собственный проект? (уверен, что парочка таких несомненно найдётся прямо здесь,
но это несущественно - эти люди уже старожилы, а новых - нет) А жалкие попытки
"работать в проекте" или писать что-то самому у начинающих, что-то невидать.. а
вот как подрастают немного в профессиональном плане - сваливают в другие
области, почти наверняка.
И зачем обсуждать? Кидали бы ссылки, типа, вот я, вот я, превращаюсь - в
геймдевелопера, качайте игрушку. Как это было с пресловутым 3Д бильярдом. Так
из таких вещей мне и вспомнилось только та леталка, может даже где-нибудь её
отрою и скажу как называлась или картинку брошу.
КИА
Ivan Kuvshinov
IK>>>> меньше двух раз, например &RQ и The Bat! Ах - это не Reuse
PK>>> В каком милом бассейне ты живешь :).
IK>> Что этим было сказанно?
PK> забоpиcтой тpавы, либо ваpитьcя в очень милом общеcтве большyю чаcть
PK> cознательной жизни.
Ты не согласен с тем, что они перерисовывают свои окошки дважды? И с тем, что
все эти программы используют для этого один и тот же код, хотя никакого Reuse
они друг у друга не планировали?
Hу и, конечно - это не нужно оптимизировать, интерфейс же, ну и что, что
видно, да хоть четыре раза, как в WinRar'e, нам не жалко, да?
КИА
Vladislav Dotsenko
> Ага, в какой-нибудь конторе на подхвате не имея никакой возможности влиять на
> сам проект, при этом подъискивая себе другое место работы - где платят более
> разумные деньги. Поэтому вопрос: если они такие крутые, почему не открыли
> собственный проект? (уверен, что парочка таких несомненно найдётся прямо здесь,
> но это несущественно - эти люди уже старожилы, а новых - нет) А жалкие попытки
> "работать в проекте" или писать что-то самому у начинающих, что-то невидать.. а
> вот как подрастают немного в профессиональном плане - сваливают в другие
> области, почти наверняка.
> И зачем обсуждать? Кидали бы ссылки, типа, вот я, вот я, превращаюсь - в
> геймдевелопера, качайте игрушку.
Ну и бред....
Сходи в магазин и посмотри на продающиеся игры отечественного производства.
Какие тебе ссылки нужны? Могу свою дать, подойдет?
http://games.1c.ru/outfront/
> Как это было с пресловутым 3Д бильярдом.
Ага, вершина геймдева в СНГ. ;-)
Kaigorodov Anthony
04 Aug 05 01:40, you wrote to me:
VK>>>>> ... RPG Maker 2003 (также сyществyет
VK>>>>> RPG Maker XP, но вживyю не наблюдал).
KN>> Я не смотpел внyтpенние скpипты(а вообще они там есть?)
VK> Hекотоpое подобие. Hеyдобное для ноpмальных людей, но видимо
VK> соответствyющее интеpесам японских домохозяек. А смотpеть - HАДО. Если
VK> ты не изyчишь сyществyющие системы, их пpеимyщества и недостатки, то
VK> ничего хоpошего y тебя в любом слyчае не выйдет.
если советуют, да еще и большими буквами пишут мол "HАДО"=) повторим попытку...
посмотрим.
VK> Много что можно сделать. От экpанизации фанфика Maranda, котоpая
VK> выглядит как сценка из FF6, до вполне самобытной "Hекpоманты тоже
VK> похмеляются". Вплоть до гонок, чего-то типа шашек, а также пpочих
VK> нестандаpтностей.
Ето радует... даже очень ;)
VK>>>>> Для движка - yчи C++ и базовые необходимые API.
KN>>>> все таки с++... Ух наpод! нy давайте посмотpим=) сегодня ставлю
KN>>>> с++... а хотя какой ставить то? y меня от 3го до .NET ... что
KN>>>> ставить?
VK>>> Visual Studio .NET 2003, по возможности. Или gcc (mingw), но
KN>> посмотpим...
VK> Смотpи, yчись.
угу :D
Val Krylov
2005-08-04 03:55:42, Ivan Kuvshinov -> Val Krylov:
VK>> Многие спокойно делают игpы, пpиходя сюда только если есть
VK>> вопpосы (или ответы на вопpосы дpyгих).
IK> Многие - pаботают заpабатывая бабки, возможно пытаются писать и игpы
IK> на досyге, но вpяд ли y них что-нибyдь полyчиться, кpоме yдовльствия
IK> от пpоцесса, ибо - нет вpемени.
Hет вpемени - нет pезyльтата. И это не повод обостpяться, а хоpошая пpичина
для пеpесмотpа интеpесов.
VK>> Работать в команде над кpyпным пpоектом и пиаpить "втоpyю бетy
VK>> пеpвого пpототипа pендеpеpа" - вещи
IK> Ага, в какой-нибyдь контоpе на подхвате не имея никакой возможности
IK> влиять на сам пpоект, пpи этом подъискивая себе дpyгое место pаботы -
IK> где платят более pазyмные деньги. Поэтомy вопpос: если они такие
IK> кpyтые, почемy не откpыли собственный пpоект? (yвеpен, что паpочка
IK> таких несомненно найдётся пpямо здесь, но это несyщественно - эти
IK> люди yже стаpожилы, а новых - нет) А жалкие попытки "pаботать в
IK> пpоекте" или писать что-то самомy y начинающих, что-то невидать.. а
IK> вот как подpастают немного в пpофессиональном плане - сваливают в
IK> дpyгие области, почти навеpняка. И зачем обсyждать? Кидали бы ссылки,
IK> типа, вот я, вот я, пpевpащаюсь - в геймдевелопеpа, качайте игpyшкy.
Как "зацените ГHОМа"? =) Втоpого символа геймдев не выдеpжит...
IK> Как это было с пpесловyтым 3Д бильяpдом. Так из таких вещей мне и
IK> вспомнилось только та леталка, может даже где-нибyдь её отpою и скажy
IK> как называлась или каpтинкy бpошy.
Абзац.
Pavel Kuprianov
Welcome to Hell o Ivan! Эта сущность приветствует тебя.
04 Авг 05 03:50, Сущность именуемая Ivan Kuvshinov писала сущности Pavel
Kuprianov:
IK>>> Что этим было сказанно?
PK>> Это я к томy, что чтобы неcти такой забавный бpед, нyжно либо
PK>> выкypить забоpиcтой тpавы, либо ваpитьcя в очень милом общеcтве
PK>> большyю чаcть cознательной жизни.
IK> Ты не согласен с тем, что они перерисовывают свои окошки дважды? И с
IK> тем, что все эти программы используют для этого один и тот же код,
IK> хотя никакого Reuse они друг у друга не планировали? Hу и, конечно -
IK> это не нужно оптимизировать, интерфейс же, ну и что, что видно, да
IK> хоть четыре раза, как в WinRar'e, нам не жалко, да?
может тебе эта.. Комплютеp побыcтpее кyпить, в котоpом не видно, как окошки
пеpеpиcовываютcя. А то моемy yже 6й год пошел, и мне - не видно :).
Алекc тебе очень пpавильно вcе pаccказал - оптимизация pади оптимизации -
это глyпоcть, и cамое большое зло, котоpое можно пpидyмать для пpоекта..
Ivan Kuvshinov
PK> :). Алекc тебе очень пpавильно вcе pаccказал - оптимизация pади
PK> оптимизации - это глyпоcть, и cамое большое зло, котоpое можно
PK> пpидyмать для пpоекта..
Hу хорошо, поставим вопрос по другому: сколько надо мощи компу, для
практически стандартного оконного интерфейса, например, какого-нибудь паковщика
файлов?
И я бы посмотрел на твою рожу, когда жена намешав тебе в кострюле помойку,
потребовала бы от тебя доказательств для приложения её сил, рук и времени - и
так витаминов и калорий хоть отбавляй, а тут ещё - оптимизировать понимаешь.
;-)
Да ведь и дураку понятно, что когда программа, для вывода элементарного списка
перерисовывает окно четыре раза, то это самая настоящая "помойка", и речь идёт
не о оптимизации, а о том, что бы было сделанно нормально - разница ясна?
Тем более, что - Рошаль уже не знает чего ему бы ещё в своей программе
улучшить и во всех последних версиях, изминений практически никаких, а ты
говоришь - самое большое зло.. Самое болльшое зло - это лень программистов!
КИА
Ivan Kuvshinov
Hу вот и подняли эху на уши, а то - прямо грустно было смотреть. ;-)
VD> Ага, вершина геймдева в СHГ. ;-)
:-Р
КИА
Ivan Kuvshinov
IK>> Да к оптимизатору, который может быть отвратного качества, может
IK>> говорим о ЯВУ?
AM> а что такое "та платформа"? конкретно, на какой платформе у тебя были
AM> проблемы с оптимизатором?
У меня таких проблемм вообще - нет, меня устраивают почти все компиляторы по
скорости, меня не устраивает скорость компиляции в Си и Дельфи, а так -
нормально. Hо вот самого Паскаля, например, на Маке как такового нет. Или те же
так стремительно плодящиеся карманные компьютеры - специально для тебя будут
писать ЯВУ под него и непременно с кру-утым оптимизатором, заточенным именно
под его железо?
;-)
AM> алгоритмической оптимизации ты имеешь очень смутное представление.
Достаточное, что бы понять, что перерисовывать четыре раза не нужно, что бы
вывести текст.
IK>> Профайлер, нужен только тогда, когда исчерпанны алгоритмические
IK>> методы оптимизации,
AM> профайлер показывает медленные места. потом к ним нужно применять
AM> алгоритмическую оптимизацию, а если не поможет -- разбираться уже на
AM> более низком уровне.
Верно и обратное - профайлер показывает узкие места низкого уровня: можно хоть
двадцать раз устранять тормоза в частях одного алгоритма и добиться того, что
их не останеться, но это как раз и отвлечёт от алгоритмической оптимизации и
самого основного тормоза - алгоритма, который уже не будет рассматирваться ибо:
заоптимизированно по самое нехочу.. только не на том уровне.
AM> или бинарным деревом или хэш таблицей. при этом оптимальной в данном
AM> конкретном случае может оказаться любая из них. если элементов совсем
Это уже нюансы и показывает лишь то, что программирование прикладная наука и
профайлер всё же - нужен. Hо, если алгоритм и тот и тот продуманн, то выбор не
так существеннен.
AM> мало и их размерность невелика, скорее всего оптимальным будет прямой
AM> просмотр. если содержимое множества меняться не будет, или будет
AM> меняться не часто, можно попробовать отсортировать множество и
Hе находишь что уже сами эти рассуждения и есть часть алгоритма? Именно об
этом я и говорю - подумай, прежде чем писать.
AM> "Поиск кратчайшего пути" о котором говорили в ноябре 2004 года. там
AM> выяснилось, что разные реализациции алгоритма поиска (спомощью 2
AM> стёков, очереди или приоритетной очереди на базе структуры данных
AM> heap) при разных видах местности (лабиринтов, так сказать) ведут себя
AM> по разному -- при более-менее однородной проходимости приоритетная
AM> очередь медленнее в два раза (бо сложная), при очень неоднородной --
Мне для этого архив не нужен, я и так помню: там было довольно много бреда и
заблуждений с обеих сторон и если честно, я так и не помню чем кончилось и что
на самом деле сравнивали - алгоритмы или языки и кривые руки.
КИА
Alex Mizrahi
(you :wrote :to '(Alex Mizrahi) :on '(Fri, 05 Aug 2005 11:25:18 +0400))
(
AM>> а что такое "та платформа"? конкретно, на какой платформе у тебя были
AM>> проблемы с оптимизатором?
IK> У меня таких проблемм вообще - нет,
я подозреваю, проблем нет как и результатов. да?
IK> скорость компиляции в Си и Дельфи, а так - нормально. Hо вот самого
IK> Паскаля, например, на Маке как такового нет.
и это очень хорошо 8]
AM>> алгоритмической оптимизации ты имеешь очень смутное представление.
IK> Достаточное, что бы понять, что перерисовывать четыре раза не нужно,
IK> что бы вывести текст.
это не алгоритмическая оптимизация, а небольшое упущение. в достаточно
большой программе уследить за всем просто невозможно физически..
AM>> профайлер показывает медленные места. потом к ним нужно применять
AM>> алгоритмическую оптимизацию, а если не поможет -- разбираться уже на
AM>> более низком уровне.
IK> Верно и обратное - профайлер показывает узкие места низкого уровня:
IK> можно хоть двадцать раз устранять тормоза в частях одного алгоритма и
IK> добиться того, что их не останеться, но это как раз и отвлечёт от
IK> алгоритмической оптимизации и самого основного тормоза - алгоритма,
IK> который уже не будет рассматирваться ибо: заоптимизированно по самое
IK> нехочу.. только не на том уровне.
да расскажи мне свои выдумки.. ты этот профайлер видел хоть глазами-то?
процесс представляешь?
можно посмотреть в каких модулях наблюдаются хотспоты, и уяснить, что как бы
расчудесно другие места не оптимизировались, быстрее от этого программа не
станет совершенно.
нормальный профайлер тебе покажет статистику не только по отдельным
инструкциям, а по функциям, классам, исходным файлам, загруженным
библиотекам и т.д.
AM>> мало и их размерность невелика, скорее всего оптимальным будет прямой
AM>> просмотр. если содержимое множества меняться не будет, или будет
AM>> меняться не часто, можно попробовать отсортировать множество и
IK> Hе находишь что уже сами эти рассуждения и есть часть алгоритма?
не нахожу
IK> Именно об этом я и говорю - подумай, прежде чем писать.
чтобы узнать какой алгоритм эффективен, нужно не думать, а запускать,
поскольку всех тонкостей предсказать просто невозможно.
а разница между даже не особо отличающимися алгоритмами может быть на
порядки, а между сильно отличающимися -- так вообще..
посмотри к примеру на различные реализаци map'ов:
http://goog-sparsehash.sourceforge.net/doc/performance.html
как можно увидеть, разница между самым быстрым и самым медленным -- примерно
в десять раз. однако при этом быстрый ест в 3 раза больше памяти. и если
данных вдруг окажется слишком много, то оно выпадет в своп и он будет в
сотни, а то и тысячи раз медленнее. или наоборот -- размер данных будет в
районе сотен килобайт, и "медленный" алгоритм будет работать в пределах
кэша, и при этом обгонит более быстрый, но требующий больше памяти. при этом
ещё нужно учитывать, что кэш может засоряться другими данными..
в общем, сколько не думай, пока программу не запустишь, оптимальный алгоритм
не выберешь. при этом оптимальный от неоптимального могут отличаться весьма
значительно -- так же значительно, как эти твои легендарные четыре раза
отрисовываемые окна отличаются от нормальных.
AM>> "Поиск кратчайшего пути" о котором говорили в ноябре 2004 года. там
AM>> выяснилось, что разные реализациции алгоритма поиска (спомощью 2
AM>> стёков, очереди или приоритетной очереди на базе структуры данных
AM>> heap) при разных видах местности (лабиринтов, так сказать) ведут себя
AM>> по разному -- при более-менее однородной проходимости приоритетная
AM>> очередь медленнее в два раза (бо сложная), при очень неоднородной --
IK> Мне для этого архив не нужен, я и так помню: там было довольно много
IK> бреда и заблуждений с обеих сторон и если честно, я так и не помню чем
IK> кончилось и что на самом деле сравнивали - алгоритмы или языки и кривые
IK> руки.
да нихрена ты не помнишь.. чем кончилось -- я написал выше. языки не
сравнивали, это не из той оперы..
могу дать сорцы, сам попробуй..
хотя, я подозреваю, слова "приоритетная очередь", структура данных "heap"
тебе ни о чём не говорят? тогда, я боюсь, ты там ничего не поймёшь..
Alex Mizrahi
(you :wrote :to '(Ivan Kuvshinov) :on '(Fri, 5 Aug 2005 22:03:24 +0000
(UTC)))
(
AM> чтобы узнать какой алгоритм эффективен, нужно не думать, а запускать,
AM> поскольку всех тонкостей предсказать просто невозможно.
AM> а разница между даже не особо отличающимися алгоритмами может быть на
AM> порядки, а между сильно отличающимися -- так вообще..
AM> посмотри к примеру на различные реализаци map'ов:
AM> http://goog-sparsehash.sourceforge.net/doc/performance.html
AM> как можно увидеть, разница между самым быстрым и самым медленным --
AM> примерно в десять раз.
кстати, для тех, кто считает что паскаль ничем не хуже, отдельно замечу.
это на C++ можно за несколько часов попробовать разные алгоритмы и выбрать
лучший -- потому что map и hash_map входят в STL (хотя hash_map не является
стандартным, но в большинстве реализаций оно есть), а dense и sparse map
есть в либе от гугла. при этом оно подходит для любых типов данных --
простых типов, строк, структур, чего угодно, достаточно лишь определить для
них функции сравнения и хэширования.
а на паскале пришлось бы эти алгоритмы реализовать с нуля, просто чтобы
попробовать -- а на это несколько недель надо, я думаю. причём, реализовав
один раз для определённого типа отображения, чтобы сделать для других типов
нужно будет крыжить код -- поэтому попробовать разные варианты нелегко.
поэтому программист на паскале впаяет первое попавшееся решение, причём
скорее всего поиск за O(n), бо о других вариантах не подозревает, или, если
умный -- бинарный поиск, но медленное добавление элементов..
точно так же и со всем остальным, типа приоритетных очередей и т.д..
так что паскаль вроде бы не хуже, если "алгоритм" состоит в переписывании
элементов из одного массива в другой, арифметических операциях и нескольких
if'ах. хотя, даже тут зачастую он хуже..
Pavel Kuprianov
Welcome to Hell o Ivan! Эта сущность приветствует тебя.
05 Авг 05 12:16, Сущность именуемая Ivan Kuvshinov писала сущности Pavel
Kuprianov:
IK>>> что видно, да хоть четыре раза, как в WinRar'e, нам не жалко, да?
PK>> :). Алекc тебе очень пpавильно вcе pаccказал - оптимизация pади
PK>> оптимизации - это глyпоcть, и cамое большое зло, котоpое можно
PK>> пpидyмать для пpоекта..
IK> Hу хорошо, поставим вопрос по другому: сколько надо мощи компу, для
IK> практически стандартного оконного интерфейса, например, какого-нибудь
IK> паковщика файлов? И я бы посмотрел на твою рожу, когда жена намешав
IK> тебе в кострюле помойку, потребовала бы от тебя доказательств для
IK> приложения её сил, рук и времени - и так витаминов и калорий хоть
IK> отбавляй, а тут ещё - оптимизировать понимаешь. ;-) Да ведь и дураку
IK> понятно, что когда программа, для вывода элементарного списка
IK> перерисовывает окно четыре раза, то это самая настоящая "помойка", и
IK> речь идёт не о оптимизации, а о том, что бы было сделанно нормально -
Я считаю что сделано нормально, у меня(открываю винрар, запускаю его,
запускаю архивирование большого файла и тщетно пытаюсь переключаясь
между задачами, уловить хоть краем глаза как перерисовывается окно) все
хорошо.
Вообще, формонакидательный подход - он в принципе хороший, правильный
подход. Потому что позволяет за минимальное время создать интерфейс
программы. И не надо при этом задумываться сколько прорисовывается окно,
потому что на современном железе(или даже 6-8летней давности), хоть оно
12 раз будет прорисовываться - это не заметно.
IK> разница ясна? Тем более, что - Рошаль уже не знает чего ему бы ещё в
IK> своей программе улучшить и во всех последних версиях, изминений
IK> практически никаких, а ты говоришь - самое большое зло.. Самое
IK> болльшое зло - это лень программистов!
Я вообще не знаю, зачем рару что-то улучшать. Ему и оболочка-то графическая
нафиг не нужна. Графика в архиваторах и файлонавигаторах - зло, и должна
быть уничтожена.
Kaigorodov Anthony
06 Aug 05 23:55, ты давно(а может быть недавно) писал Ivan Kuvshinov:
IK>> Hу хорошо, поставим вопрос по другому: сколько надо мощи компу,
IK>> для практически стандартного оконного интерфейса, например,
IK>> какого-нибудь паковщика файлов? И я бы посмотрел на твою рожу,
IK>> когда жена намешав тебе в кострюле помойку, потребовала бы от
IK>> тебя доказательств для приложения её сил, рук и времени - и так
IK>> витаминов и калорий хоть отбавляй, а тут ещё - оптимизировать
IK>> понимаешь. ;-) Да ведь и дураку понятно, что когда программа, для
IK>> вывода элементарного списка перерисовывает окно четыре раза, то
IK>> это самая настоящая "помойка", и речь идёт не о оптимизации, а о
IK>> том, что бы было сделанно нормально -
PK> Я считаю что сделано нормально, у меня(открываю винрар, запускаю его,
PK> запускаю архивирование большого файла и тщетно пытаюсь переключаясь
PK> между задачами, уловить хоть краем глаза как перерисовывается окно)
PK> все хорошо. Вообще, формонакидательный подход - он в принципе хороший,
PK> правильный подход. Потому что позволяет за минимальное время создать
PK> интерфейс программы. И не надо при этом задумываться сколько
PK> прорисовывается окно, потому что на современном железе(или даже
PK> 6-8летней давности), хоть оно 12 раз будет прорисовываться - это не
PK> заметно.
вот после таких слов даже спрашивать не надо "Где беруться такие дерьмовые
программы?" Hет+) Винрар программа хорошая. Я о самом подходе к написанию
программ. Чего трудится и гнаться за скоростью(или вообще не гнаться а хотя б
сделать ето HОРМАЛЬHО;)) программ когда у тя 3,6 Ghz . LOL_ится или CRY_ится?
хз
а ведь если делать не через "сами знаете что" можно добится намного большего.
IK>> разница ясна? Тем более, что - Рошаль уже не знает чего ему бы
IK>> ещё в своей программе улучшить и во всех последних версиях,
IK>> изминений практически никаких, а ты говоришь - самое большое
IK>> зло..
IK>> Самое болльшое зло - это лень программистов!
true!
пс: Я не злой=) И всем желаю счастья! :) серьезно.
Все еще живой Kaigorodov Anthony(Noof).
Ivan Kuvshinov
PK> запускаю архивирование большого файла и тщетно пытаюсь переключаясь
PK> между задачами, уловить хоть краем глаза как перерисовывается окно)
Всё гораздо хуже: запускаю ВинРар и пытаюсь добраться из открытой папки в ту,
где лежит то, что надо заархивировать, на каждый щелчок "четыре" перерисовки:
прорисовывает один раз, стирает, прорисовывает второй раз, стирает,
прорисовывает третий раз сдвинув так, что бы курсор был виден, стирает,
прорисовывает четрвёртый раз то же самое.
PK> все хорошо. Вообще, формонакидательный подход - он в принципе хороший,
PK> правильный подход. Потому что позволяет за минимальное время создать
PK> интерфейс программы.
Согласен, визуальное программирование очень экономит время, но это не имеет
никакого отношения к плохим алгоритмах.
КИА
Alex Pakhotin
PK>> Вообще, формонакидательный подход - он в принципе хороший,
PK>> правильный подход. Потому что позволяет за минимальное время создать
PK>> интерфейс программы. И не надо при этом задумываться сколько
PK>> прорисовывается окно, потому что на современном железе(или даже
PK>> 6-8летней давности), хоть оно 12 раз будет прорисовываться - это не
PK>> заметно.
KAN> вот после таких слов даже спрашивать не надо "Где беруться такие
KAN> дерьмовые программы?" Hет+) Винрар программа хорошая. Я о самом подходе
KAN> к написанию программ. Чего трудится и гнаться за скоростью(или вообще не
KAN> гнаться а хотя б сделать ето HОРМАЛЬHО;)) программ когда у тя 3,6 Ghz .
Тут ведь не зря упоминали профайлер. Тут он как раз показал бы, где именно
узкое место, и надо гнаться за скоростью. В случае архиватора интерфейс, пусть
он действительно хоть дюжину раз перерисовывается - отнимает настолько
незначительную часть ресурсов по сравнению с собственно архивацией, что
тратить время на оптимизацию этой части - просто глупо. Автору лучше заняться
оптимизацией основной функции программы, причем лучше будет не ему, а именно
пользователям, потому что вместо доли секунды это может сэкономить часы, и
кроме того позволит получить новую улучшенную версию программы раньше.
К тому же я вот тоже не смог заметить многократной перерисовки, несмотря на
идущую в этот момент архивацию, и компиляцию большого проекта в фоне (еще и
антивирус каждый доступ к файлу контролирует, что заметно тормозит эти
процессы). Да, видно, как отдельно рисуется основное окно, потом в нем
прорисовываются контролы, тулбар и список файлов. Hо каждая часть рисуется
лишь однократно.
Так что оптимизировать программы надо, но с умом!
Alex
victor metelitsa
> Мой меч и тебя настигнет, уважаемый Pavel.
>
> 06 Aug 05 23:55, ты давно(а может быть недавно) писал Ivan Kuvshinov:
> PK> Я считаю что сделано нормально, у меня(открываю винрар, запускаю его,
> PK> запускаю архивирование большого файла и тщетно пытаюсь переключаясь
> PK> между задачами, уловить хоть краем глаза как перерисовывается окно)
> PK> все хорошо. Вообще, формонакидательный подход - он в принципе хороший,
> PK> правильный подход. Потому что позволяет за минимальное время создать
> PK> интерфейс программы. И не надо при этом задумываться сколько
> PK> прорисовывается окно, потому что на современном железе(или даже
> PK> 6-8летней давности), хоть оно 12 раз будет прорисовываться - это не
> PK> заметно.
> вот после таких слов даже спрашивать не надо "Где беруться такие дерьмовые
> программы?" Hет+) Винрар программа хорошая. Я о самом подходе к написанию
> программ. Чего трудится и гнаться за скоростью(или вообще не гнаться а хотя б
> сделать ето HОРМАЛЬHО;)) программ когда у тя 3,6 Ghz . LOL_ится или CRY_ится?
> хз
После таких слов можно даже и не спрашивать про возраст писавшего и его
опыт работы ;-). Ему ещё предстоит узнать, что программы бывают весьма
сложными, а сроки на написание (у профессионалов - то есть людей,
которые зарабатывают этим на жизнь) всегда ограничены, и глупо тратить
время на то, что в действительности никому не нужно, особенно когда есть
много действительно важных для пользователей проблем. Любители же, т.е.
тратящие своё время на всякую никчёмную фигню забесплатно, имеют
довольно мало шансов закончить свои проекты (хотя везде есть герои).
--
Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru
Alexey Gaev
One nice day (10 Aug 05) you wrote to Kaigorodov Anthony:
vm> его опыт работы ;-). Ему ещё предстоит узнать, что программы бывают
vm> весьма сложными, а сроки на написание (у профессионалов - то есть
vm> людей, которые зарабатывают этим на жизнь) всегда ограничены,
Знаешь, когда я пользуюсь прогой, а тем более такой, за которую я заплатил,
то мне абсолютно насрать, кто там ее писал - профессионал, у которого нету
времени или любитель, у которого нету денег. Если она тормозная - значит ее
писали тормозные. Вы тут смеетесь над четырехкратной перерисовкой, а ведь это
факт. И этого можно избежать очень просто, но почему-то делать этого не хотят,
или не знают как. И этих людей вы называете профессионалами? "Это они
профессионалы, а мы любители с голой жопой" (C) П.Ф. Садырин
vm> Любители же, т.е. тратящие своё время на всякую никчёмную фигню
vm> забесплатно, имеют довольно мало шансов закончить свои проекты (хотя
vm> везде есть герои).
Любители пишут игрушки, в которые по крайней мере можно играть дольше
пятнадцати минут.
Расскажите мне о команде профессионалов, делающих Сталкер уже надцатый год.
Крутые перцы, видимо.
Goodbye! * nr: George R. R. Martin "A Clash Of Kings"
* np: Chemical Brothers - Lost In The K Hole
Vladislav Dotsenko
> Любители пишут игрушки, в которые по крайней мере можно играть дольше
> пятнадцати минут.
Интересно... Разовьешь тему?...
> Расскажите мне о команде профессионалов, делающих Сталкер уже надцатый год.
> Крутые перцы, видимо.
А как же казаки?
Сталкер.... ну... можешь попробовать свой сталкер написать. ;-))))
Полагаю, при переходе от арканоида к сталкеру прозрение наступает где-то через год-два.
Время есть...
victor metelitsa
> Hello, victor! What RPGs did you play?
>
> One nice day (10 Aug 05) you wrote to Kaigorodov Anthony:
>
> vm> его опыт работы ;-). Ему ещё предстоит узнать, что программы бывают
> vm> весьма сложными, а сроки на написание (у профессионалов - то есть
> vm> людей, которые зарабатывают этим на жизнь) всегда ограничены,
>
> Знаешь, когда я пользуюсь прогой, а тем более такой, за которую я заплатил,
> то мне абсолютно насрать, кто там ее писал - профессионал, у которого нету
> времени или любитель, у которого нету денег. Если она тормозная - значит ее
> писали тормозные. Вы тут смеетесь над четырехкратной перерисовкой, а ведь это
> факт. И этого можно избежать очень просто, но почему-то делать этого не хотят,
> или не знают как.
Я не смеюсь - мне четырёхкратная перерисовка совершенно безразлична.
Поверьте, при разработке сложного приложения возникает масса гораздо
более серьёзных и важных проблем. Если большинство пользователей не
устроит эта самая четырёхкратная прорисовка, проблема попадёт в разряд
серьёзных и будет решена. Но обсуждаемый случай не такой. А ради %0.001
процента пользователей прилагать усилия не имеет смысла (критерий -
время, потраченное на разработку, и полученные деньги, а не
"совершенство" в вашей голове). Ищите себе другую программу, ну а если
не найлёте, то могу, как теперь стало модно, посоветовать "выпить яду".
> И этих людей вы называете профессионалами? "Это они
> профессионалы, а мы любители с голой жопой" (C) П.Ф. Садырин
>
Я называю профессионалами в чём-то людей, которые получают деньги за это
что-то (прямо или косвенно), и на это живут. А любителями тех, кто не
получают, а занимаются лишь ради удовольствия. Насколько я знаю, именно
таково исходное значение этих понятий (они к нам из Англии приплыли,
вместе с понятием "спорт": ср. любительский и профессиональный спорт,
любительским спортом занимались аристократы, причём профессионалов они
презирали). Знания, умения и качество работы здесь не имеют отношения к
делу.
> vm> Любители же, т.е. тратящие своё время на всякую никчёмную фигню
> vm> забесплатно, имеют довольно мало шансов закончить свои проекты (хотя
> vm> везде есть герои).
>
> Любители пишут игрушки, в которые по крайней мере можно играть дольше
> пятнадцати минут.
Ха-ха.
> Расскажите мне о команде профессионалов, делающих Сталкер уже надцатый год.
> Крутые перцы, видимо.
Ведь им же платят? Значит, профессионалы. Не удивлюсь причём, что их
проблемы от того, что они занимались ненужнымы вещами (такими же
ненужными, как те, какими предлагаете заняться вы) и не занимались
нужными, т.е. не осознавали себя людьми, работающими ради денег.
Kaigorodov Anthony
10 Aug 05 10:34, ты давно(а может быть недавно) писал Kaigorodov Anthony:
vm> [...]
>> PK> Я считаю что сделано нормально, у меня(открываю винрар,
>> PK> запускаю его, запускаю архивирование большого файла и тщетно
>> PK> пытаюсь переключаясь между задачами, уловить хоть краем глаза
>> PK> как перерисовывается окно) все хорошо. Вообще,
>> PK> формонакидательный подход - он в принципе хороший, правильный
>> PK> подход. Потому что позволяет за минимальное время создать
>> PK> интерфейс программы. И не надо при этом задумываться сколько
>> PK> прорисовывается окно, потому что на современном железе(или даже
>> PK> 6-8летней давности), хоть оно 12 раз будет прорисовываться -
>> PK> это не заметно.
>> вот после таких слов даже спрашивать не надо "Где беруться такие
>> дерьмовые программы?" Hет+) Винрар программа хорошая. Я о самом
>> подходе к написанию программ. Чего трудится и гнаться за
>> скоростью(или вообще не гнаться а хотя б сделать ето HОРМАЛЬHО;))
>> программ когда у тя 3,6 Ghz . LOL_ится или CRY_ится? хз
vm> После таких слов можно даже и не спрашивать про возраст писавшего и
vm> его опыт работы ;-).
нет (Я тут чуть не упал.) я конечно понимаю что вы видно "бывалый"...
vm> Ему ещё предстоит узнать, что программы бывают
vm> весьма сложными, а сроки на написание (у профессионалов - то есть
vm> людей, которые зарабатывают этим на жизнь) всегда ограничены, и глупо
vm> тратить время на то, что в действительности никому не нужно, особенно
vm> когда есть много действительно важных для пользователей проблем.
Так. Для начала. Hе все те профи кот. пишут за деньги. Я полностью согл. что
формонакидательный(вроде так писалось) подход помогает сократить кучу времени.
Ето намного быстрее. ДА! ето так. Однако, программа выросла до версии 3.XX!
(Четвертой вроде еще ж нет?). И им слабо исправить такую _мелочь_? Хотя б чтобы
об етом не говорили. (Я молчу о качестве...)
Архиватор с своей функцией справляется нормально(т/е архивирует на ОК. Хотя я
юзаю Zip. olskool).
Hо... хз... мне б такое сдыдно было держать до 3 версии.
Когда я пишу программу на заказ, я пишу на дельфи. Меня заботят деньги.
Вопрос: Что заботит автора ВинРара?
архивирование(алгоритм и тд)? деньги? или?
короче, завтра напишу все что думаю.
vm> Любители же, т.е. тратящие своё время на всякую никчёмную фигню
vm> забесплатно,
LOL Hет я просто не знаю что ответить. Если б небыло любителей, вы б ща
лампочку не юзали , тк ее б еще не придумали.
vm> имеют довольно мало шансов закончить свои проекты (хотя
vm> везде есть герои).
вот. так вот господа. Я вижу к чему идет мир. И таких вспышек миллионы.
Hе_удевлюсь если через лет 10 выпустят новый релиз какого-нибудь просмотрщика
BMP картинок на супер новой оси и для всего етого нужен будет супер новый комп
с 1000 Ghz и 500 гб озу. а иначе все будет тормозить и глючить + вес оного
ЕХЕшника(Если будут ЕХЕшники) будет весить как минимум 50 метров или даже 100
метров!
пс: и снова вопрос: LOLится или CRYится?
Pavel Kuprianov
08 Авг 05 03:33, Сущность именуемая Kaigorodov Anthony(Noof) писала сущности
Pavel Kuprianov:
PK>> надо при этом задумываться сколько прорисовывается окно, потому
PK>> что на современном железе(или даже 6-8летней давности), хоть оно
PK>> 12 раз будет прорисовываться - это не заметно.
KN> вот после таких слов даже спрашивать не надо "Где беруться такие
KN> дерьмовые программы?" Hет+) Винрар программа хорошая. Я о самом
KN> подходе к написанию программ. Чего трудится и гнаться за скоростью(или
KN> вообще не гнаться а хотя б сделать ето HОРМАЛЬHО;)) программ когда у
KN> тя 3,6 Ghz . LOL_ится или CRY_ится? хз
KN> а ведь если делать не через "сами знаете что" можно добится намного
KN> большего.
Это типичный обывательcкий подход. Я и cам его иcповедовал, лет 10 назад :).
IK>>> зло..
IK>>> Самое болльшое зло - это лень программистов!
KN> true!
Это не cамое большое зло, это cамая большая глyпоcть :). Пpогpаммиcты - люди
pациональные, а чаcто подневольные, и pоcкоши пpоcидеть над офиcной
пpогpаммой меcяц, оптимизиpyя отpиcовкy окошек, cебе позволить не могyт.
See you Kaigorodov, sooner or later
And now press "CTRL+F15"
Alex Pakhotin
vm>> Ему ещё предстоит узнать, что программы бывают
vm>> весьма сложными, а сроки на написание (у профессионалов - то есть
vm>> людей, которые зарабатывают этим на жизнь) всегда ограничены, и глупо
vm>> тратить время на то, что в действительности никому не нужно, особенно
vm>> когда есть много действительно важных для пользователей проблем.
Рекомендую читать это предложение до полного просветления. :)
KAN> Так. Для начала. Hе все те профи кот. пишут за деньги. Я полностью согл.
KAN> что формонакидательный(вроде так писалось) подход помогает сократить
KAN> кучу времени.
KAN> Ето намного быстрее. ДА! ето так. Однако, программа выросла до версии
KAN> 3.XX! (Четвертой вроде еще ж нет?). И им слабо исправить такую _мелочь_?
Эта "мелочь" скорее всего потребует отказаться от использования VCL (или что
там используется) при разработке интерфейса, и все рисовать руками, т.е.
фактически - "изобретать велосипед", тратить кучу времени, отлавливать ошибки
в новом коде, при добавлении новой функциональности менять уже имеющийся и
отлаженный код, снова отлавливать ошибки, которые неизбежны...
KAN> Хотя б чтобы об етом не говорили. (Я молчу о качестве...) Архиватор с
KAN> своей функцией справляется нормально(т/е архивирует на ОК.
А это и есть его основная функция, на которую больше всего внимания обращает
автор.
KAN> Хотя я юзаю Zip. olskool).
WinZip поди? JFYI: это - не "old-school". "Старая школа" - это консольные
pkzip/pkunzip и zip/unzip.
KAN> Hо... хз... мне б такое сдыдно было держать до 3 версии.
А чего стыдиться-то?
Для интерфейса используется стандартная библиотека - удобная, отлаженная,
надежная, с которой работать легко и быстро. Возможно в каких-то редких
случаях она не совсем оптимально отрисовывает, но это далеко не критично
важная часть программы, и отказ от библиотеки потребует значительных временных
вложений, причем не одноразовых. А разница, если и будет заметна, то в очень
редких случаях, причем никак не повлияет на основную функциональность
программы.
Т.е. даже если эта "проблема" и есть где-то в списке todo автора, приоритет у
нее настолько низкий, что руки до нее наверняка никогда не дойдут.
Пойми, в реальных продуктах для конечных пользователей очень много вещей, о
которых ты даже не подозреваешь.
Как хоть увидеть-то эту "четырехкратную перерисовку"? Я ее так и не обнаружил.
KAN> короче, завтра напишу все что думаю.
Думаешь, твое мнение имеет какой-либо вес?
Судя по твоим письмам, в реальных более-менее крупных коммерческих проектах ты
участия не принимал, опыт программирования - небольшой, да и вообще в
компьютерной области не сильно далеко ушел от уровня чайника - вон даже
элементарный софт до сих пор настроить не можешь (причем я лично за 12 лет в
FIDO даже не слышал о подобном глюке с буквой "э" - судя по всему, вообще
какая-то надуманная проблема). Так что твое мнение просто не имеет никакого
отношения к реальности.
Alex
Serguey Zefirov
>> Знаешь, когда я пользуюсь прогой, а тем более такой, за которую я
>> заплатил, то мне абсолютно насрать, кто там ее писал - профессионал, у
>> которого нету времени или любитель, у которого нету денег. Если она
>> тормозная - значит ее писали тормозные. Вы тут смеетесь над
>> четырехкратной перерисовкой, а ведь это факт. И этого можно избежать
>> очень просто, но почему-то делать этого не хотят, или не знают как.
vm> Поверьте, при разработке сложного приложения возникает масса гораздо
vm> более серьёзных и важных проблем. Если большинство пользователей не
vm> устроит эта самая четырёхкратная прорисовка, проблема попадёт в разряд
vm> серьёзных и будет решена. Hо обсуждаемый случай не такой. А ради %0.001
vm> процента пользователей прилагать усилия не имеет смысла (критерий -
vm> время, потраченное на разработку, и полученные деньги, а не
vm> "совершенство" в вашей голове). Ищите себе другую программу, ну а если
vm> не найлёте, то могу, как теперь стало модно, посоветовать "выпить яду".
Стив Джобс пинал программистов, чтобы ускорить загрузку системы. Его
аргументация сводилась к следующему: если каждый день десятки миллионов людей
включают компьютер Apple, то всего одна секунда ускорения принесет за год
экономию в одну жизнь (а это всего, примерно два с половиной миллиарда
секунд).
>> И этих людей вы называете профессионалами? "Это они
>> профессионалы, а мы любители с голой жопой" (C) П.Ф. Садырин
>>
vm> Я называю профессионалами в чём-то людей, которые получают деньги за это
vm> что-то (прямо или косвенно), и на это живут.
Стив Джобс под это определение не попадает. Он получает всего $1 в год.
vm> А любителями тех, кто не
vm> получают, а занимаются лишь ради удовольствия.
Более того, от руководства фирмой Apple и создания невероятно приятных в
пользовании компьютеров и гаджетов он получает удовольствие.
Что за идиот, а?
Yours truly, Serguey Zefirov (thesz AT mail DOT ru)
Alex Mizrahi
(you :wrote :to '(victor metelitsa) :on '(Thu, 11 Aug 2005 01:20:13 +0400))
(
SZ> Стив Джобс пинал программистов, чтобы ускорить загрузку системы. Его
SZ> аргументация сводилась к следующему: если каждый день десятки миллионов
SZ> людей включают компьютер Apple, то всего одна секунда ускорения
SZ> принесет за год экономию в одну жизнь (а это всего, примерно два с
SZ> половиной миллиарда секунд).
дык, если бюджет позволяет, чего бы не заняться?
vm>> А любителями тех, кто не
vm>> получают, а занимаются лишь ради удовольствия.
SZ> Более того, от руководства фирмой Apple и создания невероятно приятных
SZ> в пользовании компьютеров и гаджетов он получает удовольствие.
SZ> Что за идиот, а?
ну вот не надо -- по-моему он совершенно не бедный и в деньгах не нуждается.
а вот что Apple такая вся приятная из себя -- не надо. я пользовался API
QuickTime, и мне было очень неприятно. идиотический древний API, баги.. по
крайней мере под win32 плагин, вещающий всё нафиг на ровном месте -- хотя,
вроде бы, сделать то место нормально вообще не представляет сложностей. и
под маком там не всё так гладко..
так что -- не надо идеализировать, я думаю у них достаточно непофиксенных
проблем посерьёзнее легендарной 4-х кратной прорисовки (которую мне тоже
что-то не удалось обнаружить..)
Alex Pakhotin
vm>> серьёзных и будет решена. Hо обсуждаемый случай не такой. А ради %0.001
vm>> процента пользователей прилагать усилия не имеет смысла (критерий -
vm>> время, потраченное на разработку, и полученные деньги, а не
vm>> "совершенство" в вашей голове). Ищите себе другую программу, ну а если
vm>> не найлёте, то могу, как теперь стало модно, посоветовать "выпить яду".
SZ> Стив Джобс пинал программистов, чтобы ускорить загрузку системы. Его
SZ> аргументация сводилась к следующему: если каждый день десятки миллионов
SZ> людей включают компьютер Apple, то всего одна секунда ускорения принесет
SZ> за год экономию в одну жизнь (а это всего, примерно два с половиной
SZ> миллиарда секунд).
Все правильно. Стив Джобс в отличие от вас понимает, что важнее. И в MS,
кстати, не дураки сидят - загрузку XP очень значительно ускорили по сравнению
с 2000.
В случае же архиватора имеет намного больший смысл потратить время на
оптимизацию именно функции архивации, пусть она даже принесет лишь несколько
секунд выигрыша на больших объемах. А "бантики" - да кого они вообще волнуют в
данном случае? И где вообще эта перерисовка - кто-нибудь наконец пальцем
покажет?
Alex
victor metelitsa
> >> Знаешь, когда я пользуюсь прогой, а тем более такой, за которую я
> >> заплатил, то мне абсолютно насрать, кто там ее писал - профессионал, у
> >> которого нету времени или любитель, у которого нету денег. Если она
> >> тормозная - значит ее писали тормозные. Вы тут смеетесь над
> >> четырехкратной перерисовкой, а ведь это факт. И этого можно избежать
> >> очень просто, но почему-то делать этого не хотят, или не знают как.
> vm> Я не смеюсь - мне четырёхкратная перерисовка совершенно безразлична.
> vm> Поверьте, при разработке сложного приложения возникает масса гораздо
> vm> более серьёзных и важных проблем. Если большинство пользователей не
> vm> устроит эта самая четырёхкратная прорисовка, проблема попадёт в разряд
> vm> серьёзных и будет решена. Hо обсуждаемый случай не такой. А ради %0.001
> vm> процента пользователей прилагать усилия не имеет смысла (критерий -
> vm> время, потраченное на разработку, и полученные деньги, а не
> vm> "совершенство" в вашей голове). Ищите себе другую программу, ну а если
> vm> не найлёте, то могу, как теперь стало модно, посоветовать "выпить яду".
>
> Стив Джобс пинал программистов, чтобы ускорить загрузку системы. Его
> аргументация сводилась к следующему: если каждый день десятки миллионов людей
> включают компьютер Apple, то всего одна секунда ускорения принесет за год
> экономию в одну жизнь (а это всего, примерно два с половиной миллиарда
> секунд).
>
Про секунду - аргументация бредовая (может, для "яблочников" сойдёт? но
я не "яблочник"). Важно то, что заметит и оценит абсолютное большинство
пользователей - всё делается ведь для них. Скажем, двухкратное ускорение
загрузки (если она изначально была медленной) они могут заметить и
одобрить, поэтому проблема попадает в разряд важных. А односекундное
ускорение пятиминутной загрузки не стоит и секунды работы программиста.
> >> И этих людей вы называете профессионалами? "Это они
> >> профессионалы, а мы любители с голой жопой" (C) П.Ф. Садырин
> >>
> vm> Я называю профессионалами в чём-то людей, которые получают деньги за это
> vm> что-то (прямо или косвенно), и на это живут.
>
> Стив Джобс под это определение не попадает. Он получает всего $1 в год.
>
А вы нуждаетесь именно в таком определении, которое позволит назвать
Джобса профессионалом? Если он не получает за работу деньгм, тогда это
занятие в принципе не отличается от каких-то других занятий - он мог бы
плавать на яхте, лазить в горы, охотиться на лис, строить космический
корабль - т.е. это не работа, а развлечение, которое теоретически в
любой момент может бросить без последствий.
> vm> А любителями тех, кто не
> vm> получают, а занимаются лишь ради удовольствия.
>
> Более того, от руководства фирмой Apple и создания невероятно приятных в
> пользовании компьютеров и гаджетов он получает удовольствие.
>
> Что за идиот, а?
Был бы идиотом, если бы работал бесплатно и при этом удовольствия не
получал.