Кодерский уголок

@Kristobal Hozevich Hunta, дык, форк вовсе не значит что его нужно обратно мерджить) Может, хочется начать новую разработку на имеющейся кодовой базе, либо заточить под свои личные нужды, так например делают форки эмуляторов для поддержки специфических функций записи видеопрохождений, на которые авторы оригинального кода явно не станут заморачиваться. Ваш Кэп.
Offtop

я не кодер, просто кое-что читаю по теме, ибо нельзя ковыряться в линухе, не зная ничего про Гитхаб и другие системы совместной разработки

 

Тогда выходит, что branch - это глобальные точки ветвления проекта, осуществляемые автором, а fork - это локальные точки ответвления, которые могут служить базой для нового проекта. При этом изменения, внесенные в fork, могут быть включены в основной проект посредством pull request.

Короче: репозиторий - дерево, основной проект - ствол, бранчи - развилки, форки - мелкие ветви, майнтайнер - хозяин дерева, контрибуторы - мичуринцы ))

Мда, книжку прочитать всё ж придётся ))

 

Суть подхода GIT в том, что любые значительные изменения принято делать в отдельной ветке, и ты можешь по желанию подтягивать себе изменения, которые вносятся в это время в родительскую. И, как я уже говорил, добавление веток - это буквально ветвление дерева коммитов, а merge - обратное действие, где ветки срастаются вместе. при этом ветки необязательно перестают существовать в качестве отдельных сущностей.
Благодаря merge, репозиторий - не дерево, а (направленный ациклический)граф.
Форк - это всего лишь ветка, которая предположительно будет существовать неограниченное время и склонированная в отдельный репозиторий, вместо типичной ветки, которая существует временно, потом мержится в главную и удаляется. При этом вся ее структура, все коммиты не пропадают, а переносятся в родительскую.

 

С какой стороны подступать к оптимизации существующего кода под много ядер?

Последнее, что помню - оптимизирующие компиляторы, которые из стройного ассемблера делали нечитаемую кашу из странных инструкций (конвейер, предвыборка, все дела).

Сейчас это делают какие-нибудь новые фичи в последней платной VS?

Где увидеть простейшие примеры-сравнения оптимизированного и не оптимизированного кода?

Спасибо.

 

VS давно уже бесплатная (Community Edition, все фичи поддерживаются без ограничений).

 

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



Наверно, оптимизацию игры надо начинать с архитектуры движка. А может быть с чего-то более высокоуровневого.

 

@MisterGrim,

Спойлер

хотел поспорить, но передумал ))

 

Ну, например, в OSX/iOS есть такая забавная технология Grand Central Dispatch...
Некоторые игровые движки содержат внутренний таск-менеджер, делающий примерно то же самое.

 

Пытаюсь собрать код, рассчитанный по заявлениям производителя на Microsoft C 6.00A, скачанным с old-dos.ru Microsoft C 6.0.

Вылетает с руганью на такую строчку:

extern void( __interrupt __far *nDSPSaveVect )();

Ругается так:

error C2146: syntax error : missing ')' before identifier '__far'
error C2182: '__interrupt' has type void
error C2045: expected '(' to follow '__interrupt'

Что ему надо, и что означает такая запись __interrupt?

Я интуитивно заменил __interrupt __far на _interrupt _far, и ругань прекратилась, зато появилась новая ошибка при сборе:

LINK: warning L4051: CLIBCE.lib : cannot find library

При этом Microsoft C я честно устанавливал с 7 дискет. Почему линкер требует библиотеку, которой нет в дистрибутиве? Может, это связано с заменой __ на _?

 

Пишу загрузчик pcx файлов(24 битных) Вместо нормального изображения выводится три его копии меньшего размера и в оттенках серого. Кто поможет пофиксить баг? Ссылка на код -

 

@Bobbie, Use stb_image, Luke! Хотя PCX там нет..

 

Возник вопрос на тему "как определить, что программа / игра использует direct3d7 и ниже"?
Тот же glide (если не 2.1.1 и ниже) элементарно определяется по импорту функции, то есть по наличию строки grGlideInit внутри .exe.
D3d9 c d3d8 - по Direct3DCreate9 и Direct3DCreate8.
Ddraw7 по DirectDrawCreateEx.
Ddraw более ранних версий, соответственно, по DirectDrawCreate.
А вот как однозначно определить использование d3d7 и более ранних? CreateDevice ещё и в DirectInput есть... А вызов IDirect3D7 через QueryInterface ничего нового в импортируемые функции не вносит...

 

