Войти
ПрограммированиеФорумОбщее

В C/C++ про дефолту типы знаковые или беззнаковые? (3 стр)

Advanced: Тема повышенной сложности или важная.

Страницы: 1 2 3
#30
(Правка: 14:35) 14:25, 27 июля 2021

rcsim
> А в чём вообще контекст трагедии?

Научиться получать компилируемый и рабочий Си-код игры из EXE.

rcsim
> Что там за игра, которую надо непременно реверсить, а не к примеру написать
> самому, с поддержкой нужных ОС (а по сути аппаратных платформ)?

Это моё новое увлечение. :)

rcsim
> И в чём предметная суть SetPixel? Т.е. для чего он нужен в игре?
> Т.е. не спрайт, не буфер целиком, а именно пиксель?

В DOS-овских играх нет аппаратных спрайтов.  Все рендереры игры - свои - программные.  Любой спрайт рисуется попиксельно.  Как вы это будете делать - рисовать по 1 пикселу или использовать цепочечные команды CPU для блочного копирования - это уже вам решать...


#31
14:34, 27 июля 2021

FordPerfect
> А нужно ли? Буфер из памяти отправляется на отрисовку одним вызовом
> StretchDIBits или BitBlt. Ну и InvalidateRect при желании.
>
> В чём цель lock/unlock?

Ну рисовать конечно же можно в обычном массиве.  Речь шла об отплёве кадра на дисплей.  В винде через SDL нынче это сделано через ОГРОООООМНУЮ  жопень - текстура в OpenGL или Direct 3D.  Не правда ли извращение?

На Direct Draw дядя Билл давно болт забил, поэтому  SDL использует текстуру для отплёва на экран.  Кишки я не ковырял как оно, но видя сорцы СДЛя - я понял, что не для слабонервных.

Вот джентльменский набор для рисования в  ДОСе:

void RGB(u8 C,u8 R,u8 G,u8 B)
{
 _asm
 {
  mov       ax,0x1010
  xor       bh,bh
  mov       bl,C
  mov       dh,R
  mov       ch,G
  mov       cl,B
  int       0x10
 }
}

void Pixel(u32 x,u32 y, u8 c)
{
 *(u8*)(0xA0000+((320*y)+x))=c;
}

void VSYNC()
{
  do
  while ( (__inbyte(0x3DA) & 8) == 0 );
}


void VideoMode(void)
{
 _asm
 {
  mov    ax,0x13
  int    0x10
 }
}

void TextMode(void)
{
  __asm
 {
  mov       ax,3
  int       0x10
  mov       ax,0x1112
  xor       bx,bx
  int       0x10
 }
}

void OutChar(u32 o,u8 c)
{
 *(u16*)(0xB8000+(o*2))=c+(0xF<<8);
}

void OutString(u32 p,char *s)
{
 int i=p;
 while(*s)
 {
  OutChar(i,*s);
  s++;
  i++;
 }
}

Простенько и минималистично )))  Дальше можно родить printf( )  и DrawSprite() на своё усмотрение.

И задействовать rep movsd/stosd для пересылки в видеопамять блоков.

#32
15:00, 27 июля 2021

Если исторический контекст поднять, то сперва Ричи с Томпсоном изобретали язык B на PDP-7.
В 70-х самая распространённая архитектура ЭВМ предполагала, что и регистры и ячейки памяти все имеют размер слов - и битность слов выбирали все наугад пытаясь нащупать оптимум чтобы и инструкции в одно слово влезали и числа которыми надо было оперировать.
Так в PDP-7 слова имели размер в 18 бит.
Поэтому в языке B был только один числовой тип - и он никак не обозначался.
Так в функции переменные описывались просто:

    auto x, y;
при этом слово auto означало что переменные располагаются в стеке (как и в первых версиях C/C++).
И указатели и числа - всё декларировалось вот так и работаем мы с числом или с указателем следовало просто из операторов.

В PDP-11 появились байты и 16-битная машина могла экономно обращаться к памяти располагая в них маленькие числа или символы.
Адаптируя B к PDP-11 Ричи уже с Керниганом поняли, что примитивные типы уже прямо нужны.
Но если посмотреть на систему команд PDP-11: https://en.wikipedia.org/wiki/PDP-11_architecture , то вот незадача - эта архитектура имела в опкоде бит который определял работают такие инструкции как MOV или CMP с байтом или со словом, но в арифметических инструкциях этот бит был пущен на определение того сложение мы выполняем или вычитание - таким образом инструкции ADD и SUB работали только со словами!

Из этого в языке С родилось два правила:
- во первых char не стал восприниматься как арифметический тип, а стал синонимом именно символа. char и char. компактное место под знак.
- во вторых попытка складывать или вычитать char-ы автоматически поднимает тип аргументов и выражения до int (int promotion).

