Viнt@rь

может и "верблюд", но "глаз не режит", и вполне приятно читать такой код Именно лучше среды разработки, чем Intellij IDEA(ну и всего, что на ней базируется) не встречал

Оно уже написано и работает, ежедневно не менее 10000 юзеров онлайн одновременно, потому и занялся рефакторингом и оптимизацией, ибо тогда писалось все в спешке, и сейчас, в очередной раз просматривая код, решение "исходя из условия" показалось мне немного костыльным... Все может быть, что понадобятся... Но пока что, на ближайший год 100% уверен в обратном Вот потому и отписал сюда, так как интересно мнение еще других программистов... Мне вроде как и без разницы, исходя из условия, либо переопределением... В первом варианте, условия в классе, лишний метод и тд., которые "режут глаз". Во втором - получаем дополнительные(лишние?) файлы/классы...

Пересмотрел вот только что класс Location, когда делал скриншот, еще раз убедился, что класс довольно таки не маленький... Разве это рационально использовать увесистый класс, из которого мне понадобится всего лишь 2 значения? ЗЫ Конечно, как вариант, написать свой класс/структуру с этими двумя переменными, широтой и долготой и сопутствующими им методами... Ну тогда наверное не правильный, а более рациональный что-ли... Честно - я уже запутался немного Изначально было сделано, как в первом варианте, то есть исходя из условия... Вопрос чисто для уточнения/справки, "Как ты и хотел" имеется ввиду второй вариант, с наследованием и переопределением и прочим, верно? Поправил свой пост, который выше, согласен, немного перегнул, это все же венгерка, вернее ее очень малая часть(да и по крайней мере для Android все же так принято). По отношению к методам и другому применяется CamelCase