https://github.com/jack7277/Dosbox-Subtitle-Loader

может быть кто-нибудь допилит загрузчик субтитров, проект не мой.
проблема - частенько падает на некоторых конфигурациях.
использовалось в harvester, чтобы во время видео показывались хардсабы, метод вроде универсальный, но падучий.

 

@jack7277, это к @Рыжий Тигра - он точно такую же хрень собрал и ровно с теми же целями. Так что, скорее всего, за пару минут заменит на свою реализацию.

--- добавлено 27 дек 2016, предыдущее сообщение размещено: 27 дек 2016 ---

без DX9, например.

 

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

@Bato-San, насчет дх9 хз, может быть, у меня были падения на всем одинаковом, но разные сборки досбокса, несколько штук перебрал, выбрал стабильно у меня работающий и прошел)

 

... сам понимаешь, что это скорее намекает не на

а на "делай всё правильно, как положено, что бы работало, как надо."

ЗЫ. Но в целом исходники полезные для ознакомления желающими запилить нечто похожее.

 

Вожусь с ремейком одной игры и возникла потребность в хранении текстовых ресурсов, т.к. часть строк в игре кривая, часть с ошибками, плюс для перевода на другие языки (Бюро попросило) всё равно должен быть какой-то файл с текстовыми ресурсами. Первое что пришло в голову - использовать ini-файлы. Мысль неплохая, но мозг активно и очень долго ей сопротивлялся: тут нужен либо парсер, к тому же учитывающий возможные ошибки, либо компилятор в какой-то бинарный формат (что парсер не отменяет), чтобы оно быстрее строки из массива строк извлекало (бинарный формат уже скомпилирован и не проверяется).
Есть готовые решения для парсинга ini-файлов, но они толстые (на данном этапе отладочная версия игры, с кучей прибамбасов для отладки, занимает всего 23 Кб) и/или навороченные - стрельба из пушки по воробьям.
Воспалённый мозг в какой-то момент выдал оригинальное решение, которое и было благополучно использовано.

Итак, зачем корячиться и писать компилятор строк, если это можно свалить на... FASM.

1) Создаём файл с константами "constant.inc" (здесь и далее содержимое файлов - это примеры):

Код:

s_hello = 1
s_world = 2
s_main_menu = 3
; и так далее

2) Создаём файл с текстами "messages.asm":

Код:

; подключаем константы
include 'constant.inc'
; макрос для объявления строк, чтобы кучу кода вручную не писать
macro _ id, tx {
  ; идентификатор строки
  dw id
  ; размер (без нуля 0), строка, 0
  db @f - $ - 2, tx, 0
  @@:
}

; погнали объявлять строки
_ s_hello, 'Hello'
_ s_world, 'world!'
_ s_main_menu, 'Main Menu'
; и так далее

; обязательный терминатор - строки закончились
dd 0

3) Компилирует в FASM файл "messages.asm" и получаем "messages.bin".

4) Использовать вот так (переменная "p" - буфер с файлом "message.bin", остальное, думаю, и так понятно):

Код:

char err_str_id_not_found[] = "ERR_STR_ID_NOT_FOUND";

char *GetStrById(BYTE *p, DWORD id) {
char *result;
DWORD ci;
  // default - string not found
  result = NULL;
  // sanity check
  if (p) {
    // by now only WORD used as id
    id = LOWORD(id);
    // while not NULL terminator
    for (ci = *((WORD *)p); *((DWORD *)p); ci = *((WORD *)p)) {
      // not found since all strings stored in ascending id order
      if (ci > id) {
        break;
      }
      // id matches?
      if (ci == id) {
        // string found
        result = (char *) &p[3];
        break;
      }
      // skip the whole string and header data
      p += p[2]; // string length (without zero byte)
      p += 4;    // id (2 bytes) + string length (1 byte) + zero (1 byte)
    }
  }
  // string id not found
  if (!result) {
    // FIXME: fatal error?
    // by now - use default stub
    result = err_str_id_not_found;
  }
  return(result);
}

