Re: [Rgdengine-design] Rgdengine-design digest, Vol 1 #6 - 1 msg

[Jihar <ji...@bk...>]

Всем привет!

>>> Хмм, делайте лучше определением имя файла с заглавными буквами, т.е.:
>>> FILEMGR_H, _IFileManager_H_ вообще неуместно.
Anubis>> ОК. Я просто делал на подобии того, что мне послал Jihar -- там было #ifndef _IRender_H_
BA> Хмм, пора договорится о code-styling'е.
Кароч я крайний оказался :))
Да, стиль кодинга пора ввести, давно пора...
Значит предлагаю следующий вариант развития нашего сотрудничества -
пока пишем как можно больше писем в мейл лист, просто надо разобраться
с ним. Потом мы создадим несколько важных тем, первоочередной
важности.

rdrlsn>> Аналогично бралось из посланного мне примера. (И выравнивание тоже:)
BA> Точно пора.
Предлагаю такой вариант ответов на посты в мейл листе. Если нужна
цитата, пишем что-то вроде:

Black Angel:
>Типа цитата

или

<Цитата от Black Angel>
Типа цитата
</Цитата от Black Angel>

или

Цитата от Black Angel:
"Типа цитата"

Здесь я на эту цитату отвечаю. Так будет проще разобраться что, кто и
когда написал. Иначе просто запутаемся, все-таки это не просто
переписка двух человек.

Теперь насчет namespaces. Мое мнение - это хорошая вещь, и суживать ее
до rgdcore нет смысла. Просторанство имен так же разграничивает модули
движка, как и его дизайн, это отличная и мощная чтука. Надо лишь
определиться с количеством этих пространств и тем, что в них будет
содержаться. Все.
Предлагаю такие ограничения - есть главное пространство, rgde.
Остальные будут находиться в нем, но уровень вложений не должен быть
больше двух. Ессно не больше двух для юзверя, при конкретной
реализации можете плодить эти нейм спейсы как хотите (но ессно следите
за этим). Кандидаты на пространства имен:
rgde::core
rgde::renderSystem
rgde::soundSystem
rgde::inputSystem
rgde::networkSystem

Я бы хотел еще для внутренних нужд иметь что-то вроде
rgde::componentObjectModel
rgde::plugin

Возможно  еще  что-то.  Названия  ессно условные, их надо укорачивать,
выслушаю ваши варианты этих названий.

rdrlsn>> У меня core.h нет, я не могу вносить туда изменения... А как тогда надо файл-менеджер определять?
BA> Сейчас Jihar идею подкинул, цитирую:
Jihar>>мм... Вот какая идея в голову пришла. В принципе пакетный файл у тебя
Jihar>>и есть файловый менеджер, верно? Идея ясна? Ессно поясню немного
Jihar>>При создании ядра будем указывать типа:
Jihar>> core->CreateFileManager(Class_Usual, 'c:\games\rda');
Jihar>>Обычный манагер. Путь - откуда ему начинать искать. При открытии файла
Jihar>>ты будешь писать что-то вроде
Jihar>> file_man->OpenFile('data\textures\cube.jpg');
Jihar>>Что-то вроде. Ессно все условно, но думаю мысть понятна.
BA> Тут есть одна проблемка: file_man->OpenFile должен будет вернуть хэндл
BA> файла, который потом будем использовать для чтения и т.п.
Забудь это слово - хендл. У нас не будет такого.

BA> В   принципе   он   может  вернуть  объект  IFile,  который  будет
BA> использоваться   для   работы   с  файлом,
Да, этот вариант и подразумевался.

BA> либо  сам  FileManager  становится  привязан  к открытому файлу, и
BA> работает  только  с  ним. В таком случае повторное открытие любого
BA> файла   (без   закрытия  рабочего)  должно  быть  запрещено.  Если
BA> использовать  2-е  решение с привязкой файла к менеджеру, логичнее
BA> было  бы  отказаться  от  название  File manager и перейти к более
BA> подходящему.
Не-не. ЗАчем такой вариант? Ограничение на максимальное количество
открытых файлов, причем это количество равно ОДНОМУ имхо смысла не
имеет. Возвращаем IFile и все.

