Kos94ok, чат супер. Как там проблемы с сетевым кодом? решились?
Добавлено (12 июля 2015, 15:56) ---------------------------------------------
ЦитатаKos94ok ()
Удачи тебе в твоей разработке, кстати )
И да, спасибо) Но до твоего уровня мне далековато. У меня больше просто наработки самообучения и веселья. Если я захочу издать законченный продукт, я скорее воспользуюсь фреймвоком
а затем в таймере каждые 20 миллисекунд запускаю метод run что-бы метод выполнялся постоянно
Ну сморите, при запуске метода start() создается новый поток и в нем автоматически выполняется метод run(), после того как метод run() завершился поток удаляется. нужно заново запускать метод start() чтобы вызвать метод run() в новом потоке. В каком потоке находится таймер? Если в основном, тогда вызов метода run() по таймеру блокирует основной поток.
Попробуйте запускать по таймеру метод start(), скорее всего это не сработает и будет вылетать ошибка что-то типо "This thread is already running.". Тогда попробуйте останавливать поток перед запуском. Пример:
Код
public static void main(String args[]){ //MyThread это некий класс, наследующий Thread MyThread mt = new MyThread(); while(timer){ //я не знаю как работает ваш таймер, но предположим что это цикл if(!timer)continue; //если 20 секунд не прошло, то продолжаем цикл if(mt.isAlive()){mt.interrupt();mt.join();}//пытаемся завершить поток и подключаемся к нему, чтобы не переходить к запуску потока до завершения mt.start(); } }
(ВНИМАНИЕ! код выше не работает, он просто представляет структуру. подключайте его в ваш таймер)
Если и это не поможет, тогда попробуйте третий способ. Просто запускайте свой таймер в отдельном потоке.
А также есть таймер который, каждые 20 милисекунд запускает этот метод run и еще один метод из основного потока
Если я вас правильно понял, то вы запускаете метод run(); из основного потока. Или все таки метод start();? Ведь именно метод start() выполнит метод run() в отдельном потоке. Запуская run(), из того же потока вы блокируете поток так, как если бы просто выполняли "еще один метод из основного потока". Надеюсь понятно объяснил, поясните пожалуйста то, что я прошу)
И да. Не обязательно, но желательно использовать аннотацию @Override (она определяет точно ли переопределен метод) при переопределении методов, с ней удобнее программировать.
Мне кажется, что должно прийти понимание, что один язык не может быть лучше другого, о каких бы языках мы не говорили.
Ну фактически вы находитесь с другой стороны баррикад и доказываете мне, что Java не лучше C# => C# лучше Java.
ЦитатаVinchensoo ()
Я даже не буду просить пруфлинк
Эхх я бы его и не дал. Это инфа из моих воспоминаний давно прочитанных статей.
Что ж в результате спора я понял лишь одно. Мы с вами рассматриваем вопрос с двух разных точек. Вы говорите о нем с точки зрения именно крупного бизнеса и быстрой прикладной пользы от используемых инструментов. Я же говорю с точки зрения фрилансера-студента, который программирует не ради денег, а ради интереса. И я бы на месте ТС писал бы все под читый OpenGL и организовывал запуск своего кода на разных платформах самостоятельно (это же интересно, понять как все устроено и реализовать все самому). Но да, готов признать, вы меня убедили, для общей разработки игр ради прибыли с использованием сторонних инструментов разработки, лучше однозначно C#. Все, хватит споров на эту тему) Надеюсь ТС все это прочитае и сделает свои собственные выводы.
Я почему-то уверен, что у вас дома в уголке стоит алтарь с кружкой дымящегося кофе =)
Ахаха, что-то типо того
Ладно, сдаюсь, во многом вы правы, но тем не менее вернемся к нашим баранам, изначально разговор был о выборе между C# и Java. И именно в этом выборе, именно для программирвания фреймвоков и логики игр (а не для абстрактной разработки игр) я не отступлюсь. C точки зрения разработки игр, эти языки совершенно одинаковы (с одним НО ), сейчас я постараюсь это хоть как-нибудь доказать. Говоря о прикладном инструментарии, вы в первую очередь говорите про Unity, но C# имеет к Unity такое же отношение, как и Boo (исходники самого Unity никакого отношения к С# имеют). На Java же своих инструментов предостаточно (LibGDX, JMonkey), которые на деле для рядового программиста(именно программиста) оказываются более гибкими, потому что реализованы именно на Java и предоставляют открытые исходники. В остальном же инструментарий программиста ограничивается IDE (VS с одной стороны и intellij idea с другой), сборщиками проектов (тот же Gradle повсюду) и системами контроля версий (тот же gitHub повсюду), остальной мелкий инструментарий для среднестатистического разработчика игр (программиста) значения не имеет. В таком случае, если мы говорим, о прикладном инструментарии разработчика игр, то это уже разговор не о выборе языков, а о выборе Движков для разработки (и тут конечно же выбор делается в пользу Unity). Если же говорить о языках то C# и Java крайне похожи и в промышленной сфере используются в примерно одинаковых областях, но я напомню, что ТС хотел под разные платформы писать.
Цитатаandarky ()
А мне хочется чтобы язык был таким чтобы на разные платформы писать
А на рынке многоплатформенности на текущий момент Java мощнее С# (давайте не приплетать другие языки мы сейчас говорим об этих двух исключительно), ведь C# сталь кросплатформенным чуть ли не пол год назад (если не меньше) и еще очень плохо развит в эту сторону.
Если же говорить про то, что Java медленный, то я еще раз скажу, что все это чушь и пойду поставлю свечку к своему алтарю Если же серьезно, то на самом деле я сейчас занят активнм изучение С (именно из-за производительности). И вообще джава всего лишь в 1.5 раза медленее Си (еще одну свечку к алтарю).
надеюсь ниче не забыл и моя логика была ясна Я бы еще написал про мое крайнее несогласие с вашим оношением к статистике, но я че-то устал холиварить, попозже мб отпишу.
Сообщение отредактировал Remmintan - Пятница, 10 Июля 2015, 20:56
Я, как человек который разрабатывал моды Minecaft за деньги пару лет, могу сказать, что основное знание для разработчика модов, это голая Java, знай Java на должном уровне и ничего больше учить не нужно. Хорошо бы знать архитектуру самого minecraft'a, но достойный ее разбор в интернете найти тяжело. Есть два в корне разных подхода к разработке модов, можно разрабатывать под API Forge (как делает большинство) или непосредственно менять исходный код (декомпилируя Minecraft с помощью MCP). Разработка под Froge более проста но менее гибкая (удобно на ней делать только какие-то элементарные вещи, аля добавление новых мобов, NCP, блоков, биомов итд). Разработка под Forge чем-то отдаленно напоминает разработку плагинов Bukkit. Forge совершенно не затрагивает исходный код игры, это важно. Изменение исходного кода игры процесс более сложный (и требует более глубокого знания языка), но крайне гибкий, тут с игрой можно делать все что угодно, например я в одном из заказов превратил игру в RTS, аля Dwarf Fortress. И да, я не знаю насколько это законно, изменять исходный код.
Еще один ключевой момент. Если вы будете использовать сторонние моды в своем проекте, то однозначно Froge ваш выбор (большинство сторонних модов под последние версии игры именно под Forge). Если же все моды вы собираетесь писать самостоятельно, то изменение исходников ваш выбор. Потому что в таком случае все ограничится только вашей фантазией и знаниями языка.
О каких "всех платформах" вы говорите, если джава не умеет нормально работать на флагмане рынка- iOS.
Я говорю не только о смартфонах, а о многочисленных носимых устройствах, начиная фитнес трекерами и заканчивая "умными" домами, таких устройств сейчас все больше и больше и лет через 5 они вероятно будут повсюду. Если же говорить про смартфоны, то iOS (выстрелив когда-то в далеком 2007) уже не флагман и его доля на рынке неуклонно падает (по данным IDC Android в 2014 занимает 81% рынка смартфонов и 66% рынка планшетов. пруф на русском), и это при условии, что Android достойно вышел на рынок на год позже iOS, так что именно за Android будущее (исключительно из-за его открытости и универсальности по отношению у устройствам). Про WP и говорить не стоит, для начала потом что он оффициально мертв и вернулся Windows Mobile (пруф), которому только предстоит выходить на рынок и отвоевывать себе хоть какой-нибудь процент устройств.
ЦитатаVinchensoo ()
Java и .NET ОЧЕНЬ часто используется в веб-разработке в корпоративной среде.
Я этого не отрицал, это их основная сфера использования. Я хотел сказать, что десктопные (и мобильные) приложения отлично пишутся на Java тоже.
ЦитатаVinchensoo ()
Oracle на 80% написан на С, как и все другие промышленные СУБД
Тоже верю, я и этого не отрицал, я говорю про те 20%, которые написаны именно на Java. Цитата с википедии: "СУБД Oracle Database включает JVM как свою составную часть, обеспечивающую возможность непосредственного программирования СУБД на языке Java", и эта часть цветет и пахнет и "диких тормозов" за ней замечено не было. Следуя вашей логике можно каждому второму советовать учить С, чтобы писать крайне производительные приложения (близкие по производительности к языку ассемблера). Но, на мой взгляд, Си уж очень низкоуровневый для быстрого освоения и недостаточно гибкий для быстрого и удобного программирования (напомню, мы говорим о языке, в котором ООП хоть и реализуем, но больше похож на бред сумасшедшего). И если человек хочет писать сейчас игрушки, а в будущем маленькие приложения под различные платформы то Си уж точно не его выбор (если этот человек не заядлый велосипедист, конечно).
ЦитатаVinchensoo ()
Это язык сугубо корпоративных серверов и всяких распределенных систем обработки данных.
Ну это же стереотип, все языки, которые полны по Тьюрингу абсолютно универсальны, все зависит только от таланта и фантазии программиста. А языков для "создания игр" не существует вовсе (я не говорю про языки конкретных IDE и систем разработки, аля Gamr Maker Language). Пожалуй продублирую вопрос адресованый вам:
ЦитатаJhon ()
А какой язык надо учить, чтобы делать игры?
В качестве еще пары аргументов: В Java 8 представлен на порядок более высокий уровень абстракции (они даже от циклов постепенно избавляются), который позволяет создавать красивейший и быстрый код, до которого (уровня абстакции, а не красивейшего и быстрого кода) Шарпу пока что далековато. Java востребованнее на рынке чем C# И еще раз повторюсь, что Android сейчас занимает почти весь рынок смартфонов (пруфы выше) и Java является основным языком разработки под Android (NDK откровенное извращение)
Сообщение отредактировал Remmintan - Пятница, 10 Июля 2015, 19:58
andarky, как сказал pixeye С# и Java в сущности очень похожи. Оба языка являются стандартом Энтерпрайзной разработки, оба языка имеют ярко выраженный ООП и схожий синтаксис. В сущности, Шарп (# - это шарп) очень многое перенял от Java, глядя на практику ее использования. Поэтому, если ты хорошо научишься программировать на одном из этих языков, переход на другой язык потребует не более недели (мне хватило недели для перехода на Шарп реализации полноценного приложения с графическим интерфейсом, шифрованием, сокетами и другими плюхами). Но в этих языках есть одно отличие, если C# только начинает свой путь кроссплатформенности, то Java с самого своего рождения кроссплатформенен и выставляет эту свою черту, как ключевую особенность. Не для кого не секрет, что мобильные платформы - будущее, количество носимых гаджетов растет с каждым днем, и уже сейчас Java Runtime Enviroment можно поднять на всех этих гаджетах (даже на платке с 64 КБ оперативной памяти, недавно где-то читал). Поэтому очевидно, что пока С# только набирает обороты на рынке мобильных устройств, локомотив Java уже летит на всех парах. Что же на счет скорости выполнения, так медленная скорость работы Java это давно неактуальный миф, пришедший из начала нулевых. Скорость работы твоих приложений зависит только от прямоты рук программиста (посмотрите на ту же Oracle, ее БД цветут и пахну, обрабатывая тонны информации на сверхсветовых скоростях). Ну и на последок повторю то, что уже сказали все. Пока сидишь на Unity конечно С# (Javascript недостаточно мощен, хотя тоже становится все круче и круче), но вообще гляди в сторону Java и мобильных платформ (потому что интерпрайз это богато, но скучно, а на мобильных платформах все еще процветает инди).
На счет Ruby и Python. Языки очень мощные и в отличии от всяких C++, Джав и Шарпов просто великолепные с точки зрения синтаксиса. Вот именно эти языки (а не Java) исопльзуются исключительно в WEB'е, чаще на стороне сервера (особенно ROR). А Qt вообще не язык, а библиотека (или фреймвок, я не особо прошарен) для плюсов.
К слову, в нынешних реалиях ограничивать частоту кадров - идея так себе. Если уж и резать, то до 120, не меньше.
Полностью согласен, резать частоту кадров, находясь в здравом уме, не лучшая идея. Я просто забыл добавить, я разрабатываю под мобильные платформы, с ресурсами там туговато (особенно когда хочется поддерживать старые Android устройства). Приходится выжимать все, что есть.
О, брат по видеокарте, у меня тоже GTX 660
Сообщение отредактировал Remmintan - Четверг, 09 Июля 2015, 14:37
Такое "падение" FPS я бы не назвал ударом по производительности, я в своем фреймвоке вообще спецом режу FPS до 60, а освободившееся процессорное время использую для служебных целей. Все равно все, что выше 100 FPS, не сильно влияет на плавность картинки.
Программирование увлекся чуть ли не с младенчества. Первым был Basic в далеком 2007, но скорее всего в силу возраста, я его осилить толком не смог. За ним был С# который так же долго не продержался. Но потом я нашел Java и он мне запал в душу. Своим синтаксисом (во многом схожим с C#, где все крайне логично) и ярко выраженным ООП. И вот уже 5 лет программирую на Java, с каждым годом все лучше.
P.s. иногда жалею, что ушел от C#, в Java нет перегрузки операторов, а в текущем проекте она бы мне очень помогла.
Сообщение отредактировал Remmintan - Среда, 08 Июля 2015, 13:05
kol9mbo, ну непосредственно при программировании игр это делается с опорой на FPS. Вычисляется разница во времени (delta) между соседними кадрами, эта разница каждый раз прибавляется переменной и когда значения переменной становится равно минуте (в неких единицах), срабатывает некое событие и переменная обнуляется, все начинается сначала.
Более универсальный способ: В момент запуска приложения вызываешь System.currentTimeMillis(); этот метод вернет тебе переменную типа long, содержащую текущее время в милисекундах, записываешь ее куда нибудь. После этого каждую итерацию цикла (некого цикла в твоей программе в котором происходит все) вновь вызываешь System.currentTimeMillis() и из нового значение вычитаешь начальное. Когда разница становится равна 60000 (1000 миллисекунд равна 1 секунде) значит прошла минута.
В сущности оба метода одинаковы, потому что основаны на одинаковых принципах (Вычисления разницы во времени).
Вот пример кода, как это реализовывать, код писал прямо сейчас в строке ввода pstebin, поэтому ни разу не отлаживал. Код может содержать мелкие синтаксические ошибки, по той же причине. Код здесь
BESS55555, игра супер. Но мне кажется, что логичнее было бы сделать на начальных уровнях большее количество миньёнов (этих чуваков, бегающих по экрану), у тебя сейчас ровно наоборот. Потому что чем их больше, тем проще набрать две звезды (куска г*вна в твоем случае) и получается парадокс, с уровням все проще их проходить на 2 звезды. И да, набрать три звезды практически нереально. Я так понимаю, надо взорвать всех? Это невозможно же)
Ошибка очень странная. Вся проблема в мтоде Integer.getInteger(String str) этот метод почему-то возвращает null. Я, честно говоря, не знаю почему. Возможно кто-то поумнее меня найдется и ответит на этот вопрос. Я лишь могу рекоменовать не использовать этот метод (я никогда его не использую), есть другой более безотказный метод Integer.parseInt(String str)
Добавлено (22 июня 2015, 20:24) --------------------------------------------- Главное теперь предусмотреть, чтобы в текстовое поле ничего кроме цифр не вводили.
kol9mbo, с каким кодом? Моим? Странно, что я там успел накосячить. Можно весь код посмотреть? (Именно тот, который ты компилируешь) И да, кратко по ошибке: это исключение, говорящее о том, что ты где-то в программе пытаешься вызвать метод у объекта который не объявлен. Проверь, все ли у тебя переменные объявлены, ни одной не присвоено значение null. А вообще NullPointerException это типичное исключение, которое можно перехватить и отладить. Про исключения читай тут.
Все верно! Так сделать можно, и в данной ситуации это лучший вариант. Я вынес в отдельную переменную, создавая гибкость кода (то есть в будущем при расщирении функционала программы с моей переменной можно будет проводить промежуточные действия, добавляя новые функции). Ну а с точки зрения производительности мой и твой вариант абсолютно равносильны. Функция getText() в обоих случаях создает новый объект (то есть оперативная память выделяется), только я в своем случае сохраняю локальный указатель на эту память (объект String), чтобы потом с ним что-нибудь сделать.
На счет первого вопроса: Если тебе нужно по индексу найти значение, тогда ты правильно делал, когда из String делал Integer Только вот вместо метода indexOf тебе нужно использовать метод List.get(int i); То етсь:
), сейчас я постараюсь это хоть как-нибудь доказать. 