В первых версиях С не было signed char или unsigned char - такие словосочетания вызвали бы ошибку компиляции. Но задумываясь о том в какой именно int будет промоутится char создатели решили отдать это на откуп конкретной машинной архитектуре - ведь они жили еще посреди огромного зоопарка архитектур, тем более, что в самой PDP-11:

Moving byte to a register sign-extends into bits 8-15

работало расширение со знаком. Но очевидно было, что в других архитектурах где char был бы эквивалентен машинному слову принуждать чтобы было какое то соответствие с тем что происходит с символом с кодом '~' на PDP-11 было бы слишком обременительно.

Так и повелось: что такое char и как оно превращается в int - отдано на откуп машинной архитектуре.
В дальнейшем уже с тотальным засильем байтов чтобы выработать какие то жёсткие гарантии пришли к дополнительным типам signed char и unsigned char.

#33
15:33, 27 июля 2021

> Речь шла об отплёве кадра на дисплей.
Ну так и я о том же.
Выдача кадра - один вызов StretchDIBits, плюс один вызов InvalidateRect.
Не сказать, чтобы сильно больше кода, чем в твоём посте.

Пример:
https://gamedev.ru/flame/forum/?id=216920&m=4260662#m2

#34
15:57, 27 июля 2021

Gradius
> В DOS-овских играх нет аппаратных спрайтов. Любой спрайт рисуется попиксельно.

Ты путаешь понятие ОС и способ доступа к железу (прямой/через драйвер-api).
И во времена В DOS-овских игр были (напр. EGA) режимы, где конкретно пиксель ты адресовать не мог.
Были блоки пикселей, разделенные на битплейны, которые переключались портовыми командами.

#35
16:34, 27 июля 2021

rcsim
> И во времена В DOS-овских игр были (напр. EGA) режимы, где конкретно пиксель ты
> адресовать не мог.
> Были блоки пикселей, разделенные на битплейны, которые переключались портовыми
> командами.

Такое говно не интересует в принципе.  К тому же я вскользь его уже упомянул тут:

Gradius
> А режим chained 256 kB (4 видеоплоскости по 64К )был не интересен, из-за того
> что там битовую маску через порты дополнительно выставлять надо было (чтобы
> загасить пиксели или защитить их от изменения).


rcsim
> Ты путаешь понятие ОС и способ доступа к железу (прямой/через драйвер-api).

А кто ещё кроме ДОС-а позволяет делать прямой доступ к железу без написания драйвера?

И это немного  не вяжется с моей цитатой, на которую ваш ответ:

rcsim
> > В DOS-овских играх нет аппаратных спрайтов. Любой спрайт рисуется
> > попиксельно.

FordPerfect
> Ну так и я о том же.
> Выдача кадра - один вызов StretchDIBits, плюс один вызов InvalidateRect.
> Не сказать, чтобы сильно больше кода, чем в твоём посте.
>
> Пример:
> https://gamedev.ru/flame/forum/?id=216920&m=4260662#m2

Спасибо! Как раз попытаюсь задействовать  в будущем.

=A=L=X=
> В первых версиях С не было signed char или unsigned char - такие словосочетания
> вызвали бы ошибку компиляции.

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

#36
17:27, 27 июля 2021

Gradius
> А кто ещё кроме ДОС-а позволяет делать прямой доступ к железу без написания драйвера?

Бутлоадер. Т.е. ОС тут вообще непричём, и понятие лишнее.

#37
(Правка: 17:31) 17:30, 27 июля 2021

rcsim
> Т.е. ОС тут вообще непричём, и понятие лишнее.
Причем, современные BIOS настолько продвинуты, что их пользовательская среда вполне пригодна для жизни "без ОС".

А еще сейчас продают однокристаллки для создания умной техники - уиграйся.

#38
18:48, 27 июля 2021

rcsim
> Бутлоадер. Т.е. ОС тут вообще непричём, и понятие лишнее.

Не лишнее.  Разрабатывать программы и запускать ИДЕ, отлаживаться где будете?

gudleifr
> Причем, современные BIOS настолько продвинуты, что их пользовательская среда
> вполне пригодна для жизни "без ОС".

При всей их продвинутости, GCC наверное туда не поставишь.

gudleifr
> А еще сейчас продают однокристаллки для создания умной техники - уиграйся.

Это Target.  Host по-прежнему остаётся ПеКа с ОСью.

#39
18:56, 27 июля 2021

Gradius
> При всей их продвинутости, GCC наверное туда не поставишь
А зачем? CC - это сделанный на коленке компилятор для написания UNIX-утилит. Много весит он только из-за "совместимых кусков". Обычно BIOS-разработчики идут более простым и удобным путем: реализуют что-то FORTH-образное и не заморачиваются.

Gradius
> Это Target.
Да весь Ваш проект - Target. Реализуйте под Must Die простое графическое окно и не парьтесь. При нынешних скоростях сойдет даже HTML-gif-окно.

Страницы: 1 2 3
ПрограммированиеФорумОбщее