5) Всё элементарное - просто. Можно пользоваться. Файл "constant.inc" можно подключать как к сценам, так и к движку, чтобы вместо "3" писать "s_main_menu" и, вообще, было понятно что и где используется.

6) Ограничения:
6.1) Все id строк должны быть в возрастающем порядке (или убрать проверку на "ci > id").
6.2) Нельзя объявлять пустые строки с id = 0 (4 байта и все нули - это терминатор, означающий конец файла) - легко исправляется, но здесь это не нужно.
6.3) Длинна одной строки не может быть более 255 символов (без нуля) - аналогично предыдущему пункту.
6.4) На очень большом количестве строк, конечно же, будет быстрее держать (или строить) таблицу смещений отсортированную по id, чтобы можно было дихотомией по ней быстро проходиться.

 

@iunnamed, прочитал и подумал, что всё же длительное употребление современных (именно так) высокоуровневых языков и всяких lua изрядно попортило современных программистов, коли подобные вещи, внезапно, воспринимаются на уровне "осенило", хотя они изначально составляют основу.

 

Запутался c directdraw'ными оверлеями, нужна подсказка куда копать.
Имеем три IDirectDrawSurface'а:

• screen - на весь экран, параметры (снимались GetSurfaceDesc()'ом сразу после CreateSurface()):
  dwFlags: 0000100f DDSD_CAPS DDSD_WIDTH DDSD_HEIGHT DDSD_PITCH DDSD_PIXELFORMAT
  dwWidth: 1920 dwHeight: 1080 lPitch: 7680
  ddsCaps.dwCaps: DDSCAPS_PRIMARYSURFACE | DDSCAPS_VIDEOMEMORY | DDSCAPS_VISIBLE | DDSCAPS_LOCALVIDMEM
  ddpfPixelFormat.dwFlags: DDPF_ALPHAPIXELS | DDPF_RGB
  dwRGBBitCount: 32 dwRBitMask: 00ff0000 dwGBitMask: 0000ff00 dwBBitMask: 000000ff dwRGBAlphaBitMask: ff000000
• overlay - привязанный к screen'у оверлей, параметры:
  dwFlags: DDSD_CAPS | DDSD_WIDTH | DDSD_HEIGHT | DDSD_PITCH | DDSD_BACKBUFFERCOUNT | DDSD_PIXELFORMAT
  dwWidth: 640 dwHeight: 480 lPitch: 1280 dwBackBufferCount: 1
  ddsCaps.dwCaps: DDSCAPS_COMPLEX | DDSCAPS_FLIP | DDSCAPS_FRONTBUFFER | DDSCAPS_OVERLAY | DDSCAPS_VIDEOMEMORY | DDSCAPS_LOCALVIDMEM
  ddpfPixelFormat.dwFlags: DDPF_FOURCC
  dwFourCC: 0x32595559 (YUY2)
• source - уже сформированная игрой картинка, параметры:
  dwFlags: DDSD_CAPS | DDSD_WIDTH | DDSD_HEIGHT | DDSD_PITCH | DDSD_PIXELFORMAT
  dwWidth: 640 dwHeight: 480 lPitch: 1280
  ddsCaps.dwCaps: DDSCAPS_OFFSCREENPLAIN | DDSCAPS_SYSTEMMEMORY
  ddpfPixelFormat.dwFlags: DDPF_RGB
  dwRGBBitCount: 16 dwRBitMask: 0000f800 dwGBitMask: 000007e0 dwBBitMask: 0000001f

Дальше пытаюсь сделать:
overlay->UpdateOverlay( NULL, screen, [0,0,640,480], DDOVER_SHOW, NULL );
overlay->GetAttachedSurface( [DDSCAPS_BACKBUFFER], &backbuffer );
backbuffer->Blt( [0,0,640,480), source, [0,0,640,480], DDBLT_WAIT, NULL );
- первые две функции проходят на ура, вторая - обламывается с кодом 0x80004001 (DDERR_UNSUPPORTED, то бишь не поддерживается).
Всё, кроме двух последних строк, честно слизано с микро$офтовского "москитного" примера.

Что я делаю не так? Или Blt() для YUV'ных оверлеев действительно не поддерживается? Подкиньте примеров и/или что-ньдь почитать, плиз!