@xStream, мне не важно куда присваивать/запоминать, в переменные либо в Location... Location это обычный класс в котором есть те же поля широты и долготы в все том же double, так зачем мне тогда создавать объект, который, я уверен, сожрет больше памяти(пусть и на несколько байт, но все же) нежели простой тип double... Да и к тому же при каждом закрытии приложения, в настройки придется сохранять эти координаты(конечного адреса) дергая опять таки методы get... А при загрузке обратно создавать объект и сетить туда эти загруженные координаты, а это как бы не есть хорошо, хотя операции сейв/лоад и разовые. Это не венгерка, а CamelCase(цитата с вики https://ru.wikipedia.org/wiki/CamelCase): Вот пример того самого Location: По поводу "mSettings" как видно, даже гугловцы(и не только) пишут с некими элементами венгерки Хотя так же и встречал онли lowerCamelCase по отношению к переменным во многих кодах Java разработчиков "правильный" и имелось ввиду эффективность, и "лучше" В общем, мне интересен ответ, я уже несколько раз разжевал на что именно, но ни малейшего приближения к нему я так и не получил...

@Allender, ну примерно так во втором варианте я и реализовал... Базовый класс реализует все, что надо вообще для диалога и для запоминания текущих координат, класс наследник просто переопределяет логику запоминания координат на свою, то бишь на установку конечных координат. Вопрос вообще заключается не в том, как это сделать, а какой подход более правильный!

@Allender, немного не то, да и в Android есть такой класс как Location и всякие приблуды для вычисления радиуса/расстояния от одной точки(lat, lon) к другой... В настройках в приложении есть 2 пункта, установка текущего местоположения, установка конечного адреса. По нажатию на любой из пунктов, открывается диалог, что в первом, что во втором случае, это по сути(по своей цели) один и тот же диалог, просто в первом варианте в диалоге выбираем из списка адресов с координатами, текущее местоположение, во втором выбираем конечное местоположение. То есть, что на первый, что на второй случай, логика у диалога должна быть практически одинаковая, за исключением того, в какие именно переменные мы запоминаем координаты. Ну и в первом случае необходимо отображать кнопку, что бы получить координаты с помощью GPS, а во втором нет... Вот я и спрашиваю, как лучше сделать, проверять условием по флагу, что диалог открыт для установки конечного адреса/координат, то бишь: if (!isFinalAddress) { mSettings.setCurLatitude(location.getLatitude()); ... } else { mSettings.setFinalLatitude(location.getLatitude()); ... } Либо вынести эту часть логики, которая будет отрабатываться в зависимости от условия, в класс наследник, в итоге базовый класс будет для выбора и запоминания текущих координат, а класс наследник будет для установки конечных координат. Вот небольшой пример

Вот как раз таки надо разделять, эти переменные - на самом деле, поля некоего класса "настроек" там есть и текущие координаты, и координаты конечного адреса и куча еще всего другого... Например размеры текста, его цвет и тд... Для наглядности. вот более детальный пример: if (isFinalAddress) { mSettings.setCurLatitude(location.getLatitude()); ... } else { mSettings.setFinalLatitude(location.getLatitude()); ... } В итоге в будущем приложение может использовать одновременно и координаты текущего и конечного местоположения, да и при том в границах одного метода, например для сортировки по дистанции(радиусу) от пользователя до конечного адреса.

В этом то и заключался вопрос), как правильнее/лучше сделать, как диалог должен понять, что сейчас запоминаем текущие координаты, а сейчас конечное местоположение. Возможно я немного натупил, и забыл указать еще то, что нужно запоминать координаты в разные переменные: double curLatitude... double curLongitude... double finalLatitude... double finalLongitude... Отсюда по всему классу диалога будет код такого вида: if (isFinalAddress) { finalLatitude = location.getLatitude(); finalLongitude = location.getLongitude(); } else { curLatitude = location.getLatitude(); curLongitude = location.getLongitude(); } Вот выше приведенное в пример, показалось мне костылем, я просто не знаю правильный(либо насколько правильный) такой подход? Потому и задумался, над тем, как еще можно сделать. В голову пришло, вынести это поведение(логику/операции... чет в голове все немного перемешалось) в разные классы, при этом есть базовый диалог(наследуемый), который реализует все, и в каком-то там отдельном методе реализует "запоминание" текущих координат. А класс наследник, переопределяет этот метод, в котором реализует "запоминание" конечных координат. В итоге так можно уйти от "какого-то флага" и всех if `ов. И в конце концов, там где необходимо установить текущие координаты, мы откроем первый диалог(базовый класс), а где необходимо конечные координаты, откроем второй диалог(класс наследник первого) @xStream, Прочитав еще несколько раз твои ответы, начало складываться мнение, что мы друг друга не правильно поняли Массив положений, сейчас я понял, что имелось ввиду нечто типа: ArrayList<Location> верно? Если я верно понял, то вопрос все же заключался не в получении места положения и массиве положений, как их отобразить/выбрать и провести еще какие либо операции... А в:

Хотелось бы пример увидеть, если не сложно И да, забыл упомянуть, помимо логики, еще диалоги немного разные в визуальном плане, почему немного? Потому что у первого должна быть еще и кнопка GPS, а у второго ее не должно быть, соответственно верстать почти одинаковые разметки, с различием в один элемент, нет смысла... Потому в случае с конечным адресом, как мне кажется, лучше просто скрыть кнопку... В случае с первым вариантом реализации такого(таких диалогов) код будет выглядеть в таком плане: ... if (isFinalAddress) { button.setVisibility(View.GONE); } ...

Пишу на Java(Android), и хотел бы уточнить кое что, есть некий класс диалогового окна, унаследованный от базового DialogFragment, в диалоге выполняется смена какого-то значения пользователем, допустим - выбор местоположения из предоставленного списка, с помощью этого диалога, пользователь может выбрать свое текущее местоположение, и конечный адрес, соответственно "запоминать" координаты и сам адрес нужно в разные переменные, в итоге в голову пришло такое, да бы не плодить классов разных, задавать какой то там булеан типа isFinalAddress при создании/открытии диалога и повсюду, где нужно, смотреть, выставляем конечный адрес или нет, ну и при этом выполнять нужные действия... Вторым вариантом есть такая реализация: базовый класс этого диалога, реализует возможность устанавливать только текущее местоположение, а унаследованный от предыдущего, реализует возможность установки конечного адреса. С точки зрения ООП, я так понимаю, что более правильный - второй вариант, но в итоге у нас на 1 класс(ну и естественно файл) становиться больше, мне то это не принципиально, но все же... Таких моментов(классов) в приложении примерно 3-4, то есть в итоге, если действовать по второму варианту, то кол-во классов увеличиться еще на такое же число.

@НаноБот, можно попросить весь список не учитываемых движком(ЗП) параметров, и желательно формулы просчета "правильной" баллистики?

Если имеется ввиду "на работай и не смей отвлекаться ни на секунду", то я не согласен, от такой "напряженки" программист очень быстро устает, по себе знаю, а вот когда дают возможность отвлечься и почитать что-то, либо просто встать пройтись когда захотелось... Это уже другое дело, и работать приятно и не утомляет нисколько. Уточнять же нужно сразу у каждого своя практика, потому и свои взгляды на одни и те же вещи. А эти самые "драконовские дисциплины" называются соглашениями(внутренние, в команде/компании и общепринятые) по оформлению кода и тд. И я считаю абсурдно их не придерживаться. Вряд ли кто именно "заставляет" это делать. Ведь все, по идее, понимают, что это повлечет за собой.

а за это спасибо учту и говоря за инкапсуляцию я и имел ввиду скрытие реализации, а точнее ее отсутствие. Сам каждый день, так сказать, вынужден использовать ООП ибо Java(Android) от этого там никуда не уйдешь. Возможно у меня возникла некая путаница в реализации принципов в Lua и в Java(C#, C++) ЗЫ "вынужден" сказано не с досадой, а наоборот, так как самому нравятся идеи и применение ООП.

Я думаю, что спорить с этим будет лишь дурак, и лишь дурак не поймет всех прелестей применения парадигмы. @warwer, сразу скажу не наезд, а интереса ради, ну да бы понять, я нагадил или нет. Потому не стоит ниже мною написанное воспринимать в штыки. вроде бы от меня не поступало такого имеется ввиду наше обсуждение парадигмы ООП? Точно не о тебе писал. - warwer

@Malandrinus, все мною изложенное писалось в пол третьего ночи, потому я пытался не вбиваться в подробности и по-быстрому вкратце ответить Карлану на вот это: Потому просто как бы, дал наводку, в каких местах использование парадигмы все же лучше/хуже(оправдано/не оправдано), если вбиваться в подробности, то тут можно рассуждать и рассуждать, курить и курить... Ведь, если не лезть в дебри применения, все в том же "вкратце" это можно назвать удобством Ну, а если все таки лезть: для чего именно, в какие моменты, как и за счет чего... - в своем посте ты уже и так растолковал. Все же я наверное сильно категорично выразился. Больше склоняюсь к кое-когда сказанному xStream - термину псевдо-ООП. Как бы наследование есть, объектная ориентированность тоже есть, а вот допустим инкапсуляции и полиморфизма нет...

А так же проектирования архитектуры приложения и тд... Имею ввиду в программах написанных на С++ и подобных(Java, C# - тут уж от объектной ориентированности никуда не уйдешь...) Как оно в Lua - вот только сейчас задумался, как бы по логике и влиять не должно, так как это не совсем ООП. ЗЫ и с этими постами думаю уже можно переезжать в подобающую тему "Язык Lua. Общие вопросы программирования". Хотя тут и неопределенность получается, и там и тут курим одно и тоже... Так как это курилка, почему-то мне кажется, что в скоре мы получим микс тем С++ и Lua, так как в плане Сталкера, это самые актуальные вопросы, да и по большому счету они тесно связаны между собой. Потому не думаю, что здесь пойдут вопросы или обсуждения написания ПО на Java, C# и тп. Имелось ввиду это: Скорее всего они плохи и хороши одновременно той самой универсальностью, так как универсальность очень часто является врагом производительности. Когда ты пичкаешь кучи проверок и кучи кода, с целью предусмотреть все возможные развития того или иного сценария для разных платформ(в нашем же случае это разные моды, со своими модулями и разные движки сталкера).

@Карлан, это был не выпад, это был ответ на "Но я так и не понял почему не обменяетесь кодами". То есть, помимо простого ответа "обменялись кодами давно", я дополнил его списком систем/тех самых кодов... Говорят за эти системы не конкретно, а в общем(не только ты, от тебя проскочило максимум пару строчек в паре постов, примерно в контексте "меганавороченныхсуперсистем"), в основном оставаясь на стороне старых(времен величия АМК мода), когда сами же их разработчики говорят, что из себя представляют "старые", и какие выгоды можно получить от "новых". Я вроде бы и не говорил, что они плохи, даже наоборот, сам много для себя почерпнул из его наработок. Это скорее всего и было адресовано Денису Просто я видимо для себя не правильно растолковал вот эту твою фразу: В ответ на это я и дал примерную дату и место(тему) где можно почитать об этом всем, замерах, обсуждениях и тд... ООП в Lua - не ООП вовсе, все в той же теме о которой я упоминал выше и примерно в те же даты, происходило и обсуждение ООП + Lua. В итоге помню примерно такую фразу xStream "в Lua псевдо-ООП", средствами Lua невозможно задействовать и половины принципов ООП. Было еще примерно такое class "Foo" вовсе и не класс, а само выражение равносильно class("Foo") ну и сам этот класс являет собой на самом деле некую таблицу. В итоге мы получаем примерно такое класс = таблица, методы = поля таблицы(вроде бы даже метатаблицы, не помню точно) ну и естественно в коде выходит примерно такое: class "Foo" function Foo:name() return "Foo" end local Foo = {} Foo.name = function() return "Foo" end Вроде бы так, но я и не настаиваю на конкретике примера, думаю суть и так уловить можно. В общем ООП не ООП в Lua, тут скорее всего уже как тебе будет удобно, сама же парадигма используется программистами для удобства написания кода, хотя на деле, это потеря в скорости выполнения программы

Эмм... На самом деле кодами довольно таки давно обменялись и предоставили на общее пользование. Ув. xStream(кстати с возвращением, давно не видел на форуме ): Песочница, даже процитирую из мануала "Песочница" основана на так называемой event-driven модели", работа с net-пакетами, универсальное хранилище, таймера и прочее. Ув. Malandrinus: слот-сигнальная система, таймера, хранилище и тд...(оно же используется в новом OGSE) Там это все себе подцепил и ув. Artos, немного где-то подправил, под свой стиль, так сказать... Еще были реализации от Monoroch, Меня(на основе выше указанных наработок написал свое, но более упрощенное и конкретно под свои нужны без "забеганий наперед") и еще несколько других... Все это происходило примерно года 2 назад(время то как летит...) в теме "Язык Lua. Общие вопросы программирования", если мне не изменяет память... Все эти наработки имели достаточно разжеванный мануал по их использованию. Ну и присоединюсь к

@KD87, не сочти за наглость)) Я только начинаю разбираться в игровой графике и в шейдерах, потому, если тебе не составит труда, может подтолкнешь хотя бы примерно где копать(за сан флары знаю, уже даже обдумывал этот вариант), а то не пойму я, как рендерить квады эти(рисовать дерт для каждой лампы???), и мб есть где за это почитать? Мб есть вариант попроще и более правильный? Или твой вариант и является правильным и рациональным? Где-то видел, что можно привязать к блюму от лампочек, эффект будет похуже чем из расчета позиций источников освещения(наверное и имелось ввиду то, что ты сказал), но, тоже более-менее нормальный. ЗЫ прошу сильно не бить, мб и бредятину понаписывал)))

@KD87, Легко тебе говорить))) А мне бы для начала разобрать что это) и как его реализовать, и оно все в шейдере реализуется или же нужно и в движке какие манипуляции проводить?)

@tatarinrafa, игра то его скомпилирует(и то, если сможет), но функция, которая внутри не вызовется и никак не обработается...

Это по названию семплера было понятно))), но спасибо) И все же как бы его прикрутить на другие источники освещения? Блюм же как бы идет от них, соответственно это тоже эффект освещения, потому наверное имеет смысл на него и навешивать Lens Dirt

Я реализовываю это на движке ЗП и правлю его сам, потому имя семплера у меня s_lens_dirt Вот сейчас я и пытаюсь додумать))

С блюмом, что бы он проявлялся и от обычных источников освещения, а не только от солнечного оcвещения/лучей, или при такой реализации, как ты показал, оно не только от солнечных лучшей будет проявляться? у себя пока реализовал так, но возможности проверить нет float4 lens_dirt_img = s_lens_dirt.Sample(smp_rtlinear, center); img += ((bloom * lens_dirt_img) * 2); ЗЫ текстура взята из Metro LL

Всем привет, пытаюсь реализовать эффект Lens Dirt. Платформа ЗП(render R3), Исходники есть и активно правятся... В общем зарегистрировал я свой семплер(s_lens_dirt) и текстуру для этого дела, в шейдер combine_2_aa/naa эту текстуру передаю. Комбинирую там свой семплер с блюмом(s_bloom), в игре текстуру видно, но она там почти как самый обычный кастом статик. Так как в шейдерах пока еще не сильно разбираюсь, не могу понять как правильно написать логику комбинирования всего этого, что бы Lens Dirt был именно Lens Dirt, например как в том же Metro LL. Пытался, пытался - нифига, потому прошу помощи в реализации.