Добрый день. Впринципе, нужно иметь память под Z-буфер и 640х480 режим. В чистом realmode тяжко заиметь память под такой буфер, а и еще один буфер для смены кадра. (ну по крайней мере я не знаю способов как достать столько памяти, если подскажете - премного благодарен). Поэтому вот какие проблемсы: 1) Нужен линейный буфер, а, соответственно Vesa 2.0 2) Как решить проблему malloc'a больших областей памяти 3) Как это ГРАМОТНО сделать в BC ? (на чистом ASM'e проблем нет, затруднений у меня ничто не вызовет..., но здесь нужно именно на BC 3.1) Самое нужное - чтобы BC скомпилил нормальный код и не бодался при смене режимов. Итак, уважаемый All, чем подсобите? С уважением.
AsmGuru62 calloc() Скорее farmalloc, ибо %bc31root%\ctrl\calloc.c Код (Text): ... void * _FARFUNC calloc(size_t nelem, size_t elsize) { unsigned long msize; register char *cp; msize = (unsigned long)nelem * elsize; cp = (msize > 0xFFFF) ? NULL : malloc((unsigned)msize); if (cp) setmem(cp, (unsigned)msize, 0); return(cp); } ... dos_getmem() Afaik такой в bc31 нет. Elusory Jo Как это ГРАМОТНО сделать в BC ? (на чистом ASM'e проблем нет Использовать inline ассемблере нельзя?
О, ну впринципе тогда по идее проблем нет, буду пробовать. Его-то как раз и собирался, просто опасался что может быть не совсем корректно возможно падение...
_dos_allocmem (); Подзабыл TC 3.1 ... И совет: если большие аллокации есть в программе - с отладчиком такие аллокации могут возвратить NULL.
CnCVK Мне нужно в процессе работы динамически выделить 1200кило под Z-buffer, настройки компилятора и линкера здесь непричем..
Блин, farmalloc при числе, большем 64К возвращает NULL... Что делать? Модели памяти пробовал разные, все равно... =(
На крайняк мона использовать окна видеопамяти и, если видеопамяти достаточно, брать место для Z-buffer'а и дополнительного буфера там. Правда, она не кэшируется, что сильно скажется на скорости работы. А вообще, можно перевести проц в нереальный режим, падения быть не должно - никто и не заметит этого. Только к памяти придется обращаться явно не сишными способами из-за необходимости подставлять 0x67-prefix.
мой совет посмотри - может это отладчик ограничивает свободную память. Тебе наверно придется использовать XMS или EMS.
Elusory Jo нужно в процессе работы динамически выделить 1200кило Afaik средствами BC31 столько не выделить. Его alloc'и работают в пределах 640кб. Что касается "использовать XMS или EMS" (c) CnCVK, то работают они так: в области памяти за пределами 1Мб можно выделить сколько-то памяти, получить доступ к ней напрямую нельзя. Для ems доступ через 64-х килобайтное окно (адрес которого фиксирован), т.е. сделал запрос, получил кусок в окно, поработал, оповестил, что можно забрать (вернуть за пределы 1Мб), запросил и получил следующий кусок, обработал его и т.д. Для xms можно получать куски большего размера по любому адресу в пределах 640кб. В итоге вся логика работы на твоих (твоей программы) плечах.
Пипец... =( Мне тут посоветовали DOS-экстендеры всякие.... Что скажете? (просто я ни разу с ними не работал)
да все это я знаю. очень большое количество приложений используют эту технологию. специлизированное управление памятью, типа при обращении проверяем текущие EMS окно, меняем его и т.д. (например при обращении вызывать LockMemory и вызывать после UnlockMemory) И не надо говорить что все это просто ужас как сложно - это использовалось и весьма успешно. Попробуй скачай Open Watcom - там весьма и расшилители есть в комплекте
Хмм... Ясненько... А подскажите пожалуйста тогда... 2 вопроса: 1) будет ли тогда прога с дос-экстендером работать под виндой? 2) как прикручивать/компилить прогу с экстендером, возможно ли это на BC3.1? Как вообще с экстендером работать, а то я даже понятия не имею как и что, гугл ничего путного не выдал =(
Под Win2k и выше линейный буфер работать не будет в любом случае, независимо от того с DOS Extender'ом или без ты сделаеш программу.
