MysticCoder написал:
Я решил применить компонентный подход для юнитов. Если кто не знает, это когда логика класса разделена по своим ролям на другие классы.

MysticCoder написал:
Ну, может быть, в твоей вселенной это и так, а в моей вселенной, пусть будет так как я думаю) Если хочешь, могу исходники выложить, глянешь, компонентный у меня подход или некомпонентный. Мне вот кажется - компонентный. Декораторами тут даже и не пахнет вроде, хотя если я правильно понял, любой класс можно обозвать декоратором для TObject и быть довольным.

AtomKrieg написал:
Реализовывал небольшую игру через компоненты и пришел к выводу что полиморфизм и наследование идут лесом при использовании компонент.

bsivko написал:

Лес замечательно живет с компонентами.

MysticCoder написал:судя по активности, здесь мало кому интересны технические подробности которые я выкладываю, видимо плюшек подавай да красивостей, поэтому посты будут реже и если будет что показать.

var
List : TSomeObjectList; // список с которым работает 2 потока
procedure ThreadOne;
var
SomeObject : TSomeObject;
begin
while true do
begin
SomeObject := List[0]; // берем нулевой обьект из списка
SomeObject.DoSomething; // а здесь он иногда оказывается нелегитимным
end;
end;

procedure ThreadTwo;
begin
while true do
begin
....
List.Add(OtherObject); // этот поток просто иногда добавляет в список новый обьект.
end;
end;

T_NetDiffRec = class
pVariable : Pointer; // указатель на поле, которое необходимо контролировать
pOldVariable : Pointer; // второе хранилище, в нем хранится "старое" значение поля
Size : integer; // размер поля
FromClientAgreed : Boolean; // Этим флагом обозначаются поля которые серв может принимать от клиента. Например, Серв не должен принимать от клиента поле Life, но может принять wasd кнопки.
constructor Create(AVariable : Pointer; ASize : integer);
function IsDiffed : boolean; // есть ли изменение поля?
procedure Update; // синхронизировать поле с его хранилищем
end;

...
RegisterNetDiffVar(@LookAngle, SizeOf(LookAngle), True);

Ну, тем интереснее будет мне узнать насколько мой код прозрачен и читабелен :)

продуктивнее было бы форк-небольшой чейндж- пулреквест

Ну, тем интереснее будет мне узнать насколько мой код прозрачен и читабелен :)

Daemon написал:
Порицать за glut и glBegin/glEnd можно? И в целом за код рисования прямо в юнитах, без абстракций?

Daemon написал:
phomm

Да тут не обойтись мелкими патчами, "господь, жги!" :) В целом архитектура несколько неудачная. Именно по части рендера. Если рендер тестовый, то все равно его стоило инкапсулировать где-то единожды, чтобы потом поменять его без особых проблем.

phomm написал:

За сим решил пока не продолжать а послушать инструкций от автора.

Darthman написал:

Отсуствие у филдов префикса F, четкого разделения области видимости, отсуствие пропертей и странные укороченные названия не добавляют читаемости и удобства в использовании твоего кода. Это уж точно.
Кстати, а зачем все модули называть с подчеркивания? что за мания такая?

ZblCoder написал:
Да, код немного странный. Любовь к символу "_" заметна сразу.

procedure _LoadMaterials;

T_Mesh = class

procedure T_Mesh.Draw;

хоть А ставит в названии входных параметров.

function T_Map.AddUnit(AUnit: TObject; ADoGenerateID: boolean): TObject;

TObject у юнита? Сделал бы кастомный класс юнита, что ли.

так же, нет деструкторов у классов, это БЕЗУМИЕ.
пример:
убивать созданный TList кто будет?

constructor TS_TextureManager.Create;

begin

  Textures := TList.Create;

end;

Darthman написал:
Если до сих пор возникают проблемы перекрестных ссылок, значит что-то пишется до сих пор неверно.

Давай, порицай, излагай поподробнее, что да как тебе не нравится и как бы ты это поменял. А то я нуб и не очень понимаю, что за код рисования прямо в юнитах без абстракций, и как рендер инкапсулировать?