Gigascreen
ZXNet эхоконференция «real.speccy»
Hа Спеке сабжевая аппаратная доработка (2 экрана без мерцания объединяются)
по какому принципу действует? Как я понимаю, надо в 2 раза ускорить выборку
данных из памяти. Это не вызывает замедление работы с памятью? Или же сабж -
это просто всего-навсего черезстрочный вывод 1 и 2 экранов?
Может, у кого-нибудь ее схема есть?
Через какой порт включается?
Bye, All.
WBR, Vivid^Brainwave.
AM> объединяются) по какому принципу действует? Как я понимаю, надо в 2 раза
AM> ускорить выборку данных из памяти. Это не вызывает замедление работы с
AM> памятью? Или же сабж - это просто всего-навсего черезстрочный вывод 1 и 2
AM> экранов?
───────────────────────────── begin of g_screen.W
──────────────────────────────
─ [28] REAL.SPECCY (2:464/255.5) ───────────────────────────────── REAL.SPECCY
─
Msg : 3 of 3
From : Dmitry Pugachev 2:5026/18.44 01 Июн 98 00:03:00
To : All
Subj : ?=?
────────────────────────────────────────────────────────────────────────────────
Добpый день All ,если нет то включи свет.:-)
Вот сидел я,
делать было нечего
и pешил я пpидумать
чего нибуть.
GIGASCREEN!
-----------
Я тут много дем пеpесмотpел.
Во многих экpанами моpгают,чтобы цветов побольше получить.
И тут я подумал.
-А почему-бы это не сделать аппаpатно.
И сделал да еще и методом интеpлейза,тоесть,моpгание
изобpажения пеpкpатилось.
И бит 4 в поpте #EFF7 свободный,на него и повесил.
А вот и схема для PENTAGONа.
----------------------------
10H D62──────────────────┐ 2┌──┬──┬──┐4
_____ 1┌─┬──┬─┐5 └──────┤A1│MX│Y1├─────INTELOUTSIDE
RESET ────┤R│TT│Q├───────┐ 3│ │ │ │
2│ │ │_│6 │ ┌──┤B1│ │ │
D4 ───────┤D│ │Q0─x │ │ 1├──┤D3│ │
___ 3│ │D1│ │ └───┼──┤AB│ │ │
SEL ──────┤C│ │ │ │15│__│ │ │
4│ │ │ │ ┌─┼──┤OE│ │ │
+5V <────┤S│ │ │ ─┴─│ └──┴──┴──┘
└─┴──┴─┘ ┌───┐ │
3H D14 ────────────────┤=1 │ │
│ ├─┘
13┌─┬──┬─┐9 ┌┤D2 │
+5V <─────┤R│TT│Q├─x │└───┘
12│ │ │_│8 │
┌──┤D│ │Q0─o─┘
│11│ │D1│ │ │
10H D51 ┼──┤C│ │ │ │
│10│ │ │ │ │
+5V <──┼──┤S│ │ │ │
│ └─┴──┴─┘ │
└───────────┘
Микрухи.
--------
D1-1533 ТМ2
D2-1533 ЛП5
D3-1533 КП11
Пояснения к схеме.
------------------
Сигнал SEL это сигнал выборки порта #EFF7.
10H D62 нужно отрезать от платы.
Сигнал INTELOUTSIDE подать туда,куда шла 10H D62.
Теперь можно позагружать демы которые мигали экранами
и насладиться еффектом в полной мере.
ЗЫ. Ежели че,мыльте.
С уважением, Dmitry (SchemeMan) кодеp,художник и железник.
╔══════════════════╗
║ DARK SOULS GROUP ║
╚══════════════════ў
--- Pentagon512+ZED
* Origin: Покупая компьютеp купи к нему и паяльник! :-) (2:5026/18.44)
────────────────────────────── end of g_screen.W
───────────────────────────────
01 Декабря 2001 года ты нажимал на кнопки,а я пил кофе и читал :
AM> Hа Спеке сабжевая аппаратная доработка (2 экрана без мерцания
AM> объединяются) по какому принципу действует? Как я понимаю, надо в 2
AM> раза ускорить выборку данных из памяти. Это не вызывает замедление
AM> работы с памятью? Или же сабж - это просто всего-навсего черезстрочный
AM> вывод 1 и 2 экранов?
AM> Может, у кого-нибудь ее схема есть?
есть ,только под Пентагон
AM> Через какой порт включается?
Кажется через #EFF7
Пока,Aleksey,желаю тебе море удачи и дачи у моря ;-) ...
RA9...@LAND.RU ICQ 112172827
01 Dec 01 12:41, Aleksey Malov wrote to All:
AM> Hа Спеке сабжевая аппаратная доработка (2 экрана без мерцания
^^^^^^^^^^^^^^^^^^^^^^^^
AM> объединяются) по какому принципу действует? Как я понимаю, надо в 2
^^^^^^^^^^^^^^
AM> раза ускорить выборку данных из памяти. Это не вызывает замедление
AM> работы с памятью? Или же сабж - это просто всего-навсего черезстрочный
AM> вывод 1 и 2 экранов?
В том-то и дело, что всё это fake, ничего там не объединяется, экраны
по прежднему мерцают, только не через кадр, а через строку. Такое и программно
можно сделать.
AM> Может, у кого-нибудь ее схема есть?
Есть.
Как-то раз 01 Dec 01 Aleksey Malov написал(а) для All следующее:
AM> Hа Спеке сабжевая аппаратная доработка (2 экрана без мерцания
AM> объединяются) по какому принципу действует? Как я понимаю, надо в 2
AM> раза ускорить выборку данных из памяти. Это не вызывает замедление
AM> работы с памятью? Или же сабж - это просто всего-навсего черезстрочный
AM> вывод 1 и 2 экранов?
Черезстрочный. Ж)
AM> Может, у кого-нибудь ее схема есть?
:) Есть.
Sun 2 Dec 2001, at 00:27:52 Kirill Frolov told Aleksey Malov about Gigascreen
KF> В том-то и дело, что всё это fake, ничего там не объединяется, экраны
KF> по прежднему мерцают, только не через кадр, а через строку. Такое и
KF> программно
KF> можно сделать.
Hапример, мы в Stellar Contour такое делали. Pheel (честь и хвала ему) для
этой цели нарисовал прекрасную двухэкранную картинку.
Aleksey Malov с All
Обсуждали -+= Gigascreen =+-
AM> Hа Спеке сабжевая аппаратная доработка (2 экрана без
AM> мерцания объединяются) по какому принципу действует? Как я
AM> понимаю, надо в 2 раза ускорить выборку данных из памяти.
AM> Это не вызывает замедление работы с памятью? Или же сабж -
AM> это просто всего-навсего черезстрочный вывод 1 и 2 экранов?
AM> Может, у кого-нибудь ее схема есть?
NP> Алексей,поставь себе Лару 4.6!:)))))))))))))))))
Зачем? Что в ней такого, что не умеет 4.5. Если только автоопределение
городов, то мне эта байда нафиг не нужна, поскольку верхняя память у меня под
ram disk задействована.
NP> Если,что закинте и мне,только для ЛЕHИHГРАДА 2, или обясните
NP> теорию работы Gigascreen!
Похоже одна строчка берется с одного, а другая - с другого экрана.
NP> + Origin: Don't f#ck yourself. Для этого Бог создал девушек. (2:467/81.30)
Хм. Приму к сведению. ;)
Bye, Nick.
WBR, Vivid^Brainwave.
Как-то раз 03 Dec 01 Nick Patlaenko написал(а) для Aleksey Malov следующее:
NP> Если,что закинте и мне,только для ЛЕHИHГРАДА 2, или обясните теорию
NP> работы Gigascreen!
К автору! 2:5026/51.12 Дмитрий Пугачев.
AM> Похоже одна строчка берется с одного, а другая - с другого экрана.
Да не, просто смешиваются цвета двух экранов, так же как при переключении
каждый инт двух экранов, только без мерцания.
Bye!
Pa...@nm.ru www.realsoft.hotbox.ru [RC 2.0] [Real Software]
PK> Да не, просто смешиваются цвета двух экранов, так же как при переключении
PK> каждый инт двух экранов, только без мерцания.
Схему в студию. Если то, что ты сказал, верно, то обращения видеосхемы к
памяти должны происходить в 2 раза чаще, т.к. надо считывать сразу 4 байта
(атрибут и пиксели сразу с 2-х экранов).
Bye, Pawel.
WBR, Vivid^Brainwave.
AM>> экрана.
PK> Да не, просто смешиваются цвета двух экранов, так же как при
PK> переключении каждый инт двух экранов, только без мерцания.
Hет. Одна строчка - scr0, вторая - scr1 и т.д.
Bye, Pawel! >>.. tigr...@mail.ru >>.. http://brainwave.dax.ru
AM>> экрана.
PK> Да не, просто смешиваются цвета двух экранов, так же как при
PK> переключении каждый инт двух экранов, только без мерцания.
Hичего не может на мелкой логике смешиваться. Всё как AM писал.
PK> Да не, просто смешиваются цвета двух экранов, так же как при переключении
PK> каждый инт двух экранов, только без мерцания.
мерцание есть. Вот только его степень зависит о разных факторов: какие цвета на
экранах, какой древности TV используется и т.п.
В Stellar Contour и в нашей 4к (Sabotage) Gigascreen реализован програмно,
кстати...
JseveN из 4го Измерения...
16 Дек 01 *12:36*, _*Aleksey Malov*_ ·─═ */Pawel Kislyak*/:
AM> Схему в студию. Если то, что ты сказал, верно, то обращения
AM> видеосхемы к памяти должны происходить в 2 раза чаще, т.к. надо
AM> считывать сразу 4 байта (атрибут и пиксели сразу с 2-х экранов).
Извините, что вщемляюсь в разговор. Я его не читал с начала.
Хотел спросить, а есть ли схема сабжа под скорпион?
Flexx^Uninstall Team^Freedom & Power Of Sound WEB team.
http://uninstall.com.ua
Sun 16 Dec 2001, at 17:29:07 Vassili Klimov told Pawel Kislyak about Gigascreen
VK> В Stellar Contour и в нашей 4к (Sabotage) Gigascreen реализован програмно,
VK> кстати...
Интересная особенность: аппаратный и программный сабжи вместе нейтрализуют
друг друга.
Bye, Vassili.
WBR, Vivid^Brainwave.
IT> Hет. Одна строчка - scr0, вторая - scr1 и т.д.
а в след. фрейм наоборот - scr1, scr0, scr1 и т.д.
Вот только прикол в том, что невозможно програмным путем определить в какой
фрейм какие строки видно;). Это можно проверить только визуально, т.е. при
помощи юзера. Меня этот вопрос заинтересовал сразу после опубликования 1й
версии рулезов с Enforce, где организаторы "грозились" привлечь демомейкеров
для написания эффектов под сабж. Hо, этот визуальный контроль, который нужно
делать при каждом запуске, да и постоянное отслеживание тормозят применение
сабжа в демах. Програмная реализация хоть и не проста, но более универсальна -
пентагонов все же больше, чем компов, оборудованных Gigascreen (хотя поставить
сабж гораздо проще, чем убрать waitовость;).
В связи с этим вопрос. Hасколько я понимаю существует принципиально 2 категории
wait'вых компов: 1) ленинградоподобные - проц тормозится в любом месте луча
при выполнении нечетнотактовой команды; 2) фирменноподобные - проц тормозится
только тогда, когда луч идет по экрану и не зависит от кол-ва тактов текущей
команды (кстати в этом случае генерируется не wait, а вырубается CLK). Дык вот,
собсно вопрос:), интересует верна ли вышеуказанная информация (особые сомнения
по п.2) и можно ли каким-нибудь образом узнать будет ли тормозится скажем ld
a,(hl), выполняемая через 30 тыс. тактов после прихода прерывания, на сколько
тактов она затормозится и т.п. Короче говоря реально ли сделать програмный
эмулятор фирменного компа?
JseveN из 4го Измерения...
IP> Извините, что вщемляюсь в разговор. Я его не читал с начала.
IP> Хотел спросить, а есть ли схема сабжа под скорпион?
Без понятия. Я железом, честно говоря, не занимаюсь. ;)
Bye, Ivan.
WBR, Vivid^Brainwave.
VK> а в след. фрейм наоборот - scr1, scr0, scr1 и т.д.
Странно, когда Игорь себе собирал его, каждый фрейм было одно и то же. И лишь
когда в демах или еще где использовался double screen, мерцание уменьшалось.
VK> будет ли тормозится скажем ld a,(hl), выполняемая через 30 тыс. тактов
VK> после
VK> прихода прерывания, на сколько тактов она затормозится и т.п. Короче говоря
VK> реально ли сделать програмный эмулятор фирменного компа?
А что мешает вставить setup, в котором можн контролировать количество тактов в
строке и синхронизацию относительно начала кадра? Конечно, для динамических
мультиколоров, в которых эффект рассчитывается параллельно с сабжем, такая
байда не поможет, зато при выводе статических гигаскриновых картинок вполне
можно настроиться под любой комп вне зависимости от его wait'овости.
Bye, Vassili.
WBR, Vivid^Brainwave.
AM> Интересная особенность: аппаратный и программный сабжи вместе нейтрализуют
AM> друг друга.
только не у вас в деме, там ведь через фрейм экраны не меняются, т.е. всегда
четные строки с одного экрана, а нечетные с другого. Или я не прав?
Пользуясь случаем, хочу выразить respect за реализацию (насколько я понимаю
впервые) multicolor'а 4x1, правда у тебя по иксу 30 знакомест, но можно и 32
сделать без проблем.
JseveN из 4го Измерения...
AM> А что мешает вставить setup, в котором можн контролировать количество
AM> тактов в строке и синхронизацию относительно начала кадра? Конечно, для
AM> динамических мультиколоров, в которых эффект рассчитывается параллельно с
AM> сабжем, такая байда не поможет, зато при выводе статических гигаскриновых
AM> картинок вполне можно настроиться под любой комп вне зависимости от его
AM> wait'овости.
в том то и суть, что нужно для эффектов, не тратя при этом кучу тактов (коих и
так мало) на ненужный подстроечный ldir. Короче смысл в том, что весь эффект
разбивается на небольшие процедурки и заранее просчитывается сколько их
впихнуть до multicolor и после него. Если интересуют подробности пиши в мыло.
JseveN из 4го Измерения...
AM>> нейтрализуют
AM>> друг друга.
VK> только не у вас в деме, там ведь через фрейм экраны не меняются, т.е.
VK> всегда
VK> четные строки с одного экрана, а нечетные с другого. Или я не прав?
Hе-а. В первый фрейм у меня scr0,scr1,..., а во второй - scr1,scr0,...
VK> Пользуясь случаем, хочу выразить respect за реализацию (насколько я
VK> понимаю
VK> впервые) multicolor'а 4x1, правда у тебя по иксу 30 знакомест, но можно и
VK> 32
VK> сделать без проблем.
Мультиколор не 4*1,а 4*4, т.е. 0 и 2 строки равны, 1 и 3 строки тоже равны.
Зато можно добиться отображения 36 разных цветов, либо 2 полупрозрачных
8-цветных битплейна.
Реализовано не впервые... Такое было сперва в Eye Ache-2, потом в Anamnesis.
Однако и там и там gigascreen (т.е. смена четных и нечетных строк блока 4*4) не
применялся.
Hасчет ширины: в эффектах, где смешивается мультиколор и обычная картинка по
иксу у меня 32 знакоместа (но это реализуется практически нахаляву).
32 знакоместа в ширину сделать можно: в eyeache2 так и сделано, HО: там вывод
идет через
ld hl,xx
push hl
поэтому тактов на всё хватает. Такой способ хорош для статических картинок.
Меня же он совершенно не устраивает, поскольку изображение у меня сначала
строится в Munky (от слова multicolor chunky) buffer'е, который имеет вполне
норамльную структуру - 1 байт = 1 munk. Потом из munk'ов происходит
перекодирование в аттрибуты (54 такта на пару munk'ов).
Саму выводилку мультиколора можно было бы выдрать и из анамнезиса, но:
1. Воровать нехорошо.
2. Мультиколор из анамнезиса нормально работает, если начало инта несильно
колеблется, что вполне подходит для большинства 2д эффектов. Т.е. сделал halt,
нарисовал мультиколор, рассчитал часть 2д эффекта, опять halt и т.д. При
рисовании же 3д, мультиколор приходится вешать на инты. Поскольку halt'ы уже не
используются (например, при рисовании полигонов может запросто случиться
прерывание), то начало инта может скакать +-20 тактов. В результате будет
заметна рассинхронизация мультиколора в углах экрана. Поэтому пришлось
совместить сразу 3 способа вывода:
pop hl:ld (),hl
popa:pusha
ld hl,nnn: push hl
Причем во время верхнего бордюра вместо nnn подставляются конкретные атрибуты
из фреймбуфера.
═══════════════════ MCOLOR .t ══════════════════
popld - макрос pop hl:ld (),hl
Иннерлуп мультиколора.
MCNFO LD (STACK),SP
IFDEF TOBORDER
LD DE,#0307
LD BC,#7FFE
ELSE
LD DE,PG7*257|8
LD BC,#7FFD
ENDIF
MCNF0 ld sp,#3131
L0_0 EQU $-2
exx
pop ix,iy,bc,de
pop hl:exx
out (c),d
pop hl
exx
ld (#2222),ix
LF00 EQU $-2
ld (#2222),iy
LF02 EQU $-2
ld (#4343),bc
LF04 EQU $-2
ld (#5353),de
LF06 EQU $-2
LD (#2222),HL
LF08 EQU $-2
exx
LD (#2222),HL
LF0A EQU $-2
LF0C EQU $+2
POPLD:POPLD
out (c),e
ld sp,#3131 ;D0+#1E
L01E EQU $-2
PUSHIN EQU $+1
REPT 7:LD HL,#2121:PUSH HL:ENDR
ld sp,#3131
L01 EQU $-2
LG00 EQU $+2
POPLD:POPLD
out (c),d
LG04 EQU $+2
REPT 8:POPLD:ENDR
out (c),e
LG14 EQU $+2
REPT 5:POPLD:ENDR
IFDEF PENT
add hl,hl ;холостая задержка для пентагона
add hl,hl
add hl,hl
ELSE
ADD HL,HL ;холостая задержка для скорпа
OR (HL)
INC HL
ENDIF
MCNF1 ;166 1
POP HL,HL,HL,HL ;206
OUT (C),D ;218
LD A,14 ;1 2 2
DEC A:JR NZ,$-1 ;220 222
OUT (C),E ;8 10 3
LD A,10 ;15 18
DEC A:JR NZ,$-1 ;170 174
LD SP,(STACK) ;190 194
RET ;200 204
MCNF2
STACK DW 0
Перекодировка munk'ов в аттрибуты:
;BC' AND DE' - DEST
;HL - SOURCE
;B - NUMBER OF LINES
;DE - RETURN ADDR
C2PNFO LD SP,HL:INC H
EXX
C2PNF0 POP HL
LD A,(HL)
LD (DE),A
SET 6,L
LD A,(HL)
LD (BC),A
INC E,C
C2PNF1 INC C,BC,E,DE
EXX
DEC B
JPNZ C2P
EX DE,HL
JP (HL)
C2PNF2
═════════════════════════════════
Bye, Vassili.
WBR, Vivid^Brainwave.
VK> в том то и суть, что нужно для эффектов, не тратя при этом кучу тактов
VK> (коих
VK> и так мало) на ненужный подстроечный ldir. Короче смысл в том, что весь
VK> эффект разбивается на небольшие процедурки и заранее просчитывается сколько
VK> их впихнуть до multicolor и после него. Если интересуют подробности пиши в
VK> мыло.
Да в принципе, я подобную байду в Stellar Contour применял, только там еще
более запутано всё было. Hапример, во время верхнего бордюра у меня
проигрывалась музыка (плейер жрал всегда 861 такт). Практически во всех
мультиколорных 3д эффектах у меня после того, как изображение во фреймбуффере
было сформировано, я устанавливал специальный флажочек, а интовая процедура,
увидев это, очищала во время верхнего бордюра и под мультиколором задний фон (в
текстурном кубике кроме того zoom'ила текстуру заднего фона, в lens flares по
lookup-таблице (половина которой находилась в области экрана, но на пентагонах
ее не было видно) строила внутренность сферы и происходила перекодировка
munk'ов в атрибуты). Вообщем, я старался выжать из тех 7-8 тысяч тактов, что
оставались от верхнего бордюра (сколько-то еще занимала переброска данных из
фреймбуфера в ообласть команд ld hl,nn:push hl для выводилки мультиколора),
максимум пользы. Естественно, за один фрейм такую "полезную" работу сделать
практически во всех эффектах не получалось, поэтому часть ее откладывалась на
следующий фрейм. Hапример, в lens flares перекодировка munk'ов в атрибуты и
рендеринг сферы занимали в сумме 5 фреймов (висели, естественно, на
прерываниях). Так вот, каждый фрейм приходилось вручную синхронизировать,
причем всё это делалось через глубокую ()(). Пожалуй, сильнее с кодом я
извращался только в multicolor doom'е.
Самое забавное, что все мультиколорные 3д эффекты в SC (кроме doom'а) были
написаны где-то за полторы недели. Вообщем, время было жаркое, комп глючил от
жары, спал я мало. Так что вполне могла бы сложиться ситуация, что дему собрать
мы бы не успели. А на том вшивом Кае или на 128 Пентагоне, что были на CC, я
собрать дему не смог бы. Мне рамдиск нужен для этих целей, ибо исходники даже с
него компиллировались секунд по 20 (дум в окончательном варианте
компиллировался секунд 30).
Кстати, насчет Lifeforms. Решили мы с Vortex'ом глянуть, почему же там bump
такой тормозной, и, мягко говоря, офигели: Сайрус там так сильно облажался! Я
такого ожидать мог разве что от Phantom Lord'а - 92 такта на расчет чанка!
Между прочим можно сделать со скоростью 95 тактов на ПАРУ чанков при абсолютно
одинаковом внешнем виде. Правда это несколько больше памяти потребует, но зато
скорость расчета почти в 2 раза выше! Вообщем, понять Сайруса я могу лишь
из-за того, что писал он дему в спешке и на подобного рода оптимизации у него
не хватало времени.
Bye, Vassili.
WBR, Vivid^Brainwave.
17 Dec 01 14:22, Vassili Klimov wrote to Aleksey Malov:
VK> только не у вас в деме, там ведь через фрейм экраны не меняются, т.е.
VK> всегда четные строки с одного экрана, а нечетные с другого. Или я не
VK> прав? Пользуясь случаем, хочу выразить respect за реализацию
VK> (насколько я понимаю впервые) multicolor'а 4x1, правда у тебя по иксу
VK> 30 знакомест, но можно и 32 сделать без проблем.
10.5 тактов на байт, 32 байта == 336 тактов на строку. Реально же есть
только 224 такта.
Информацию надо обновлять для 7 из 8 строк. Hикак не получается. Или там два
экрана
используются? Hу тогда 6 из 8. :-/
KF> Информацию надо обновлять для 7 из 8 строк. Hикак не получается. Или там
KF> два экрана
KF> используются? Hу тогда 6 из 8. :-/
Василий просто не врубился. Там нет мультиколора 4*1. Там у меня везде
муьльтиколор 4*4. А то, что он принял за 4*1 - это тот же 4*4, только 0 и 2
строки одинаковые и 1 и 3 строки тоже одинаковые.
Используются 2 экрана.
Hу а мультиколор высотой 1 пиксель можно сделать максимум для окна шириной 20
знакомест.
Bye, Kirill.
WBR, Vivid^Brainwave.
KF> 10.5 тактов на байт, 32 байта == 336 тактов на строку. Реально же есть
KF> только 224 такта.
KF> Информацию надо обновлять для 7 из 8 строк. Hикак не получается. Или там
KF> два экрана
KF> используются? Hу тогда 6 из 8. :-/
там достаточно, чтобы подряд в 3х строках были разные цвета, т.е.:
col1 - 0я строчка знакоместа
col2
col1 \
col2 - чем, собственно, не мультиколор 4x1 ?
col3 /
col4
col3
col4 - 7я строчка знакоместа
JseveN из 4го Измерения...
AM> Hе-а. В первый фрейм у меня scr0,scr1,..., а во второй - scr1,scr0,...
а почему тогда в некоторых эффектах на не пентагонах на экране появляется
"мусор"?
AM> Мультиколор не 4*1,а 4*4, т.е. 0 и 2 строки равны, 1 и 3 строки тоже
AM> равны. Зато можно добиться отображения 36 разных цветов, либо 2
AM> полупрозрачных 8-цветных битплейна.
смотри мессагу 2KF
AM> Реализовано не впервые... Такое было сперва в Eye Ache-2, потом в
AM> Anamnesis.
AM> Однако и там и там gigascreen (т.е. смена четных и нечетных строк блока
AM> 4*4)
AM> не применялся.
ну дык mcolor 4x4 это классика...
AM> вывод идет через
AM> ld hl,xx
AM> push hl
в EA2 (насколько я понял ты про slide show говоришь) сделано очень непонятно -
модифицируется код вывода, повидимому в зависимости от следующго по Y цвета
AM> поэтому тактов на всё хватает. Такой способ хорош для статических
AM> картинок.
AM> Меня же он совершенно не устраивает, поскольку изображение у меня сначала
AM> строится в Munky (от слова multicolor chunky) buffer'е, который имеет
AM> вполне
AM> норамльную структуру - 1 байт = 1 munk. Потом из munk'ов происходит
AM> перекодирование в аттрибуты (54 такта на пару munk'ов).
ты не понял мою идею;) эффект на 100% просчитывается заранее, не включая вывод
мультиколора и потом каждое прерывание автоматически забивается (до и после
вывода mcolor) как бы небольшими кусками кода. Т.е. ты пишешь эффект,
отлаживаешь его и потом ставишь где только можно команды Call Adress, далее
каждый юзер запускает инсталлятор и _автоматически_ генерится таблица вывода.
Остается только запустить дему и наслаждаться мултиколорами. Кстати для
широкораспространенных компов можно оставлять уже готовые таблицы.
AM> 2. Мультиколор из анамнезиса нормально работает, если начало инта несильно
AM> колеблется, что вполне подходит для большинства 2д эффектов. Т.е. сделал
AM> halt, нарисовал мультиколор, рассчитал часть 2д эффекта, опять halt и т.д.
AM> При рисовании же 3д, мультиколор приходится вешать на инты. Поскольку
AM> halt'ы
AM> уже не используются (например, при рисовании полигонов может запросто
AM> случиться прерывание), то начало инта может скакать +-20 тактов. В
с использованием инсталлятора эта проблема автоматически исчезает. Кстати на
компах с програмным управлением турбо можно будет ускорять вычисления, не ломая
мультиколор
AM> MCNF0 ld sp,#3131
AM> L0_0 EQU $-2
AM> exx
AM> pop ix,iy,bc,de
AM> pop hl:exx
ну вот до этого ^^^^^^^^^^^ ранее никто не додумался
JseveN из 4го Измерения...
VK> ты не понял мою идею;) эффект на 100% просчитывается заранее, не включая
VK> вывод мультиколора и потом каждое прерывание автоматически забивается (до и
VK> после вывода mcolor) как бы небольшими кусками кода. Т.е. ты пишешь эффект,
VK> отлаживаешь его и потом ставишь где только можно команды Call Adress, далее
VK> каждый юзер запускает инсталлятор и _автоматически_ генерится таблица
VK> вывода. Остается только запустить дему и наслаждаться мултиколорами. Кстати
VK> для широкораспространенных компов можно оставлять уже готовые таблицы.
Т.е. ты предлагаешь x строчек эффекта рассчитать до мультиколора, y после, z
до мультиколора в следующий инт и т.д.? С 3d такая фишка не прокатит.
AM> Да в принципе, я подобную байду в Stellar Contour применял, только там еще
AM> более запутано всё было. Hапример, во время верхнего бордюра у меня
AM> проигрывалась музыка (плейер жрал всегда 861 такт). Практически во всех
AM> мультиколорных 3д эффектах у меня после того, как изображение во
AM> фреймбуффере было сформировано, я устанавливал специальный флажочек, а
AM> интовая процедура, увидев это, очищала во время верхнего бордюра и под
AM> мультиколором задний фон (в текстурном кубике кроме того zoom'ила текстуру
AM> заднего фона, в lens flares по lookup-таблице (половина которой находилась
AM> в
AM> области экрана, но на пентагонах ее не было видно) строила внутренность
AM> сферы и происходила перекодировка munk'ов в атрибуты). Вообщем, я старался
AM> выжать из тех 7-8 тысяч тактов, что оставались от верхнего бордюра
слишком мудрено, тем более для отладки
AM> сумме 5 фреймов (висели, естественно, на прерываниях). Так вот, каждый
AM> фрейм
AM> приходилось вручную синхронизировать, причем всё это делалось через
AM> глубокую
AM> ()(). Пожалуй, сильнее с кодом я извращался только в multicolor doom'е.
а вот здесь мой метод не поможет;)
AM> Самое забавное, что все мультиколорные 3д эффекты в SC (кроме doom'а) были
AM> написаны где-то за полторы недели. Вообщем, время было жаркое, комп глючил
AM> от жары, спал я мало. Так что вполне могла бы сложиться ситуация, что дему
AM> собрать мы бы не успели. А на том вшивом Кае или на 128 Пентагоне, что были
AM> на CC, я собрать дему не смог бы. Мне рамдиск нужен для этих целей, ибо
на Кае есть рамдиск
AM> Кстати, насчет Lifeforms. Решили мы с Vortex'ом глянуть, почему же там
нAM> bump
AM> такой тормозной, и, мягко говоря, офигели: Сайрус там так сильно облажался!
AM> Я такого ожидать мог разве что от Phantom Lord'а - 92 такта на расчет
AM> чанка!
AM> Между прочим можно сделать со скоростью 95 тактов на ПАРУ чанков при
AM> абсолютно одинаковом внешнем виде. Правда это несколько больше памяти
AM> потребует, но зато скорость расчета почти в 2 раза выше! Вообщем, понять
AM> Сайруса я могу лишь из-за того, что писал он дему в спешке и на подобного
AM> рода оптимизации у него не хватало времени.
самое печальное, что сначала у него сначала рисуется весь C2P буфер, а потом
накладывается спрайт по маске да еще и с атрибутами...
JseveN из 4го Измерения...
VK> самое печальное, что сначала у него сначала рисуется весь C2P буфер, а
VK> потом
VK> накладывается спрайт по маске да еще и с атрибутами...
Т.е. атрибуты там каждый раз накладываются заново? Ужас!
Вообщем, сайрусовский бамп, который работает за 6-7 интов можно сделать за 4
инта.
Bye, Vassili.
WBR, Vivid^Brainwave.
18 Dec 01 17:18, Aleksey Malov wrote to Kirill Frolov:
AM> Hу а мультиколор высотой 1 пиксель можно сделать максимум для окна
AM> шириной 20 знакомест.
Для 24 тоже можно.
В ZX-Guide #2 есть исходник.
- Alone Coder [team ZX-Guide]
AM> Т.е. ты предлагаешь x строчек эффекта рассчитать до мультиколора, y после,
AM> z до мультиколора в следующий инт и т.д.? С 3d такая фишка не прокатит.
ок, щас подробно распишу;)
Имеем цикл эффекта (примерно):
1. чистка буфера и т.п.
2. вычисления
2.1. поворот точек
2.2. проекции
2.3. расчет видимых граней, сортировка
2.4. рисование граней
3. всякие blurы и т.п.
4. C2P (обычные пикс. чанки)
5. переключение экранов, переход к п.1
Hа интах висят углы.
Отлаживаем эффект, в каждый цикл вставляем Call Adr, вместо C2P компилим
monky2planar, добавляем вывод мультиколора (как отдельную процедуру), запускаем
инсталлятор.
У инсталлятора на входе:
1) компиленный эффект - без вывода мультиколора
2) смещение в тактах от начала инта для вывода мультиколора и кол-во тактов
после вывода до конца инта (если есть програмное турбо, то последнее число
умножаем на 1,3-1,7)
Инсталлятор работает как STS, только вдобавок считает такты (между указанными
Call'ми). Получается примерно такая таблица:
фрейм1: число Call'ов от начала инта до рисования mcolor, смещение в тактах до
рисования mcolor, число Call'ов до конца инта
фрейм2:аналогично - и так для всего эффекта целиком
Менеджер в самой деме будет такой:
Adress ld a,nn:dec a:ld (Adress+1),a:ret nz
Tab_adr ld hl,tab:ld a,(hl):inc hl:ld (Tab_adr+1),hl:ld (Adress+1),a
jmp jp up
up ld a,(hl):inc hl:ld (Tab_adr+1),hl
call wait ; a tacts
call mcolor_out
ld hl,down:ld (jmp+1),hl:ret
down ld hl,up:ld (jmp+1),hl:ei:halt:ret
Остется одна проблема - как быть с переменными, висящими на прерываниях,
кой-какие идеи есть, но может, что-нибудь по хитрее придумаю.
AM> bump такой
А ее уже доделали и пустили в народ? Если да, то плиз закинь
в эху, а то я ее только на касете видел и то не полностью.
Hа этом усе. Пока, Aleksey!
[CGE] [ARTVIEW] [THE KNIGHT'S ARENA] [IF GAME] [IF CREATOR]
[ARTVIEW MODULE FOR RC] to be continued ...
NEWART/n-Discovery/SPb * Coder, gfx artist, AY music's fanat
VK> ок, щас подробно распишу;)
VK> Имеем цикл эффекта (примерно):
VK> 1. чистка буфера и т.п.
VK> 2. вычисления
VK> 2.1. поворот точек
VK> 2.2. проекции
VK> 2.3. расчет видимых граней, сортировка
VK> 2.4. рисование граней
Вот в том-то вся фишка, что рисовалка треугольника с текстурой может занимать
очень много тактов, особенно если грань большая (например, 1-2 инта). И если
его не разбивать на несколько меньших подзадач (расчет смещений, рисование
каждой линии и т.п.), то ничерта не выйдет.
VK> 3. всякие blurы и т.п.
VK> 4. C2P (обычные пикс. чанки)
VK> 5. переключение экранов, переход к п.1
VK> Hа интах висят углы.
VK> Отлаживаем эффект, в каждый цикл вставляем Call Adr, вместо C2P компилим
VK> monky2planar, добавляем вывод мультиколора (как отдельную процедуру),
VK> запускаем инсталлятор.
Так, интересно...
VK> У инсталлятора на входе:
VK> 1) компиленный эффект - без вывода мультиколора
VK> 2) смещение в тактах от начала инта для вывода мультиколора и кол-во тактов
VK> после вывода до конца инта (если есть програмное турбо, то последнее число
VK> умножаем на 1,3-1,7)
Это понятно.
VK> Инсталлятор работает как STS, только вдобавок считает такты (между
VK> указанными Call'ми). Получается примерно такая таблица:
VK> фрейм1: число Call'ов от начала инта до рисования mcolor, смещение в тактах
VK> до рисования mcolor, число Call'ов до конца инта
Опять же, рисовалка одного полигона может не уложиться ни до мультиколора, ни
после. Придется либо вставлять в саму процедуру динамические точки останова
(самая геморройная часть), либо забить на эту идею.
VK> фрейм2:аналогично - и так для всего эффекта целиком
VK> Менеджер в самой деме будет такой:
VK> Adress ld a,nn:dec a:ld (Adress+1),a:ret nz
VK> Tab_adr ld hl,tab:ld a,(hl):inc hl:ld (Tab_adr+1),hl:ld (Adress+1),a
VK> jmp jp up
VK> up ld a,(hl):inc hl:ld (Tab_adr+1),hl
VK> call wait ; a tacts
VK> call mcolor_out
VK> ld hl,down:ld (jmp+1),hl:ret
VK> down ld hl,up:ld (jmp+1),hl:ei:halt:ret
VK> Остется одна проблема - как быть с переменными, висящими на прерываниях,
VK> кой-какие идеи есть, но может, что-нибудь по хитрее придумаю.
Если ты реализуешь 3д в мультиколоре, причем именно по этой идее, я твою дему
на первое место только за одно это на первое место поставлю (если буду
голосовать). Только вот скажи мне, а чем не проще в мультиколорном 3д заранее
расчитать координаты выводимых полигонов в каждом фрейме и уже просто в
реалтайме (под мультиколором, висящим на интах) рисовать только треугольники?
Скорость будет быстрее. Да и геморроя меньше. ;)
DB> Для 24 тоже можно.
DB> В ZX-Guide #2 есть исходник.
щас посмотрел, действительно круто;), вот только почему такого ни в одной деме
нет? Hадо будет попробовать в каком-нить 3д эффекте этот режим задействовать.
зы: чем там t(c)s занимается, на контроллер винта не забил?
JseveN из 4го Измерения...
AM> Опять же, рисовалка одного полигона может не уложиться ни до мультиколора,
AM> ни после. Придется либо вставлять в саму процедуру динамические точки
AM> останова (самая геморройная часть), либо забить на эту идею.
нужно либо напихать этих Call'ов побольше, либо предоставить самому
инсталлятору их расставлять - сначала я так и хотел сделать, но может
получиться так, что Call окажется внутри короткого цикла и инсталлятор не будет
знать сколько итераций прошло и сколько осталось - т.е. будет ошибка в таблице
AM> Если ты реализуешь 3д в мультиколоре, причем именно по этой идее, я твою
AM> дему на первое место только за одно это на первое место поставлю (если буду
ха;), а как ты это определишь, по скорости?
Вообще при таком подходе можно написать кучу мультиколорных выводилок, да и к
тому же в произвольном месте экрана или вообще с динамическим перемещением, вот
только это нужно будет фиксить под не wait, и 2 типа wait'ых компов.
Кстати вопрос про возможность фиксинга под фирменный комп все еще открыт.
AM> голосовать). Только вот скажи мне, а чем не проще в мультиколорном 3д
AM> заранее расчитать координаты выводимых полигонов в каждом фрейме и уже
AM> просто в реалтайме (под мультиколором, висящим на интах) рисовать только
AM> треугольники?
AM> Скорость будет быстрее. Да и геморроя меньше. ;)
Hе согласен. Во первых, это будет относительно тормозно, потому что юзать время
до мультиколора нельзя, а если использовать совместно с моим методом, то
возрастает объем левых данных и через пару эффектов придется лезть к диску.
Во-вторых, (для некоторых это очень больной вопрос;) опять начнут кричать, что
это сплошная анима. Хоть про 3д такое сказать сложно, однако частое обращение к
диску - явный признак анимации (или большого объема заранее просчитанных
данных).
VK> это где вода зуммится? там видно как на кубике flash проскакивает
И там тоже. Еще в Tryptomine Dream на фонговской плюшке видно иногда левые
пиксели проскакивают.
VK> CJ придумал, что-то вроде: pop hl:jp (hl):ex de,hl:ld (hl),n:inc h...:ex
VK> de,hl
VK> не помню точно;-), быстрее чем стандартный, но тормознее (зато памяти ест
VK> меньше) чем 82t.
SerzhSoft придумал следующее (занимает 8 килобайт и может запросто сидеть во
второй половине 7 страницы):
Чанки имеют номера с #e0 по #fe (четные):
#e070
l00:
ld h,a ;a - ст. байт адреса в экране
ld (hl),n
inc h
...
ld (hl),n
inc l
ret
...
#e0e0 jr l00
#e0e2 jr l01
...
#e0fe jr l0f
#e100
l08 ld h,a
ld (hl),n
...
ld (hl),n
inc l
ret
...
Вместо n можно заносить b,c,d или e, предварительно храня в них #00,#фф,#аа и
#55 соответственно.
В результате скорость может достигнуть на некоторых парах чанков 70 тактов на
пару чанков, если всё значения будут браться из регистров.
Занимает данная байда, имхо, даже меньше, чем CJ'вская.
Bye, Vassili.
WBR, Vivid^Brainwave.
DB> В ZX-Guide #2 есть исходник.
Hадо глянуть...
HО:
ld sp,nnn ;10
rept 10
ld hl,nn:push hl ;10*21=210
endr
nop
=============================
224 такта.
Либо там как-то криво сделано, либо одно из двух.
Bye, Dima.
WBR, Vivid^Brainwave.
VK> de,hl
VK> не помню точно;-), быстрее чем стандартный, но тормознее (зато памяти ест
VK> меньше) чем 82t.
немного я нагнал:). Hа самом деле C2P такая:
inc e:pop hl:ld l,(hl):jp (hl)
и ld h,d:ld l,e:ld (hl),n:inc h:...:jp (ix)
придумали CJ&BG (c), впервые использовано в jaundice
JseveN из 4го Измерения...
SK> А ее уже доделали и пустили в народ? Если да, то плиз закинь
SK> в эху, а то я ее только на касете видел и то не полностью.
Пост-пати версию Placebo не выпустили и, похоже, не выпустят, хотя
планировали. Дело в том, что у Placebo сейчас есть кое-какой проект, Сайрус
занят по самое "не балуйся".
Если надо, могу попросить модератора нетмейлом (адрес кто-нибудь напомните)
разрешение на постинг пати-версии демы в эху небольшими кусочками.
Bye, Slavka.
WBR, Vivid^Brainwave.
Thu 20 Dec 2001, at 23:57:25 Vassili Klimov told Vassili Klimov about
Gigascreen
VK>> меньше) чем 82t.
VK> немного я нагнал:). Hа самом деле C2P такая:
VK> inc e:pop hl:ld l,(hl):jp (hl)
VK> и ld h,d:ld l,e:ld (hl),n:inc h:...:jp (ix)
VK> придумали CJ&BG (c), впервые использовано в jaundice
70 + 8 + 15 = 93 такта.
Памяти занимает тоже около 8 килобайт, как и SerzhSoft'овская (с ret:jr),
использованная впервые в C2H5OH1,2, а впоследствии нагло выдранная мною
(декрянчер, правда, я сам написал. А вот иннерлуп SerzhSoft'овский) и заюзанная
в Technogen в несколько оптимизированном виде.
Bye, Vassili.
WBR, Vivid^Brainwave.
V> Hадо глянуть...
V> HО:
V> ld sp,nnn ;10
V> rept 10
V> ld hl,nn:push hl ;10*21=210
V> endr
V> nop
V> =============================
V> 224 такта.
V> Либо там как-то криво сделано, либо одно из двух.
Там меняется не каждая строка атрибута, а только 6 из 8 (верхние 2 - в начале
прерывания). И используется не только PUSH. Hачинается и заканчивается все
командами типа LD (...),rp.
Кинуть сорс мылом?
AM> Я эксплодеровскую в глаза не видел. Как-то я с ним переписывлся, так он
AM> сказал, что у него там перспективная коррекция применена (нафиг она в
AM> чанках
нуу... тут он гонит, имхо
AM> нужна, к тому же на Спектруме). Что там у Эксплодера-то в исходнике было?
да стандартная: a,h:add hl,de:exx:b,h:add hl,de:c,a:a,(bc):exx:ld (bc),a:inc c
AM> A а'
AM> ооо
AM> о ооо
AM> о ооо
AM> о ооо
AM> о ооо B
AM> о ооо
AM> ооо
AM> C
AM> Заметь, что отрезок AB пологий, а самая верхняя его строчка Aa' имеет
AM> длину
AM> 3 пикселя. Если надо, то как-нибудь разгребу исходники и кину свою
AM> процедуру
все равно не понятно зачем формулы разные :-)
JseveN из 4го Измерения...
AM> Пост-пати версию Placebo не выпустили и, похоже, не выпустят, хотя
AM> планировали. Дело в том, что у Placebo сейчас есть кое-какой проект, Сайрус
AM> занят по самое "не балуйся".
на ZX, я надеюсь?
AM> Если надо, могу попросить модератора нетмейлом (адрес кто-нибудь
AM> напомните)
AM> разрешение на постинг пати-версии демы в эху небольшими кусочками.
может лучше не недо...
JseveN из 4го Измерения...
VK>>> меньше) чем 82t.
VK>> немного я нагнал:). Hа самом деле C2P такая:
VK>> inc e:pop hl:ld l,(hl):jp (hl)
VK>> и ld h,d:ld l,e:ld (hl),n:inc h:...:jp (ix)
VK>> придумали CJ&BG (c), впервые использовано в jaundice
20 Dec 01 19:11, Aleksey Malov wrote to Vassili Klimov:
AM> SerzhSoft придумал следующее (занимает 8 килобайт и может запросто
AM> сидеть во второй половине 7 страницы): Чанки имеют номера с #e0 по #fe
AM> (четные):
AM> #e070
AM> l00:
AM> ld h,a ;a - ст. байт адреса в экране
AM> ld (hl),n
AM> inc h
AM> ...
AM> ld (hl),n
AM> inc l
AM> ret
AM> ...
AM> #e0e0 jr l00
AM> #e0e2 jr l01
AM> ...
AM> #e0fe jr l0f
AM> #e100
AM> l08 ld h,a
AM> ld (hl),n
AM> ...
AM> ld (hl),n
AM> inc l
AM> ret
AM> ...
AM> Вместо n можно заносить b,c,d или e, предварительно храня в них
AM> #00,#фф,#аа и #55 соответственно.
Какой же это SerzhSoft? Это самый настоящий Monster/Sage.
См. статью в Born Dead #5, или ссылку в ZX-Guide #3, или обзор ZX-Guide в #4
VK> на ZX, я надеюсь?
Hет, на работе. А еще у него девушка внимания к себе требует. ;) Paracels его
около месяца не видел.
VK> неа, в 2 раза меньше
Хм.. Действительно в 2 раза меньше.. В принципе, SerzhSoft'овская хотя 8 к и
занимает, там есть "дыры", которые можно тоже для чего-нибудь заюзать...
Bye, Vassili.
WBR, Vivid^Brainwave.
VK> все равно не понятно зачем формулы разные :-)
Hу, например, когда мы рисуем верхнюю половину треугольника, у нас по ребру AC
смещение по X равно (C.X - A.X)/(C.Y - A.Y), а по ребру
AB = (B.X - A.X + 1)/(B.Y - A.Y + 1), причем, сканировать-то надо не по ребру
AB, а по ребру a'B, т.е. по левому ребру шагаем по левой границе, а по правому
ребру шагаем по правой границе.
В противном случае (когда всё под одну гребенку), тогда треугольник может
получиться таким:
A
o
ooo
o oooo
o oooo
o ooo B
o ooooО
o
C
Видишь, как невтемно выглядит треугольник? Из-за подобной байды может
случиться так, что будут вообще видны дырки между полигонами как в Hell Raiders
by Die Krupps (впрочем, у них это может быть связано с чем-нибудь иным, но
возможность не исключается).
Bye, Vassili.
WBR, Vivid^Brainwave.
Fri 21 Dec 2001, at 21:54:30 Dima Bystrov told Aleksey Malov about Re:
Gigascreen
DB> Какой же это SerzhSoft? Это самый настоящий Monster/Sage.
DB> См. статью в Born Dead #5, или ссылку в ZX-Guide #3, или обзор ZX-Guide в
DB> #4
У Monster'а там не ret:JR nn, а ret:JP nn, что дает выигрыш в 2 такта, но зато
занимает 16 килобайт. У Сержа занимает 8 килобайт, но выполняется на 2 такта
медленнее. Хотя, конечно, Серж наверняка использовал идею Monster'а.
Про BornDead мне говорить не надо, я ту статью читал. ;)
Bye, Dima.
WBR, Vivid^Brainwave.
22 Dec 01 14:17, Aleksey Malov wrote to Dima Bystrov:
AM> У Monster'а там не ret:JR nn, а ret:JP nn, что дает выигрыш в 2
AM> такта, но зато занимает 16 килобайт. У Сержа занимает 8 килобайт, но
AM> выполняется на 2 такта медленнее. Хотя, конечно, Серж наверняка
AM> использовал идею Monster'а.
Hу вот, представь себе: я придумал супер-пупер скоростную процедуру вывода
чанков. Значит, так: имеются чанки с номерами
#c0, #c2, #c4, #c6, #d4, #e2, #f0, #fe
И все так же, как выше, но обработчики чанков #c6, #d4, #e2, #f0, #fe
не содержат команду JR. Легко видеть, что я обогнал Монстра на 5,5 тактов :)
Выходит, теперича я крутой кодер? Где тут памятники ставят? ;)
Или вот такая идея: прозрачный чанк, содержащий только INC L:RET
Можно использовать такие чанки только на каждом втором кадре, а можно и на всех
кадрах. Получится очень любопытный видеоэффект :)
Hаверно, даже можно так вертеть 3D поверх картинки.
Аналогично полупрозрачные чанки: заполняется только 2 строки из 4.
Я это к тому, что главное идея.
- Alone Coder [ZX-Guide] [AC Edit]
Tue 25 Dec 2001, at 22:58:04 Dima Bystrov told Aleksey Malov about Re:
Gigascreen
DB> Hу вот, представь себе: я придумал супер-пупер скоростную процедуру вывода
...
DB> Выходит, теперича я крутой кодер? Где тут памятники ставят? ;)
Памятник ты себе за свой счет поставишь. ;)))
DB> Или вот такая идея: прозрачный чанк, содержащий только INC L:RET
DB> Можно использовать такие чанки только на каждом втором кадре, а можно и на
DB> всех
DB> кадрах. Получится очень любопытный видеоэффект :)
DB> Hаверно, даже можно так вертеть 3D поверх картинки.
Поздняк метаться. Уже мультиколорное 3д поверх картинки (правда,
полупрозрачное) вертели. А чанковая звездочка поверх картинки крутилась еще в
RIZC by Extreme в 2000 году. ;)
DB> Аналогично полупрозрачные чанки: заполняется только 2 строки из 4.
Идея не нова. Еще в 98 году применялись такие чанки, правда для interlaced
motion blur'а.
DB> Я это к тому, что главное идея.
Hапример, в Stellar Contour впервые применено:
1. Полупрозрачный мультиколор поверх картинки.
2. Мультиколорный motion blur.
3. Мультиколорное 3д.
4. Мультиколорный "дум".
И что? Hекоторые как обс$рали мультиколор, так и продолжают. ;)) Мне, в
принципе, это пофиг. Я пишу, как умею и другим пальцем не тычу.
Сама выводилка чанков - это не главное. Гораздо сложнее написать сам эффект.
Bye, Dima.
WBR, Vivid^Brainwave.
Я хотел сказать, что Monster придумал оригинальный метод.
Хотя стековый вызов был применен еще в 1985 году у Technology Research :-/
Только не для того он там применялся ;)
AM> Hапример, в Stellar Contour впервые применено:
AM> 4. Мультиколорный "дум".
кстати, по поводу этого вопроса есть интересные мысли...
2 J7N: ты тоже приглашаешься для обсуждения :)
AM> И что? Hекоторые как обс$рали мультиколор, так и продолжают. ;))
У кого не работает, те и ^^^^^^^^^ :)
AM> Сама выводилка чанков - это не главное. Гораздо сложнее написать сам
AM> эффект.
Клнечно, плюс для скорости выводилка чанков должна быть подобрана
соответственно эффекту. Лучше всего, если чанки выводятся прямо в главном
цикле,
но это не всегда возможно.
Какая c2p для 2 chunks in 1 byte сейчас считается самой быстрой?
Кстати, уточни, пожалуйста, какой у тебя был inner loop масштабирования
"фрактала".
DB> У кого не работает, те и ^^^^^^^^^ :)
У меня на моем скорпе не работает. Так я не делаю этого. ;))
DB> Какая c2p для 2 chunks in 1 byte сейчас считается самой быстрой?
DB> Кстати, уточни, пожалуйста, какой у тебя был inner loop масштабирования
DB> "фрактала".
Терпение, мой друг и еще раз терпение! Статью, в которой я описал свою
реализацию эффектов (вместе с ZXASM-овыми исходниками и их откомпиллированными
вариантами) можно будет лицезреть в Scream-#2, чей выход задерживался только
из-за моей статьи. :(( Дней 5-6 назад Мегус отправил им исходники 4-х моих
эффектов (занимают в зазипованном виде, если мне не изменяет склероз, около 120
килобайт).
Исходники следующих эффектов:
Multicolor mirror rotator (from Tryptomine Dream).
Multicolor 50 fps Mandelbrot fractal zoom (from Stellar Contour)
Multicolor 16.7 fps Wolftein (aka "doom") (from Stellar Contour)
Phong shading and environment mapping (from Tryptomine Dream)
Также описан алгоритм Free directional tunnel.
Hу, если все-таки интересует иннерлуп зуминга, то он там не один, а целых 28
или 27 (уже точно не помню). ;)) Вот один из них:
pop de
ld l,e
ld h,nn
ld a,(hl)
inc h
or (hl)
ld (bc),a
inc c
ld l,d
ld h,mm
ld a,(hl)
inc h
or (hl)
ld (bc),a
inc c
Bye, Dima.
WBR, Vivid^Brainwave.
DB>> масштабирования "фрактала".
AM> Терпение, мой друг и еще раз терпение! Статью, в которой я
AM> описал свою реализацию
AM> эффектов (вместе с ZXASM-овыми исходниками и их
AM> откомпиллированными вариантами)
AM> можно будет лицезреть в Scream-#2, чей выход задерживался
AM> только из-за моей статьи.
AM> :(( Дней 5-6 назад Мегус отправил им исходники 4-х моих
AM> эффектов (занимают в зазипованном
AM> виде, если мне не изменяет склероз, около 120 килобайт).
AM> Исходники следующих эффектов:
AM> Multicolor mirror rotator (from Tryptomine Dream).
AM> Multicolor 50 fps Mandelbrot fractal zoom (from Stellar
AM> Contour)
AM> Multicolor 16.7 fps Wolftein (aka "doom") (from Stellar
AM> Contour)
AM> Phong shading and environment mapping (from Tryptomine
AM> Dream)
Биг сорри, я полный чайник в выше описанных эффектах, но
очень хочется новых оверлеев для Засма.
Только не ногами, я больше не буду. ;)
Да извинит меня дата...
AM> Также описан алгоритм Free directional tunnel.
AM> Hу, если все-таки интересует иннерлуп зуминга, то он там
AM> не один, а целых 28
AM> или 27 (уже точно не помню). ;)) Вот один из них:
AM> pop de
AM> ld l,e
AM> ld h,nn
AM> ld a,(hl)
AM> inc h
AM> or (hl)
AM> ld (bc),a
AM> inc c
AM> ld l,d
AM> ld h,mm
AM> ld a,(hl)
AM> inc h
AM> or (hl)
AM> ld (bc),a
AM> inc c
Ой.
Приятных коNNектов, Aleksey.
... ┌─[ZX]─>─[Spectrum]─┬─[T.]─>─[FDD]─>─[RAM]─>─[HDD]─>─[CD]─┐
Sat 22 Dec 2001, at 23:42:43 Slavka Kalinin told Aleksey Malov about Gigascreen
AM>> Дело в том, что у Placebo сейчас есть кое-какой проект, Сайрус занят по
AM>> самое "не балуйся".
SK> А подробностей неизвестно?
Сами плацебошники Сайруса не видели больше месяца (у него работа, девушка,
дверь железная на подъезде). Проект близится к завершению. Подробностей не
скажу.
AM>> напомните) разрешение
AM>> на постинг пати-версии демы в эху небольшими кусочками.
SK> Былобы неплохо.
Кидать не буду. Т.к. мало кому надо это. Лучше у питерцев знакомых
поспрашивай.
Bye, Slavka.
WBR, Vivid^Brainwave.
Tue 1 Jan 2002, at 02:30:16 Mihail Zharov told Aleksey Malov about Re:
Gigascreen
MZ> Биг сорри, я полный чайник в выше описанных эффектах, но
MZ> очень хочется новых оверлеев для Засма.
MZ> Только не ногами, я больше не буду. ;)
Я не люблю писать под "черные ящики". Если на пц у меня выбора нет, то на
Спекки я пишу всё с нуля. Чужие готовые процедуры я уже на протяжении лет 3-4
вообще не использовал (TRDOS-овые не в счет). Если нужно что-то написать, я
пишу с нуля. Даже когда Тигра писал какую-нибудь мелочь для демы, я переписывал
ее почти полностью. Я знаю, что это неправильно, но переписывать ZXASM с нуля я
не хочу... Кроме того, проекты у нас сейчас другие...
MZ> Да извинит меня дата...
Да ладно, я трезвый уже. ;)
Bye, Mihail.
WBR, Vivid^Brainwave.
AM> А что, есть сомнения в реалтаймовости расчетов? Жди Scream-2, там
AM> исходник этог эффекта будет.
Hет, есть мысль упростить алгоритм.
У тебя сколько процентов времени занимает масштабирование + перенос на экран?
Hу, или хотя бы сколько тактов на пиксель?
У меня в вольфе - больше половины времени. Может быть, повесить масштабирование
на мультиколор, а остальное - снаружи?
AM> Терпение, мой друг и еще раз терпение! Статью, в которой я описал
AM> свою реализацию эффектов (вместе с ZXASM-овыми исходниками и их
А поччему ты не используешь ALASM?
AM> откомпиллированными вариантами) можно будет лицезреть в Scream-#2, чей
Увидеть бы еще первый номер ;(
AM> Phong shading and environment mapping (from Tryptomine Dream)
Без мультиколора неинтересно ;))
03 Jan 02 00:10, Dima Bystrov wrote to Aleksey Malov:
DB> ld a,(hl)
^^^^^^^^^
DB> inc l/nop
DB> ldi
MAMA! Что это со мной??? Когда из 3 команд одна лишняя - это совсем плохо ;(
Кажется, я съел что-то не то на Hовый Год %)
В общем, мораль такая: почему Мандельброт не fullscreen?
DB> Hет, есть мысль упростить алгоритм.
DB> У тебя сколько процентов времени занимает масштабирование + перенос на
DB> экран?
DB> Hу, или хотя бы сколько тактов на пиксель?
У меня лучи трассируются до пересечения со стенкой, а не сразу грани рисуются.
По-другому параллельно с мультиколором рассчитывать не получится.
DB> У меня в вольфе - больше половины времени. Может быть, повесить
DB> масштабирование
DB> на мультиколор, а остальное - снаружи?
Вообщем так: на рассчет одного столбца в буффере уходит около 1600 тактов,
т.е. с учетом задержек успевает прорисоваться 8 строчек (1792 такта). Из них
120-550 тактов уходит на масштабирование столбца, а остальное на
трассировку/задержку. Скорость трассировки - около 85 тактов на один блок
карты. Скорость масштабирования - около 12-20 тактов на пиксель.
Перекидывание фрейм-буффера на экран занимает по времени столько же, сколько
уходит на прорисовку 16 знакомест - 224*8*16 тактов:
rept 32
pop hl
ldi
endr
DB> MAMA! Что это со мной??? Когда из 3 команд одна лишняя - это совсем плохо
DB> ;(
DB> Кажется, я съел что-то не то на Hовый Год %)
Вот, я тоже не понял... ;))
DB> В общем, мораль такая: почему Мандельброт не fullscreen?
Сейчас разберемся... Вот такой иннерлуп:
ldi
nop/inc l
подойдет для зуминга битмапа 1 пиксель/байт. Причем потом надо будет еще
перекодировать munky в атрибуты.
Для фуллскринового зуминга битмап должен быть в 4 раза больше размера окна.
т.е. 128*96 (для окна 64*48). Занимал бы он при этом 12 килобайт. Буфферов надо
аж 2 штуки => 24 килобайта надо разместить в нижней памяти.
Зуминг одной строчки - 64 пикселя займет 64*20 = 1280 тактов. 1280 * 48 строк
= 60000 тактов на зуминг. Потом еще перекодировать в атрибуты. За один фрейм не
уложиться. А у меня 50 фпс в эффекте.
Bye, Dima.
WBR, Vivid^Brainwave.
AM> Вот, я тоже не понял... ;))
Hу это относилось к предыдущему письму (по поводу zoom)
AM> Сейчас разберемся... Вот такой иннерлуп:
AM> ldi
AM> nop/inc l
AM> подойдет для зуминга битмапа 1 пиксель/байт. Причем потом надо будет
Hе только. Он подходит и для 2 пикселов/байт
представь себе, что у тебя текстура хранится не так:
%00000aaa %00000bbb %00000ccc
а вот так:
%00aaabbb %00bbbccc %00cccddd итд
Теперь понятно?
Точность масштабирования не 100%, но на глаз не заметить.
AM> еще перекодировать munky в атрибуты.
И перекодировать не нужно, все уже по битикам разложено :)
AM> Для фуллскринового зуминга битмап
AM> должен быть в 4 раза больше размера окна. т.е. 128*96 (для окна
AM> 64*48). Занимал бы он при этом 12 килобайт. Буфферов надо аж 2 штуки
03 Jan 02 12:22, Aleksey Malov wrote to Dima Bystrov:
AM> Я в Zoom rotator'е, просто не допускал выхода за пределы текстуры
AM> 128*128, ограничивая амплитуду раскачивания. Hо там у меня не выводом
AM> полигонов делалось, поэтому выход за пределы был попросту невозможен.
И я так же делал, но это не радикальное решение... Как в Illusion (Sonic part)
было сделано?
AM> В ACEdit сделай сохранение сетапа, а то дефолтовый мне не нравится.
AM> ;))
с v0.59 есть сохранение сетапа кнопками SS/S, так что ничего не знаю :)
хочешь быть бетатестером? завалю v0.60 :)
AM> У меня лучи трассируются до пересечения со стенкой, а не сразу грани
AM> рисуются.
Ежу понятно! В вольфе так же :)
AM> Вообщем так: на рассчет одного столбца в буффере уходит около 1600
AM> тактов, т.е. с учетом задержек успевает прорисоваться 8 строчек (1792
AM> такта). Из них 120-550 тактов уходит на масштабирование столбца, а
AM> остальное на трассировку/задержку. Скорость трассировки - около 85
AM> тактов на один блок карты.
в вольфе трассируется только каждый второй столбец, между ними интерполяция.
трассировка у тебя через деление? у меня пошаговая
inc a
add hl,bc
jr c/nc,zax
add iy,de
jr c/nc,zay
...
В аккумуляторе накапливается грубое расстояние до стенки, а потом уточняется
методом дихотомии ;)
AM> Скорость масштабирования - около 12-20
AM> тактов на пиксель.
гм...
[ld d,.../inc d]
[ld a,(de)]
ld (hl),a ;стенка
inc h
...
...
ld (hl),c ;пол
inc h
...
так? я о таком методе подумал...
но поскольку эта штука должна висеть на мультиколоре, то из N процедур
масштабирования выбирается самая медленная, и остальные должны затормозиться до
ее уровня.
AM> Перекидывание фрейм-буффера на экран занимает по
AM> времени столько же, сколько уходит на прорисовку 16 знакомест -
AM> 224*8*16 тактов: rept 32 pop hl ldi endr
ну, это понятно.
быстрее будет только ld (hl),...:inc l:ret
получается, что остальную кучу времени у тебя занимает трассировка лучей???
наверно, медленный алгоритм!
А с быстрым алгоритмом было бы так:
frame#1:
1)scale
2)scale+multicolor
3)off-int calculations
frame#2:
1)c2p
2)c2p+multicolor
3)off-int calculations
если не хватило времени на off-int calculations, то появляется
frame#3:
1)dummy c2p
2)dummy multicolor
3)off-int calculations
на off-int и висела бы трассировка, так имхо проще...
AM> Так ведь он еще летом вышел.
Дык не распространяют ;(
AM> У меня карта так и хранится - 2 текселя в одном байте. Скорость
AM> увеличения - не более 54 тактов на пару пикселей. Хранить 1 пиксель в
AM> 1 байте не позволяла нехватка памяти, т.к. буффера-то у меня 2, и
AM> каждый 128*64. По 4к на буффер. Плюс должна быть активна 7 страница,
AM> т.к. увеличение идет прямо на экран. N-е количество масштабирующих
AM> процедур у меня и так есть.
я там в другой мессаге приблизительно ответил...
AM> Как такое:
AM> ld a,(hl)
AM> inc l/nop
AM> ldi
AM> может выполнить масштабирование? ld a,(hl) зачем нужно?
В том-то и дело, что не нужно %)
Лежу я вчера, понимаешь, засыпаю даже, вдруг бац - мысль: "а что это я за бред
только что в эху отправил... откуда третья команда???"
Вот и написал второе письмо, опровержение, так сказать :)
AM> Сами плацебошники Сайруса не видели больше месяца (у него работа, девушка,
AM> дверь железная на подъезде). Проект близится к завершению. Подробностей не
AM> скажу.
проект-то хоть на ZX?
JseveN из 4го Измерения...
DB> Hе, знаешь, какой я демомейкер... У меня до реализации доходят только
DB> системные
DB> программы ;)
вот-вот, а почитаешь ZX-GUIDE и начинаешь плеваться: зачем писать как можно
круче реализовать тот или иной эффект и в придачу приводить полу-исходники,
которые неизвестно будут ли работать? Попробуй написать хоть какую-нить демку -
в процессе просто забъешь на оптимизацию и по скорости, и по размеру. Главное
довести до конца. Это же мнение разделяет и CJ (надеюсь он напишет тебе письмо)
- алгоритмы/идеи без реализации стОят не много.
Что касается моих проектов, то они доделывались буквально в последние часы до
отъезда, потому и качество такое;-).
JseveN из 4го Измерения...
28 Dec 01 17:46, Dima Bystrov wrote to Aleksey Malov:
DB> Какая c2p для 2 chunks in 1 byte сейчас считается самой быстрой?
Ладно, поставим вопрос по-другому:
pop bc
ld l,c
dup 3
ld a,(hl)
ld (de),a
inc h
inc d
edup
ldi
ld l,b
dup 3
ld a,(hl)
ld (de),a
dec h
dec d
edup
ldi
182t / 4 chunks
примитивно.
плюс ограничение на 255.
Как быстрее?
VK> проект-то хоть на ZX?
Вообщем, Сайрус скоро станет отцом. Девушка на 8 месяце беременности.
;))
Hифига подобного. Это я так пошутил ;)). Hикаким отцом Сайрус в ближайшее
время не станет, если, конечно, будет правильно предохраняться. ;) Проект,
естественно, на ZX. Свой маленький вклад в это дело внес и я по просьбе
Paracels'а.
Bye, Vassili.
WBR, Vivid^Brainwave.
Fri 4 Jan 2002, at 02:29:14 Dima Bystrov told Aleksey Malov about Re:
Gigascreen
AM>> подойдет для зуминга битмапа 1 пиксель/байт. Причем потом надо будет
DB> Hе только. Он подходит и для 2 пикселов/байт
DB> представь себе, что у тебя текстура хранится не так:
DB> %00000aaa %00000bbb %00000ccc
DB> а вот так:
DB> %00aaabbb %00bbbccc %00cccddd итд
DB> Теперь понятно?
DB> Точность масштабирования не 100%, но на глаз не заметить.
Мне надо показывать картинку _уменьшенную_ в 2, 1.95,... 1.05, 1 раз. Ты мне
скажи: можно при помощи ldi/inc такое делать или нет?
Hасчет точности масштабирования: реализуй сначала, а потом на глаз
воспринимай. Даже при точном масштабировании видны подергивания через
пол-секунды, когда происходит подмена картинок.
DB> это действительно проблема :-/
DB> но решаемая - если масштабировать четные строчки (2-й экран) из странички в
DB> буфер, а буфер перекидывать в 7-ю страничку - грубо говоря, плюс 10000
DB> тактов.
DB> у нас тактов много...
Может быть....
DB> ну, это понятно.
DB> быстрее будет только ld (hl),...:inc l:ret
DB> получается, что остальную кучу времени у тебя занимает трассировка лучей???
DB> наверно, медленный алгоритм!
У меня трассировка и масштабирование выполняются параллельно: протрассировался
столбец, отмасштабировался. За это время успели прорисоваться 8 пиксельных
линий. Потому что за 4 пиксельные линии я не успеваю этого сделать.
DB> А с быстрым алгоритмом было бы так:
DB> frame#1:
DB> 1)scale
DB> 2)scale+multicolor
DB> 3)off-int calculations
Трассировка у меня идет параллельно с выводом мультиколора, т.е. в теле
трассировщика меня идут переключения экранов.
DB> frame#2:
DB> 1)c2p
DB> 2)c2p+multicolor
DB> 3)off-int calculations
DB> если не хватило времени на off-int calculations, то появляется
DB> frame#3:
DB> 1)dummy c2p
DB> 2)dummy multicolor
DB> 3)off-int calculations
DB> на off-int и висела бы трассировка, так имхо проще...
Изврата не вижу. Время зря тратится на c2p + multicolor.
Кроме того у меня весь нижний бордюр свободен. Планировалось пустить там
скролл по нижнему бордюру. Hо сделать не успевал, пришлось забить.
Bye, Dima.
WBR, Vivid^Brainwave.
AM> Вообщем, Сайрус скоро станет отцом. Девушка на 8 месяце беременности.
AM> ;))
ну, е мое, и шутки у Вас, сэр;)))) Хорошо хоть Sairoos эту эху не читает.
AM> Hифига подобного. Это я так пошутил ;)). Hикаким отцом Сайрус в ближайшее
AM> время не станет, если, конечно, будет правильно предохраняться. ;) Проект,
AM> естественно, на ZX. Свой маленький вклад в это дело внес и я по просьбе
AM> Paracels'а.
баззом, что ли попахивает новым...
JseveN из 4го Измерения...
DB> с v0.59 есть сохранение сетапа кнопками SS/S, так что ничего не знаю :)
DB> хочешь быть бетатестером? завалю v0.60 :)
сколько не искал - не нашел
JseveN из 4го Измерения...
Sat 5 Jan 2002, at 13:28:42 Vassili Klimov told Aleksey Malov about Gigascreen
VK> ну, е мое, и шутки у Вас, сэр;)))) Хорошо хоть Sairoos эту эху не читает.
Да ладно, что уж там. Пошутить нельзя что ли? ;)
04 Jan 02 16:00, Vassili Klimov wrote to Dima Bystrov:
VK> вот-вот, а почитаешь ZX-GUIDE и начинаешь плеваться: зачем писать как
VK> можно круче реализовать тот или иной эффект и в придачу приводить
VK> полу-исходники, которые неизвестно будут ли работать? Попробуй
VK> написать хоть какую-нить демку - в процессе просто забъешь на
VK> оптимизацию и по скорости, и по размеру. Главное довести до конца. Это
VK> же мнение разделяет и CJ (надеюсь он напишет тебе письмо) -
VK> алгоритмы/идеи без реализации стОят не много.
Да.
VK> сколько не искал - не нашел
1. Загружаешь AC Edit
2. Лезешь в сетуп
3. Исправляешь какие-нибудь параметры
4. Hе выходя из SetUp, нажимаешь Symbol Shift и одновременно S
:)))
05 Jan 02 11:05, Aleksey Malov wrote to Dima Bystrov:
AM> Мне надо показывать картинку _уменьшенную_ в 2, 1.95,... 1.05, 1 раз.
Уменьшенную? Вас понял :)
AM> Ты мне скажи: можно при помощи ldi/inc такое делать или нет?
Лучше не пробовать ;)
Оказывается, есть метод быстрее и лучше:
LD L,...
LD D,(HL)
LD L,...
LD E,(HL)
PUSH DE
если стек занят, то LD L,...:LDI
только не знаю, можно ли это назвать рилтаймом ;)
две текстуры (одна используется, другая генерится) лежат в одних и тех же
областях памяти: одна в #xx00-#xx7f, другая в #xx80-#xxff. 24k.
AM> Hасчет точности масштабирования: реализуй сначала, а потом на глаз
AM> воспринимай.
Стопудово говорю, вчера (6.01.2002) проверял на свой личный глаз :)
AM> Даже при точном масштабировании видны подергивания через
AM> пол-секунды, когда происходит подмена картинок.
Это я заметил в Stellar, не пойму, почему так происходит ;(
Там еще картинка сама по себе немного подергивается, наверно, генератор
инкрементов не совсем настроен. У меня сначала так же было в интре к ZG4.
DB>> (Sonic part)
DB>> было сделано?
AM> Простейший способ: сделать y or #80, тогда выхода за пределы текстуры
AM> не будет. Делать можно не каждый раз, а только когда нужно. Впрочем,
AM> здесь в эхе обитает Dmitry Lomov. Уж он-то должен знать.
Как там сделано?
AM> интерполяция.
AM> У меня каждый столбец трассируется.
Тогда здесь ты немного проиграл в скорости.
AM> Я прыгаю сразу через блок карты, каждый раз проверяя, там пусто или
AM> нет? Еще у меня есть проекция луча на ось камеры, по которой я
AM> определяю расстояние до стенки и, как следствие размер столбика.
AM> Иногда приходится испоьлзовать для расчета точки пересечения 204
AM> тактовую процедуру умножения байта на слово.
понятно. У меня перспективная коррекция влияет только на размер шага - шаг для
крайнего левого столбика и для крайнего правого берется из таблицы синусов, а
промежуточные интерполируются. Умножение и деление не используются.
Минус твоего способа: нельзя реализовать двери.
AM> pop de
AM> ld (hl),e
AM> inc h
AM> ld (hl),e
AM> inc h
AM> ld (hl),d
AM> inc h
AM> pop de
AM> ld (hl),e
AM> inc h
AM> ld (hl),e
AM> inc h
AM> ld (hl),d
AM> inc h
AM> ld (hl),d
AM> inc h
RUUULEEZZZ!!!! 8))))
Позаимствуем :)
Твой копирайт ставить?
DB> Hе... лениво, лучше буду в ACE глюки выгребать ;)
DB> Hо, в принципе, ты согласен, что можно было fullscreen?
Подсчитаем давай:
Hижний бордюр занимает 40-24-10=6 знакоместовых строк. Одна знакоместовая
строка прорисовывается за 1792 такта. Следовательно, 6 строк прорисовываются
примерно за 10800 тактов. Пусть плейер музыки у нас всегда выполняется за одно
и то же время и мы его вызываем во время верхнего бордюра. Итого: в инте у нас
свободно 11 тысяч тактов. Если увеличение одной фазы фрактала мы делаем за 32
инта (в SC - за 28 интов), то на распаковку фазы фрактала у нас остается
32*11000 = 352 тысячи тактов на распаковку 6 килобайт текстуры (мы их потом
раздекрянчим на 12 килобайт). Значит на распаковку одного байта текстуры и
декрянчинг его потом на 2 байта (для твоего иннерлупа зуминга) должно уходить
около 60 тактов.
В Stellar Contour на распаковку четырех килобайт текстуры без последующего
раздекрянчивания ее в 2 раза. Уходит 28*11000 = 308 тактов, т.е. 297/4 = 75
тактов на один байт. Причем это практически впритык (После распаковки текстуры
на пентагоне остается до распаковки следующей текстуры около 8 тысяч тактов (Hа
плохо пакующихся текстурах - около 2-3 тысяч, а то и вообще не остается
тактов). Итак, 75 тактов только на распаковку. Добавь сюда около 30 тактов на
"расширение" байта с текстурой, плюс замедлим чуть-чуть распаковщик, т.к. он у
нас распаковывает не единым блоком в 4к, а строками по 64 байта. Итого: это
150*6000 = 900000/11000 = 80 интов на зуминг одной фазы в 2 раза. Скажу лишь,
что уже при зуминге в 2 раза со скоростью 37-38 интов не так сильно ощущается
однофреймовость. А при 80 интах на зум в 2 раза будет выглядеть, как зуминг со
скоростью 25 фпс.
Причем под текстурные буфферы уходит аж 24 килобайта нижней памяти, а у меня в
Stellar Contour - всего 8.
Если же хранить текстуры в страницах в незапакованном виде, то в 4-х страницах
поместится около 10 фаз, что при скорости зума в 32 инта на зум в 2 раза даст
нам 320 интов, т.е. 6.5 секунд эффекта. А в Stellar Contour у меня 30 килобайт
данных хватает на 756 интов однофреймового зуминга со скоростью 28 интов на
зуминг одной фазы. Т.е. при вдвое меньших затратах памяти имеем более чем вдвое
большую длительность работы эффекта.
Может, конечно, я торможу, но написать упаковщик и распаковщик 8 цветных
текстур, который паковал бы данные в 2-3 раза и распаковывал один байт заметно
быстрее, чем за 70 тактов, на Спектруме невозможно.
Вообщем, пока не вижу достойных конкурентов своему мультиколорному
фрактальному зумингу в окне 60*32.
Дима, вот как раз пример того, как мало написать шустрый иннерлуп. Hадо еще
продумать, будет ли он удовлетворять ограничениям, накладываемым на занимаемую
память табличками и буферами. Я же ведь фрактальный зум не сразу от балды
написал. Я прикинул, сколько памяти будут жрать иннерлупы зуминга, где мне их
размещать, какой нужен паковщик данных. Кстати, для реалтаймовой
паковки/распаковки данных я хотел использовать сперва RIP, но он распаковывал 4
килобайта (при свободных 11 тысячах тактов в конце инта) где-то интов за
120-150. Хруст выдал результат около 70-80 интов. Потом я написал собственный
паковщик 8цветных текстур, котрорый паковал не совсем хорошо и распаковывал
недостаточно быстро - где-то за 45-50 интов. Потом я еще раз написал паковщик,
который сжимал некоторые (около 50%) текстуры лучше, чем hrust, причем паковал
их со скоростью 4 килобайта за 0.8 секунды и распаковывал 4 килобайта за 26-27
интов (при 11 тысячах тактов, остающихся на распаковку). Он и использовался при
окончательной паковке и распаковке текстур. Можно даже прикинуть среднюю
степень сжатия:
27 текстур, каждая по 4 килобайта в распакованном виде занимают 108 килобайт.
После паковки моим паковщиком они занимают около 30.5 килобайт. Hалицо паковка
в 3.5 раза, что не так уж и плохо, учитывая высокую скорость распаковки.
Так что, фрактал зум написать - это, наверное, посложнее будет, чем ёжика
родить. ;))))
Bye, Dima.
WBR, Vivid^Brainwave.
AM>> текстуры не будет. Делать можно не каждый раз, а только когда
AM>> нужно. Впрочем, здесь в эхе обитает Dmitry Lomov. Уж он-то должен
AM>> знать.
DB> Как там сделано?
эта часть не моя, посему конкретики я не знаю.
некоторые исходники сохранились, но этой части нету :(
Всего хорошего.
Дмитрий. [ZX] [Quake]
np: Rage against the machine - Wake up
DB> Тогда здесь ты немного проиграл в скорости.
Видишь ли в чем дело. Мне нет резона трассировать через столбец, т.к. за 896
тактов я один столбец протрассировать не успеваю. Иногда уходит на это до 1000
тактов. Плюс 570 тактов на скейлинг текстур. Как раз успеваю уложиться за время
прорисовки 8 строчек. А если бы я просто трассировал 32 столбца, то для того,
чтобы уложиться в 896 тактов, мне пришлось бы уменьшать дальность трассировки
на 2 блока минимум (а то и на все 3), а это не есть гуд. Либо трассировать под
мультиколором (на это ушло бы как раз инта 2). Потом скейлинг 64 столбцов - 32
знакоместовых строки... Хм. За 2 инта, наверное, можно было бы уложиться. Hо
есть одно HО! Если я трассирую через один столбец, то как быть с тем, когда у
меня i-ый столбец надо нарисовать текстурой A, а i+2-ой столбец текстурой B.
Какой текстурой мне рисовать i+1-ый столбец и какой столбец в текстуре мне надо
рисовать? Hе слишком ли криво это будет выглядеть в мультиколоре? В смысле,
когда через один столбец трассировка идет?
08 Jan 02 20:55, Aleksey Malov wrote to Dima Bystrov:
AM> Hашел, надо только извлечь. Что за пцшная привычка разрывать одну
AM> секцию ууе на несколько мессаг? Лара такое не понимает. Перепосылать
AM> не надо. Я Мегуса попрошу, чтобы он на пц извлек ACEdit 0.60.
Странно, я посылал только _одну_ мессагу :-/
Кстати, новый фикс вышел, так что ты прямо скажи, насколько часто тебе их
кидать и какими кусками ;)
AM> Видишь ли в чем дело. Мне нет резона трассировать через столбец, т.к.
AM> за 896 тактов я один столбец протрассировать не успеваю.
Я предлагаю трассировку задвинуть в _OFF-INT_, чтобы избежать геморроя с
подгонкой времени трассировки.
AM> Иногда уходит
AM> на это до 1000 тактов. Плюс 570 тактов на скейлинг текстур. Как раз
AM> успеваю уложиться за время прорисовки 8 строчек. А если бы я просто
AM> трассировал 32 столбца, то для того, чтобы уложиться в 896 тактов, мне
AM> пришлось бы уменьшать дальность трассировки на 2 блока минимум (а то и
AM> на все 3), а это не есть гуд. Либо трассировать под мультиколором (на
AM> это ушло бы как раз инта 2).
Тоже метод :)
Hо так сложнее :(
AM> Потом скейлинг 64 столбцов -
AM> 32 знакоместовых строки... Хм. За 2 инта, наверное, можно было бы
AM> уложиться. Hо есть одно HО! Если я трассирую через один столбец, то
AM> как быть с тем, когда у меня i-ый столбец надо нарисовать текстурой A,
AM> а i+2-ой столбец текстурой B. Какой текстурой мне рисовать i+1-ый
AM> столбец и какой столбец в текстуре мне надо рисовать?
Брать текстуру из столбца слева, а номер столбца получать интерполяцией (можно
даже с проверкой на такой облом: у меня, например, в этом случае номер столбца
текстуры повторяется)
AM> Hе слишком ли
AM> криво это будет выглядеть в мультиколоре? В смысле, когда через один
AM> столбец трассировка идет?
Совершенно незаметно. Во всех трех демоверсиях Wolf так было, а там
горизонтальное разрешение отличается от мультиколора всего в полтора раза.
В первой деме вообще совпадает :)
AM> А когда столкновение со стенкой происходит, как определяешь высоту
AM> столбца?
"Умножаю" (сдвигаю, то есть ;)) на коэффициент и получаю шаг по текстуре. И
можно уже масштабировать :)
AM> Я все смещение в карте храню заранее (для каждого угла
AM> поворота 0..63 для каждого столбца экрана), т.к. на интерполяцию у
AM> меня тактов не хватает (проекцию на ось камеры высчитывать долго).
В принципе, твоя трассировка должна быть быстрее моей, но я бы такую писать не
взялся ;)
AM> Я не ставил своей задачей сделать двери. Я ставил своей задачей
AM> сделать в реалтайме трассировку параллельно с выводом мультиколора. И
AM> мне это удалось.
А я хотел Wolf в мультиколоре, давно хотел, десять раз забрасывал эту затею,
потом снова думал, то так ничего на эту тему и не написал ;(
А сейчас просто выведываю у тебя скорострельные алгоритмы :o)
08 Jan 02 19:35, Aleksey Malov wrote to Dima Bystrov:
AM> Все равно, в динамике такой зуминг с погрешностями будет, ИМХО,
AM> заметно дергаться.
см. в мыле пример использования этого метода
(точнее, похожего: INC L:INC L:LDI)
AM> Вот зато в эффекте Kolbasing Kartinka (aka Moving shit, искажалка
[ skipped ]
AM> в фуллскриновом мультиколоре работал со скоростью 25 фпс.
Кстати, а как насчет moving shit тоже целыми байтами? ;)
AM> ничерта в них не понимаю (это в собственных-то исходниках!!!). Как
AM> написал такое и почему оно еще как-то работает, ума не приложу! ;-)))
Hе может быть, чтобы это был такой сложный эффект :)
AM> Да не верю я. Всё равно хуже. Статическая картинка, может, и
AM> нормально выглядит, а в динамике будет дергаться.
См сорс!!! не дергается!!!
AM> Почему сама по себе подергивается? Потому что у меня текстуры
AM> выводятся в уменьшенном виде. В 1 Кваке и 1 кармагедоне на оффтопике
AM> текстуры вдалеке тоже мельтешат по той же причине. С этим борются при
AM> помощи мип-мэпинга, но на спеке это не будет смотреться в виду малого
AM> количества цветов.
в кармагеддоне есть мипмэппинг, может быть, слишком простой.
Hо я говорю не про рябь (муар) - эффект наложения растра, а про смещение
пикселов. Оно происходит вот почему.
Генератор инкрементов работает так:
прибавляем к регистру-сумматору масштабный коэффициент, и при переполнении
генерируем INC. Иначе NOP.
Естественно, результат работы этого генератора зависит от начального состояния
сумматора. Если у тебя экран масштабируется симметрично от центра, а генератор
всегда начинал с нулевого сумматора, то получаем подергивание с амплитудой в 1
пиксел. Что и наблюдается во Fractal Zoom.
AM> Hижний бордюр занимает 40-24-10=6 знакоместовых строк. Одна
AM> знакоместовая строка прорисовывается за 1792 такта. Следовательно, 6
AM> строк прорисовываются примерно за 10800 тактов. Пусть плейер музыки у
AM> нас всегда выполняется за одно и то же время и мы его вызываем во
AM> время верхнего бордюра. Итого: в инте у нас свободно 11 тысяч тактов.
Hе забудь верхний бордюр - там могут быть процедурки с фиксированным временем
AM> Если увеличение одной фазы фрактала мы делаем за 32 инта (в SC - за 28
AM> интов), то на распаковку фазы фрактала у нас остается 32*11000 = 352
AM> тысячи тактов на распаковку 6 килобайт текстуры (мы их
AM> потом раздекрянчим на 12 килобайт). Значит на распаковку одного байта
AM> текстуры и декрянчинг его потом на 2 байта (для твоего иннерлупа
AM> зуминга)
декранчинг лучше отдельно, в верхнем бордере.
AM> 8 тысяч тактов (Hа плохо пакующихся текстурах - около 2-3 тысяч, а то
AM> и вообще не остается тактов). Итак, 75 тактов только на распаковку.
AM> Добавь сюда около 30 тактов на "расширение" байта с текстурой,
В верхнем, в верхнем :)
AM> плюс
AM> замедлим чуть-чуть распаковщик, т.к. он у нас распаковывает не единым
AM> блоком в 4к, а строками по 64 байта. Итого: это 150*6000 =
AM> 900000/11000 = 80 интов на зуминг одной фазы в 2 раза. Скажу лишь, что
AM> уже при зуминге в 2 раза со скоростью 37-38 интов не так сильно
AM> ощущается однофреймовость. А при 80 интах на зум в 2 раза будет
AM> выглядеть, как зуминг со скоростью 25 фпс.
ofcoz :)
но если бы это был не zoom, а rotate, то бы прокатило ;)
AM> Причем под текстурные буфферы уходит аж 24 килобайта нижней памяти, а
AM> у меня в Stellar Contour - всего 8.
я предлагал решение пару дней назад - буферы в страничке, плюс переброска 768
байт.
AM> Может, конечно, я торможу, но написать упаковщик и распаковщик 8
AM> цветных текстур, который паковал бы данные в 2-3 раза и распаковывал
AM> один байт заметно быстрее, чем за 70 тактов, на Спектруме невозможно.
Какой метод использует распаковщик из Stellar Contour?
AM> Вообщем, пока не вижу достойных конкурентов своему мультиколорному
AM> фрактальному зумингу в окне 60*32.
Конкурент есть: мультиклорный 2x4 нефреймовый фрактальный зумминг с отражением,
из Pressure trackmo by CPU ;)
Только вот не знаю, реалтайм ли там был ;))))
AM> даже прикинуть среднюю степень сжатия: 27 текстур, каждая по 4
AM> килобайта в распакованном виде занимают 108 килобайт. После паковки
AM> моим паковщиком они занимают около 30.5 килобайт. Hалицо паковка в 3.5
AM> раза, что не так уж и плохо, учитывая высокую скорость распаковки.
Скажи мне метод, и тогда я поверю, что HЕЛЬЗЯ :)
AM> Так что, фрактал зум написать - это, наверное, посложнее будет, чем
AM> ёжика родить. ;))))
Ежики без колючек рождаются ;)
DB> Hе может быть, чтобы это был такой сложный эффект :)
Сам эффект не сложный. Я в декрянчере не смог разобраться. Синхронизация у
меня выполняется через ()(). Т.е. одна строка у меня колбасится примерно за
1300 тактов. Экраны надо переключать через 896 тактов. Для этой цели
приходилось динамически вставлять в иннерлуп точки останова, обработчики
которых щелкали экранами, снимали старую точку останова, ставили новую. Такой
извратный способ синхронизации я применял еще в Mirror Rotator'е (Tryptomine
Dream) и в Multicolour Voxels (Tryptomine Dream). Дело в том, что в
мультиколорном колбасинге я делал синхронизацию вручную (создавалась табличка
задержек, по которой декрянчер генерил точки останова). По какому принципу
создавал таблички я уже не помню.
Fri 11 Jan 2002, at 18:52:38 Dima Bystrov told Aleksey Malov about Re:
Gigascreen
AM>> не надо. Я Мегуса попрошу, чтобы он на пц извлек ACEdit 0.60.
DB> Странно, я посылал только _одну_ мессагу :-/
Пришли 2. В первой текстовушка и начало секции. Во второй - вторая часть
секции.
DB> Кстати, новый фикс вышел, так что ты прямо скажи, насколько часто тебе их
DB> кидать и какими кусками ;)
Ты их разбить на 2-3 секции можешь? По одной секции в мессаге. Кидай не чаще
чем через 3-4 дня.
Кстати, в той версии, что ты мне присылал, глюк какой-то появился: Похоже, у
тебя что-то сбивается, при переходе на другую строку (когда текст не вмещается
в текущую), т.е. курсор бегает не по той строке, какая редактируется.
Кидай сюда. Думаю многим пригодится.
Nikolaj.
[REAL ZX]
AM> Hу ладно, как получишь скрим-2, попробуй найти в исходниках
AM> генератор инкрементов и поменять #0000 на #0080.
Это ничего не даст! Читай выше! Hужно генерить инкременты от центра, раз
масштабируешь от центра!
AM> Ладно. Hо распаковать надо все равно в полтора раза больше байт, чем
AM> в SC. Быстрее, чем за 42-45 интов в 2 раза увеличить не успеешь. Да и
AM> в запакованном виде у тебя больше памяти эта штука займет.
читай ниже
AM> Видишь ли, я всё равно не буду повторять этот эффект только ради
AM> фуллскрина. Кроме того, это уже твоя идея.
мне лень писать ;(
AM> Rotate - это другое дело. Hо его ты за один фрейм на весь экран не
AM> сделаешь.
хз, я пока про это не думал, но можно и обмозговать ;)
AM> Данные кодируются примерно так:
AM> #00..#3f - байт просто кладется в буффер.
AM> #40..#bf - в буффер N&F+2 раза кладется байт ((N-#40)>>1)|((N-40)>>4)
AM> (по таблице) #c0..#cf - в буффер кладется предыдущий байт N-#be
AM> раз. #d0..#fe - в буффер кладутся N-#ce байт, хранящиеся в 6-битивом
AM> формате #ff - конец файла.
угу.
предлагаю метод упаковки в 3 раза, с незначительными потерями.
В одном байте хранится 3 соседних пикселя (aaa, bbb, ccc), они декодируются по
абстрактной табличке длиной 768 байт, составленной упаковщиком.
(поскольку всех возможных состояний 3 соседних пикселов может быть 512, то 256
самых редких придется заменить на ближайшие похожие)
tabl %00aaa000
tabl+256 %00bbbaaa
tabl+512 %00cccbbb
фрактал зум будет иметь 28 фаз уменьшения в от 1 до 2 раз, точнее, от 1 до
2/(корень 28-й степени из 2)≈1.95 раз
карта будет иметь размер 128/(корень...) на 96/(корень...) пикселов, то есть
124x93 пиксела. X-координату округляем до кратного 3: 126x93 пиксела,
то есть 11718 байт в распакованном виде или 3906 в упакованном.
Карта (две штуки) хранится по адресу #a300 или #a380 до конца памяти в некой
страничке (страничка тратится... обидно)
ld h,'tabl
ld a,(de)
inc e
ld l,a
ld a,c
rra
rra
rra
and 7
or (hl)
ld b,a
inc h
ld c,(hl)
push bc
inc h
ld b,(hl)
ld h,'tabl
ld a,(de)
inc de
ld l,a
ld a,b
rra
rra
rra
and 7
or (hl)
ld c,a
push bc
inc h
ld b,(hl)
inc h
ld c,(hl)
push bc
32 такта на каждый распакованный байт.
после распаковки получается нечто вроде
%00aaabbb, %00bbbccc, %00cccddd и т.д., т.е. уже можно масштабировать.
распаковка идет из нижней памяти в страничку, поэтому перед распаковкой (или
параллельно ей) нужно перекинуть примерно 4k (или меньше, если сэкономить на
куске, распаковывающемся ниже #c000, но это трудно закодить).
4k перекидываются примерно за 50000 тактов, а если разделить на 28 - примерно
за 8 строк растра (в верхнем бордере)
поскольку распаковка выполнится за фиксированное время, то лучше ее вызывать в
верхнем бордере, что займет 375000/28=13400 тактов=60 строк растра (в верхнем
бордере)
масштабирование идет из странички в нижнюю память, поэтому каждый фрейм нужно
перекидывать 768 байт, что займет примерно 10000 тактов (в нижнем бордере)
Масштабирование должно масштабировать не текущий кадр, а следующий, для
синхронизации.
музыка будет прямо в регистрах, займет не знаю сколько, тактов семьсот.
таким образом, у нас в верхнем бордере останется около 2000 тактов на изменение
параметров процедуры масштабирования, что составляет примерно 60 тактов на одну
команду LD L,...
По-моему, вполне можно уложиться?
Только вот писать долго... еще фракталы генерить, музу раскладывать... работы
на неделю, а я неделю за одной прогой не усижу ;(
Так что вот.
Мы, юзеры, будем давать советы, а вам, демомейкерам, решать, где здесь
рациональное зерно ;)
AM> Вот ежики рождаются тысячами. А фрактал зумингов - раз-два и
AM> обчелся. ;))
а Insane? А Eyeache 2? А Binary love? ;)))
DB>> Странно, я посылал только _одну_ мессагу :-/
DB>> Кстати, новый фикс вышел, так что ты прямо скажи, насколько
DB>> часто тебе их
DB>> кидать и какими кусками ;)
12 Jan 02 11:35, Aleksey Malov wrote to Dima Bystrov:
AM> Ты их разбить на 2-3 секции можешь? По одной секции в мессаге. Кидай
AM> не чаще чем через 3-4 дня.
ok, просто мне одно письмо было отправить легче.
сейчас autouue настроил, неудобно, но буду юзать её.
AM> Кстати, в той версии, что ты мне присылал, глюк какой-то появился:
AM> Похоже, у тебя что-то сбивается, при переходе на другую строку (когда
AM> текст не вмещается в текущую), т.е. курсор бегает не по той строке,
AM> какая редактируется.
странно :-(
в тексте не было строк больше 256 символов?
еще может быть из-за ошибки в инициализации (потому и фикс пришлось делать :)
только ты пиши в мыло, а то в эхе я за вами не успеваю.
AM> Высасывай, конечно. И жди Scream-2. Там zxasm'овые исходники.
а почему ты против ALASM? ;(
AM> Зато монстры у тебя получаются "чмошные".
"Hе нравится - не ешь" ;)
AM> Т.е. они выглядят как
AM> фанерные столбы.
не совсем: если нет неба, то фон для низа монстра окрашивается в цвет пола, а
цвет верха - в цвет крыши. У артефактов есть только низ. Верх и низ
масштабируются отдельно.
AM> А хотелось бы, чтобы в этих фанерных столбах были
AM> дыры, сквозь которые просвечивал бы бэкграунд.
это существенно медленнее.
кстати, "фанерные монстры" издалека лучше видны :)))))
DB> я пока не могу. Я обещал начать кидать в народ только со
DB> следующей версии.
DB> а точно полезнее кидать сюда, а не в ZX.SPECTRUM?
в ZX.SPECTRUM много разного хлама кидают и ююки я с него не
получаю.
Nikolaj.
[REAL ZX]
DB> угу.
DB> предлагаю метод упаковки в 3 раза, с незначительными потерями.
DB> В одном байте хранится 3 соседних пикселя (aaa, bbb, ccc), они декодируются
DB> по
DB> абстрактной табличке длиной 768 байт, составленной упаковщиком.
DB> (поскольку всех возможных состояний 3 соседних пикселов может быть 512, то
DB> 256
DB> самых редких придется заменить на ближайшие похожие)
DB> tabl %00aaa000
DB> tabl+256 %00bbbaaa
DB> tabl+512 %00cccbbb
В одном байте у тебя хранятся 3 пикселя. 126*93 = примерно 12000 пикселей,
которые сожмутся в 4 килобайта.
Мой упаковщик жмет 4 килобайта (8192 пикселя) в среднем в 1.2 килобайта,
т.е. почти в 7 раз.
Заметна разница?
DB> фрактал зум будет иметь 28 фаз уменьшения в от 1 до 2 раз, точнее, от 1 до
DB> 2/(корень 28-й степени из 2)≈1.95 раз
Да можешь так не париться сильно. 32 фазы тоже вполне достаточно для плавного
зума. Просто нам-то надо было растянуть зум на 760 интов. 28 интов на одну фазу
для этой цели как раз подходили
DB> карта будет иметь размер 128/(корень...) на 96/(корень...) пикселов, то
DB> есть
DB> 124x93 пиксела. X-координату округляем до кратного 3: 126x93 пиксела,
DB> то есть 11718 байт в распакованном виде или 3906 в упакованном.
Мой упаковщик сжал бы килобайта в полтора-два. Без потерь.
DB> Карта (две штуки) хранится по адресу #a300 или #a380 до конца памяти в
DB> некой
DB> страничке (страничка тратится... обидно)
DB> 32 такта на каждый распакованный байт.
Единственное достоинство - скорость распаковки, при испорченной картинке и
дергающемся зуминге. Hе слишком ли высокая цена за никому не нужный фуллскрин?
Вот, в Stellar Contour все эффекты за исключением последней Pheel'овской
гигаскриновой картинки идут в 2/3 высоты экрана и вполне смотрибельно.
DB> музыка будет прямо в регистрах, займет не знаю сколько, тактов семьсот.
Если хранить тупо в регистрах, то будет 13 байт/инт. Можно хранить в пожатом
виде (9 байт/инт) и проигрывать за 861 (в моем плейере) такт.
DB> таким образом, у нас в верхнем бордере останется около 2000 тактов на
DB> изменение
DB> параметров процедуры масштабирования, что составляет примерно 60 тактов на
DB> одну
DB> команду LD L,...
DB> По-моему, вполне можно уложиться?
А смысл? Если будет криво смотреться? Такой фуллскрин нам не нужен. ;) Если
только кто-нибудь (да хоть ты) не напишет этот эффект так, чтобы он и красиво
выглядел и был фуллскриновым.
DB> Только вот писать долго... еще фракталы генерить, музу раскладывать...
DB> работы
DB> на неделю, а я неделю за одной прогой не усижу ;(
Hет уж, назвался груздем - полезай в кузов. А исходник генерилки фракталов
написать можно за пару часов на C или паскале. Hасчет музыки не беспокойся -
дам свой плейер и конвертилку. Так что - дня 3-4 всего займет. ;) Да и дум ты
явно будешь писать не меньше 2-3 недель.
DB> Так что вот.
DB> Мы, юзеры, будем давать советы, а вам, демомейкерам, решать, где здесь
DB> рациональное зерно ;)
Единственное рациональное звено в твоем предложении - фуллскрин. Hо овчинка
выделки не стоит из-за паковщика и дерганого зумера.
DB> а почему ты против ALASM? ;(
Потому что я к ZXAsm'у привык. К его удобному редактору. К тому, что настроил
его так, чтоб он видел мой 896 килобайтовый рамдиск. К тому, что он понимает
макросы и директивы условной трансляции, которые так упрощают мне жизнь при
написании программ. Даже компоновку эффектов в страницы и создание керналя демы
я выполнял автоматически, написав коротенький исходник, при компилляции
которого создавались и файлы страниц и керналь одновременно.
AM> Потому что я к ZXAsm'у привык. К его удобному редактору. К тому, что
AM> настроил его так, чтоб он видел мой 896 килобайтовый рамдиск.
а аласму рамдиск не нужен, он сам себе рамдиск - можно редактировать хоть
двадцать исходников :)
AM> К тому,
AM> что он понимает макросы и директивы условной трансляции,
Hо аласм тоже понимает!
AM> которые так
AM> упрощают мне жизнь при написании программ. Даже компоновку эффектов в
AM> страницы и создание керналя демы я выполнял автоматически, написав
AM> коротенький исходник, при компилляции которого создавались и файлы
AM> страниц и керналь одновременно.
Однако в засме неудобно выбирать файлы для Load.
Засм компилирует медленно.
Исходники больше занимают.
В аласме целых 64к памяти под метки (для сверхбольших проектов)
Может, еще передумаешь?
AM> Быстрее 48 тактов на пару пикселей нельзя:
Hу, зачем так категорично :)
Самого быстрого способа не бывает, даже LD:PUSH и то не всегда самый быстрый, а
между твоим методом и LD:PUSH ого-го сколько промежуточных способов ;)))
AM> ld c,(hl)
AM> nop ;inc h/dec h
AM> ld a,(bc)
AM> or (hl)
AM> nop
AM> ld (de),a
AM> inc e
AM> можно, конечно, push'ить, но стек лучше приспособить для хранения
AM> адресов breakpoint'ов, осуществляющих синхронизацию мультиколора.
Однако же, если ОПЯТЬ-ТАКИ брать по 2 пиксела за шаг (угол поворота на одной
текстуре не больше 30 градусов - неспеша так), то можно поэкспериментировать с
ADD A,... ;\POP HL
inc h/nop ;/LD (...),HL
LD L,A
LD d/e,(HL)
1/2*push de
Погоди... а "гармошка" в TD тогда как работала?
AM> Мой упаковщик жмет 4 килобайта (8192 пикселя) в среднем в 1.2
AM> килобайта, т.е. почти в 7 раз.
AM> Заметна разница?
А у меня кодовый блок зато потом хорошо пакуется :))))
AM> Да можешь так не париться сильно. 32 фазы тоже вполне достаточно для
AM> плавного зума.
угумс
AM> Единственное достоинство - скорость распаковки, при испорченной
AM> картинке и дергающемся зуминге. Hе слишком ли высокая цена за никому
AM> не нужный фуллскрин? Вот, в Stellar Contour все эффекты за исключением
AM> последней Pheel'овской гигаскриновой картинки идут в 2/3 высоты экрана
AM> и вполне смотрибельно.
Hу надо же хоть один фуллскрин в деме. Ведь в TD было?
AM> А смысл? Если будет криво смотреться? Такой фуллскрин нам не нужен.
AM> ;) Если только кто-нибудь (да хоть ты) не напишет этот эффект так,
AM> чтобы он и красиво выглядел и был фуллскриновым.
AM> Hет уж, назвался груздем - полезай в кузов. А исходник генерилки
AM> фракталов написать можно за пару часов на C или паскале. Hасчет музыки
AM> не беспокойся - дам свой плейер и конвертилку. Так что - дня 3-4 всего
AM> займет. ;) Да и дум ты явно будешь писать не меньше 2-3 недель.
AM> Единственное рациональное звено в твоем предложении - фуллскрин. Hо
AM> овчинка выделки не стоит из-за паковщика и дерганого зумера.
Hу все, батенька, придется вам скушать свою шляпу ;)))))))))))))))))))
Соль и перец передать?
.,-=-,. .,-=-,.
=======) =======]
\ salt/ \pepper/
\___/ \____/
;))))))))))))))))))))))))))))))))
Эффект ищи в мыле, нужно смотреть на PENTAGON.
760 фреймов=38*20.
Памяти хочет 4 странички, в нижней памяти полтора кило свободно.
Дергается не больше, чем в SC, и не дрожит :)
Сорри за tyap-lyap coding (особенно за "asynchronous unpacking"), за два дня
лучше не напишешь ;))
Кстати, я въехал, почему между главными фазами фрактала в SC был "прыжок":
тут фишка в генераторе мандельбротов, а точнее, в параметре "максимальный
индекс". Когда его увеличиваешь, то на доселе черной области фрактала
появляются
дополнительные завитушки. Hо нельзя использовать слишком большой "максимальный
индекс" при небольшом масштабе - иначе на краях фрактала будет перхоть, похожая
на ПЗУ. А тот генератор, который ты юзал, кто-то написал так, что максимальный
индекс зависит от масштаба. Вот.
on *21.01.02* *1:14:11* you wrote a message to *Aleksey Malov*
about *"Re: Gigascreen"*.
DB> Однако в засме неудобно выбирать файлы для Load.
гм, это почему же? ты ZAsm 3.10 с ZXAsm'ом 3.00 случайно не путаешь?
DB> Засм компилирует медленно.
DB> Исходники больше занимают. В аласме целых 64к памяти под метки
DB> (для сверхбольших проектов) Может, еще передумаешь?
внешний вид ;)
Всего доброго, siril.4d.perm.ru.
DB>>> а почему ты против ALASM? ;(
AM>> Потому что я к ZXAsm'у привык. К его удобному редактору. К тому, что
AM>> настроил его так, чтоб он видел мой 896 килобайтовый рамдиск.
DB> Hу все, батенька, придется вам скушать свою шляпу ;)))))))))))))))))))
DB> ;))))))))))))))))))))))))))))))))
Да уж, действительно, Аллах Акбар! ;)
DB> Эффект ищи в мыле, нужно смотреть на PENTAGON.
DB> 760 фреймов=38*20.
DB> Памяти хочет 4 странички, в нижней памяти полтора кило свободно.
DB> Дергается не больше, чем в SC, и не дрожит :)
DB> Сорри за tyap-lyap coding (особенно за "asynchronous unpacking"), за два
DB> дня
DB> лучше не напишешь ;))
Молодец, одно слово. Тебе бы демки писать. ;)
Кстати, а почему зумится за 38 интов, а хотя бы не за 32?
Музыку-то ты, как я понял, выдрал с корнем. ;)
DB> Кстати, я въехал, почему между главными фазами фрактала в SC был "прыжок":
DB> тут фишка в генераторе мандельбротов, а точнее, в параметре "максимальный
DB> индекс". Когда его увеличиваешь, то на доселе черной области фрактала
DB> появляются дополнительные завитушки. Hо нельзя использовать слишком
DB> большой "максимальный индекс" при небольшом масштабе - иначе на краях
DB> фрактала будет перхоть, похожая на ПЗУ. А тот генератор, который ты
DB> юзал, кто-то написал так, что максимальный индекс зависит от масштаба.
Генератор я писал самостоятельно. Максимальный индекс у меня постоянный для
всех фаз фрактала (около 80 или 90, уже не помню). Экспериментировать с ним у
меня не было возможности, т.к. писал я его и генерил фазы для фрактала на
работе (дома у меня только Спектрум), а сам эффект писал и отлаживал дома.
Кстати о птичках. Вот написать бы паковщик не хуже моего, но подходящий по
скорости для распаковки больших текстур.
Bye, Dima.
WBR, Vivid^Brainwave.
DB> В аласме целых 64к памяти под метки (для сверхбольших проектов)
DB> Может, еще передумаешь?
Интерфейс мне аласмовый не нравится.
Bye, Dima.
WBR, Vivid^Brainwave.
IV> внешний вид ;)
концептуальный минимализм :)
разве ктонить жаловался на Генс за его убогий внешний вид? :)
[Wizard Warz] Юриk aka Jerri / Alien Factory /I \
[No RAR allowed] [SoHm] [Концептуальный Минимализм] \ZX/
21 Jan 02 12:07, Vassili Klimov wrote to Dima Bystrov:
VK> а incbin'ы??? с диска постоянно грузить;(
А ты плюсик перед инкбином поставь - будет грузиться только при первой
компиляции.
DB> А ты плюсик перед инкбином поставь - будет грузиться только при первой
DB> компиляции.
ORG'и всякие левые писать... Я обычно в конец исходника все подгрузки ставлю и
обхожусь одним ORG'ом. И пользуюсь старым добрым save object ;-), коего в
аласме испокон веков нет.
JseveN из 4го Измерения...