main()
{
  system("xv cool-super-puper-porno640x480.jpg");
}

i don't need to view porno in *.jpg... (-:

ya by predpochel vyvodit' svou grafiku, kotoraya, dopustim, uzhe lezhit v bufere i ee tol'ko nuzhno zapihat' v videopamyat'.

tak chto:

1. - kak ustanovit' nuzhnyi mode?

2. - kak pisAt' v videopamyat'? (libo vyvodit' grafiku drugim bystrym sposobom...)

svgalib подойдёт? www.svgalib.org

spasibo. mojet i podoidet.

P.S. samu biblioteku poka ne smotrel, no simple tutorial mne uje nraavitsya - s moim poganym enlishem ni razu ne prishlos' lezt' v slovar'.

Слушай, это тебе не дос попсовый. Нет никакой видеопамяти. Забудь.
Но, как мне кажется, тебе лучше всего подойдёт SDL - это портабельный
аналог DirectX. Смотри сюда, тут и примеры и сама библиотека:
http://www.libsdl.org/

я-бы посмотрел(настрадавшись в свое время с svgalib) в сторону libsdl или mesa

Nachnem s togo, chto DOS - eto ne popsa. prosto eto ot MS i u tebya, vidimo, vrojdennoe k nemu otvraschenie... nu da ladno, razgovor-to ne o DOS, a o videopamyati:

1. ne zabudu. u menya pamyat' poka esche horoshaya. (-:

2. Ne veru ya, chto v linux'e nel'zya obratit'sya k videopamyati.

posmotrel ya uje SDL - ne podoidet.

pardon za pospeshnost' (-:
dochital introduction. nado posmotret' - mojet vse-taki voz'mu SDL..

DOS - таки попса, так как однопользовательская, незащищенная ОС без разделения времени. От того DOS и позволяет страдать всяческим онанизмом вроде прямой записи в видеопамять. Нормальные люди так не поступают. Так что забей на свою память и быстрее забывай про это говнище. Ну а SDL тебе таки подойдёт, ты посмотри на готовые демки и игрушки. Самое главное в SDL - это портабельность. При желании даже под сволочным DOS-ом можно её заставить работать.

Togda DOS - eto popsa tol'ko dlya teh, komu nujna mnogozadachnost', razdelenie vremeny i ne nujen onanizm vrode pryamoi zapisi v videopamyat'. No eto esche ne znachit, chto vse ostal'nye - nenormal'nye.

Da... Kstati... poputno esche povedaite kto-nibud', kak zapretit, sisteme swapit' kakoi-libo process.

DOS, мы тебя не забудим!
Но следует помнить, что он безнадежно устарел, что реального режима у процессоров нет, кажется, еще со времен 486- просто при загрузке они его эмулируют, причем у последнего поколения по моему нет даже этого.
Используя SVGAlib вы лишаете даже потенциальной возможности воспользоваться вашей программой пользователей не только MakOS, BSD, Win, BeOS етс но и Linux на SonyPS, Sun SPARC или Nokia MediaTerminal, причем совместить X и SVGAlib даже на PC на многих картах представляется весьма затруднительным (на моей Voodoo, говорят приводит к вылетанию X.....)
в SDL есть возможность обращатся к видеопамяти (или эмулировать подобное), но попытка совместить это, например, с аппаратным OpenGL, в лучшем случае приведет к многократному падению производительности.....

А ты не пробовал читать Фроловых Программирование графики ? (только там по-моему еще есть слово VGA :) или почему бы не воспользоваться нормальным GTK ? он везде рулит, даже на Win переносится.

2Serik: net, ne proboval.

2Anonimous: da-da, ty prav - ustarela DOS.
zakroem temu. ya vybral SDL.

Ха. Свою карьеру с ДОСа начинали только ламеры. Так что не стоит гордиться "славным прошлым".

А по поводу SDL+OpenGL - никаких проблем нет, советую посмотреть на всяческие демки, ну или на игрушку tuxracer - всё прекрасно совмещается.

2Antichrist
OpenGL+SDL - никаких проблем, прямое обращенее к видеопамяти вперемешку с аппаратным OpenGL- см. выше,
Ха. Свою карьеру с ДОСа начинали только ламеры. Так что не стоит гордиться "славным прошлым".
а с чего начинали Вы, Guru? и когда это было

Эт смотря как писать. Стояла задача - нужен был Бейсик для обучения стьюдентов - написал свой BGI (эмулятор). Конечно, тогда не было ни svgalib, под Фрю вроде и до сих пор нет, ну да - макаронный код из #ifdef-ов, но ведь работало под SCO/FreeBSD/Linux/DOS... При желании например RT и графика совместимо, так что DOS в некотором смысле живее всех живых, т е вышеперечиленные операционки более сильно изменились, чем DOS за это время.

2Antichrist: ochen' neostorojnoe zayavlenie... ya znau neskol'ko chelovek, kotorye nachali s DOS i lamerami ih nazvat' kak-to yazyk ne povorachivaetsya.

Еще раз - SDL может работать ПОВЕРХ OpenGL, используя его как низкий уровень (так же как и поверх DGA). Естественно, никто не станет перемешивать DGA с OpenGL. А начинать надо было хотя бы с совковых аналогов DEC-овской или голубой техники, но уж никак не с персоналок. Ибо писюки и особливо DOS мозги портят преизрядно. Мне после RSX и VMS на писюки и смотреть не хотелось..,.

Очевидно, шибко крутые эти перцы были, если им такая дрянь, как DOS, мозги не смогла покалечить.

Гы, на LOR появился еще один крутой спец (вдобавок к vsl'у). Кул haЦKer, млин. Ну давай, расскажи, чем ты круче тех парней, которые делали ковырялки на Spectrume, размещавшиеся в 1/3 видеопамяти (потому как основная память занята под ковыряемую прогу). Чем слабее машина и ОС на ней, тем, как правило, почему-то качественнее код. Может быть, подумаешь на досуге, почему так происходит?

2nobody: А ты посмотри в инфо, из какого города vsl, и из какого города Antichrist. Наводит на размышления :-)

da. shibko krutye eti percy, potomu chto umeut sdelat' na tom, chto est' v rasporyajenii (DOS) to, chto nujno zakazchiku, pri etom sohraniv psihicheskoe zdorov'e i ne vozmuschayas' "oi! kakaya eta DOS nehoroshaya, daite chto-nibud' poprosche. i voobsche vse der'mo krome UNIX". Oni prosto delali lybimoe delo. im eto bylo interesno.

2justme. Спасибо за подсказку, посмотрел, вопросов больше нет :).

