Pull to refresh

Comments 36

Теплые ламповые эффекты.
Минимум памяти, минимум кода, максимум результата.
Не то, чтобы я был старым ворчливым дедом, который считает, что раньше стоял лучше. Но про соотношение памяти к результату — как по мне сейчас ОЧЕНЬ актуальная проблема.
Уже жду, когда появится какое-то движение, по типу гринписа, только за экономию ресурсов памяти/энергии. Потому что иногда производители ПО уже выходят за рамки разумного.
Незнаю как насчёт старым но ворчливым я стал уже давно и последнюю фразу думаю стоит писать так:
Потому что иногда производители ПО ещё НЕ выходят за рамки разумного.

Платформа Electron нам доказывает обратное. И да, я старый и ворчливый, но по делу.
UPD: Хоть это и не имеет отношения к игростроению...

Ключевое слово "иногда" в значении "только иногда", верно?

достаточно бы было движения за «открытую статистику по структуре ПО» — т.е. сколько там в процентах ресурсов (сколько музыки, картинок, видео и проч), сколько сторонних либ и фреймворков (и их названия с версиями), и сколько — собственного кода.
Применительно к самому DOOM: EXE (код) занимал 693Кб, WAD (графика, звук, карты) — 4МБ. Кода в играх всегда намного меньше, чем художественной составляющей.
Ее (память) и сейчас также можно экономить. Только в таком режиме большой по современным меркам продукт за разумное время не напишешь. Если бороться за каждый байт, как на приставках раньше, то сколько займет написание игры типа GTA5? Плюс большинство людей забывают, что разрешение в несколько раз увеличилось, плюс битность цвета и размер текстур.
В приставочных играх и сейчас за память борются, так как там ресурсов сильно меньше чем на ПК, особенно уже ближе к концу жизненного цикла приставки. Когда она уже на порядки по производительности отстает от современных на этот момент ПК.
Я помню как удивлялся, что игры, шустро идущие на PS3 с ее 512М памяти, адово лагали и свопились на моем ПК с 2 гигабайтами.
Другое дело что разработчики сами никогда таким добровольно заниматься не будут, в случае с консолями их производитель приставки заставляет, просто не пропуская лагающие игры.
Уже нет. На PlayStation 4 некоторые игры тормозят вплоть до 10 FPS, сам видел. На PlayStation 4 Pro добавляют ещё больше эффектов, в результате и там игры тормозят вплоть до 10 FPS. Микрофризы и неравномерная задержка между кадрами — в порядке вещей. Ну а уж всякие квестовые баги и непроходимые задания были и в предыдущем поколении приставок. Тут ведь как всё обстоит: как только дали возможность исправить все «когда-нибудь потом» патчами, так начали забивать на тестирование и отладку, стараясь быстрее отправить игру в релиз и заработать деньги. «Когда-нибудь потом» при этом частенько не наступает вообще.
За рамки разумного они выйдут, когда наконец доделают Qt под WebAssembly. Электронщики уже ждут не дождутся возможности писать приложения под Electron на Qt…
Возможно все потому, что они не творцы, как те товарищи, о чьих трудах идет речь в статье, а именно производители.
[Прим. пер.: Youtube ужасно пережимает видео, лучше смотреть демо на Javascript в оригинале статьи.]

Так запостили бы гифкой:
23MB
На здоровье! Вот вам ещё и для КДПВ гифка вместо статичного кадра:

Гифки на 23 и 8 мегабайт, при том что демки целиком (вместе с логотипом DOOM-a) весят 400 килобайт.


Спрятал под спойлер

Ух ты! Я не знал, что Хабр позволяет такое инлайнить.
Безусловно, ваш вариант лучше, чем гифки.
Нет, не безусловно. Он жрет 15-20% цп на старичке 2600к и 80-150 метров оперативы. На мобильном устройстве откройте его.
Открыл сразу два демо, оба работают вообще без тормозов. При этом на странице предзагружены все гифки и видео.
// iphone 6s

Помнится на Speccy этот эффект (с практически идентичным алгоритмом реализации) был весьма популярен году в 1997-м или даже несколько раньше.