Jihar>> core->CreateFileManager(Class_PacketByAngel, 'c:\games\rd\file.pba');
Jihar>>Не обычный манагер. В качестве пути принимает имя пакетного файла,
Jihar>>который и содержит в себе данные. Использование:
Jihar>> file_man->OpenFile('data\textures\cube.jpg');
Jihar>>Ессно использование полностью аналогичное.
Jihar>>Для включения поддержки какого-либо норвого пакетного формата,
Jihar>>достаточно написать плагин и все.
BA> Тут возникнет та же проблема. Либо метод OpenFile вернет объект IFile
BA> для работы с данными, либо менеджер привяжется к одному файлу. Вообщем
BA> думать надо.
Имхо все вполне нормально. Мы можем расплодить огромное количество
объектов - сказат, например, что работа с огл рендером не может быть
такой же, как и с д3д рендером. Вся наша работа и заключается как раз
в том, чтобы уже на данном этапе предоставить юзверю универсальный
набор средств для осздания игры.
Я это называю низко-уровневый набор высоко-уровневых средств :))

BA> imho, необходимо различать работу с файлом на диске и в пакете. Т.е.
BA> не выгодно для работы с этими файлами использовать один интерфейс.
BA> Пакетные файлы придумывались для ускорения работы с данными, а если
BA> при открытии нового файла из пакета, мы будем создавать новый объект,
BA> какое же тут ускорение? Думаю нельзя вводить понятие "open file from
BA> packfile", можно лишь позиционировать менеджер на заданной записи
BA> (файле).
Все ускорение достигается за счет сжатия файла. Не думаю, что вариант,
использующийся в кваке3, добавил какое-то количество лишних
миллисекунд. Ускорение при использованиии пакетных файлов особенно
заметно будет при чтении со всяких сд-ромов. Гораздо быстрее считать с
него 1мб данных и затем распаковать их в 2мб файл, чем считать эти
2мб. Даже то преимущество, что файл мы открываем только один раз (даже
без сжатия), не потеряется при использовании подхода, который я
предложил.

>>> Имхо, нет необходимости использования путей поиска ресурсов. В моем
>>> понимании всё должно быть упаковано в один файл, в крайнем случае
>>> должно быть в одной папке. Хотя тут кому как удобней, не
>>> принципиально.
rdrlsn>> Jihar сказал, что надо...
BA> Надо, так надо :) Я не против.
Опять же, давайте обсудим. Тот подход, который я предложил выше, по
своему устройству не позволяет использовать пути поиска. Какой вариант
лучше я чесс говоря не знаю. В принципе лично мне нравится больше
вариант без путей.

>>>J>         virtual bool RGDE_CALL DeleteFile(char*) = 0; //Deletes a file, passing throw the search path list.
>>>J>                                                       //arguments: file name.
>>> А зачем это если не секрет?
rdrlsn>> Секрет:) Не нужно, наверное, это я сглючил:)
BA> Можно конечно для удаления свопа, но я просто обнулял его размер.

>>> J> #ifndef _IFile_H_
>>> J> #define _IFile_H_
>>> Все интерфейсы относящиеся к уровню ядра логичнее объявлять в одном
>>> файле.
rdrlsn>> Ну и файлик тогда получиться!!!
BA> Не, не большой. На уровне ядра всего-то интерфейсов 5 будет.
Ты имеешь в виду объявить все интерфейсы в одном файле, или всю
функциональность собрать в одном классе? Ну например сам класс core
будет содержать методы файлового менеджера, и мы будем писать
 core->OpenFile
 а не
 file_man->OpenFile
 

rdrlsn>> Однако  один  может  сам  использовать другой, но имхо лучше,
rdrlsn>> если  на  каждый  объект  по файлу -- так удобнее, и файлы не
rdrlsn>> очень большие.
BA> Так куча файлов будет. Вот за это я не люблю DX, взгляни на ОГЛ, вот
BA> где порядок.
Да, большое количество файлов плохо. Но небольшое количество огромных
файлов тоже плохо. Где компромисс? Я не знаю :)

>>> Вывод один: сначала надо выработать стандарты. У меня недели две в
>>> голове летает идея о RGD Evangelion - сборник спецификаций и правил
>>> для разработчиков и основная документация по движку.
>>> Для начала необходимы следующие главы:
>>>     - Project managing
>>>     - Architecture specification
>>>     - Code style
>>>     - Debugging
>>>     - Interfaces specification

rdrlsn>> Может и надо... Я не знаю, я в этом опыта не имел...
BA> Тут вообщем-то ни у кого реального опыта нету :)
Аналогично :D