kak chuvstvoval, chto etim konchitsya... my tut daje stavki sdelaly - na kakom soobschenii poidut lichnye oskorbleniya... (-^

Долой ублюдочные C/C++! Всем переходить на VBA! (так считает самый крутой программер с лексикой дворовой шпаны).

C/C++ популярны вовсе не из-за того, что это хорошие языки. Просто когда писали первый ЮНИКС, не было ничего лучше C. А после этого - уже мода, привычка, "совместимость", незнание альтернатив, когда они есть.

C/C++ имеют слабую типизацию, не позволяют иметь range-checking в генерированном коде (за исключением может быть С++, но не видно, чтобы этим как-то пользовались), поэтому в программах на C/C++ постоянно находят buffer overflows.

Да и вообще, на мой взгляд, C++ и C уже морально устарели.

Проблема с типами - далеко не самая болезненная для C++. Куда как важнее то, что это чисто императивный язык, и он страдает от всех недостатков императивщины. Да и устарели C/C++ не сейчас, а еще до своего рождения - ведь тогда уже давно существовал Лисп.

2justme. А насколько код, сгенеренный компилятором Ada, лучше кода, выходящего из-под компилятора си (если Ada - компилятор)? Это не подковырка, мне действительно интересно. Я тоже не считаю си идеальным языком, но, насколько я знаю, по эффективности он уступает только асму. Я не прав?
2Akan. Не надо понимать мои слова всерьез, это просто ехидство. Оно относится еще к давним нашим спорам с Antichrist (aka vsl).

Эффективность Ады

Теория: в Аде нет ничего такого, что вынуждало бы компиляторы генерировать медленный код, за исключением всяких run-time checks, которые можно отключить (после отладки, разумеется :-). Даже есть некоторые особенности, которые теоретически могут позволить генерировать код более быстрый, чем компиляторы С.

Практика: В случае i386-linux компилятор по сути дела один - GNAT, использующий back-end gcc 2.8.1. Поэтому оптимизация должна быть где-то на уровне C. Если есть интерес, то можешь написать сюда какую-нибудь программу на C(++), я попробую написать аналогичную на Аде, и сравним.

Вообще, где-то писали, что если программы одинаковые, то GNAT и GCC генерируют одинаковый код. Есть ещё интересная история о том, что компилятор Ады генерировал код более быстрый, чем написанный вручную на ассемблере: http://tangle.seas.gwu.edu/~adagroup/sigada-website/lawlis.html.

Я недавно пробовал сделать бенчмарк, упоминавшийся в одном из комментариев к новостям (сто тысяч хелловорлдов), он получился раз в 5 медленнее, чем на С, дело скорее всего в библиотеках. Если есть интерес, то могу написать программу на Аде, которая будет пользоваться Сишными функциями, и сравнить.

Вообще, неправда, что быстрее C только ассемблер. Математические вещи, например, пишут на Фортране, для которого существуют сильно оптимизирующие компиляторы. Для новых процессоров (IA-64) вообще код на ассемблере писать будет бессмысленно.

2justme: skaji pojaluista, bud' tak lubezen kto, gde i kogda napisal pervyi UNIX i na kakom yazyke. a, da, chut' ne zabyl - pod kakuu platformu esche povedai.

А ты не помнишь? 69й год, Bell Labs, машинка PDP8. Писано сначала было на ассемблере, потом бОльшую часть переписали на C. Самого что ни на есть первого юникса я тебе не найду, а вот самый первый релиз System V можешь взять на поиграться, всё это лежит у меня тут: ftp://ontil.ihep.su/pub/mirrorz/emu/

Вот плюсовый код:
int buf[128];
for (int i = 0x7fffffff; i; i--)
  {
  int *p = buf;
  for (int j = sizeof(buf); j; j--)  *p++ = 0;
  }
Если не лень, сделай, pls, что-нибудь подобное на Аде. Инициализатор "i"
можешь поставить любой достаточно большой. Результаты выполнения обеих
прог запости потом сюда, pls (результатом будет время выполнения).

Если Ада окажется быстрее, попробуй сравнить ее с аналогичным кодом на асме:
  push edi
  mov edx,0x7fffffff
  sub esp,512
  cld
  xor eax,eax
L0:
  mov ecx,128
  mov edi,esp
  rep stosd
  dec edx
  loop L0
  add esp,512
  pop edi
  ret
Код для транслятора nasm (не нравится мне синтаксис gas).

Насчет Фортрана я с тобой спорить не буду, мат.расчеты - не мой профиль.
А вот насчет "Ада бастрее асма"... Ну ведь одно же из трех: либо программер
был не очень, либо он это делал левой ногой, либо гон. Ну подумай сам,
какие еще могут быть варианты? Только не воспринимай это как наезд на
Аду,
я то же самое скажу про любой другой язык высокого уровня. Ну не может
компилятор сделать код лучше, чем профессионал-ассемблерщик, тем более
когда речь идет о 10000 строк кода на асме (ладно бы еще 1000000). Он
может сделать сравнимый по скорости. Но чтоб быстрее, да еще в 2 раза...

Это все было об эффективности. Теперь об удобстве программера: чем Ада
в этом отношении лучше с++? Меньше время разработки/отладки? Меньше
багов в программах? И вообще, на кого он ориентирован: на системщика или прикладника?

2nobody loop LO на JNZ LO замени, а то Asm в 0x7fffffff раз всех уделает.....

ОК, состряпал:
1. Во внутреннем цикле, я так понимаю, надо sizeof (buf) заменить на sizeof (buf) / sizeof (buf[0]). Это соответствует программе на ассемблере, вариант на C вылезает за границы массива.
2. Программу я переделал на C - объявил переменные i и j перед циклами.
3. Я так понял, программа должна просто огромное количество раз обнулять массив. Программу на Аде я сделал, исходя из этого, по-другому, впишу её сюда на всеобщее обозрение следующим постом.
4. Огромное количество раз из п.3 пришлось несколько уменьшить. Вместо 7FFF_FFFF я поставил 7FF_FFFF.

5. Компиляция (программа на Аде компилируется без run-time checks):
gcc-2.8.1: gnatgcc -O2 -march=i686 test.c -o test-2.8.1
gcc-2.95.4: gcc-2.95 -O2 -march=i686 test.c -o test-2.95
ada: gnatmake -O2 -gnatpn -march=i686 test_ada

6. Результаты:
$ time ./test_ada
real 1m26.135s
user 1m21.000s
sys 0m0.520s

$ time ./test-2.8.1
real 1m28.428s
user 1m20.950s
sys 0m0.560s

$ time ./test-2.95
real 0m59.131s
user 0m54.800s
sys 0m0.320s

7. Выводы: Код на Аде имеет такое же быстродействие, как и код на С в случае gcc-2.8.1 (он сейчас используется как back-end для GNAT'а). gcc-2.95.4 естественно впереди. GNAT планируют перевести на новый back-end к релизу gcc-3.1, тогда он скорее всего догонит gcc-2.95.

При этом программы на Аде более читабельны, количество ошибок в них в несколько раз меньше, чем в программах на С - есть несколько исследований, подтверждающих это. Кстати, твою опечатку с sizeof в Аде сделать трудно, если вообще возможно.

Ада ориентирована примерно на ту же область, как и С. При этом имеет такие высокоуровневые возможности, как поддержку multi-threading и шаблонов, и такие низкоуровневые возможности, как обозначение положения элементов структур с точностью до бита.

Пример программы на Аде - отладчик gvd (GNU Visual Debugger) - http://libre.act-europe.fr/gvd/

Насчёт Ады и ассемблера - почитай, там пишут, что как раз наоборот, программист, писавший на ассемблере, был более опытный, чем тот, который писал на Аде. Вообще, на x86, конечно, ассемблерные программисты могут написать более быстрый код, чем компиляторы, поскольку оптимизировать для CISC-процессора с 8-ю регистрами довольно-таки трудно, но для RISC-процессоров писать на ассемблере IMHO глупо.

P.S. Сейчас сделал ту же программу на ассемблере, выполнилась за ~30 сек. Интересно было бы сделать все эти тесты на каком-нибудь RISC'е.

Программа на Аде, которую я тестировал:

--  File: test_ada.adb
pragma No_Run_Time;  -- для большей эффективности

procedure Test_Ada is

   Buffer : array (0 .. 127) of Integer;

begin

   for I in reverse 0 .. 16#7FF_FFFF# loop
      Buffer := (others => 0);
   end loop;

end Test_Ada;

2justme. Спасибо! Код, конечно, непривычный (на Аде), но понять можно. Так вот, обнуление массива идет в строке:
Buffer := (others => 0);

как я понял? Т.е., одной записью? А как будет
buf[i] = i & 1 ? fn1(i) : fn0(i);
Или еще какой-нибудь подобный сложный код? Для каждого варианта своя запись, а если ее нет, то и возможности это сделать нет? Или это у тебя просто оптимизация для частного случая? А нечто подобное виртуальным функциям есть? И вообще, что порекомендуешь почитать для ознакомления?

Теперь опять по асму. Ну не получится у тебя написать код на языке высокого уровня, когда требуется что-то более сложное, чем офисная приблуда. И памяти не хватит, и риал-тайм не сделаешь. Возьми, например, прибор на ADSP (если уж мы говорим о RISC архитектуре), который в реальном времени читает АЦП (с которого данные идут с частотой 1кГц), обрабатывает то, что считал, и пишет это на флэш, которой управляет вручную (дергая сигналами, точность которых измеряется микросекундами). А еще надо принимать команды по последовательному порту (с персоналки). Последовательный порт тоже реализован полупрограммно. А куда помещать алгоритмы обработки сигналов, если памяти кот наплакал? На асме все это работает и всего хватает, но впритык, так что ни на чем другом это дело написать невозможно (при сохранении той же аппаратной части). А разработка новой аппаратной части стоит денег, и бОльших, чем софта, поэтому хочется выжать из железа все, на что оно способно (себестоимость ниже получается).

2Antichrist. Не старайся меня разозлить, кишка у тебя тонка. Пойди ROOT'а подонимай лучше, он - парень молодой, горячий :). Кстати, чем закончилось ваше с ним свидание? Или ты испугался, что побьют, и не пришел? :)

> 2justme. Спасибо! Код, конечно, непривычный (на Аде), но понять можно. Так вот, обнуление массива идет в строке:
> Buffer := (others => 0);

> как я понял? Т.е., одной записью? А как будет
Да, эта запись означает "присвоить всем элементам массива значение 0" (others в этом случае - все элементы массива), можно это рассматривать как оптимизацию, но это стандартная конструкция языка для таких случаев.

> buf[i] = i & 1 ? fn1(i) : fn0(i);
Одной строчкой не получится, и двоичные операции в Аде на числах легко не сделать, так что:

if I mod 2 /= 0 then
Buffer (I) := fn1 (I);
else
Buffer (I) := fn0 (I);
end if;

Насчёт виртуальных функций: Ада95 - это первый стандартизированный объектно-ориентированный язык :-) Так что, виртуальные функции, объекты, наследование - всё есть. Нет только множественного наследования, но есть (не очень элегантный) способ, как его сымитировать.

Я Аду выучил по книжке - Programming in Ada'95, John Barnes. В интернете есть Ada Lovelace Tutorial, с него я начинал, но книжка оказалась полезнее. Есть ещё книжка Ada as a Second Language, автора не помню. Если интересует "пропаганда" и сравнение Ады и C/C++, то загляни на http://www.adaic.org, там прямо наверху есть ссылка "Why Ada?"

Насчёт ассемблера - я DSP & friends никогда не интересовался и соответственно я про них знаю мало, поэтому рассуждать на эту тему особо не могу. Но согласен, что для "микроскопических" проектов, где нужно выжимать последние капли из оборудования, Ада подходит меньше. Главное преимущество Ады - не быстродействие или размер программ, а их надёжность плюс поддержка "принципов software engineering."

2justme:
Buffer := (others => 0); // а где указанно, что масив надо раком заполнять? и вообще, нельзя-ли посмотреть, что у ADы на ассемблере вышло? для gcc там -oСколько? опция Unrol All Loops используется?
P.S. и что за железо, чтоб можно было примерно сравнивать?

Не совсем понял, что имеется в виду под "раком" :-) Массив у nobody заполнялся от первого элемента к последнему, просто переменная j менялась от 128 до 1.

