ProGramMoS: Все сообщения за 27 Февраля 2012 года

 
ПнВтСрЧтПтСбВс
1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29

ProGramMoS

новичок
О как... Я думал, что проект умер с концами, а тут такое за полгода... Слов нет :)


TSR> это, ориентировка на качество, ресурсы будут жраться не мерено, но... с другой стороны если брать клиент лины, то он то когда был написан... самое что интересное, что он как тормозил на старых видюхах и компах, так же точно и на новых тормозит... но ведь сейчас видеокарты и компы уже не той производительности... но все равно, много объектов наверное не гуд будет...
А теперь посмотрите, что пихают в движек игры и какого он года, ессесно это все будет тормозить даже на топовых конфигурациях ;)

TSR> я все-таки попробую переделать то. что в данный момент ковыряю, разберусь только что к чему... но там есть одно сильное отличие, локация не одна глобальная, а разделена на отдельные карты с тп между картами, в этом есть смысл определенный, в плане тормозов, меньше карта, меньше ресурсов надо... в принципе в лине есть квадраты, которые динамически подгружаются, можно по ним поделить (не обязательно по одному квадрату), ну или попробовать воткнуть динамическое подгружение..
Это называется дальность видимости, сюда же и относится количество полигонов для отрисовки :) А карта разделена на квадарты всего лишь потому-что, не очень good постоянно делать seek по файлу (да и в память такую дуру не загрузишь). Например, представь себе огромную карту, эдак под 1гб, ее можно конечно загрузить в память, но мы ограничены максимум 2гб на приложение (стандарт х32 систем), куда загружать сам движек, временные данные? В конце концов: куда мы будем "читать"/"писать" сетевую часть? Окей, отойдем от кеша на время и посмотрим в сторону seek: нужно будет постоянно перескакивать по файлу (а наш винт далеко не обладает скоростью ОЗУ, даже домашние SSD-диски). Да, можно часть данных кешировать, но получится все равно so slooooow.

Balancer> Я не думаю, что из него получится что-то подходящее. Заточка движка совсем не для MMORPG. И по графической части и по части клиент-серверной.
Balancer> Ты видел на движке Doom III реализацию больших открытых пространств, и хотя бы на полсотни игроков в одном регионе? (не говоря уже про хотя бы сотни NPC).
Можно посмотреть в сторону OGRE/Irrlicht, хотя с последним придется повозиться :) А вообще, написание своего клиента - новые костыли, т.к. тут появляются проблемы с копирастами, длительностью разработки, да и вообще: как-то оно не оправдывает себя.


P.S: скажите приблизительное время, когда собираетесь в конференции. Если я не путаю, то l2jconference.balancer.ru
 9.0.19.0.1

ProGramMoS

новичок
Проект вроде бы поднимается на ноги и в связи с этим решил создать тему о работе с обьектами :) Источник мозгования тут.

Немного информации.
Когда-то давно уже было обсуждение подобной темы (а даже больше ;)), но на другом форуме (ссылка).
В принципе с тех времен мало, что изменилось и вполне реально использовать ORM для работы с базой данных и XML, чисто на вскидку фреймворки: hibernate, castor xml.

Сабж.
И тут у нас возникает одна проблема: будет ли отдача от самого ORM-подхода? Все ORM фреймворки довольно сильно замедляют работу, по сравнению с jdbc, возможно стоит просто сменить пул коннектов на другой (менее багованный) и радостно попивать чай? Я конечно понимаю, что ORM довольно сильно упрощает работу с базой и другими внешними данными, но это все же серверное приложение и оно должно оправдывать свой статус. Писать же свой ORM-фреймворк - [матерное_слово], а точнее изобретение велосипеда с квадратными колесами, т.к. существуют стабильные фреймворки (и с более богатым функционалом), которые серьезно поддерживаются.
Если уж на скорость наплевать (относительно, всегда можно сделать распределенный сервер), то можно и IoC использовать: spring, google guice, etc (которые как раз дают неплохую почву для распределенного сервера).

Таск лист:
1. Установить насколько медленее ORM подход по сравнению с JDBC
2. Проверить потребление ресурсов и скорость работы под критической нагрузкой (около миллиона-двух некеширующих коннектов?)
3. Определить удобность использования IoC-компонентов в нашем случае

P.S: если идти по пути "DAO - везде" - то можно рассмотреть AspectJ препроцессор и уже с помощью него генерировать довольно легковесный код под DAO, причем в независимости от того с чем идет работа: от базы данных до xml. Эдакий четвертый вариант :)
 9.0.19.0.1

в начало страницы | новое
 
Поиск
Настройки
Твиттер сайта
Статистика
Рейтинг@Mail.ru