>>3555161 (OP) Как загрузить картинку BMP под ДОС. Читаешь, изучаешь формат файлов BMP. Он не очень сложный. Пишешь парсер, грузишь картинку в память. Главное, чтобы памяти хватило. Там же ограничение реального режима 640 КБ. Но есть ещё и EMS и XMS (кажется так они называются). И вообще можно попробовать переключить процессор в защищённый режим, и заюзать всю доступную память. С этой памятью можно промудохаться как следует.
В принципе всё, картинка загружена. Проблема в том, что наверное под ДОС надо её отобразить. На самом деле, вся задача отображения картинки сводится к задаче отображения произвольных пикселей.
Под ДОС надо будет экран переключить в нужный видеорежим. Это ещё одно направление пердолинга. Знаю про VGA режим 640x480, 256 цветов, палитровый цвет. Так просто больше режимов я не знаю. А картинка наверняка True Color, 24 битный цвет. Придётся мудохаться, как-то переводить её в 256 цветов. Вообще, вроде бы как-то можно задействовать видеорежимы с большим разрешением и глубиной цвета. Наверное, работая напрямую с видеокартой. Они, говорят, часто поддерживают стандарты VESA. Гугли в этом направлении. Получается, это ещё одна область пердолинга.
В общем, загрузить и отобразить BMP под DOS не так-то просто.
>>3557688 Рисовать под DOS элементарно, ставишь нужный видео-режим (1 команда) и пишешь байты по адресу (1 команда) видео-буфера, проще не бывает. Это в современном говне какая-то параша из 100 слоёв абстракций, шизофрения ебаная.
>>3557988 >Это в современном говне какая-то параша из 100 слоёв абстракций, шизофрения ебаная.
Чувак, под C++ Builder с библиотекой VCL, считать и нарисовать картинку в окне - дело 5 строк кода. О чём ты вообще? Как раз таки благодаря всем этим абстракциям такое возможно. Под Delphi всё то же самое.
Это с DOS нужны все эти изъёбства с ассемблером, видеорежимами, парсерами, ограничениями по памяти. Всё делать ручками. И перед этим ещё курить талмуды мануалов.
>>3558080 Не пизди. В окошках даже хеллоуворлд это миллион строк, винапи-парадигма, лупы сообщений, бла-бла. Поэтому до сих пор программирование учат сраньем текста в консоль. Раньше и то было умнее, рисовали графику, а в современном говне графика это система, а система мега сложная, голову сломаешь пока первый пиксель нарисуешь, вот никто даже не пытается, сидят в эмуляторе примитивнейшего говна из 1960 года - консоли, куда графику не завезли, и хрюкают что НИНУЖНО. лол. Потому что компьютеры стали сумасшедше-переусложненными, по такому калу ничего не научишь, ведь учить надо с основ, а основы закопаны под миллионом слоёв защит и абстракций, типа пользователю туда лезть не положено "ради вашей безопасности" кудкудах.
Сейчас чтобы научить программированию надо использовать какие-то микроконтроллеры с экранчиками на светодиодах, их вроде еще не успели засрать, хотя уже успели наверняка, лол.
>>3558666 Кстати базированно. Когда меня в группе чел учил шеллкоды писать, я мало того что через ROP его сдалать не смог: я сделал "обычный"... и не смог его запустить.
Формально всё верно. Какие-то настройки ос выключал, чтобы заработало. Но толи руки кривые, то ли не всё отключил.
Среди зумерков хаксоров будет мало, если будут вообще. Проще фишинг.
>>3558931 Дебил, эта хуйня бесполезна для учебы. Чему ты там научишься? Тыкать кнопки как тупая обезьяна, совершенно не понимая что делаешь, как это работает? Толку - ноль.
Чтобы пользоваться такими обертками, нужно УЖЕ ЗНАТЬ как оно под капотом устроено, оно нужно для ускорения РАБОТЫ, когда ты делаешь что уже знаешь, а не для учебы, не для узнавания нового. Такая простота мешает. Когда тупо на винапи пишешь, кода больше, зато он весь перед тобой, дальше понятно как писать, а в VCL всё скрыто, одни магические методы на каждый пук вызывающиеся непонятно как и откуда. А если магического метода для твоей задачи нет? Нужно заранее знать винапи и искать магию уже в целом соответственно.
>>3559077 Я лишь утверждал, что под виндой, с современными библиотеками и прочими средствами для программирования, загрузить и отобразить картинку BMP - дело раз плюнуть. И это так.
Что там, как там для учёбы. Что там под капотом - да посрать.
>>3559099 Если говорить о выводе изображений на окна, WinAPI позволяет выводить любые растровые изображения, сгенерированные программным образом. Позволяет закрашивать любые пиксели на окне в любой цвет. Этого вполне достаточно, чтобы далее написать любой код, какой тебе хочется, который бы генерировал нужные тебе пиксели и изображения. Ты можешь хоть 3D графику рендерить, и рисовать в окошках. Это что касается окошек и WinAPI (вернее его часть - GDI). GDI медленно работает. Если тебе нужна скорость, полноэкранный режим, изменение разрешения экрана и цветности пикселей - добро пожаловать к DirectX.
>>3558676 >Проще фишинг. Хакинг, фишинг... Кто этим будет заморачиваться? Зумерок с криминальными наклонностями просто возьмёт прохожего на нож в подворотне, вот и всё. Жизнь или кошелёк.
>>3559492 >Самое крутое 640x480 и палитра 256 цветов.
что будешь делать, когда BMP файл окажется с 24 битным цветом? И когда он будет разрешения 4К, и тебе надо будет вывести на 640x480 экран кусочек большой картинки?
>>3559607 >что будешь делать, когда BMP файл окажется с 24 битным цветом? Ничего, такое в DOS не нужно. Это всё зумерсвий визг дебила родившегося через 20 лет после конца DOS и перехода на Windows. Такие говнокартинки даже теоретически компьютер того времени не потянет. Хватит сочинять бред, обосрался, обтекай, малолетний дебил. Почему сопливое говно так любит кукарекать за старое о чем понятия не имеет? Да тогда даже твои выблядки-родители еще не родились.
Но если имеем дело с палитрой, то прост подгонять цвета к палитре, брать самый близкий палитровый цвет из доступных. Можно загрузить сразу линейную палитру, чтобы не ебаться с стандартной.
По поводу подгона разрешения - неплохо выглядит и быстро - выуживать по 4 цвета на пиксель ближайшим соседом, а потом брать средний цвет.
>>3559881 А я развлекаюсь с ассемблером под ZX Spectrum. Там всё просто до невозможности. И возможности компьютера такие маленькие, домашние и понятные. По-моему, чтобы изучить как работают компьютеры на самом низком уровне - надо как раз попробовать программировать под Z80.
>>3560119 Да, спектрум это круто. Один из первых компьютеров. 8-и битный ассемблер. Вроде все хорошо для лампового изучения с самых азов, но отталкивает то что графон урезан по самое нимогу. Разве с стандартным графическим режимом удобно иметь дело? Думаю спекки сейчас больше в плане цифровой археологии интересен, типа как раньше диды развлекались.
>>3560156 Z80 это очень примитивная и ограниченная система команд Это в вашем x86 есть целочисленное умножение и деление. А ещё такая роскошь, как FPU. В Z80 нет команд для ни умножения, ни деления. Ни тем более FPU.
Блядь, да я уже просто чтобы написать процедуру сложения двух целых 32-битных чисел, пердолился часов 12 с гаком. Там в Z80 есть регистр флагов с zero flag, carry flag, sign flag и прочими. Ну ты знаешь, в x86 тоже есть такое. И оказалось, что команда сложения 16-битных чисел не ставит все эти флаги! Для флагов извольте пользоваться 8-битным сложением через регистр аккумулятора! Я думал, что мне светит пердолиться по самые гланды, складывая таким образом. А код будет тормозным, что пиздец. Спасло лишь то, что я выяснил, что оказывается команда сложения с переносом 16-битных чисел всё-таки ставит эти сраные флаги. Удивительный изврат, но это факт. Теперь я просто сбрасываю carry flag, и у меня есть обычное сложение.
Я с графикой под спектрум не делаю вообще ничего. Уже просто пишу самые примитивные процедурки, вроде сложения этих двух чисел. Доставляет.
>>3560223 >А код будет тормозным, что пиздец. Не будет. Даже эти древние компы делали такие операции очень быстро. Лучше напиши транспилятор какого-нибудь высокоуровнего языка в этот асм для z80. Это будет прикольно.
>>3560223 И Z80 считается ещё продвинутым процессором среди 8-битных. Так-то был Intel 8008, где вот была полная жопа. А до этого, первый процессор Intel 4004 был вообще немощным калекой, что только для калькуляторов годился. Первый персональный компьютер Altair 8800 был выпущен в 1975 г на процессоре Intel 8080.
>>3560273 Там в Z80 ещё все главные вычислительные операции, вроде SUB, AND, OR, XOR, сдвиги всякие можно делать только через единственный регистр аккумулятора. Ибо ALU процессора жестко завязан на этот аккумулятор. Впридачу, любой побитовый сдвиг возможен только ровно на один бит.
Для тех же умножений и делений надо писать специальный код подпрограммы, которая бы это выполняла.
>>3560223 Традиционно, все 8-ми битные игрушки под эти компы писали как раз на ассемблере.
Погугли сайтик, посвященный игре Elite 1984 года. Там приводится все её исходники на ассемблере, плюс разбор различных аспектов программы. Например, генератора случайных чисел, генератора мира, процедуры умножения и деления, тригонометрические функции.
И вот прикинь, какого года рождения были программисты, создающие эти игры, и сколько им лет сейчас.
>>3560282 Современный x86, где одной командой за один такт на частоте 3 ГГц можно сложить или умножить 32-битные числа, расположенные в любом регистре - это просто блажь несусветная. Раньше в x86 была пенальти за обращение по невыровненным адресам, но теперь даже и его убрали.
>>3560285 Да я видел этот сайт. Просто отпад. И игра прикольная, на тот момент прорывная. Это надо было умудриться запилить 3д-игру на железках тех лет.
>>3560282 >Для тех же умножений и делений надо писать специальный код подпрограммы, которая бы это выполняла. В наше время это хуйня. Если не получится нагуглить сам код, то всегда можно найти в интернете алгоритм и реализовать его. Если память не изменяет, там есть пара алгоритмов умножения, один квадратичный, второй кубический, но второй при этом быстрее за чем счёт того, что умножаешь ты всё равно короткие числа.
А вот тогда вся эта информация была только в книжках или в статьях в журналах, или вообще недоступна. Вот приходилось людям изобретать что-то постоянно.
>>3560411 Ты осознай, что эти ребята не просто были программисты, которые кодили по таскам, спускаемым им сверху. Ребята буквально придумали всю эту игру. Придумали что там будет космос, корабли, планеты, торговля, и так далее. Они были ещё и геймдизайнеры, как это говорится на современный лад. Даже банально названия всех звёзд и планет - это тоже надо было придумывать. Программисты обычно таким не заморачиваются.
А то был 1984 год, релиз. Когда геймдев индустрия была в зародыше. И это США. В СССР вообще ничего не было. Всё было крайне просто. Electronic Arts была основана 2 года раньше.
GDC впервые была проведена только в 1988 году. Было 27 человек. Чисто тусовочка для своих. Ещё в 90-е она была очень скромным событием.
>>3560448 Ты подумай, как должны звёзды сойтись. 1. На дворе 1982 2. Нашим героям лет 20, они считай студенты 3. В то время, персональные компьютеры даже на Западе были редкостью. Много ли о них кто знал? Считались чудом техники. 4. Но тем не менее, эти студенты к этому году уже имели опыт и знания в программировании, чтобы накатать такую софтину 5. Учились наверное по книжкам и лекциям. Профессия была элитарной. 6. Когда же они начали изучать программирование?
Кстати я, когда начинал учить программирование в 90-х, я тоже по книжкам учился. Дональд Кнут, если что, опубликовался ещё в 60-е.
>>3560218 Да. Жесть. Я сейчас попробовал ради спортивного интереса в дампе спектрумовской видеопамяти разобраться и вывести картинку на экран и офигел пока делал это.
>>3560223 > А ещё такая роскошь, как FPU. Да, но нет. У x86 встроенная плавучка появилась только начиная с 80486, а до этого приходилось покупать отдельный сопроцессор за отдельные деньги. У восьмибитных процессоров такое тоже было возможно (Am9511/12 и их интеловские клоны), но популярностью не пользовалось.
>>3561316 Ебанутая адресация, как сообщают с мест, это последствия подлаживания под железо:
> When the ULA is drawing the screen, it needs to make two fetches from DRAM, for the pixel data and the attribute data. In order to make this more efficient, the ULA uses DRAM page read mode. The advantage of this mode is that the bytes can be read quicker, but there is a limitation: the least significant 7 bits of the address being read must be the same. http://www.breakintoprogram.co.uk/hardware/computers/zx-spectrum/screen-memory-layout
>>3561578 А как без циклов? Тут вроде можно обойтись одним циклом и формулу изобрести для прыжков по знакоместам. Но с формулой вроде медленно будет, с циклами быстрее.
>>3560223 Софтовое умножение в ZX имеется. Там есть встроенный калькулятор, можно помещать числа (целые и вещественные) в его стек и умножать, делить, извлекать корни, брать синусы и т.д. Но графический движок писать замучаешься. Я еле-еле сделал спрайты и с тайлами (как в NES) и обнаружил, что команда LDIR для копирования байтов очень медленная, полный экран выводится 6 секунд. Надо как-то настраивать SP на видеопамять и рисовать с помощью PUSH и POP, в демках так делают, но это уже изврат полный.
В целом годные темы для начинающих байтолюбов - 16-битные платформы, т.е. MS-DOS (COM файлы с лимитом в 64K) и Sega Mega Drive (там сложнее, нужно изучать видеопроцессор, но CPU очень простой, плюс никаких "мапперов" как у NES). Защищенный 32-разрядный режим i386 сложнее, там с одной настройкой прерываний замучаешься. А 8-битные системы слишком уж ограничены, если делать что-то сложнее Тетриса со Змейкой. Я клон Bomberman (черно-белый и на 1 игрока) для ZX так и не осилил. Тут нужно быть гением Медноноговым.
>>3559290 >>3559492 В DOS это видеорежимы VESA: https://www.osp.ru/pcworld/1998/07/159374 https://www.osp.ru/pcworld/1998/08/159480 Например, код 118h у 1024x768 True Color (24 или 32 бита). Но в 16-битном Real Mode они неудобны, т.к. экран не влазит в 64K сегмент, и потому нужно переключать банки видеопамяти. А в 32-битном защищенном режиме уже нет простого доступа к прерываниям BIOS и DOS (нужно настраивать таблицу прерываний и эмуляцию V86). На Watcom C++ для этого придумали расширитель DOS4GW, именно с его помощью были написаны Doom, Quake, WarCraft 2, X-COM и т.д.
>>3564342 >Я клон Bomberman (черно-белый и на 1 игрока) для ZX так и не осилил. Тут нужно быть гением Медноноговым. А как же демосценеры, которые всякие штуки для спектрума писали?