Если вместо Buffer := (others => 0); писать

for J in reverse 0 .. 127 loop
Buffer (J) := 0;
end loop;

то код получается абсолютно идентичный, то есть GNAT никак others не оптимизирует.

Ключи компиляции я сюда писал, -funroll-all-loops я не использовал. Сейчас прогнал тесты с ним, результаты:
Ada: 20-21s
gcc-2.8.1: 18-19s
gcc-2.95: 18.5s

Процессор Duron 700MHz, код, который генерирует GNAT, сейчас сюда впишу.

(командная строка: gnatgcc -S -O2 -march=i686 -gnatpn test_ada_forward_loop.adb)
 .file	"test_ada_forward_loop.adb"
	.version	"01.01"
gcc2_compiled.:
.text
	.align 4
.globl _ada_test_ada_forward_loop
	.type	 _ada_test_ada_forward_loop,@function
_ada_test_ada_forward_loop:
	pushl %ebp
	movl %esp,%ebp
	subl $512,%esp
	pushl %ebx
	movl $134217727,%ecx
	leal -512(%ebp),%ebx
	.align 4
.L5:
	movl $127,%edx
	movl $508,%eax
	.align 4
.L9:
	movl $0,(%ebx,%eax)
	addl $-4,%eax
	decl %edx
	jns .L9
	decl %ecx
	jns .L5
	movl -516(%ebp),%ebx
	movl %ebp,%esp
	popl %ebp
	ret
.Lfe1:
	.size	 _ada_test_ada_forward_loop,.Lfe1-_ada_test_ada_forward_loop
	.ident	"GCC: (GNU) 2.8.1"

Уупс, соврал слегка: код получается идентичный, если использовать вместо others нормальный цикл, для обратного цикла код естественно слегка отличается.

ЭЭ.....
А вот ссылка на http://www.adaic.org тоже, скажешь, правильная?

Works for me... Mozhesh poprobovat' http://www.adaic.com

2justme. Еще раз спасибо!