Re: Life_of_ANTS
А нащо вектори перетворювати? Якщо конче потрібно, то є dynamic_cast, але наявність cast-ів переважно свідчить про некоректність моделі. Ну і звісно краще кастувати не весь масив, а окремі елементи.
Ви не увійшли. Будь ласка, увійдіть або зареєструйтесь.
Ласкаво просимо вас на україномовний форум з програмування, веб-дизайну, SEO та всього пов'язаного з інтернетом та комп'ютерами.
Будемо вдячні, якщо ви поділитись посиланням на Replace.org.ua на інших ресурсах.
Для того щоб створювати теми та надсилати повідомлення вам потрібно Зареєструватись.
Український форум програмістів → C++ → Life_of_ANTS
Сторінки Попередня 1 2 3 4 5 6 Наступна
Для відправлення відповіді ви повинні увійти або зареєструватися
А нащо вектори перетворювати? Якщо конче потрібно, то є dynamic_cast, але наявність cast-ів переважно свідчить про некоректність моделі. Ну і звісно краще кастувати не весь масив, а окремі елементи.
А нащо вектори перетворювати? Якщо конче потрібно, то є dynamic_cast, але наявність cast-ів переважно свідчить про некоректність моделі. Ну і звісно краще кастувати не весь масив, а окремі елементи.
Хоча ви правий. Тут замість приведення треба змінити ті функції, які власне приведення вимагають, щоб не змінювати їх потім.
Пане quez, а можете на вікі в завданнях відписати, що саме ви робите?
Пане quez, а можете на вікі в завданнях відписати, що саме ви робите?
Роблю (а точніше робив) поведінку мурах. Заодно пробував правити структуру класів, але одна зміна тягне за собою іншу, і так далі. Їжа дуже сильно прив’язана до сцени, як це виправити, не переписаши половину проекту, не знаю. До того ж я не знаю, чи вийде все це змержити з тим, що було додано сьогодні. Тому завтра (або пізніше) зроблю простіше. Тоді й відпишусь на вікі.
Взагалі, структура проекту вганяє в депресію.
Не вистачає лише можливості звертатись до мурахи і до їжі. Тобто мінімум — поле id і метод getById. Тут ніяких проблем немає. Але у випадку їжі це все потрапляє до класу Scene, де йому явно не місце — в цьому класі лежить малювання і всякі SDL штуки, і це мені дуже не подобається.
Ідентифікуйте мураху за адресою. Жодних id і getId, хіба що треба перевіряти, чи ще воно існує... але це і з id треба. Якщо не так - наведіть приклад, коли крім адреси потрібне окреме id.
Малювання є в draw() - це у всіх класів так. Коли розберемося зі спрайтами, все буде правильніше.
В Scene наразі є graphics і processEvents - так, треба створити основний клас гри, це в завданнях написано, і витягнути туди код з main.cpp та Scene.
І жодне з цих завдань не вимагає перероблення моделі "мураха-сцена-їжа".
Ну і якщо вже брати C++11, то вказівники треба shared_ptr та weak_ptr робити.
Ще одна пропозиція: додати класи точок для моделі і екрану, і використовувати їх, щоб не переплутати, які координати зараз використовуються.
А тим часом у мурах з'явилися імена
Ще одна пропозиція: додати класи точок для моделі і екрану, і використовувати їх, щоб не переплутати, які координати зараз використовуються.
Читаєте мої думки.
А от що стосується класу юнітів, колонії, і їжі(ресурсів) то мені здається що вони повинні не наслідуватись один від одного. Якось так.
Якщо щось знаходиться на карті і з ним можна робити щось у відповідності до цього розміщення, то воно має так чи інакше наслідуватися від "об'єкта на карті". Але, звісно, не одне від одного.
Наслідування - це відношення "А є Б". Мураха є об'єкт з колонії. Об'єкт з колонії є об'єктом на карті. Їжа теж є об'єктом на карті. Маєте кращі пропозиції - давайте обговорювати.
Он quez якісь менеджери хоче ввести, мені дуже цікаво, як воно там, але комітів поки не було.
Ідентифікуйте мураху за адресою. Жодних id і getId, хіба що треба перевіряти, чи ще воно існує... але це і з id треба. Якщо не так - наведіть приклад, коли крім адреси потрібне окреме id.
Малювання є в draw() - це у всіх класів так. Коли розберемося зі спрайтами, все буде правильніше.
В Scene наразі є graphics і processEvents - так, треба створити основний клас гри, це в завданнях написано, і витягнути туди код з main.cpp та Scene.
І жодне з цих завдань не вимагає перероблення моделі "мураха-сцена-їжа".
Ох ці сішні фокуси. Я й не думав в цю сторону.
Он quez якісь менеджери хоче ввести, мені дуже цікаво, як воно там, але комітів поки не було.
Та ніяк воно там. Буду заново писати. Ті менеджери варто було б мати зразу, щоб робота з об’єктами не розмазувалась по незв’язаним класам, а не вводити зараз. Тож працюватиму з тим, що є.
Ох ці сішні фокуси. Я й не думав в цю сторону.
Найсмішніше, що я теж не задумувався про адреси як ідентифікацію (хоча по факту використовував), доки не дізнався, як функція hasCode в Java працює
Та ніяк воно там. Буду заново щось пробувати.
Тоді відпишіться, що саме збираєтеся робити, на вікі.
І давайте якось обговоримо координати, а то мені цей манхеттен не подобається (швидкість реалізовувати важко). Може, просто замкнений прямокутник із float-координатами?
quez написав:Та ніяк воно там. Буду заново щось пробувати.
Тоді відпишіться, що саме збираєтеся робити, на вікі.
І давайте якось обговоримо координати, а то мені цей манхеттен не подобається (швидкість реалізовувати важко). Може, просто замкнений прямокутник із float-координатами?
Насмілюсь припустити, що настільки абстрактні мурахи як зараз не будуть нікому цікаві. Підтримую прямокутник.
Зачекайте зі змінами - я зараз на розумні вказівники все переробляю.
А от алгоритм обдумуйте.
Переробив. Як і очікувалося, стало гальмувати
Завтра гляну, що можна оптимізувати
Переробив. Як і очікувалося, стало гальмувати
Завтра гляну, що можна оптимізувати
Ті 5 fps тепер гальмують ще більше?
Я поки не наважуюся залити розумні вказівники до основної гілки. З геометрією (два класи точок - окремо для моделі і для вікна) - поки що займаюся сексом. Хтось що збирається щось змінювати/додавати?