- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 66
- 67
- 68
- 69
- 70
- 71
- 72
- 73
- 74
- 75
- 76
- 77
- 78
- 79
- 80
- 81
- 82
- 83
- 84
- 85
- 86
- 87
- 88
- 89
- 90
- 91
- 92
- 93
- 94
- 95
Assign(F, FileName);
IOResult;
Reset(F);
if IOResult = 0 then begin
for i := 0 to MaxModelNamesCount-1 do ModelKind[i] := mkVagon;
Result := True;
BlockRead(F, W, 2);
if W = OldWDim then begin // старый формат
// 20 строк пропущено
end else if W = WDim then begin // новый формат
BlockRead(F, FormatVersion, 4); // версия нового формата
if FormatVersion <= 4 then begin
BlockRead(F, EditorDate, 4);
BlockRead(F, C, 4);
LCount := C;
for i := 0 to LCount - 1 do begin
BlockReadLine(F, Lines[i], 16);
if (FormatVersion <= 2) and (Lines[i].Attr[3] and $0F = 5) then Lines[i].Attr[0] := 0
else if (Lines[i].Attr[3] and $0F = k3DObject) then ModelKind[Lines[i].IntAttr[1]] := mkStatic;
end;
if FormatVersion <= 1 then begin
ModelNamesCount := 8; // для 1й версии список жёстко задан
ModelNames[0] := 'ГЗРВ-10';
ModelNames[1] := 'ГЗРВ-10М';
ModelNames[2] := 'КТМ-5М3';
ModelNames[3] := 'ЛМ-68';
ModelNames[4] := 'ЛМ-68М';
ModelNames[5] := 'ЛМ-68ММ';
ModelNames[6] := 'ЛВС-86';
ModelNames[7] := 'ЛВС-97';
for i := 8 to MaxModelNamesCount-1 do ModelNames[i] := '';
end else if FormatVersion <= 3 then begin
ModelNamesCount := 0;
for i := 0 to 255 do begin
j := 0;
BlockRead(F, j, 1);
SetLength(ModelNames[i], j);
for j := 1 to Length(ModelNames[i]) do Read(F, byte(ModelNames[i, j]));
if ModelNames[i] <> '' then Inc(ModelNamesCount);
end;
end else begin
BlockRead(F, ModelNamesCount, 4); // кол-во моделей
for i := 0 to MaxModelNamesCount - 1 do ModelNames[i] := '';
for i := 0 to ModelNamesCount-1 do begin
BlockRead(F, k, 4); // номер считываемой модели
j := 0;
BlockRead(F, j, 1); // длина имени, не более 255
SetLength(ModelNames[k], j);
for j := 1 to Length(ModelNames[k]) do Read(F, byte(ModelNames[k, j]));
end;
end;
for i := 0 to 8 do
for j := 0 to 12 + Byte(FormatVersion >= 2) do with Routes[i, j] do begin
BlockRead(F, PCount, 2);
SetAllowedModels(Routes[i,j], 0, -1);
if FormatVersion <= 1 then begin
BS := [];
BlockRead(F, BS, 4);
AllowedModelsCount := 0;
for k := 0 to 255 do if k in BS then begin
Inc(AllowedModelsCount);
AllowedModels[k] := True;
end;
end else if FormatVersion <= 3 then begin
BlockRead(F, BS, 32);
AllowedModelsCount := 0;
for k := 0 to 255 do if k in BS then begin
Inc(AllowedModelsCount);
AllowedModels[k] := True;
end;
end else begin
BlockRead(F, AllowedModelsCount, 4);
for k := 0 to AllowedModelsCount-1 do begin
BlockRead(F, n, 4); // номер модели
AllowedModels[n] := True;
end;
end;
for k := 0 to PCount - 1 do begin
if FormatVersion >= 3 then BlockRead(F, c, 4)
else begin
c := 0;
BlockRead(F, c, 2);
end;
Points[k] := c;
end;
BlockRead(F, DefVagons, 1);
SpeedRoute := boolean(DefVagons shr 4);
DefVagons := DefVagons and $0F;
BlockRead(F, Interval, 1);
end;
end else Result := False;
end else Result := False;
Close(F);
Короче, лапша из if FormatVesion такой-то...
Обратная совместимость формата файла.
Формату уже 4 года.
Follow us!
Где смеяться-то?
немного доставил руглиш с вагоном
Ну короче я просто хотел сказать, в какое говнище и портянку из непонятных условий превращается поддержка (даже в одну сторону) всей файловых форматов, когда-либо связанных с данной программой.
Возможно, стоило бы отдельно реализовать чтение данных для каждой версии файлов. тот еще высер, конечно, но для поддержки и модификации кода намного проще.
Судя по всему, даже в четвертой версии эта идея не пришла в голову автора формата, и даже если в пятой версии он исправится, остальные четыре прийдется читать вот так вот.
а сейчас все-таки стоит рефакторить с учетом всего выше сказанного, а поддержку ранних версий вынести в depricated-функцию (функции).
плюс еще в том, что при внесении изменений не придется проверять работоспособность всех старых версий.
есть идеи получше?
>плюс еще в том, что при внесении изменений не придется проверять работоспособность всех старых версий.
Про нормальный формат я знаю. Например, можно в начале каждой записи записывать её размер. И если при чтении из файла размер больше того, что знает программа, то проигнорировать лишнее, если меньше, то добить недостающее нулями. Это позволило бы очень долго дополнять формат новыми полями, не меняя код загрузки и сохранения вообще.
Идея изменить формат на нормальный висит уже давно. Вместе с идеей обновить движок полностью, не ковыряясь в наследстве времён 3 курса. Уже год, как я каждый месяц вклиниваю какое-нибудь изменение, делая это в лоб, не думая об архитектуре (уже не до неё потому что), обещая больше это не трогать и вскоре переписать нафиг.
именно это я вам и предлагаю
Короче, полгода жизни я угроблю точно.
ну и понятно, что ничего не делать - проще сейчас. а что потом - ну вам виднее.
А модели там и так текстовые, кстати. Размер при этом поражает. Довольно хорошо выглядящая модель вагона в архиве занимает максимум 10КИЛОбайт, и это нормально.
В итоге выйдет меньше.
в любом случае вопрос в критичности размера данных.
Я вчера то же самое хотел написать из-под гостя (под хромом не логинился), не пустило, зато капча была 9999, не вру!
Никуда не денешься - и изобретай тут велосипеды:(
я наступил на такие же грабли лет 7-8 назад - описал свои действия - как позже оказалось, все делал не зря.
у себя подобную проблему решил написанием довольно простого контейнера данных - древовидная структура нодов с доступом по строковому ключу, в каждом из них хранится массив элементов (у меня был 2д массив, но это частности). элемент может быть int, double, string, data (бинарные данные). формат файла после этого больше не менялся, менялась только спецификация, в плюсе имеем стандарт, контроль за ошибками (был случай по почте файл пересылали килобайт 50 размера, а он испоганился), удобство работы (если нормально классы сделать), маленький размер данных (можно zlib поюзать). в минусе - день потраченного времени.
Как бы я не вижу никаких причин не создавать свои форматы, если этого требует ситуация. Это все равно что не делать новые редакторы кода потому что есть emacs. :) (скоро 24-я верся, релиз, кстати).
А кто это делает, кстати? Я бы с удовольствием затащил их в свой подвал для вивисекторских экспериментов.
После того, как я два дня убил на то, чтобы найти все кодеки и конвертёры для одного видео (я хотел его склеить из 2 файлов в 1 и перевести в другой формат), я ненавижу тех, кто плодит эти форматы.
А так, Википедия говорит, что знает вот такие: http://en.wikipedia.org/wiki/List_of_codecs :)
А ещё и тех, кто из года в год меняет ГОСТы оформления документов просто от того, что-бы его не выгнали с работы за бездействие, заменяя жирные буквы большими, меняя отступ от края страницы на миллиметр и тд - без причин.
Разумеется, на самом верхнем уровне мы принимаем стратегические решения, какие из стандартных форматов использовать, как их комбинировать. это уже зависит от нашего приложения и полностью наше.
Типичный пример: нужно как-то передавать данные из флеша на сервер и обратно. Казалось бы банально, но когда это вырастает до десятковы тысячь запросов в час, то начинают чесать репу о том, что в мемкешед не влезает, мемкешед не успевает и т.п. XML - долго генерится и долго парсится. Вот так вот. JSON - чуть лучше, но это нестандартная хрень, особенно в том, как оно работает с алиасами в строках (типа \r например). AMF - формат построен с поддержкой дурацкой фичи, которая не нужна никому - кроме того, что хранятся описания классов, в таблицах символов хранятся не хеши строк, а строки, как есть. Пробовал переписывать таблицы символов, долго. Protobuf - никому не нужные во флеше long / ulong. Изза которых нужно тянуть левую библиотеку для длинной математики + реализация формата в рекоммендуемом Гуглом проекте ниже плинтуса. Писатель не в курсе был про ByteArray.endian свойство, поэтому разворачивал все 4-байтовые последовательности вручную. В итоге пришлось писать самим. Это даже не гордость никакая, просто ничто другое нормально не работало. Kонечно, можно было и даже тем же XML воспользоваться, но по деньгам, это 2К долларов в месяц убытков на ровном месте (аренда доп. серверов у Амазона).
В любом случае у текстового представления будут преимущества (если это не большой блоб, упакованный специальным алгоритмом, вроде картинок, музыки, видео).
Что до стандартизации алиасов, то, например ECMAScript считает, что \v (вертикальная табуляция) существует, а JSON так не считает. И, собственно поэтому утверждение о том, что JSON и ECMAScript совместимы не верно. Хотя авторы колотят себя пяткой в грудь :)
Нет, RFC - это не стандарт. ECMA - тоже не стандарт, стандарты это ISO / ANSI и им подобные. ECMA свои произведения утверждает в качестве стандартов. JSON - это пока что на уровне инициативы, но никак не стандартизирован. Кроме того, заявление его авторов о полном соответсвии синтаксиса с ECMAScript какой бы то ни было версии - это всего лишь выдумка его авторов. Валидное выражение ECMAScript "foo\vbar" вызывает ошибку в любом JSON парсере правильно реализующем формат. Кроме того, этот формат не гарантирует полного соответсвия полученной и отправленной информации - поэтому, использовать его там, где это критически необходимо (например места, где нужно оперировать контрольными сумами) не возможно.