|
Пытаюсь замутить свой симулятор.
| |
| V9 | Дата: Понедельник, 20.01.2020, 23:57 | Сообщение # 21 |
|
Поездной диспетчер
Группа: Пользователи
Сообщений: 345
Награды: 7
Репутация: 0
Статус: Offline
| Цитата Фома (  ) Отработал первый приказ, вот что получилось:
Спасибо! буду тестировать с разными браузерами и платформами, чтобы повторить баг. upd. Я вводил номера поездов цифрами, поэтому этого бага не видел. 
====
Пока что еще два часа потрачено на добавление логики "сегментов пути" и "приемо-отправочных путей" к "станциям". Всего в проекте 2995 строк кода на данный момент.Добавлено (24.01.2020, 17:05)
---------------------------------------------
Долго меня не было. 
Сегодня "пробивал" полигон движения Сургут — Сургут-Порт. За час добавлено 145 строк кода, сейчас в игре 3140 строк.
Сообщение отредактировал
V9 - Вторник, 21.01.2020, 00:01 | | |
| |
| V9 | Дата: Суббота, 25.01.2020, 22:50 | Сообщение # 22 |
|
Поездной диспетчер
Группа: Пользователи
Сообщений: 345
Награды: 7
Репутация: 0
Статус: Offline
| Отвлекся я чутка от программирования симулятора, занялся оффтопом. Загадко. Сможете догадаться, что это?
| | |
| |
| andreyzpr91 | Дата: Воскресенье, 26.01.2020, 09:39 | Сообщение # 23 |
 Станционный диспетчер
Группа: Пользователи
Сообщений: 65
Награды: 2
Репутация: 1
Статус: Offline
| Кашмар.
| | |
| |
| Neo7 | Дата: Воскресенье, 26.01.2020, 14:42 | Сообщение # 24 |
 Руководитель совместных игр
Группа: Модераторы
Сообщений: 2490
Награды: 6
Репутация: 9
Статус: Offline
| НГДП намеченный
| | |
| |
| Фома | Дата: Воскресенье, 26.01.2020, 16:08 | Сообщение # 25 |
 Поездной диспетчер
Группа: Пользователи
Сообщений: 248
Награды: 7
Репутация: 9
Статус: Offline
| Цитата Neo7 ( ) НГДП намеченный | | |
| |
| V9 | Дата: Воскресенье, 26.01.2020, 21:59 | Сообщение # 26 |
|
Поездной диспетчер
Группа: Пользователи
Сообщений: 345
Награды: 7
Репутация: 0
Статус: Offline
| Цитата Neo7 ( ) НГДП намеченный
 Добавлено (26.01.2020, 22:31)
