Вот начал окультуривать свою курсовую игрушку. Пишу в Borland C++ 3.1
Почитал о bmp, открыл, вывел, всё отлично... но...

Открытие файла происходит очень медленно, у меня на машине это не заматно, но в ВУЗЕ и на машиене в соседней комнате это занимает около трёх секунд.

По совету препода и одногруппников, решил перед тем, как программа запуститься, считать все картинки в оперативную память и с неё напрямую их грузить.

Здесь как раз и вышла заморочка.

Выставил в компияторе heapsize 640 Kb, начал выделять память.
У меня около 10 картинок 640x480 256(цв), следовательно выделил:



Подгрузил картинку, всё ок. Но потом понял, что я уже использовал 640*480*1 байт или 300 кб, памяти у меня под всё 500 с чем-то (проверил спец. функцией). Второй раз выделить столько же не получилось.

Вопрос такой, можно ли как-нибудь обхитрить это дело и занести в ОЗУ через DOS хотя бы 3000 кб, ведь я точно знаю, что к примеру такие игры как Doom, Quake подгружали в память намного больше, и писались под C++ (правда компиль был другой), однако они тоже под Dos.

Или хотя бы подскажите, как можно загрузить эти 10 картинок, чтобы используя всего около 500 кб, можно было играть вполне без подзагрузок. Вариант каждый раз вывешивать 'Loading' не очень то нравиться, учитывая, что небольшие объекты в игре должны быть подвижными.

PS: Знаю, что 640 кб - это предел, как завещал наш бог Билли Гейц, этого достаточно для программ в DOS)))
Переезжать на WinAPI к примеру или OpenGL я не собираюсь, т.к. очень много работы уже под Dos, а именно прорисовки, сделано.

использовать нереальный режим (unreal mode)
получим возможность использовать адресацию 32-ух разрядного режима (а значит получим доступ ко всей памяти) при отсутствии всех ограничений в плане защиты (в отличии от защищенного режима)

Это сообщение отредактировал(а) MAKCim - 15.4.2007, 20:06

Все досовские игрушки, богатые графикой, запускали расширение DOS 4 GW (если не ошибаюсь в названии) - это расширение предназначеное для работы программы в защищенном режиме (поправьте, если я его путаю с "нереальным", так как о таком режиме слышу впервые). Кажется, программы, использующие это расширение, были скомпилированы на Watcom C.
Только учти, что в защищенном режиме не работают прерывания БИОС (например, переключение режимов работы дисплея), поэтому, к этим играм прилагался драйвер видеокарт. Забыл как назывался, но помню, что он не поддерживал изделия NVIDIA.

Короче, мой совет, переходи на API операционной системы защищенного режима, иначе реализовать будет трудно.

Из-под ДОС в реальном режиме, можно попробовать обратиться к драйверу HIMEM.SYS с просьбой выделить память... Но я этого никогда не делал.

нереальный режим - это реальный режим без адресных ограничений
так что это немного другое

Если честно, не припоминаю такого режима. У x86 начиная с i386 было 3 режима:
1. реальный
2. защищенный
3. виртуальный x86

"Нереального" тут нет. Или ты про работу в 0 кольце защиты?

http://en.wikipedia.org/wiki/Unreal_mode

Блин. Забыл про этот "хак". Не думаю, что стоит его использовать напрямую. Лучше уж через HIMEM.SYS - хотя бы не будет проблем со smartdrv.exe.   
Вот только меня гложат смутные сомнения на счет реализуемости этого без привлечения ассемблера.

если без использования библиотек, без ассемблера никак   

Все что я знаю об этом.

1). Использование Xms через himem.sys
Если мне не изменяет память это позволит тебе записывать в память до 64 mb.
Однако там не будет прямой адресации, будет косвенная через буфер, лежащий в 640кб. 
Процесс таков :
1. Начало программы. Записать данные в область памятивыше >1m
2. Необходимость использования данных. Скопировать их из >1mb в <640кб.
3. Использовать.
Таким образом за возможность использовать >1m память ты платишь
1. необходимость использовать операцию memcpy размером нужных тебе данных.
2. надо место под буфер в памяти <640 кб.
Такой способ имел название "быстрый жесткий диск"

2). Используй компилер watcom c++ 10.0
С ним тяжело разобраться, но с ним идет дос-расширитель do4gw, который ничего не просит,
а дает возможность явной адресации. Там уже будет не сегмент смещение.

Я сам писал как-то порт клона движка wolfenstain3d Фрунзе на tc3.0 и использовал схему с xms.
Если ты будешь мудро использовать память. (мало операций memcpy), то скорость будет очень высокая.

Кстати небольшой оффтоп.
wolfenshtain 3d писался на borland c++ 3.1
doom2 - watcom (версию не помню)
quake2 - visual c++ 6.0

Вот ссылка на техническое описание
У меня есть реализация под turbo c++ 3.0
если тебе интересно, могу ее выслать.

  

Вот вырезки из моей многострадальной недоделанной игрушки.

Общие вещи... проверяем наличие драйвера, доступность хотя бы метра памяти свыше 640кб.


Грузим те текстуры, которые составляли основу дизайна уровней.
Их много, поэтому в conventional memory они не умещаются.


Текстуры грузились группами, т.к число дескрипторов, отводившихся под адреса памяти было ограничено кажется 16-ю. Т.е загрузить можно хоть 64mb, но не более 16-ти кусков. Про это должно быть сказано в спецификации и мне это не кажется неудобным.

Какая-то функция для удобства дальнейшей работы.



Где-то в дебрях функции отрисовки стен, дверей и спрайтов врагов.


Отрисовка статус бара


Ну и завершение работы с xms


На пне 166 игрушка давала 30 кадров в секунду, а на каждый кадр происходило копирование 2-8 текстур стен (4096 байт каждая), 1-4 спрайтов врагов (тоже 4096), 34*320 байт на строку состояния игрока. Т.е тормозил игру только просчет геометрии мира, но не копирование из >1m памяти.

Я ложу 4 файла XMS.CPP XMS.H XMSTEXTU.CPP XMSTEXTU.H. Это работа с xms. В плане самой программы там, конечно, есть зависимости от других модулей


Присоединённый файл ( Кол-во скачиваний: 6 )
 WolfShte.rar 2,42 Kb

К приведенному списку игр маленькое добавление: Quake 1 для DOS. Он был откомпилирован DJGPP -- портом GCC для DOS, который использовал свой собственный DOS-экстендер и CWSDPMI в качестве DPMI-сервера. А DOOM1/2 - действительно Watcom C с DOS4GW в качестве экстендера. (Кстати, есть бесплатная альтернатива DOS4GW: PMODE/w или как-то в этом роде называется.)

А что, если в DOS просто использовать EMS в качестве XMS с помощью EMM386.exe, предварительно отредактировав config.sys? Взять сколько нужно памяти, или же всю доступную.

Нифигасе : это конечно замечательно, но боюсь со своей ВУЗ'овской нагрузкой мне с этим не разобраться, слышал, что можно использовать far указатели, можете пояснить, что это такое и с чем едят, да и можно ли действительно с ними работать под Borland C 3.1?

demonoide, 
в DOS (= реальный режим работы CPU)
любой адрес так или иначе определяется как A << 4 + B, где A - значение регистра CS/DS/SS/ES/GS/FS, а B - значение регистра IP (если A = CS) или любое 16-ти битное значение, используемое в качестве адресного операнда относительно DS/SS/ES/GS/FS
обычный (не far) указатель содержит это 16-ти битное значение в то время как far указатель дополнительно содержит 16-ти битный сегментный адрес (А)