Menu
▾
▴
rgdengine-design — Design of rgdEngine
You can subscribe to this list here.
| 2004 |
Jan
|
Feb
(3) |
Mar
(27) |
Apr
(5) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|---|
|
From: <ben...@id...> - 2004-05-25 08:41:38
|
Dear Open Source developer I am doing a research project on "Fun and Software Development" in which I kindly invite you to participate. You will find the online survey under http://fasd.ethz.ch/qsf/. The questionnaire consists of 53 questions and you will need about 15 minutes to complete it. With the FASD project (Fun and Software Development) we want to define the motivational significance of fun when software developers decide to engage in Open Source projects. What is special about our research project is that a similar survey is planned with software developers in commercial firms. This procedure allows the immediate comparison between the involved individuals and the conditions of production of these two development models. Thus we hope to obtain substantial new insights to the phenomenon of Open Source Development. With many thanks for your participation, Benno Luthiger PS: The results of the survey will be published under http://www.isu.unizh.ch/fuehrung/blprojects/FASD/. We have set up the mailing list fa...@we... for this study. Please see http://fasd.ethz.ch/qsf/mailinglist_en.html for registration to this mailing list. _______________________________________________________________________ Benno Luthiger Swiss Federal Institute of Technology Zurich 8092 Zurich Mail: benno.luthiger(at)id.ethz.ch _______________________________________________________________________ |
|
From: Anubis <ann...@fr...> - 2004-04-04 04:35:24
|
Привет всем!
Кодировку я сейчас попробую установить...
Про неймспейсы это не ко мне, про количество файлов я свое имхо писал и про интерфейсы тоже... С константами - ну давайте тогда только enum и const.
Вот в том-то и прикол, что совсем в данный момент я почти ни над чем не работаю...:(
Вот с файловой системой (в смысле интерфейсов) все ОК? Тогда с конфигом... Приведите пример конфига, который должен уметь загружать класс конфига... Такой, что ли?:
///////////////////////////////////////////////////////////////////////////////////
[VIDEO]
screenwidth 1024
colorbits 32
depthbits 24
[OPTIONS]
playername "Anubis"
playermodel "Anubis"
sensitivity 4.5
///////////////////////////////////////////////////////////////////////////////////
И надо прописать функции, типа float getFloat(char *groupname, char *paramname), которая на запрос getFloat("OPTIONS", "sensitivity") выдаст 4.5?
Если так, то я могу сделать... Если не так, то я не понял задачу:(
Anubis.
|
|
From: Jihar <ji...@bk...> - 2004-04-03 20:17:07
|
Всем привет! Я извиняюсь за задержки, с которыми отвечаю. Просто сейчас дел навалилось немеряно. > [Jihar] >>Плюс надо что-то решать с кодировкой, потому что она разная у всех, и >>читать архив неудобно. > [/Jihar] [BlackAngel] > Давайте все установим windows-1251, а то я половину писем прочитать не > могу. [/BlackAngel] Я только за :). Только я не в курсе, как мне ее поменять :) Насколько я понял, я автоматически отвечаю в той кодировке, в которой пришло письмо. Если знаешь, как тхе бату прописать кодировку - скажи. [BlackAngel] > Надо бы договорится по ключевым вопросам: > 1) Сколько неймспейсов будет. Я за один единственный, т.к. плодить их [/BlackAngel] Один неймспейс - имхо довольно плохо. Пространства имен позволяют более конкретно чувствовать разделение движка на модули. Причем не факт, что эти модули должны общаться друг с другом (в идеале так и должно быть), те набор модулей - над ними модуль, который ими управляет (rgde::core). Тут дело даже не в повторе всяких констант\методов итд. Дело именно в логическом разделении движка. [BlackAngel] > 2) Условимся о количестве файлов. У движка будет SDK и рабочие файлы. [/BlackAngel] Опять же. Юзверь например просто напишет incude <rgde.h> в котором будут все остальные инклюды. Или он напишет incude <render.h> в котором будут incude <irender.h> incude <itexture.h> incude <imaterial.h> etс те надо лишь определиться, как нам удобнее. Как будет включать файлы юзверь - не наша забота. Мы создадим ему все удобства. Лично мне удобнее, когда файлы небольшие. те один класс - один файл. Ну или парочку классов на файл, если и классы небольшие, и они четко соответствуют какой-либо одной цели. [BlackAngel] > 3) Способ декларирования интерфейсов. Тут либо вариант Jihar'a, либо [/BlackAngel] Думаю мне не надо говорить, какой из этих вариантов мне болше нравится :) [BlackAngel] > 4) Далее договоримся о константах. Два варианта либо enum, либо [/BlackAngel] Предлагаю сразу решить. Мы пишем на С++. Это означает, что мы не пользуем дефайны вообще. Только чтобы не было повторного включения заголовочного файла. Константы - енумы и константы. Да, товарищи. Предлагаю каждому сказать, над чем он сейчас работает в плане ргде. Кому чего не хватает для полноценной работы, над чем надо определиться в срочном порядке итд итп. Мои цели на данный момент. Переписать обертку для ком, чтобы не зависеть от windows.h. Этот файлик должен включаться лишь в файлы реализации. И то только там, где это необходимо (например создание вин окошка). Далее - система плагинов. Она плавно претекает из предыдущего пункта. Для этого мне нужна готовая файловая система и конфиг. Далее - рендер огл. Тут пока проблем нет. Надо лишь дождаться завершения работ над предыдущими пунктами. Значит как будет работать система плагинов. В конфиге будут прописаны существующие плагины. С такими параметрами, как имя, тип (рендер, звук, файловая система итд), гуид, возможно версия, автор и еще какая-нить побочная инфа. Ядро при загрузке считывает конфиг, и запоминает какие плагины доступны. При этом згрузки самих плагинов ессно не происходит (меня лично этим бесит огре - он пока не загрузит д3д7, д3д9 итд не успокаивается. а мне нужен только огл! и загрузка у него очень долгая получается). Это есть конфиг движка. Потом считвается или конфиг игрушки, или ручками указывается, какие плагины загружать. Жду ваших мыслей :)) Анубис - следи, чтобы у тебя в теме стояло Re, когда ты отвечаешь на письмо. Иначе с большой вероятностью создастся новая тема в рассылке, и фиг что там потом поймешь. |
|
From: Anubis <ann...@fr...> - 2004-04-02 14:50:40
|
Привет! 1. Неймспейсы - сами решайте:) 2. По-моему тоже надо каждый класс пихать в отдельный файл, даже в два файла - .h и .cpp. 3. Я по способу BlackAngel'a никогда не писал... Очень неуютно...:) (В первый раз вижу такие конструкции), а вот по Jihar'овски более понятно. 4. Наверное лучше #define'ами. Но у меня нет аргументов... Так в OpenGL сделано:) Anubis. |
|
From: Anton F. <tes...@bk...> - 2004-04-02 10:46:22
|
> Надо бы договорится по ключевым вопросам: > 1) Сколько неймспейсов будет. А что мешает использовать using namespace для нескольких неймспейсов? Смысл неймспейсов - ограничивать область видимости. Если у тебя будет два одинаковых класса/функции в двух модулях движка, то в случае одного неймспейса тебе придется придумывать новое имя, которое возможно отражает меньше смысла. В случае, когда различные модули движка - в разных неймспейсах, такие проблемы будут возникать намного реже. Что бы не писать лишний раз например rgde::core, rgde::audio и т.д., пишем "using namespace rgde::core; using namespace rgde::audio;" > 2) Условимся о количестве файлов. У движка будет SDK и рабочие файлы. > На количество последних в принципе не накладывается никаких > ограничений, конечный пользователь их и не увидет (если внутрь двига > не полезет ессно). Мое мнение: Очень удобно пихать каждый класс (интерфейс) в отдельный файл. И придумать иерархию каталогов - на каждый модуль по каталогу. Не стоит сваливать всё в одну кучу в которой потом трудно разобраться. > 3) Способ декларирования интерфейсов. Тут либо вариант Jihar'a, либо > мой: Вариант джихара мне ближе... Зачем СТОЛЬКО макросов!? :-) > 4) Далее договоримся о константах. Два варианта либо enum, либо > #define. а const? мы же на C++ пишем, или я что-то пропустил? ;-) |
|
From: Black A. <ne...@ud...> - 2004-04-01 19:03:04
|
Hello All,
[Jihar]
>Плюс надо что-то решать с кодировкой, потому что она разная у всех, и
>читать архив неудобно.
[/Jihar]
Давайте все установим windows-1251, а то я половину писем прочитать не
могу.
[Jihar]
>Насчет стиля - у меня щас в времени в обрез просто, я даже никак не
>посмотрю OpenML ангела :(. Как маненько освобожусь, предложу свой
>вариант стиля, пока можете предлагать свои.
[/Jihar]
Там в OpenML не мой стиль, т.е. не тот которого я обычно
придерживаюсь.
Надо бы договорится по ключевым вопросам:
1) Сколько неймспейсов будет. Я за один единственный, т.к. плодить их
не вижу смысла. Сразу скажу, что я не в восторге от конструкций вида
rgde::ICore или lpCore->GetLaLaLa(rgdgpu::Lalala), где тут
преимущества пространства имен? Проще уж IRGDCore, IRGDGPUDRIVER.
Поэтому я предлагаю оставить только пространство rgde, дабы избавится
от префикса rgd в названиях интерфейсов и структур, а сам namespace
активировать using namespace rgde;
2) Условимся о количестве файлов. У движка будет SDK и рабочие файлы.
На количество последних в принципе не накладывается никаких
ограничений, конечный пользователь их и не увидет (если внутрь двига
не полезет ессно). А вот с SDK необходим сдравый смысл, не стоит
повторять подвиг DirectX с его 146 заголовочными файлами. У движка
будет несколько модулей core, engine, render, world и драйверы
устройств. Предлагаю на каждый модуль по заголовочному файлу, все
интерфейсы модуля определены в нем, там же описаны и необходимые
структуры. Также необходим один файл с базовыми типами данных.
3) Способ декларирования интерфейсов. Тут либо вариант Jihar'a, либо
мой:
[Jihar]
interface ICore : public IUnknown
{
virtual HRESULT STDCALL QueryInterface(REFIID riid, void** ppvObj) = 0;
virtual ULONG STDCALL AddRef() = 0;
virtual ULONG STDCALL Release() = 0;
virtual HRESULT STDCALL InitCore(LPRGDEINITSTRUCT lpInitStruct) = 0;
virtual HRESULT STDCALL ShutdownCore() = 0;
...
};
[/Jihar]
[Black Angel]
DECLARE_INTERFACE_(ICore, IUnknown)
{
STDMETHOD(QueryInterface)(THIS_ REFIID riid, void** ppvObj) PURE;
STDMETHOD_(ULONG,AddRef)(THIS) PURE;
STDMETHOD_(ULONG,Release)(THIS) PURE;
STDMETHOD(InitCore)(THIS_ LPRGDEINITSTRUCT lpInitStruct) PURE;
STDMETHOD(ShutdownCore)(THIS) PURE;
};
[/Black Angel]
Тут необходимо учитывать, что читать заголовочные файлы SDK нет
необходимости, все интерфейсы и структуры будут описаны в
документации. Вообщем тут дело вкуса и привычки.
4) Далее договоримся о константах. Два варианта либо enum, либо
#define.
Пока все, но еще много чего надо бы обсудить. Когда сформируем стиль
кода, я запишу его в RGDEvangelion и позднее серъёздные изменения
вноситься уже не будут.
--
Best regards,
Black Angel mailto:ne...@ud...
|
|
From: Anton F. <tes...@bk...> - 2004-03-26 14:00:15
|
> Переделай этот примерчик, как ты считаешь нужным, и посылай, если никто
ничего не исправит еще, то мы это дело будем считать законченным:)
#ifndef _HEADER_H_
#define _HEADER_H_
namespace a
{
namespace b
{
class AlphaClass
{
};
class IBetaClass
{
};
class Class : private AlphaClass, public IBetaClass
{
public:
virtual bool Method(int _SuperParm1, float _SuperParm2);
float GetX();
void SetX(float);
private:
float m_fSomething;
};
};
};
namespace x
{
namespace y
{
namespace z
{
namespace w
{
int Function(int);
float SecondFunction(float);
}; // namespace w
}; // namespace z
}; // namespace y
}; // namespace x
#endif //#ifndef Header_h
//Как писать комментарии -- по правилам doxygen'а
//Это пример реализации:
#include "header.h"
Class someClass;
namespace a
{
namespace b
{
bool Class::Method(int _SuperParm1, float _SuperParm2)
{
for(int i=1;i>0;i++)
{
i-=2;
}
Class megoClone(*this);
int superInteger;
} // Method (имя метода)
} // namespace a
} // namespace b
|
|
From: Anubis <ann...@fr...> - 2004-03-26 10:50:46
|
Всем привет! Антон: >Тебе действительно удобнее с С, чем без нее? Нет, мне так привычнее:) Я не настаиваю, можно и без C, но главное - нужно договориться как именно:) Ждем мнения других участников Антон: >Отступы неймспесов... Аналогично... я вообще с неймспейсами раньше не работал, и мне все-равно - даже нет привычки писать так или эдак... Антон: >Еще имеет смысл писать не только типы параметров функций Аналогично:) Антон: >Про for - это для компиляции 6-ой студией? :) Есть метод лечения этой болезни одним дефайном. Прочитать про него можно тут: Метод-то есть, но имхо надо писать именно так:) Здесь мне кажется, это даже чуть-чуть важно в отличии от всего остального, что я там написал:) Антон: >Про глобальные функции - я так обычно локальные переменные обьявляю :) Может лучше по-другому? Например как и функции-члены классов. Аналогично первым трем:) Переделай этот примерчик, как ты считаешь нужным, и посылай, если никто ничего не исправит еще, то мы это дело будем считать законченным:) Anubis. |
|
From: Anubis <ann...@fr...> - 2004-03-25 20:47:13
|
Всем привет! Если за ближайшие пять часов кто-нибудь что-нибудь мне писал - просьба переслать мне еще раз, так как при приеме писем комп ресетнулся, и их нет ни на компе, ни на сервере. Anubis |
|
From: Anton F. <tes...@bk...> - 2004-03-25 20:02:37
|
Несколько комментариев: - Отступы неймспесов... пустая трата места на экране по-моему. Чаще всего (если не всегда) в одном заголовочном файле будет обьявлены классы/функции только из одного неймспейса, так что полезность фичи стремится к нулю... - Про I джихар меня убедил... :) Но зачем имена классов начинать с C? Имхо совсем ненужная фича :\ Тебе действительно удобнее с С, чем без нее? - Еще имеет смысл писать не только типы параметров функций, но и имена со смыслом, а то потом в чужом коде бывает ооочень трудно разобраться. Вроде как решили использовать стиль из STL - т.е. SetDepthBias(float _DepthBias) например. Даже без комментариев понятно, для чего нужен данный метод и параметр. - Про for - это для компиляции 6-ой студией? :) Есть метод лечения этой болезни одним дефайном. Прочитать про него можно тут: http://www.flipcode.com/cgi-bin/msg.cgi?showThread=Tip-MSVCFor&forum=totd&id=-1. - Про глобальные функции - я так обычно локальные переменные обьявляю :) Может лучше по-другому? Например как и функции-члены классов. |
|
From: Anubis <ann...@fr...> - 2004-03-24 19:31:29
|
Привет всем! У меня сейчас есть немного времени, и, если бы я знал, что такое code-styling, я бы может чего-нибудь и сделал бы... Пока я могу такое только накатать (см. вложение). Вот такие ламеровые дела... Anubis. |
|
From: Anubis <ann...@fr...> - 2004-03-24 19:29:15
|
Привет всем! У меня сейчас есть немного времени, и, если бы я знал, что такое code-styling, я бы может чего-нибудь и сделал бы... Пока я могу такое только накатать (см. вложение). Вот такие ламеровые дела... Anubis. |
|
From: Anubis <ann...@fr...> - 2004-03-20 09:43:53
|
Всем привет. Нет, Антон писал именно про мой стиль -- несколько писем назад я приводил пример своего кода. Там буквы C перед названиями классов, а интерфейсов там нет:) Так что я отвечаю... Точнее, комментирую, все это отвечается одним -- "я так привык" или "мне так удобнее". Так как я постил пример своего кода, а не то, чем я хочу сделать стиль. Я принимаю любые изменения этого стиля. Jihar: А зачем ты все читаешь по архиву мейл-листа, а не просто?!! Jihar wrote: >Вообще был бы рад, если бы вы все поставили себе бат. У меня Outlook работает только на прием почты, а отправлять приходиться вообще через браузер:( -- глючит у меня все:(. Anubis. |
|
From: Jihar <ji...@bk...> - 2004-03-20 05:22:44
|
Anton wrote: > Несколько вопросов (можно назвать замечаниями ;)) по поводу стиля > Анубиса: Скорее всего это стиль, навязанный мной, так что я и буду отвечать. Anton wrote: > - Зачем писать букву C/I перед именем класса/интерфейса? Заметь - С не пишем, пишем I. I означает интерфейс, и на уровне интерфейсов мы и работаем. Так же будет работать и юзверь. Лично мне нравится буква I в начале по одной причине - я называю объект этого класса без I и остаюсь доволен :) IRender *Render; вместо Render *render; I дает чуть больше информации о классею Anton wrote: > - Может не стоит мешать переменные и методы класса? А например > сначала описывать методы, затем переменные. ИМХО код в таком случае > будет более читаемым. Мой вариант. Переменных в паблик части быть не должно. В приват - как хотите и зачем хотите. Это ессно относится только к интерфейсам. Конкретная реализация ничем не ограничивается, лишь разумными рамками. Так что стоит перечислят класс в таком порядке : паблик методы, протектид методы, приватные методы, приватные переменные. Anton wrote: > Вот... предлагаю такой стиль... Вот теперь залезь в архив мейл-листа, и посмотри, что ты предложил. Не стоит писать письма в мейл-лист в html. Вообще был бы рад, если бы вы все поставили себе бат. |
|
From: Anton F. <tes...@bk...> - 2004-03-19 17:05:46
|
=EE=C5=D3=CB=CF=CC=D8=CB=CF =D7=CF=D0=D2=CF=D3=CF=D7 (=CD=CF=D6=CE=CF =
=CE=C1=DA=D7=C1=D4=D8 =DA=C1=CD=C5=DE=C1=CE=C9=D1=CD=C9 ;)) =D0=CF =
=D0=CF=D7=CF=C4=D5 =D3=D4=C9=CC=D1 =E1=CE=D5=C2=C9=D3=C1:
- =FA=C1=DE=C5=CD =D0=C9=D3=C1=D4=D8 =C2=D5=CB=D7=D5 C/I =
=D0=C5=D2=C5=C4 =C9=CD=C5=CE=C5=CD =
=CB=CC=C1=D3=D3=C1/=C9=CE=D4=C5=D2=C6=C5=CA=D3=C1?
- =ED=CF=D6=C5=D4 =CE=C5 =D3=D4=CF=C9=D4 =CD=C5=DB=C1=D4=D8 =
=D0=C5=D2=C5=CD=C5=CE=CE=D9=C5 =C9 =CD=C5=D4=CF=C4=D9 =
=CB=CC=C1=D3=D3=C1? =E1 =CE=C1=D0=D2=C9=CD=C5=D2 =D3=CE=C1=DE=C1=CC=C1 =
=CF=D0=C9=D3=D9=D7=C1=D4=D8 =CD=C5=D4=CF=C4=D9, =DA=C1=D4=C5=CD =
=D0=C5=D2=C5=CD=C5=CE=CE=D9=C5. =E9=ED=E8=EF =CB=CF=C4 =D7 =
=D4=C1=CB=CF=CD =D3=CC=D5=DE=C1=C5 =C2=D5=C4=C5=D4 =C2=CF=CC=C5=C5 =
=DE=C9=D4=C1=C5=CD=D9=CD.
=F7=CF=D4... =D0=D2=C5=C4=CC=C1=C7=C1=C0 =D4=C1=CB=CF=CA =
=D3=D4=C9=CC=D8...
=FA=C1=C7=CF=CC=CF=D7=CF=DE=CE=D9=CA =C6=C1=CA=CC:
-------------------------------------------------------------------------=
-------
#pragma once
=20
// =C9=CD=C5=CE=C1 =CE=C5=CA=CD=D3=D0=C5=D3=CF=D7 - =C9=DA =
=CD=C1=CC=C5=CE=D8=CB=C9=C8 =C2=D5=CB=D7, =DE=D4=CF =C2=D9 =CE=C5 =
=D0=D5=D4=C1=D4=D8 =D3 =CB=CC=C1=D3=D3=C1=CD=C9
// =C4=CC=D1 =D2=C1=DA=C4=C5=CC=C5=CE=C9=D1 =D3=CC=CF=D7 - =
=CE=C9=D6=CE=C5=C5 =D0=CF=C4=DE=C5=D2=CB=C9=D7=C1=CE=C9=C5
namespace ns_one=20
{
namespace ns2
{
=20
// =E9=CD=C5=CE=C1 =CB=CC=C1=D3=D3=CF=D7 - =
=CE=C9=DE=C9=CE=C1=C0=D4=D3=D1 =D3 =C2=CF=CC=D8=DB=CF=CA =
=C2=D5=CB=D7=D9, =
=F3=CC=CF=D7=C1=F2=C1=DA=C4=C5=CC=D1=C0=D4=D3=D1=F4=C1=CB.
class SomeClass
{
public:
// =F0=D2=C1=D7=C9=CC=C1 =C4=CC=D1 =C9=CD=C5=CE =
=C6=D5=CE=CB=C3=C9=CA - =D4=C1=CB=C9=C5 =D6=C5, =CB=C1=CB =C9 =C4=CC=D1 =
=C9=CD=C5=CE =CB=CC=C1=D3=D3=CF=D7.
void PubMethod();
=20
protected:
char* ProtectedMethod(int _Parm);
=20
private:
// =C5=D3=CC=C9 =D3=D4=D2=CF=CB=C1 =CE=C5=C2=CF=CC=D8=DB=C1=D1, =
=D4=CF =CE=C5 =D2=C1=DA=C2=C9=D7=C1=C5=D4=D3=D1 =CE=C1 =
=CE=C5=D3=CB=CF=CC=D8=CB=CF =D3=D4=D2=CF=CB
const SomeClass& PrivateMethod(char _Parm1, int _Parm2) =
throw(SomeException);
=20
// =C5=D3=CC=C9 =D3=D4=D2=CF=CB=C1 =D0=CF=CC=D5=DE=C1=C5=D4=D3=D1 =
=C2=CF=CC=D8=DB=C1=D1, =D4=CF =D3=D4=CF=C9=D4 =C5=A3 =
=D2=C1=DA=C2=C9=D4=D8 =CE=C1 =CE=C5=D3=CB=CF=CC=D8=CB=CF =
=D3=D4=D2=CF=CB,
// =CE=CF =D3=D4=D2=CF=C7=C9=C8 =D0=D2=C1=D7=C9=CC =C9=CD=C8=CF =
=CE=C5 =D4=D2=C5=C2=D5=C5=D4=D3=D1.
const SomeClass& PrivateMethod(char _Parm1, float _Parm3,
VeryLongClassName _LongParmName,
int _Parm2)
throw(SomeException);
=20
public:
int m_PubVar; // Rare! ;)
=20
protected:
char m_ProtectedVar;
=20
private:
SomeClass *m_PrivateVar;
};
=20
// =F4=C5=CD=D0=CC=C5=CA=D4=D9...
// =C4=CC=D1 =D0=C1=D2=C1=CD=C5=D4=D2=CF=D7=D3=C1=CD =D1 =
=C9=D3=D0=CF=CC=D8=DA=D5=C0 =D0=D2=CF=D3=D4=CF =C2=CF=CC=D8=DB=C9=C5 =
=C2=D5=CB=D7=D9 - typename T =CE=C1=D0=D2=C9=CD=C5=D2,=20
// =CE=CF =C9=CD=C8=CF =D0=CF=CC=C5=DA=CE=CF =C2=D5=C4=C5=D4 =
=D5=CB=C1=DA=D9=D7=C1=D4=D8 =CB=C1=CB=C9=C5-=CE=C9=C2=D5=C4=D8 =
=C9=CD=C5=CE=C1 =D3=CF =D3=CD=D9=D3=CC=CF=CD =C4=CC=D1 =
=D0=C1=D2=C1=CD=C5=D4=D2=CF=D7 =DB=C1=C2=CC=CF=CE=C1.
//
// =F0=CF=D3=CB=CF=CC=D8=CB=D5 =D3=CC=CF=D7=C1 template, typename - =
=C4=CC=C9=CE=CE=D9=C5, =D4=CF =D7=D9=D2=C1=D6=C5=CE=C9=C5
// template<typename t_Name1, typename t_Name2> =D7=D3=C5=C7=C4=C1 =
=D0=C9=DB=C5=D4=D3=D1 =CE=C1 =CF=D4=C4=C5=CC=D8=CE=CF=CA =
=D3=D4=D2=CF=CB=C5.
template<typename t_Name1, typename t_Name2>
class TAnotherClass
{
// ...
};
=20
} // namespace ns2
} // namespace ns_one
=20
#include "ClassName.inl"
-------------------------------------------------------------------------=
-------
=20
*.INL =C6=C1=CA=CC:
-------------------------------------------------------------------------=
-------
namespace ns_one
{
namespace ns2
{
=20
template<typename t_Name1, typename t_Name2>
void TAnotherClass<t_Name1, t_Name2>::SomeMethod(t_Name1 _SomeParm)
{
Matrix4x4 projectionMatrix; // =E9=CD=C5=CE=C1 =CB=CC=C1=D3=D3=CF=D7 =
- =CE=C1=DE=C9=CE=C1=C0=D4=D3=D1 =D3 =C2=CF=CC=D8=DB=CF=CA =
=C2=D5=CB=D7=D9, =C9=CD=C5=CE=C1
// =D0=C5=D2=C5=CD=C5=CE=CE=D9=C8 - =D3 =
=CD=C1=CC=C5=CE=D8=CB=CF=CA.
// ...
}
=20
} // namespace ns2
} // namespace ns_one
-------------------------------------------------------------------------=
-------
=20
*.CPP =C6=C1=CA=CC:=20
-------------------------------------------------------------------------=
-------
namespace ns_one
{
namespace ns2
{
=20
void SomeClass::PubMethod()
{
// ...
}=20
=20
} // namespace ns2
} // namespace ns_one
-------------------------------------------------------------------------=
-------
|
|
From: Jihar <ji...@bk...> - 2004-03-19 12:09:54
|
Hello Anubis, Monday, March 15, 2004, 11:01:40 PM, you wrote: A> Всем привет! A> В общем, я начну работать с интерфейсом, а потом может и A> реализацией конфига, как только получу такой примерчик кода, на A> который можно смотреть при написании кода. A> Вот такие вот дела... A> Anubis Так... Для начала - какой у тебя почтовик? Посмотри, какие бешеные названия тем он генерит в архиве мейл-листа! Плюс надо что-то решать с кодировкой, потому что она разная у всех, и читать архив неудобно. Насчет стиля - у меня щас в времени в обрез просто, я даже никак не посмотрю OpenML ангела :(. Как маненько освобожусь, предложу свой вариант стиля, пока можете предлагать свои. |
|
From: Anubis <ann...@fr...> - 2004-03-15 19:55:47
|
Всем привет! В общем, я начну работать с интерфейсом, а потом может и реализацией конфига, как только получу такой примерчик кода, на который можно смотреть при написании кода. Вот такие вот дела... Anubis |
|
From: Anton F. <tes...@bk...> - 2004-03-14 13:59:13
|
отвечаю :) J> Кароче! J> Последний тест!!! J> Еще раз повторяю - все, кто подписан, ответьте! Ну займет от силы J> минуту, сложно что-ли? |
|
From: Anubis <ann...@fr...> - 2004-03-14 12:08:53
|
Всем привет! <Цитата от Jihar> Кароч я крайний оказался :)) </Цитата от Jihar> так, что ли цитировать? Как-то все это набирать долго...:) Еще вот так можно продолжить: <Ответ на цитату от Jihar> Надо же на кого-то свалить... </Ответ на цитату от Jihar> <Цитата от Jihar> Да, стиль кодинга пора ввести, давно пора... Значит предлагаю следующий вариант развития нашего сотрудничества - пока пишем как можно больше писем в мейл лист, просто надо разобраться с ним. Потом мы создадим несколько важных тем, первоочередной важности.> </Цитата от Jihar> А если отвечаешь на тему, то не надо менять поле "Тeма", да? то есть так и оставить "Re: [Rgdengine-design] Rgdengine-design digest, Vol 1 #6 - 1 msg"? <Цитата от Jihar> Опять же, давайте обсудим. Тот подход, который я предложил выше, по своему устройству не позволяет использовать пути поиска. Какой вариант лучше я чесс говоря не знаю. В принципе лично мне нравится больше вариант без путей. </Цитата от Jihar> Давайте буз путей... Как-то спокойней:) <Цитата от Jihar> Да, большое количество файлов плохо. Но небольшое количество огромных файлов тоже плохо. Где компромисс? Я не знаю :) </Цитата от Jihar> Как я уже написал в другом ответе имхо лучше большое количество файлов, чем их большой размер... Anubis ЗЫ А почему я rdrlsn'ом зовусь?:) |
|
From: Anubis <ann...@fr...> - 2004-03-14 11:47:52
|
Всем привет! Это ответ на письмо Ангела:
>Хмм, пора договорится о code-styling'е.
Пора... Но мне, если честно, все равно, как писать (лишь бы точно сказали, "как":) Так что, когда договоритесь, то пришлите мне примерчик
идеального кода:) Вот, как я пишу:
Это файл a_configfile.h:
/****************************************************
* Copyright (c) 2004 - A&A Corporation *
* A_ConfigFile header file in which CA_ConfigFile class is defined *
*****************************************************/
#ifndef _A_Config_File_h__
#define _A_Config_File_h__
#include "A_Object.h"
class CA_ConfigFile : public CA_Object
{
public:
CA_ConfigFile(char*);
char opened, notend;
char *command, *prevcommand;
char *GetNextCommand();
char *GetCommand();
FILE *file;
virtual ~CA_ConfigFile();
};
#endif //#ifndef _A_Config_File_h__
И пример реализации метода:
char *CA_ConfigFile::GetNextCommand()
{
delete[]prevcommand;
prevcommand = new char[strlen(command)+1];
memcpy(prevcommand, command, strlen(command)+1);
command = GetCommand();
while((!command)&&(notend)) command = GetCommand();
return prevcommand;
}
Ну, это так, если интересно...
>Чтение и запись. А что особенного, так своп-файл работает.
Ясно...
>rdrlsn> У меня core.h нет, я не могу вносить туда изменения... А как тогда надо файл-менеджер определять?
>Сейчас Jihar идею подкинул, цитирую:
>Jihar>мм... Вот какая идея в голову пришла. В принципе пакетный файл у тебя
>Jihar>и есть файловый менеджер, верно? Идея ясна? Ессно поясню немного
>Jihar>При создании ядра будем указывать типа:
>Jihar> core->CreateFileManager(Class_Usual, 'c:\games\rda');
>Jihar>Обычный манагер. Путь - откуда ему начинать искать. При открытии файла
>Jihar>ты будешь писать что-то вроде
>Jihar> file_man->OpenFile('data\textures\cube.jpg');
>Jihar>Что-то вроде. Ессно все условно, но думаю мысть понятна.
>Тут есть одна проблемка: file_man->OpenFile должен будет вернуть хэндл
>файла, который потом будем использовать для чтения и т.п. В принципе
>он может вернуть объект IFile, который будет использоваться для работы
>с файлом, либо сам FileManager становится привязан к открытому файлу,
>и работает только с ним. В таком случае повторное открытие любого
>файла (без закрытия рабочего) должно быть запрещено. Если использовать
>2-е решение с привязкой файла к менеджеру, логичнее было бы отказаться
>от название File manager и перейти к более подходящему.
имхо OpenFile должен возвращать IFile*, и открывать сколько угодно файлов одним менеджером... Иначе какой это нафиг менеджер, если только с одним файлом работает:)
>Jihar> core->CreateFileManager(Class_PacketByAngel, 'c:\games\rd\file.pba');
>Jihar>Не обычный манагер. В качестве пути принимает имя пакетного файла,
>Jihar>который и содержит в себе данные. Использование:
>Jihar> file_man->OpenFile('data\textures\cube.jpg');
>Jihar>Ессно использование полностью аналогичное.
>Jihar>Для включения поддержки какого-либо норвого пакетного формата,
>Jihar>достаточно написать плагин и все.
>Тут возникнет та же проблема. Либо метод OpenFile вернет объект IFile
>для работы с данными, либо менеджер привяжется к одному файлу. Вообщем
>думать надо.
>imho, необходимо различать работу с файлом на диске и в пакете. Т.е.
>не выгодно для работы с этими файлами использовать один интерфейс.
>Пакетные файлы придумывались для ускорения работы с данными, а если
>при открытии нового файла из пакета, мы будем создавать новый объект,
>какое же тут ускорение? Думаю нельзя вводить понятие "open file from
>packfile", можно лишь позиционировать менеджер на заданной записи
>(файле).
А тут мне и вариант Jihar'а нравиться, и твое замечание в тему... Прямо не знаю, за что и проголосовать:)
>>> Имхо, нет необходимости использования путей поиска ресурсов. В моем
>>> понимании всё должно быть упаковано в один файл, в крайнем случае
>>> должно быть в одной папке. Хотя тут кому как удобней, не
>>> принципиально.
>rdrlsn> Jihar сказал, что надо...
>Надо, так надо :) Я не против.
А может и не надо:) В общем, у себя в программах я реализовываю без списка путей, хотя это может быть и полезная вещь...
>>>J> virtual bool RGDE_CALL DeleteFile(char*) = 0; //Deletes a file, passing throw the search path list.
>>>J> //arguments: file name.
>>> А зачем это если не секрет?
>rdrlsn> Секрет:) Не нужно, наверное, это я сглючил:)
>Можно конечно для удаления свопа, но я просто обнулял его размер.
Пускай останется... Не жалко...
>>> J> #ifndef _IFile_H_
>>> J> #define _IFile_H_
>>> Все интерфейсы относящиеся к уровню ядра логичнее объявлять в одном
>>> файле.
>rdrlsn> Ну и файлик тогда получиться!!!
>Не, не большой. На уровне ядра всего-то интерфейсов 5 будет.
А что это за интерфейсы? И на уровне чего будут остальные?
>rdrlsn> Однако один может сам использовать другой, но имхо лучше, если на каждый объект по файлу -- так удобнее, и файлы не очень большие.
>Так куча файлов будет. Вот за это я не люблю DX, взгляни на ОГЛ, вот
>где порядок.
Порядок у них только потому, что там куча объявлений функций, а если это будут объявления классов с реализациями всех методов, то имхо код будет дико нечитабельный. А так: файл configfile.h -- класс CConfigFile, файл renderer.h -- класс CRenderer и т.д. все понятно и удобно. А все файлы распихать по куче директорий пятерной вложенности и все будет очень серьезно выглядеть:)
>>> Чем SEEK_CUR, SEEK_SET, SEEK_END неустраивает? Так вобщем-то все
>>> привыкли.
>rdrlsn> Так ведь будет конфликт с уже определенными SEEK_CUR, SEEK_SET, SEEK_END?
>А нэймспейсы зачем? К тому же stdio будет подцеплятся только в
>реализации файловых объектов.
Ну дык в реализации встретиться что-нибудь, типа этого:
CWinFile::Seek(position, int num)
{
if(position==SEEK_CUR) fseek(file, SEEK_CUR, num) ...
...
}
Неужели не будет конфликта?
>rdrlsn> А как же недвоичный вывод? Вручную float'ы в строки превращать?
>А зечем это? Если в лог или настройки, то fprintf.
А зачем тогда вообще IFile?:) Если файл карты или модельки, то fwrite:) Если уж делать единый интерфейс для работы с файлами, так делать...
>>> Еще не учел, что файл может быть пакетный открыт. Надо
>>> добавить методы для позиционирования на заданной записи и
>>> т.п.
>rdrlsn> Не понял... Не знаю, что это такое -- все предложение в целом:(
>Ну пакетный файл - это файл в котором упакованы множество других файлов
>(см. квейковский pak).
Ясно, но не совсем... А после позиционирования на записи мы будем работать с этим IFile так, как будто это обычный открытый файл, тот, который лежит на данной позиции в пакетном?
>>> Вывод один: сначала надо выработать стандарты. У меня недели две в
>>> голове летает идея о RGD Evangelion - сборник спецификаций и правил
>>> для разработчиков и основная документация по движку.
>>> Для начала необходимы следующие главы:
>>> - Project managing
>>> - Architecture specification
>>> - Code style
>>> - Debugging
>>> - Interfaces specification
>rdrlsn> Может и надо... Я не знаю, я в этом опыта не имел...
>Тут вообщем-то ни у кого реального опыта нету :)
Ну, тогда, вперед...:)
Anubis.
|
|
From: Jihar <ji...@bk...> - 2004-03-14 11:20:18
|
Это я просто проверяю... |
|
From: Jihar <ji...@bk...> - 2004-03-14 11:15:52
|
Блин, только сейчас до меня дошло :)) Тема у тебя такая, потому что ты ее не поправил. В поле тема надо писать именно то, что надо. Те например Re:test, а не просто тест (ты написал просто, и создалась отдельная тема). Вот :) |
|
From: Jihar <ji...@bk...> - 2004-03-14 11:06:59
|
Всем привет!
>>> Хмм, делайте лучше определением имя файла с заглавными буквами, т.е.:
>>> 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
|
|
From: Jihar <ji...@bk...> - 2004-03-14 10:29:29
|
Hello Black, Sunday, March 14, 2004, 12:28:13 PM, you wrote: BA> Hello Jihar, BA> Что-то я не совсем понимаю как mail-list работает. BA> Поля Vol 1 #6 - 1 msg править самому надо? Чесс говоря я еще не до конца с ним разобрался. Я просто указываю тему, если я отвечаю на письмо, то пишу RE и номер этого РЕ. Кстати сразу скажу, чтобы не путаться что и как, в настройках укажите дайджест, тогда вам будет приходить не каждый ответ, а кучка ответов, собранная в дайджест. Если кто не знает, как изменить настройки, скажите, я сам подправлю. Да, зачем тебе эти поля? Пишите просто тему и все. Причем в теме писать [Rgdengine-design] не обязательно. Возможно правда это лист подставляет, я хз... Вот кстати архив: http://sourceforge.net/mailarchive/forum.php?forum=rgdengine-design -- Best regards, Jihar mailto:ji...@bk... |
|
From: Black A. <ne...@ud...> - 2004-03-14 09:28:55
|
Hello Jihar, Что-то я не совсем понимаю как mail-list работает. Поля Vol 1 #6 - 1 msg править самому надо? -- Best regards, Black Angel mailto:ne...@ud... |