---------------------------------------------
Полчаса рисовал сервер, утилитный класс, реализующий очередь. Как обычно, не додумал до конца, в итоге тормознул, т.к. не знаю, какой из двух вариантов развития выбрать: один обещает экономию памяти и ускорение работы, но сложней в реализации; другой - наоборот.
| | |
| |
| V9 | Дата: Воскресенье, 26.01.2020, 22:39 | Сообщение # 27 |
|
Поездной диспетчер
Группа: Пользователи
Сообщений: 345
Награды: 7
Репутация: 0
Статус: Offline
| Параллельно поигрываю на основном симуляторе, игра на текущем годе надоела, так что решил переработать год. Условия переработки:
1. Пассажирские поезда должны прибывать и отправляться на(с) юг(а) в то же время.
2. Пассажирские должны стоять по Сургуту 40 минут минимум.
3. Должны сохраниться все нитки грузовых поездов
4. Стоянка сборных и участковых - минимум 45 минут.
5. График должен быть пробит до Ноябрьска.
6.Опционально. Должен быть исключен Ингу-ягун из работы (для полного прикола)
Сделал пока что Ульт-Ягун до НВ1, сейчас начал закладывать текущий график Севера в CAD, чтобы потом его переделать. Удалось радикально ускорить движение пассажирских поездов, даже сам удивился.Добавлено (23.02.2020, 17:14)
---------------------------------------------
Вернулся к симулятору, доделал утилитный класс очереди, выбрал "тормознутый, но упрощенный" вариант. 2 часа (без 5 минут), 3390 строк кода в проекте.
Сообщение отредактировал
V9 - Воскресенье, 26.01.2020, 22:41 | | |
| |
| V9 | Дата: Воскресенье, 14.05.2023, 14:58 | Сообщение # 28 |
|
Поездной диспетчер
Группа: Пользователи
Сообщений: 345
Награды: 7
Репутация: 0
Статус: Offline
| 
Пытаюсь победить баг отрисовки, никак не получается. 
| | |
| |
| V9 | Дата: Вторник, 16.05.2023, 01:44 | Сообщение # 29 |
|
Поездной диспетчер
Группа: Пользователи
Сообщений: 345
Награды: 7
Репутация: 0
Статус: Offline
| В общем, получился прикол. Победить баг загрузки изображения не получилось. Почесал репу и решил написать свой загрузчик .BMP файлов чтобы загрузить и реконструировать изображение из памяти компа. Так хоть может будет разобраться в причинах. На первом этапе получилось вот что:
"Ы!" - сказал я сам себе. Тут надо-ть бы пояснить проблему. Zork сохранял свой файл в формате "4 бита на пискель". В одном байте два пикселя. В чем, в какой проге, он сохранял - я не понял. Если вы попробуете отредактировать этот файл pult.bmp, скажем, в paint, то сохранив и снова загрузив, поймете, что там всё слетело. Там реально, если сохранить, вы уже не загрузите в paint обратно т.к. там все вообще поломается в цветах. Я, когда делал "реконструкцию участка Сургут-НВI", я правил через редактор GIMP. И тут получился другой прикол. GIMP, когда сохраняет, сохраняет в другом формате: BITMAPV4HEADER (длина заголовка - 108 байт). А у Zork формат более старый, но простой: BITMAPINFOHEADER - 40 байт. Т.е проблема в том, что я совершенно не могу хотя бы минимально поправить рисунок, чтобы попробовать методом научного тыка понять, где ошибка. Или сразу писать разборщик под формат GIMPa, но тогда будет не совместимо с форматом Zork.
Сидел, думал. Решил хотя бы посмотреть по первой строке. А в .BMP прикол: он грузит снизу-вверх. Реально, сначала в файле нижняя строка, потом пред-нижняя, последняя будет самой верхней. Посмотрел нижнюю строку, начало. Она должна читаться первой. А там черная точка в левом нижнем углу:
"Эгей!" - подумалось, - "Не может такого быть т.к. нижняя строка вся зеленая!" Быстрые исследования показали, что я ошибочно первую точку посылаю неинициализированной (не прочитанной). а так как ее значение - ноль, то и получается черная точка. Исправляем, точка ушла, все остальное сдвинулось.
ОК! теперь анализирую наклоную линию.
Достатоно хорошо видно, что паразитный сдвиг - 6 пикселей на каждом ряду. 6 пикселей = 3 байта. "А что у нас может быть 3 байта на каждом ряду?" - задумался я.
"Padding bytes/байты выравнивания!" - пришло в голову через минуту.
В .BMP файлах каждый ряд пикселей дожен быть кратный четырем байтам. Если у нас байты кончились ранее, надо добавить сколько-то байтов, чтобы выровнялось на 4. Проверяем. У Zork его pult.bmp имет ширину 610 пикселей. Это 610 / 2 = 375 байт. 375 не кратно 4м, надо добавить три байта выравнивания чтобы итоговая ширина делилась на 4 без остатка: (375+3)/4 = 94 ровно. Проверяю код, нахожу, что в момент сканирования строки файла не модифицируется индекс, который должен отследить, что мы дошли до конца ряда и надо-ть бы скинуть (не читать) эти три байта. Эти три байта попадали в строку и таким образом делали сдвиг на каждой строке.
Правим, запускаем, получаем вот такой несколько наркоманский бред. Но тут я уже заранее знал о такой возможности: ни в одной инструкции я так и не смог найти в каком порядке должна отправляться половина байта: то ли старшая половина сначала, то ли младшая.Сделал наугад, ошибся. Но тут уже было понятно, что исправлять, 5 минут и вот финальная загрузка, которую не могу показать т.к. у нас на сайте 6 картинок на пост ограничение.Добавлено (16.05.2023, 01:46)
---------------------------------------------
ps. Хотя финальный вариант каждый может увидеть если откроет в каталоге Territory\1\pult.bmp.
| | |
| |
| V9 | Дата: Вторник, 16.05.2023, 23:03 | Сообщение # 30 |
|
Поездной диспетчер
Группа: Пользователи
Сообщений: 345
Награды: 7
Репутация: 0
Статус: Offline
| Урямс! Удалось дописать загрузку формата BITMAPV4HEADER (4й вариант BMP файлов) и грузануть pult.bmp из моей доработки "реконструкция участка Сургут-НВ1". =) upd. Попутно выяснилось, что GIMP мне сохранил с ошибкой формата, на что я потерял много времени - я программировал по инструкции, а рисунок не грузился "никак". Я думал, ошибка у меня, пытался найти. А ошибку сделал GIMP. Пришлось это дело "обводить" в проге.
Сообщение отредактировал
V9 - Вторник, 16.05.2023, 23:06 | | |
| |
| Фома | Дата: Среда, 17.05.2023, 22:45 | Сообщение # 31 |
|
Поездной диспетчер
Группа: Пользователи
Сообщений: 248
Награды: 7
Репутация: 9
Статус: Offline
| Ууух! Сложно. Если нужно просто отредактировать//откорректировать файл Pult.bmp в папке симулятора и чтобы после сохранения изменений он корректно использовался симом, используй старую версию Paint, например из ОС "XP".
У меня есть такая, если надо могу поделиться, всего один файл (портабл-версия), пользуюсь более 4 лет, выглядит вот так:
И не придется изобретать всяких там загрузчиков)))
| | |
| |
| V9 | Дата: Среда, 24.05.2023, 15:09 | Сообщение # 32 |
|
Поездной диспетчер
Группа: Пользователи
Сообщений: 345
Награды: 7
Репутация: 0
Статус: Offline
| От облома к облому с матами и улыбкой (С) мой.
Два часа отладки были убиты на то, что в одном месте происходил сдвиг параметра на 4 бита вправо, а должен был на 8.В итоге, параметр 0x0411 писался как 0x41,0x11, а должен был - 0x04, 0x11 (16 битовое слово пишем в два байта). Причем искал не там. Задача была в том, чтобы прочитать data.dat из симулятора, коий data.dat в кодировке Windows-1251 (https://en.wikipedia.org/wiki/Windows-1251) в UTF-16, а потом записать байтами в файл. И вот на этапе записи я и ошибся. Искал проблему в момент чтения и кодирования, а проблема была в момент записи.
Сообщение отредактировал
V9 - Среда, 24.05.2023, 19:06 | | |
| |
| V9 | Дата: Пятница, 26.05.2023, 20:29 | Сообщение # 33 |
|
Поездной диспетчер
Группа: Пользователи
Сообщений: 345
Награды: 7
Репутация: 0
Статус: Offline
| 
| | |
| |
| V9 | Дата: Пятница, 26.05.2023, 20:36 | Сообщение # 34 |
|
Поездной диспетчер
Группа: Пользователи
Сообщений: 345
Награды: 7
Репутация: 0
Статус: Offline
| Добавлю, что у меня и симулятора Zork'a нет ни одной совпадающей фичи. у меня вообще нет ничего, что есть у Zork, но зато у меня есть киллер-фича: можно менять формат пульта прямо на ходу переключаясь между любым из 9 вариантов разрешения экрана клавишами Numpad. А этой фичи нет уже у Zork'a =)
| | |
| |
| d233 | Дата: Суббота, 27.05.2023, 17:07 | Сообщение # 35 |
|
Начальник станции
Группа: Пользователи
Сообщений: 129
Награды: 2
Репутация: 0
Статус: Offline
| Цитата V9 ( ) А этой фичи нет уже у Zork'a =)
Жду с интересом продолжения разработки!
| | |
| |
| V9 | Дата: Среда, 31.05.2023, 23:05 | Сообщение # 36 |
|
Поездной диспетчер
Группа: Пользователи
Сообщений: 345
Награды: 7
Репутация: 0
Статус: Offline
| 
Мы видим Сургут, мы видим попытку зажечь лампу на пути. В отладке была попытка зажечь лампу желтым, но что-то где-то пока что криво, поэтому явно кусок изображения цепанулся со стороны, с бэкграунда. Но это фигня, отладим.
Синим выделена "круговая лампа". Очень сильно замедлает работу то, что я заранее хочу добавить фичи, которые может никому никогда не понадобятся. Одна из планируемых фич заключается в том, что можно будет программировать пульт с необычными лампами. Прога должна будет сама определять "необычные" лампы и корректно их отрисовывать. В данном случае лампа в виде такого вот скругленного круга, внутри которой другая лампа. Можно сказать - отрисовывать заливкой, но все сложно с этим так в языке программирования заливки тупо нет. Поэтому будет сделано так, что прога определит контур заливки лампы, выделит прямоугольники, такие, чтобы при заливке не трогались посторонние элементы и будет красить эти прямоугольники, подставляя корректную заливку. Кроме того, уже в коде заложена возможность градиентной заливки чтобы отразить (по желанию) центральную нить лампы по центру и погашение цвета ближе к краям.
Таких задуманных "фич" очень много изза чего сама разработка идет весьма "не спеша". =( Еще замедляет сильно работу разные "затыки" которые как бы нигде в документации не описаны, но на которые постоянно нарываешься. Одна из них звучит так: "Создай рисунок, возьми с него объет Graphics, рисуй, что тебе надо!"
В игре, в каталоге Territory/1 Есть pult.bmp. На нем отрисованы станции. В data.dat инфа, где что на этом рисунке расположено. pult.bmp мы качаем и превращаем в массив пикселей, с которого массива создаем набор картинок(рисунков) - локальные образы станций. Кроме того создается рисунок-подложка, на котором распологаются эти локальные образы станций, перед тем как отрисоваться на экране. При смене варианта пульта на другое разрешение в пикселях, мы пересоздаем подложку на другой размер и перераскладываем локальные картинки станций. А потом, в цикле переноса, подолжка тупо отрисовывается на основном экране.
Все хорошо работало до тех пор пока... В общем, когда мы зажигаем(гасим) лампу, мы должны это отрисовать на двух картинках: на локальном рисунке, чтобы быть готовым перейти на другой формат пульта в любой момент; и на подложке, чтобы перерисовать экран текущей подложкой.
И тут у меня все начало падать. Объект Graphics тупо не хотел "браться" с рисунка. Методом тыка, я понял, что проблема в локальном рисунке. Но в чем именно, долго понять не мог. Оказалось, что если рисунок создан с набора пикселей (А все локальные картинки станций делаются с пикселей), то править его больше возможности нет. В итоге, пришлось делать так:
Image mimg = createImage(new MemoryImageSource(srcWidth, srcHeight, pixels, srcY * pultWidth + srcX, pultWidth));
Image img = createImage(srcWidth, srcHeight);
Graphics g = img.getGraphics();
g.drawImage(mimg, 0, 0, srcWidth, srcHeight, null);
g.dispose();
Создаем один рисунок из пикселей. Тут же создаем второй, пустой рисунок. Сразу же копируем содержимое первого во второй, первый удаляем. Вот только так и удалось добиться нужного эффекта. Уф!
| | |
| |
| V9 | Дата: Четверг, 01.06.2023, 00:55 | Сообщение # 37 |
|
Поездной диспетчер
Группа: Пользователи
Сообщений: 345
Награды: 7
Репутация: 0
Статус: Offline
| 
Потребовалось 10 минут отладки, чтобы заработало. Как и предсказывалось, оно дергало "погасшую лампу" не со станционного пути, а с левой части картинки. Пиксели дергались по алгоритму:
pixels[row * width + column] - где row - ряд от 0 до 3 (высота лампы - три пикселя), а column - это пиксель по горизонатли от 0 до длины лампы из data.dat. В общем, оно дергало с левого-верхнего угла pult.bmp, а там - зеленый фон.
Правильно было:
pixels[(row + y) * width + column + x] - скорректировать на Y по высоте (из data.dat) и скорректировать по Х по горизонтали. Но, как обычно, удивило, что более 200 строк кода "заработало" с полпинка.Добавлено (01.06.2023, 13:24)
---------------------------------------------
Посчитал время. Вся работа по подсистеме ламп заняла на данный момент пять часов одну минуту. Из этих пяти часов, 18 минут я исправлял ошибки компиляции, а 35 минут отлаживал. Отладка ушла в основном на ту самую ошибку Graphics. Забавно, что казалось наоборот, что ошибки компиляции исправлял долго, а отлаживал быстро. =)
| | |
| |
| V9 | Дата: Четверг, 01.06.2023, 20:00 | Сообщение # 38 |
|
Поездной диспетчер
Группа: Пользователи
Сообщений: 345
Награды: 7
Репутация: 0
Статус: Offline
| Сегодня делал A*-алгоритм (см. тут - https://ru.wikipedia.org/wiki/A*) чтобы обрисовывать нестандартные лампы:
В файле data.dat у zork лампа указывается верхним-левым углом. Я принял такое же решение, но оно более расширенное.
При старте разбора, алгоритм начинает сканировать стартовую точку, считая, что она верхняя-левая. Идет вправо-вниз, пока не найдет первую серую точку, которую будет считать "стартовой точкой". Далее по A*-алгоритму он обходит все точки, определяя внешний контур (показан красным) прямоугольника, который надо будет изъять с картинки, чтобы (А) ложить обратно, когда лампа выключается; (Б) чтобы его красить в разные цвета, а раскрашенное ложить на место. Алгоритм позволяет не обязательно указывать точку слева-сверху, он потом может "гулять" во всех возможных направлениях, выявляя форму лампы, лишь бы не выходить за границы станции (нестандартные лампы могут быть только на станциях).
Но так как лампы могут быть самого нестандарнтного вида, то во внешнем контуре могут оказаться другие лампы, которые другие лампы будут затерты при манипуляциях с нашей этой нестандартной лампой. Поэтому в планах далее писать алгоритм, который разбирается - "А нужно ли внешний контур дробить на множество мелких контуров, чтобы не портить другую(другие) лампу(-ы)?" Это доп.контуры показаны на рисунке синим. Чтобы не "портить" внутреннюю лампу, нам надо этот большой внешний прямоугольник подбробить на 4е внутренних и отрисовывать каждый внутренний отдельно.
Пока что вот сделан разбор внешнего контура, на что потрачено 111 минут и написано примерно 140 строк кода.
| | |
| |
| V9 | Дата: Пятница, 02.06.2023, 01:36 | Сообщение # 39 |
|
Поездной диспетчер
Группа: Пользователи
Сообщений: 345
Награды: 7
Репутация: 0
Статус: Offline
| Зделал отрисовку нетиповых ламп!
Тут сначала отрисовалась желтая лампа в центре, а потом круговая красная. Ниже на рисунке я добавил отрисовку прямоугольничков, так, как они хранятся в программе, чтобы окружная лампа не портила центральную:
Вот тут пришлос "поотлаживать", так как это была весьма нетривиальная задача. Сначала прога анализирует содержимое и создает эти прямоугольнички, чтобы взять сложную лампу с подложки. Потом, когда надо отрисовать лампу цветом или погасить цвет, прога вот этими прямоугльничками и рисует.
| | |
| |
| V9 | Дата: Понедельник, 05.06.2023, 05:07 | Сообщение # 40 |
|
Поездной диспетчер
Группа: Пользователи
Сообщений: 345
Награды: 7
Репутация: 0
Статус: Offline
| Несколько фиговое мое свойство: я что-то начинаю делать "по приколу", по принципу - "сделаем сложней, чтобы что-то доказать себе!" В итоге на это тратится время неадекватно тому, что получается в итоге. Если посмотрим на пред картинку, видно, что голубой прямоугольник захватил большую площадь с зеленым фоном. Оно ему как бы не нужно, но этот кусок инфы надо держать в памяти. Решил поправить, чтобы прямоугольники захватывали только ту область, где находятся серые пиксели. Подправил картинку лампы:
переписал код:
Все отлично, прямоугольники начали хватать только там, где есть реальные пиксели. Но, фак в том, что (А) таких сложных ламп на пульте у Zork нет; (Б) выигрышь в размерах прямоугольников не компенсируется тем, что значительно усложнился код программы; (В) незначительно уменьшилась скорость загрузки; (Г) на это все убито несколько часов.
Нафига? Вопрос без ответа...
| | |
| |
|