.webp — это, конечно, здорово, но вот огнелис его не понимает. Пока что, во всяком случае.
Единственный webp в посте — это монотонный чёрный прямоугольник, так что вы мало потеряли.
UFO just landed and posted this here
Если меряться, то по-полной. =)
Специально нашел свою школьную версию на 91 байт (есть на 97 с буферизацией), но на Досбокс сейчас, почему-то, работают с одинаковой скоростью, хотя раньше разница была налицо.

Код ASM
;╔════════════════════─────────────
;╟ CopyRight by Leushin Dmitry 2:5031/1.46@fidonet
;╚══════════════════════════════════─────────────────────
.MODEL TINY
.CODE
.386
ASSUME CS:@CODE,DS:@CODE
ORG 100H
START:
MOV AX,13H
INT 10H

CWD
XOR CX,CX

C8: MOV AX,1010H ;3
INT 10H ;2
CMP BL,63 ;3
JB SHORT C9 ;2
INC CH ;2
DB 03Dh ;1
C9: INC DH ;2
INC BL ;2
JNZ SHORT C8 ;2 = 23

PUSH 0A5D0H
POP DS

C0: MOV BH,20h
C1: CWD
DEC BX
MOV CX,3 ; 3
CP: ADD DL,DS:[BX] ; 2
ADC DH,0 ; 2
INC BX ; 1
LOOP CP ; 2
ADD DL,DS:[BX+318] ;
ADC DH,0
SHR DX,2
JZ SHORT C5
DEC DX
C5:
MOV DS:[BX-322],DL
DEC BX
CMP BH,9Eh
JNZ SHORT C1

MOV CX,320
C2: XOR DX,DS:[BX]
DEC DX
MOV DS:[BX],DX
DEC BX
LOOP C2

; MOV AH,01H
; INT 16H
; JZ SHORT C0
IN AL,60H
AAA
JB SHORT C0
MOV AX,03H
INT 10H
RET
END START

.COM файл в base64
uBMAzRCZMcm4EBDNEID7P3ID/sU9/sb+w3XtaNClH7cgmUu5AwACF4DWAEPi+AKX
PgGA1gDB6gJ0AUqIl77+S4D/nnXcuUABMxdKiRdL4vjkYDdyyrgDAM0Qww==

fire.com
У меня в DOSbox не работает (сразу завершается). Версия в 368 байт из поста выше работает.
Работает.
Она перестает работать когда из порта буфера клавиатуры вычитывает код соответствующий символу с младшим нибблом менее 9 (почему именно так? я не знаю).
Если перетаскивать программу на ярлычек досбокса (или любым другим способом передать ему программу параметром) — то нажатия клавиши не происходит, и в буфере клавиатуры лежит 0x00, вот оно и завершается.
Если запустить программу из консоли досбокса — в буфере клавиатуры будет код 0x9C, те «энтер отпущен», и она будет работать.
Так работает, но с «глюком», который периодически выезжает вниз из середины окна, а потом уезжает обратно.
У меня тоже. Но это к разработчику, лень разбираться.
Там в цикле dx не очищается, думаю, что в этом проблема, но это не точно. Была задача написать минимальный, и она была решена, возможно, сейчас я бы еще смог уменьшить, или нет. Там несколько грязных хаков.
Проблема с клавишей — раньше компьютеры были помедленнее и таких проблем не было. =) Писалось в 99м году на 386 в Дос Навигаторе на школьном компьютере.
UFO just landed and posted this here
Мне казалось, что алгоритм пламени известен практически всем. :) Во всяком случае, в 90-е мы его узнавали едва занявшись компьютерной графикой безо всяких интернетов друг у друга. Кстати, можно затравочную строчку менять случайным образом вместо того, чтобы добавлять случайность в каждый пиксель.
Никогда не мог удовлетвориться алгоритмом пламени, и реализовал свой.

Вот примеры моего алгоритма:

Z80 3.5 MHz 168 байт кода


Java через Processing

В коде нижний левый угол это нулевой индекс массива, а верхний правый угол имеет индекс FIRE_HEIGHT * FIRE_WIDTH — 1.

Только ведь верхний левый и нижний правый. В оригинале та же ошибка.
Sign up to leave a comment.

Articles