Я четко аргументировал свою позицию, (wcpt), несешь полную ахинею без единого аргумента в свою пользу, показывая лютую неадекватность
Цитатаkvestpro ()
Полегче. Чем Unity не устроил?
с Unity всё норм, для своих задач подходит и инструмент суперский, но ТС хочет стать программистом, и начав изучить C# и использовать Unity он скорее всего (как и опять же многие здесь) на нем и остановится Согласись что знание чего то одного не есть хорошо
нет, снова неверно. Нет, не хочу, спасибо, что спросил. Ты, конечно же, эксперт по с++ и имеешь несколько игр, написанных на нём? Или просто школу не окончил? Второе, конечно, вероятнее. В противном случае не мерил бы пригодность яп подобным образом.
Нет неверно, нет не прав, нет не угадал, нет не так
Берн Страуструп в оригинале)) (т.к. переводчики постарались) Еще есть сайт shatalov su, там в старой его части целый цикл статей по C++, по нему научился, но говорят он не очень точен в своих определениях))
Цитатаwcpt ()
качествами должен обладать "нормальный" язык программирования.
Ну хотя бы не жесткой привязкой к фреймворку. Возможностью работать как на низком, так и на высоком уровне.
Такое ощущение, что никто всерьез программированием не занимается, а только и делают что на юньку передерг... ээ используют только Unity
На самом деле с C# лучше не начинать, т.к. потом будет намного сложнее перейти на нормальный язык. Delphi устаревший (как и Pascal и прочие). "юнька это ява" - это JavaScript а не Java.
Уважаемый ТС, если хочешь быть адекватным, действительно разбирающимся во множестве вопросов программистом, намного лучше первым языком взять C++, т.к. он лежит в основе огромного количества вещей (в том числе языки, которые были упомянуты выше) и сильно на них повлияли.
Также определись с дальнейшим направлением, которое тебе интересно. (Скрипты, Софт, WEB, Микроконтроллеры)
Многовато проц грузит. Вижу бесконечный цикл в какомто потоке
для tracer07 и тех кто будет пилить свой движек: Tempload << ссылка на цикл статей по современному OpenGL, хоть для C++ но смысл понятен
Пара советов:
В метод инициализации движка добавь передачу параметров окна и базовых настроек движка, из скриптов не ок)
От glut лучше избавиться, т.к. если архитектура хоть немного усложниться, все превратиться в кашу
Viewport не делай статичным т.к. их может быть несколько
TimeStep лучше в 16мс, это 60 кадров в сек. Если все дела за кадр сделаны, посмотри сколько время осталось и сделай Sleep для всех потоков если времени дофига (т.к. 2D двиг обычно мало жрет ресурсов)
В Draw не надо пихать обновление всех компонентов, или назови метод Frame (кадр)
Подучи OpenGL, т.к. ты используешь слишком устаревшие методы.
Зачем ты рисуешь объекты после SwapBuffers? лучше до, т.к. опять же будут проблемы когда все усложниться
В Draw лучше передавай delta (время обработки предыдущего кадра), float для типа данных хватит
Объекты не надо хранить в классе движка
Короче ИМХО пилить и пилить) Лучше не выстовляй недоделанный движек на показ, сам на это когда то напоролся)
Текстуры не освобождаются... короче обязательно прочитай цикл статей, который я скинул
И не стремись напихать побольше всего, лучше проработай все по мельчайшем деталям, так чтобы эта деталь могла работать отдельно от остального движка
если что, стучись в скайп "Morglod", помогу
Сообщение отредактировал morglodddd - Пятница, 30 Мая 2014, 02:27
вполне можно, но ты будешь ограничен уже готовыми методами и интерфейсами, которых кстати великое множество. Например в примерах у EPIC'ов есть несколько мини игр (Space Invaders и подбор летающей тарелкой овечек). Конечно воспроизводить на графе алгоритм намного дольше, чем в коде, но игру достойную многих конструкторов сделать можно
Цитатаsystem ()
а потянет ли мой калькулятор unreal engine 4
на уже давно не новом ноутбуке идет вполне неплохо
ЦитатаBs1 ()
Тогда какой же здесь конструктор?
Конструктор - это не про классы Это такая фишка у современных "игроделов"
