x86_64 – 64-битная версия (aka AMD64 aka Intel 64).
i586 – это Pentium, 32-битная версия (x86, IA-32; указанно именно i586, чтобы не пытались устанавливать на 80386, 80486).
И о том, и о другом, собственно, выше упомянуто же.
Это нетипично, но бывает. Искать такие демы я не буду, т.к. таких критериев поиска на pouet, к примеру, нет. Но я думаю, что нагуглить при должном старании можно. Собственно, а почему нет, если это не запрещено правилами, а размер неограничен?
Я был как раз на обозначенном автором CAFePARTY, и там была лекция про Tooll2 и даже дема на нём же (которая заняла призовые места и вызвала много дискуссий). Да, это не 3D-движок, но не все демы 3D. Кроме того, есть конкурсы типа One Scene Compo, где прямо в правилах написано, что можно использовать Unity, Unreal и пр.: cafeparty.org.ru/2019/compo-rules/#demointro
В статье вообще 128-байтовая интра под DOS обсуждается :)
Тогда и обсуждение 3D-движков/OGL/DX не в тему.
Но мы же уже давно отклонились от темы в этой ветке обсуждения…
Да, демосцена – это просто энтузиазм, творчество, хобби.
Некоторые (а может и многие) прогают графику чисто для души, на работе же занимаются совершенно другими задачами.
Вообще, конечно, сцена под DOS и под Windows очень сильно отличается как минимум наличием функций и библиотек, которые доступны на уровне ОС.
Да, 4k обычно – это шейдер с кодом его запуска + музыка, созданная в 4klang (с плеером из той же коробки).
А по поводу места (меньше CPU-код или шейдер), то есть 32- и 64-байтовые демки, которые далеко не всегда можно уложить в такой шейдерный код. Да и многие 256-батовые тоже. Тут всё зависит от сложности эффекта, пожалуй ;)
Есть всякие там Tooll2, fxEngine и т.п. штуки. Другое дело, что это не всегда приветствуется и порой вызывает споры.
Ну и к слову сказать (хотя это уже несколько другое), группы нередко делают кастомные движки, но в основном для себя. И это уже не критикуется, ибо работа получается полностью авторская.
Работа шейдера и подобной интры принципиально разная.
В шейдере каждый кадр вычисляется цвет каждого пикселя.
А в подобной же интре меняется (вычисляется) координата точки и там определяется цвет. Грубо говоря, рисуется линия по-точечно (а не вычисляется цвет на основе принадлежности координаты линии для всего экрана). И изображение соответственно меняется отдельными точками, а не кадрами (тут даже нет ожидания начала кадра – ретрейса).
Пример интр, работающих по принципу шейдеров – Puls by Rrrola (на основе рей-марчинга) или фракталы (Мандельброт/Жюлиа). Т.е. где идёт проход по всему экрану и вычисляется цвет каждой точки. Правда, без многопоточности :))
Хорошая статья, очень подробно всё описано (хотя я читал немного по-диагонали, т.к. лично для меня тут всё довольно очевидно, тем не менее 1-2 момента для себя всё же отметил). При этом интра не шибко сложная, но симпатичная. Для начинающего демомейкера в категории PC tiny intro, ИМХО, довольно хороший туториал получился.
Я бы с удовольствием почитал разбор навороченных интр типа тех, что делает Digimind, к примеру. Или Rrrola, Red Sector Inc и другие ребята такого уровня. Hellmood/DESiRE, кстати, в своих микро-интрах (32/64 байта) обычно оставляет исходники с подробными комментами, за что ему большой респект. Вот, кстати, полезный ресурс в его соавторстве: sizecoding.org.
Есть же сортировки не только сравнением.
Counting Sort и Radix Sort при небольшом разбросе значений можно принять за O(n).
Bucket Sort в некоторых случаях с некоторыми оговорками – тоже O(n).
Иногда через «O» оценивают скорость вне зависимости от размера n.
Если вы так не делаете, тогда отлично, значит для вас мои речи не столь актуальны.
Тем не менее, что считать «большими числами»? Миллиард – это много? Однако ж log2(1млрд) ≈ 30. Не такой уж и большой коэффициент в некоторых случаях. Я уже начинаю повторяться :))
mov al,1out 92h,al
Из-под V86 спокойно перезагружает комп на 98-й винде (пробовал у себя через VMware – перезагружал, естественно, гостевую) :)
cli/hlt в r0 из-под PMode тоже вполне спокойно вешает систему (конечно, от NMI/SMI не защитит, но они почти наверняка и не возникнут).
clijmp $
Вполне успешно вешает комп в той же 98-й, будучи запущенной из-под V86 (а вот cli/hlt вылетает с исключением).
i586 – это Pentium, 32-битная версия (x86, IA-32; указанно именно i586, чтобы не пытались устанавливать на 80386, 80486).
И о том, и о другом, собственно, выше упомянуто же.
Довольно годные :)
Я был как раз на обозначенном автором CAFePARTY, и там была лекция про Tooll2 и даже дема на нём же (которая заняла призовые места и вызвала много дискуссий). Да, это не 3D-движок, но не все демы 3D. Кроме того, есть конкурсы типа One Scene Compo, где прямо в правилах написано, что можно использовать Unity, Unreal и пр.: cafeparty.org.ru/2019/compo-rules/#demointro
Хотя… 4k обычно Crinkler'ом сжимают вообще и ничего :)
clijmp short $ ; hlt (в Win98, по крайней мере) не сработает
А перезагрузит:
mov al,1out 92h,al
Тогда и обсуждение 3D-движков/OGL/DX не в тему.
Но мы же уже давно отклонились от темы в этой ветке обсуждения…
Некоторые (а может и многие) прогают графику чисто для души, на работе же занимаются совершенно другими задачами.
Вообще, конечно, сцена под DOS и под Windows очень сильно отличается как минимум наличием функций и библиотек, которые доступны на уровне ОС.
А по поводу места (меньше CPU-код или шейдер), то есть 32- и 64-байтовые демки, которые далеко не всегда можно уложить в такой шейдерный код. Да и многие 256-батовые тоже. Тут всё зависит от сложности эффекта, пожалуй ;)
Довольно много компо не имеют требований по размеру.
Взять, к примеру:
www.pouet.net/prod.php?which=53816
www.pouet.net/prod.php?which=66380
www.pouet.net/prod.php?which=62917
www.pouet.net/prod.php?which=76418
И т.д. Всех не перечесть, конечно…
Ну и к слову сказать (хотя это уже несколько другое), группы нередко делают кастомные движки, но в основном для себя. И это уже не критикуется, ибо работа получается полностью авторская.
В шейдере каждый кадр вычисляется цвет каждого пикселя.
А в подобной же интре меняется (вычисляется) координата точки и там определяется цвет. Грубо говоря, рисуется линия по-точечно (а не вычисляется цвет на основе принадлежности координаты линии для всего экрана). И изображение соответственно меняется отдельными точками, а не кадрами (тут даже нет ожидания начала кадра – ретрейса).
Пример интр, работающих по принципу шейдеров – Puls by Rrrola (на основе рей-марчинга) или фракталы (Мандельброт/Жюлиа). Т.е. где идёт проход по всему экрану и вычисляется цвет каждой точки. Правда, без многопоточности :))
Я бы с удовольствием почитал разбор навороченных интр типа тех, что делает Digimind, к примеру. Или Rrrola, Red Sector Inc и другие ребята такого уровня. Hellmood/DESiRE, кстати, в своих микро-интрах (32/64 байта) обычно оставляет исходники с подробными комментами, за что ему большой респект. Вот, кстати, полезный ресурс в его соавторстве: sizecoding.org.
p.s. Жоре привет! ;)
Counting Sort и Radix Sort при небольшом разбросе значений можно принять за O(n).
Bucket Sort в некоторых случаях с некоторыми оговорками – тоже O(n).
Если вы так не делаете, тогда отлично, значит для вас мои речи не столь актуальны.
Тем не менее, что считать «большими числами»? Миллиард – это много? Однако ж log2(1млрд) ≈ 30. Не такой уж и большой коэффициент в некоторых случаях. Я уже начинаю повторяться :))