Просмотр полной версии : Демонстрационные программы для Специалиста
Демки для Специалиста есть, а темы нет, надо исправить это несоответствие.
Для затравки порт демки рисующей лицо похожее на Мону Лизу. Ссылки на варианты для других компов и дополнительную информацию можно найти там (https://zx-pk.ru/threads/21907-demo-effekty-dlya-vektora.html?p=1079122&viewfull=1#post1079122).
К сожалению для Специалиста утрамбовать в 256 байт не получилось, программа занимает 313 байт (rks, понятное дело, несколько больше). Рисование можно сильно ускорить, но это +3 байта, а я выбрал оптимизацию по размеру.
Upd 05.09.2020: Заменил архив на вариант с размером программы 300 байт (rks 306 байт). При запуске из монитора (после загрузки по команде R) надо стартовать командой G80 (не просто G). При загрузке после рестарта или при дропе rks в окно эмулятора запуск будет как обычно.
ivagor, процедуры быстрого рисования нада встроить в монитор
тогда демки маленькие будут размером)
Если разместить всю рисовалку в пзу, то демка сократится до 3 байт
call mona
Сократил Мону до круглой цифры 300 байт.
Скорее всего до размера близкого к 250-260 удастся приблизится с использованием 8080 только на компах у которых есть режим >=4 цвета/точку и (да) в пзу есть процедура рисования точки. Т.е. это ириша, искра-1080, львов пк-01, может еще кого забыл. Некоторая проблема в том, что результат будет похожим на правду только на ч/б телевизоре.
Попробовал допинг в виде z80 для специалистовской версии - по первой прикидке минус 10 байт, наверняка можно сильнее сократить. С 8085 сидел дольше, но там только минус 6 байт и возможность сокращения под большим вопросом.
Upd: Еще корвет забыл в первом абзаце.
Известная демка portret ужатая до 5кб (с 17 кб).
74083
- - - Добавлено - - -
Просто демка в 100 байт.
Мандельброт для цветного (8 цветов) специалиста, также корректно запускается на MX2 из конфига специалиста, 223 байта. Картинку 48x39 (расчет 48x20 + симметрия) строит за 0.85 секунды, что на мой взгляд довольно шустро. Сделал быстро (больше времени потратил в матлабе на прототип), поэтому резервы для ускорения и сокращения есть, но не такие уж большие. До 256 байт есть солидный запас, при желании можно сделать версию для черно-белого специалиста с паттернами вместо цветов. Кстати, неплохо бы в эмуляторах с поддержкой специалиста добавить отображение цветных режимов в оттенках серого, как на ч/б телевизоре (правая картинка).
7659076591
Не то чтобы прям дема, но что-то околодемное в этом есть. Пробуем играть три тональных канала AY (без регулировки громкости) через бипер. С таймером можно сделать с регулировкой громкости, как для вектора. Автор оригинального модуля GENA1K.pt3 (https://zxart.ee/rus/avtory/a/alone-coder/gena1k/) Alone Coder.
Первый запуск из монитора G5000, потом при желании можно повторить через просто G. В эмуляторах можно просто дропнуть в окно, если нужен повтор - G.
Для вывода в ВВ55 используется out, с z80 несовместимо, но для него и таблицу надо другую посчитать. Качество звука лучше в Emu80.
Модернизированный "недоэмулятор AY". Композиция и запуск как в предыдущей версии.
1. Практически убрал призвуки и свист, причем и в Emu и в Emu80.
2. Попытка слегка поуправлять громкостью. Это бипер, не таймер, поэтому не стоит ожидать динамического диапазона как у AY, но что-то похожее на изменение громкости слышно, особенно в финале.
CityAceE
29.11.2023, 20:26
Теперь на векторе безо всяких оговорок есть пример трассировки лучей.
Исходников не будет? А версии под Специалист?
Выложил (https://zx-pk.ru/threads/21907-demo-effekty-dlya-vektora.html?p=1189541&viewfull=1#post1189541) исходник v1.
Для специалиста делать можно для собственного удовольствия, смысл выкладывания на форум близок к 0 (не буду обобщать, это я про себя).
CityAceE
29.11.2023, 21:14
смысл выкладывания на форум близок к 0
С этим полностью согласен, к сожалению.
С этим полностью согласен, к сожалению.
Почему же.
CityAceE
30.11.2023, 19:20
Запустил на реальном компьютере:
https://pic.maxiol.com/thumbs2/1701361128.780858384.rt8080.jpg (https://pic.maxiol.com/?v=1701361128.780858384.rt8080.jpg&dp=2)
Ну, и не упустил возможности запустить на собственном эмуляторе:
https://pic.maxiol.com/thumbs2/1701361198.780858384.rt8080.png (https://pic.maxiol.com/?v=1701361198.780858384.rt8080.png&dp=2)
Не замерял время, но по ощущениям изображение строилось ну ооочень долго.
Наверное, эту тему лучше перенести сюда (https://zx-pk.ru/threads/32189-demonstratsionnye-programmy-dlya-spetsialista.html), поскольку Спец в графике догоняющий другие модели, возможностей у него чуть меньше.
CityAceE
30.11.2023, 21:19
Наверное, эту тему лучше перенести сюда
Согласен! Перенёс.
Ещё могу выложить демки на сайт на эту страницу (http://специалист-пк.рф/index7.html), если автор не против.
Сейчас продумываю как это сделать в смысле оформления.
CityAceE
01.12.2023, 21:41
если автор не против.
Очень надеюсь, что у автора нет поводов быть против ;)
CityAceE
01.12.2023, 22:00
Модернизированный "недоэмулятор AY".
https://youtu.be/HPg35q2abKI
Резюмировал демо программы и собрал на странице (http://www.xn----7sbombne2agmgm0c.xn--p1ai/index7.html).
CityAceE
01.04.2024, 19:31
https://youtu.be/rwnj5e8C1rA
Векторовскую версию уже после конкурса получилось сильно разогнать и этому среди прочего помогло наличие конвертера TXT<->CAS. Если будет подобный конвертер для Специалиста, то можно и на него перетащить оптимизированный вариант. Редактор в бейсике-практик не такой уж плохой по советским меркам начала 90х, но сейчас у меня уже не хватает моральных сил активно работать в нем с программой в несколько десятков строк.
Если будет подобный конвертер для Специалиста, то можно и на него перетащить оптимизированный вариант.
Конвертер есть в одну сторону, выложил вчера вместе с новой версией эмулятора. Собственно, я и вспомнил про этот конвертер, когда захотел посмотреть исходник демы. А вот обратно хуже. Быструю вставку в эмуляторе из буфера обмена я сделал, но пока не на Специалисте :( В общем, надо подумать...
CityAceE
01.04.2024, 22:46
Если будет подобный конвертер для Специалиста, то можно и на него перетащить оптимизированный вариант.
Я мог бы на досуге поэкспериментировать с подобным конвертором на Pyton. Только я не знаю формат хранения текста. И если он нигде не документирован, то сильно помог бы листинг программы с конкурса в текстовом виде. Хотя можно, конечно, и руками набрать.
Распознал с экрана:
1 REM RCTXTSPEC
2 REM BBC MICRO VERSION BY PAUL MALIN
3 REM SPECIALIST VERSION BY IVAN GORODETSKY
4 CLS1
5 CUR0,247:PRINT"X"
6 PLOT8,250,2: PLOT8,252,2
7 PLOT6,255,2: LINE8,255
8 FORU=64T0319
9 E=(U-64)/256-.5:F=.7:N=E*.9-F*.4:0=E*.4+F*.9
10 I=7:J=248
11 L=SGN(N):M=SGN(0):S=1/ABS(N):T=1/ABS(0)
12 E=(-.5*L-(N>0)>*S:F=-(0>0)*T:Y=0:C=1
13 D=E>F
14 IFDTHENH=F:F=F+T:J=J+M:GOT016
15 H=E:E=E+S:I=I+L
16 PLOTI,J,0:P=PEEK(7901)
17 A=-180/H
18 G=0:IFY>=0THENG=Y
19 PLOTU,G,C
20 C=(NOTC)AND3:Y=128+A:IFY>=0THENG=Y
21 LINEU,G
22 IFP=0THEN13
23 B=240/H:2=31AND32*CI+(N+0)*H*,45+J);W=32/(B-A):V=W*(INT(A)-A)
24 IF(7ANDZ)=00R(7AND(2+4)>=0THEN30
25 IFDTHEN28
26 FORK INT(A+128) TOINT(B+128)
27 PLOTU,K,1-((3ANDV)>=0):V=Y+W:LINEU,K:NEXT:NEXT:GOT037
28 FORK-INT(A+128) TOINT(B+128)
29 PLOTU,K,1-NOT((3ANDV)=0):V=Y+W:LINEU,K:NEXT:NEXT:GOT037
30 FORK-INT(A+128) TOINT(B+128)
31 Q=2:R=7ANDV:V=Y+W
32 IFR>3THENQ=Q+4
33 C=C3ANDR)=00R(7ANDQ)=0
34 IFDTHENC=NOTC
35 PLOTU,K,1-C:LINEU,K
36 NEXT:NEXT
37 REM
помог бы листинг программы с конкурса в текстовом виде
В распознанном есть ошибки распознавания.
1 REM RCTXTSPEC
2 REM BBC MICRO VERSION BY PAUL MALIN
3 REM SPECIALIST VERSION BY IVAN GORODETSKY
4 CLS1
5 CUR0,247:PRINT"X"
6 PLOT8,250,2:PLOT8,252,2
7 PLOT6,255,2:LINE8,255
8 FORU=64TO319
9 E=(U-64)/256-.5:F=.7:N=E*.9-F*.4:O=E*.4+F*.9
10 I=7:J=248
11 L=SGN(N):M=SGN(O):S=1/ABS(N):T=1/ABS(O)
12 E=(-.5*L-(N>0))*S:F=-(O>0)*T:Y=0:C=1
13 D=E>F
14 IFDTHENH=F:F=F+T:J=J+M:GOTO16
15 H=E:E=E+S:I=I+L
16 PLOTI,J,0:P=PEEK(7901)
17 A=-180/H
18 G=0:IFY>=0THENG=Y
19 PLOTU,G,C
20 C=(NOTC)AND3:Y=128+A:IFY>=0THENG=Y
21 LINEU,G
22 IFP=0THEN13
23 B=240/H:Z=31AND32*(I+(N+O)*H*.45+J):W=32/(B-A):V=W*(INT(A)-A)
24 IF(7ANDZ)=0OR(7AND(Z+4))=0THEN30
25 IFDTHEN28
26 FORK=INT(A+128)TOINT(B+128)
27 PLOTU,K,1-((3ANDV)=0):V=V+W:LINEU,K:NEXT:NEXT:GOTO37
28 FORK=INT(A+128)TOINT(B+128)
29 PLOTU,K,1-NOT((3ANDV)=0):V=V+W:LINEU,K:NEXT:NEXT:GOTO37
30 FORK=INT(A+128)TOINT(B+128)
31 Q=Z:R=7ANDV:V=V+W
32 IFR>3THENQ=Q+4
33 C=(3ANDR)=0OR(7ANDQ)=0
34 IFDTHENC=NOTC
35 PLOTU,K,1-C:LINEU,K
36 NEXT:NEXT
37 REM
Сконвертировано моим старым конвертером на Паскале, вдруг поможет: https://github.com/vpyk/EmuUtils/blob/master/bsm2txt/bsm2txt.pas
Я мог бы на досуге поэкспериментировать с подобным конвертором на Pyton
Наверняка ты видел, но на всякий случай - можно оттолкнуться от конвертера (https://github.com/svofski/vector06sdl/tree/master/bas2txt) svofski.
И может начиная с моего оффтопа перетащить посты в раздел Специалиста?
CityAceE
02.04.2024, 08:23
В распознанном есть ошибки распознавания.
Действительно! Распознавалка много нулей перепутала с буквой O. Плюс ещё неточности...
Наверняка ты видел, но на всякий случай - можно оттолкнуться от конвертера svofski.
Нет, не видел. Спасибо!
И может начиная с моего оффтопа перетащить посты в раздел Специалиста?
Перенёс.
Для начала вытащил из BASIC-Практик все зарезервированные слова:
CLS
FOR
NEXT
DATA
INPUT
DIM
READ
CUR
GOTO
RUN
IF
RESTORE
GOSUB
RETURN
REM
STOP
DPL
ON
PLOT
LINE
POKE
PRINT
DEF
CONT
LIST
CLEAR
MLOAD
MSAVE
NEW
TAB(
TO
SPC(
FN
THEN
NOT
STEP
+
-
*
/
^
AND
OR
>
=
<
SGN
INT
ABS
USR
FRE
INP
POS
SQR
RND
LOG
EXP
COS
SIN
TAN
ATN
PEEK
LEN
STR$
VAL
ASC
CHR$
LEFT$
RIGHT$
MID$
CIRCLE
MERGE
AUTO
RENUM
RCOM
DELETE
COMP
SYST
EDIT
Кроме токенов от 80h до CEh (CLS - EDIT) есть еще два
CF - & (шестнадцатеричные)
D0 - AT (не реализовано)
CityAceE
02.04.2024, 17:35
Набросал конвертор (https://zx-pk.ru/threads/34692-bejsik-dlya-spetsialista.html?p=1196520&viewfull=1#post1196520). Опубликовал в более подходящей теме. Никуда не заглядывал, всё сделал с нуля так, как я это вижу. Может неправильно подошёл, но у меня вроде работает.
Кроме токенов от 80h до CEh (CLS - EDIT) есть еще два
Это легко добавить. Добавлю в следующей версии, если она будет, конечно.
Спасибо, конвертер позволил быстро портануть разогнанный рейкастер с вектора. Рисует за 3 минуты 13 секунд.
Ещё не нашёл как в BASIC задать имя.
Можно задать через первый REM.
Upd 4.04.2024: RCTXTSPEC3 - 2 минуты 57 секунд
CityAceE
02.04.2024, 20:32
Рисует за 3 минуты 13 секунд.
Ого! :v2_jawdr:Это просто что-то невероятное! Это просто за пределами моего понимания.
Я прямо очень рад, что не зря на конвертер время потратил!
HardWareMan
03.04.2024, 12:29
Набросал конвертор (https://zx-pk.ru/threads/34692-bejsik-dlya-spetsialista.html?p=1196520&viewfull=1#post1196520). Опубликовал в более подходящей теме. Никуда не заглядывал, всё сделал с нуля так, как я это вижу. Может неправильно подошёл, но у меня вроде работает.
За 20 лет методика не меняется, только выбор модного на момент написания утилиты языка погромирования:
https://i.postimg.cc/k5FkDBVn/1.pnghttps://i.postimg.cc/d1sgCwdG/2.png
CityAceE
03.04.2024, 12:47
HardWareMan, так а ссылку на этот конвертер можно? Я бы не связывался, если бы знал, что уже есть готовое.
HardWareMan
04.04.2024, 08:33
HardWareMan, так а ссылку на этот конвертер можно? Я бы не связывался, если бы знал, что уже есть готовое.
Нельзя. Это для личного пользования. Ну и потому, что лично ты, как интересующийся, должен потрогать это сам лично. Ибо я же вижу, что у тебя интерес прям сильный, ролики записываешь, а значит ты обязан разобраться в предмете сам. А с готовыми утилитами не будет ни осознания ни роликов.
Бейсиковский рейкастер (https://zx-pk.ru/threads/32189-demonstratsionnye-programmy-dlya-spetsialista.html?p=1196525&viewfull=1#post1196525) быстрее 3 минут.
CityAceE
04.04.2024, 19:04
Бейсиковский рейкастер (https://zx-pk.ru/threads/32189-demonstratsionnye-programmy-dlya-spetsialista.html?p=1196525&viewfull=1#post1196525) быстрее 3 минут.
Просто восторг! Как обычно, аплодирую стоя! Сравнил картинки первой версии, которая на ~18 минут и быструю. Картинки, действительно имеют слегка уловимые отличия. Но я бы не сказал, что это какое-то ухудшение. На мой взгляд, просто отличие и не более. Или я ошибаюсь, и ради скорости всё-таки пришлось пожертвовать качеством? Если так, то вопрос: можно ли, принеся в жертву скорость, выкрутить качество на максимум? Или первоначальный вариант и есть максимально качественный?
Спрашиваю, потому что я честно пытался изучить код. Даже для понимая пробелы расставил (кстати, доработал свой конвертер, чтобы по ключу можно было лишние пробелы убирать, как у тебя), но ровным счётом ничего не понимаю в нём. Можешь хотя бы намекнуть, где хранится карта?
Сравнил картинки первой версии, которая на ~18 минут и быструю. Картинки, действительно имеют слегка уловимые отличия. Но я бы не сказал, что это какое-то ухудшение. На мой взгляд, просто отличие и не более. Или я ошибаюсь, и ради скорости всё-таки пришлось пожертвовать качеством?
Картинки действительно немного отличаются и я бы тоже не сказал, что быстрая версия рисует более некрасивую картинку (мне даже больше нравится). Качеством ради скорости не жертвовал.
Если так, то вопрос: можно ли, принеся в жертву скорость, выкрутить качество на максимум? Или первоначальный вариант и есть максимально качественный?
Да там и так практически на максимум, если отталкиваться от оригинала и возможностей графики специалиста. Можно нарисовать шире (>256 столбцов). Будет немного дольше (это не смертельно), но что неприятнее - моя хака "перспективной коррекции текстур" не будет работать и придется с этим смирится (как в анимированной версии для вектора) или городить что-то более полноценное. А если не ограничиваться оригиналом, то конечно можно забабахать насыщенные текстуры, наложить спрайты, но для бейсика я считаю это излишествами, и так долго.
Можешь хотя бы намекнуть, где хранится карта?
Признаюсь, что когда впервые увидел оригинал (https://bbcmic.ro/?t=9dcqv), именно этот вопрос заставил меня на некоторое время задуматься. В векторовской версии получилось прикинуться шлангом почти не хуже оригинала, а в специалистовской, как мне казалось, стало слишком очевидно. Нет проблем написать, но интересно, сколько людей догадались?
а что находится по адресу 7901 ?
"16 PLOTI,J,0:P=PEEK(7901)"
что находится по адресу 7901
Это определение цвета точки, аналог POINT.
с таким бейсиком совсем незнаком, но мне кажется в качестве шаблона для построения берётся напечатанный символ `X`
CityAceE
05.04.2024, 10:40
мне кажется в качестве шаблона для построения берётся напечатанный символ `X`
Точно! То, что печатается в левом верхнем углу перед началом рисования и есть карта! И там даже точка обзора показана :) Класс!
На меня такое задание карты произвело впечатление, весьма креативно. На специалисте изображение решетки в знакогенераторе отличается от оригинала (и от вектора) и пришлось дорисовать точки, что не очень изящно, но вариант рабочий.
Пардон, немного обманул. Дело было не в знакогенераторе, а в том, что средствами бейсика нельзя было напечатать X и # с нужным зазором между ними.
Исправил (https://zx-pk.ru/threads/32189-demonstratsionnye-programmy-dlya-spetsialista.html?p=1189875&viewfull=1#post1189875) раейтрейсер, растянул картинку как надо.
CityAceE
02.08.2024, 20:57
lexarr, спасибо! Каждая программа для Специалиста на вес золота!
CityAceE
13.09.2025, 20:44
А как вам такое (https://www.asvcorp.ru/darch/asv/sgidemo/index.html)? ;)
https://www.asvcorp.ru/darch/asv/sgidemo/sgidemo.png
Анатолий Вдовичев пробовал свою дему на реале и видел картинку как на скриншоте, а не как в Emu и Emu80?
CityAceE
13.09.2025, 21:44
Анатолий Вдовичев пробовал свою дему на реале и видел картинку как на скриншоте, а не как в Emu и Emu80?
Я пробовал эту дему и на реале (прямо сейчас крутится), и под эмулятором. У меня всё работает. Возможно, проблема в некорректном RKS. Вот обрезанная и профикшеная версия.
Понятно, а то меня удивил наезд на emu80 (фактически и на emu, т.к. там аналогично), а дело все же было не в эмуляторах.
CityAceE
14.09.2025, 15:44
Привнёс цвета ;)
https://plvideo.ru/watch?v=jJZ4uRLsC6dH
CityAceE
15.09.2025, 10:24
Показал ИИ исходники SGIDEMO. Вот такой вердикт по главной процедуре рисования линии:
; ==================================================
; === ФУНКЦИЯ РИСОВАНИЯ ЛИНИИ: line ===
; ==================================================
; Входные параметры:
; DE = начальная точка (X,Y) — D=X, E=Y
; HL = конечная точка (X,Y) — H=X, L=Y
; Выходные параметры:
; DE, HL — не изменены (сохранены)
; Рисует прямую линию между точками на экране, используя алгоритм Брезенхэма (упрощённый)
; Использует putpixel для отрисовки пикселей.
;
; Примечание: код очень сложный, дублирующийся, с "жёстко закодированными" проверками.
; Не оптимизирован, но работает.
line:
Задача воспроизведения алгоритма Bresenham'а для i8080 решалась уже многократно, и я полагаю, что вылизана "от" и "до". Поделитесь пожалуйста! А за одно интересует реализация рисования окружности и эллипса по его же алгоритму.
Прошу прощения за то, что приведу ссылку на свой пост (https://zx-pk.ru/threads/28977-elita-dlya-spetsialista.html?p=999985&viewfull=1#post999985) со ссылками на две процедуры рисования линий, но в том посте есть комментарии.
Если Брезенхем не обязателен, то окружности и компания (1 (https://zx-pk.ru/threads/29144-programmirovanie-na-assemblere.html?p=989448&viewfull=1#post989448), 2 (https://zx-pk.ru/threads/29144-programmirovanie-na-assemblere.html?p=1200236&viewfull=1#post1200236)).
Еще в прекрасме (https://svofski.github.io/pretty-8080-assembler/) можно нажать на рыбу и выбрать процедуру, но там вроде не всё самое последнее.
А про алгоритм Минчера там есть? Вот тема была: https://zx-pk.ru/threads/25602-algoritmy-risovaniya-okruzhnosti-i-over-1/page2.html
Интересно, что чуть ниже (18-й пост) тоже похожий алгоритм, но без умножения на 4, чуть кривовато, но всё равно окружность.
Из нетрадиционных алгоритмов для окружностей пробовал "метод Jesko" из английской вики, он немного быстрее Мичнера, но при маленьких радиусах менее круглые окружности.
А, ну очень похоже на метод Jesko. Вот, например из вики (с учётом того, что я избавился от переменной t2):
t1 = r / 16
x = r
y = 0
Repeat Until x < y
Pixel (x, y)
y = y + 1
t1 = t1 + y
If t1 >= x
t1 = t1 - x
x = x - 1
А вот из темы по моей ссылке:
t1 = r
x = r
y = 0
Repeat
Pixel (x, y)
y = y + 1
t1 = t1 - y
If t1 < 0
x = x - 1
t1 = t1 + x
Until x < y
Разница лишь в том, что не учитывается 1/16 радиуса, и переменная t1 работает в сторону уменьшения (не от нуля до х, а наоборот). Ну и х уменьшается до использования корркекции t1.
Может это и есть причина "кривоватости" того алгоритма.
- - - Добавлено - - -
Интересно, можно ли так вычерчивать эллипс?
- - - Добавлено - - -
К примеру:
1. доработать алгоритм, чтобы он вычерчивал 1/4, а не 1/8
2. покрутить с константами при увеличении/уменьшении t1
- - - Добавлено - - -
По первому пункту:
t1 = r/2
x = r
y = 0
Repeat
Pixel (x, y)
If t1 >= 0
y = y + 1
t1 = t1 - y
If t1 < 0
x = x - 1
t1 = t1 + x
Until x < 0
- - - Добавлено - - -
function ellipse(r,k) {
let t1=r/2,x=r,y=0;
while(x>=0) {
pset(x,y);
if(t1>=0) { ++y; t1-=y*k; }
if(t1<0) { --x; t1+=x; }
}
}
ellipse(80,4);
ellipse(40,1);
Почему-то коэффициент сжатия нужно удваивать...
- - - Добавлено - - -
function ellipse(r,ky,kx) {
let t1=r/2,x=r,y=0;
while(x>=0) {
pset(x,y);
if(t1>=0) { ++y; t1-=y*ky; }
if(t1<0) { --x; t1+=x*kx; }
}
}
ellipse(40,1,1);
ellipse(80,1,1);
ellipse(80,2,1);
ellipse(80,4,1);
ellipse(40,1,2);
ellipse(40,1,4);
82801
Это проще, чем Мичнер с умножением для эллипса, а с другой стороны алгоритм средней точки без умножения, но там разрядность больше. Для полной ясности надо сравнивать реализации для 8080.
- - - Добавлено - - -
без умножения
в смысле без умножений внутри цикла
в смысле без умножений внутри цикла
Дык окружность тоже без умножения. Мичнер с умножением для эллипса не нашёл.
- - - Добавлено - - -
алгоритм средней точки без умножения
Для эллипса тоже есть?
- - - Добавлено - - -
От умножения в цикле можно избавиться:
function ellipse(r,ky,kx) {
let t1=r/2,x=r,y=0,ty=0,tx=kx*r;
while(x>=0) {
pset(x,y);
if(t1>=0) { ++y; ty+=ky; t1-=ty; }
if(t1<0) { --x; tx-=kx; t1+=tx; }
}
}
От умножения в цикле можно избавиться
Этот вариант мне понравился, только не понял насчет kx. Или я ошибся или kx это коэффициент увеличения по y? А ky - коэффициент сжатия по y?
Ссылки я тут (https://zx-pk.ru/threads/32189-demonstratsionnye-programmy-dlya-spetsialista.html?p=1218309&viewfull=1#post1218309) приводил.
Этот вариант мне понравился, только не понял насчет kx. Или я ошибся или kx это коэффициент увеличения по y? А ky - коэффициент сжатия по y?
Вобщем, это должен быть квадрат коэффициента сжатия (точнее - отношения радиусов) в обоих случаях, но радиус задаётся всегда по оси Х. Получается, kx это коэффициент увеличения по y.
Вот ещё пример:
ellipse(30,1,1);
ellipse(45,1,1);
ellipse(60,1,1);
ellipse(90,1,1);
ellipse(90,4,1);
ellipse(90,9,1);
ellipse(30,1,4);
ellipse(30,1,9);
Потестировать можно тут (https://bashkiria-2m.narod.ru/test2.html).
Вариант быстрый и компактный, особенно если принять kx=1, но в графической библиотеке общего назначения я бы предпочел алгоритм средней точки, там удобно и понятно можно задавать радиусы по x и y.
я бы предпочел алгоритм средней точки
Ага, блин, там такие вычисления (rx * rx * ry * ry), 16-битной арифметики не хватит. Вобщем, "для полной ясности надо сравнивать реализации для 8080" :)
- - - Добавлено - - -
Да, задание радиусов - не очевидно:
for(let x=40; x<90; x+=5) ellipse(x,(x/40)*(x/40),1);
for(let y=40; y<90; y+=5) ellipse(40,1,(y/40)*(y/40));
- - - Добавлено - - -
Во ещё как можно:
for(let x=40; x<90; x+=5) ellipse(x,x/40,40/x);
for(let y=40; y<90; y+=5) ellipse(40,40/y,y/40);
- - - Добавлено - - -
Или так:
for(let x=40; x<90; x+=5) ellipse(x,x*x,40*40);
for(let y=40; y<90; y+=5) ellipse(40,40*40,y*y);
Общая форма ellipse(rx, rx*rx, ry*ry)
Вобщем, "для полной ясности надо сравнивать реализации для 8080"
После того, как реализовал твой вариант, я уже их и сравниваю. Да, средняя точка намного сложнее, больше по размеру и медленнее, для условной элиты непригодно, но по моему мнению лучше подходит для графической библиотеки общего назначения. Хотя скорее так - все зависит от задач.
- - - Добавлено - - -
Общая форма ellipse(rx, rx*rx, ry*ry)
Это я не пробовал на 8080, надо увеличивать разрядность переменных.
А если так: function ellipse2(rx,ry) { ellipse(rx,rx*rx/ry,ry); } ?
А если так: function ellipse2(rx,ry) { ellipse(rx,rx*rx/ry,ry); } ?
Работает и это намного проще средней точки, но при радиусах <=3 получаются ромбы.
- - - Добавлено - - -
Ну и при больших радиусах срединная точка все же покрасивше (https://zx-pk.ru/threads/29144-programmirovanie-na-assemblere.html?p=1200236&viewfull=1#post1200236), для сравнения JeskoB2m:
82802
А JeskoB2m компактнее и быстрее.
Покрутил алгоритм методом проб и ошибок, вот так выглядит вроде лучше (только я не понял, почему):
const ellipse = function(r,ky,kx) {
let t1=(r+kx*ky)/4,x=r,y=0,ty=0,tx=kx*r;
while(x>=0) {
pset(x,y);
if(t1>=0) { ++y; ty+=ky; t1-=ty; }
if(t1<0) { --x; tx-=kx; t1+=tx; }
}
}
Мда, если ky округлять, всё не так красиво. Напрашивается фиксированная точка.
Скорее всего лучше из-за увеличения разрядности t1 с 16 до 24 (ну или 22) бит. Вряд ли я это буду пробовать для 8080, планирую выложить вчерашний вариант, желающие смогут покрутить.
Как тебе такой алгоритм эллипса:
const ellibase = function(r,r2,swap) {
let t=r/2,t1=t,t2=0,x=r,y=0;
while(x>=0) {
if(swap) pset(y,x); else pset(x,y);
if(t1>=0) { if((t-=r2)<0) { t+=r; ++y; } ++t2; t1-=t2; }
if(t1<0) { --x; t1+=x; }
}
}
const ellipse = function(rx,ry) {
if(rx>ry)
ellibase(rx,ry,0);
else
ellibase(ry,rx,1);
}
Тут вообще нет умножения, все переменные, за исключением t1, могут быть 8-битными.
Его, конечно, нужно бы доработать (ставить точку только если было смещение по x или y), иначе эллипс слегка "толстоват" :)
Потестировать можно тут (https://bashkiria-2m.narod.ru/test.html).
- - - Добавлено - - -
за исключением t1
А может и она влезает в 8 бит, всё равно крутится около ноля.
- - - Добавлено - - -
ставить точку только если было смещение по x или y
Простая доработка не помогает, тут надо откладывать рисование на одну/две точки и сравнивать координаты...
CityAceE
16.09.2025, 16:04
Воспользовался процедурой рисования линии, которую предложил (https://zx-pk.ru/threads/21907-demo-effekty-dlya-vektora.html?p=941952&viewfull=1#post941952) blackmirror. Стало всё ГОРАЗДО быстрее, даже удивительно!
https://plvideo.ru/watch?v=xV4aQ47DkHsM
ИИ глядя на эту процедуру, тоже в восторг пришёл, назвав её предельно оптимизированной.
Помимо замены процедуры рисования линии, я расширил холст с 256*192 до 256*256. Автор демки уверяет, что никакого родства со Спектрумом нет, а источников вдохновения послужила демка с IBM PC arty4, написанная на Borland Pascal. Почему был выбран именно такой размер окна он уже не помнит. И вот я подумал, что может быть в прямоугольном окне интереснее фигуры получаются?
Также приложу сюда сразу переделанную под i8080 и SJAsmPlus процедуру рисования линии. Там вроде бы и команд Z80 было раз два и обчёлся, но у меня почему-то слишком много времени заняло, чтобы заставить всё это работать корректно на Специалисте.
align 8
PixMask db 128, 64, 32, 16, 8, 4, 2, 1
SetPix macro
xor (hl)
ld (hl), a
endm
LineTo: ; (hl - x1y1)
ld de, 0x0000
ld (LineTo + 1), hl
Line: ; (hl - x1y1, de - x2y2)
ld a, d
sub h
jp nc, LineGm
cpl
inc a
ex de, hl ; swap p1, p2
LineGm:
ld d, a ; dx
ld bc, PixMask
ld a, 7
and h
add c
ld c, a
ld a, h
or a
rra
or a
rra
or a
rra
add 0x90 + 8 ; Старший байт адреса начала экрана Специалиста
ld h, a
ld a, (bc)
ld b, a
LineDy:
ld a, e
sub l
jp nc, LineXi
cpl
inc a
LineXd:
ld e, a ; dy
sub d
jp nc, LineYd
cpl
inc a
ld (LineXdd + 1), a ; dx-dy
ld a, 0x2D ; dec l
ld (LineXmm), a
jp LineXi1
LineYd:
ld (LineYdd + 1), a ; dy-dx
ld a, 0x2D ; dec l
ld (LineYy), a
ld (LineYyy), a
jp LineYi1
LineXi:
ld e, a
sub d
jp nc, LineYi
cpl
inc a
ld (LineXdd + 1), a ; dx-dy
ld a, 0x2C ; inc l
ld (LineXmm), a
LineXi1:
ld c, d ;cnt
inc c
ld a, d
or a
rra
ld d, a
ld a, b
LineXp:
SetPix
dec c
ret z
ld a, d
sub e
ld d, a
jp nc, LineXpp
LineXmm:
dec l
ld a, b
rrca
ld b, a
jp nc, LineXm
inc h
LineXm:
SetPix
dec c
ret z
ld a, d
LineXdd:
add 0
ld d, a
jp nc, LineXmm
LineXpp:
ld a, b
rrca
ld b, a
jp nc, LineXp
inc h
jp LineXp
LineYi:
ld (LineYdd + 1), a ; dy-dx
ld a, 0x2C ; inc l
ld (LineYy), a
ld (LineYyy), a
LineYi1:
ld c, e ; cnt
inc c
ld a, e
or a
rra
ld e, a
ld a, b
LineYp:
SetPix
dec c
ret z
LineYy:
inc l ; ++y
ld a, e
sub d
ld e, a
ld a, b
jp nc, LineYp
rrca
ld b, a
jp nc, LineYm
inc h ; ++x
LineYm:
SetPix
dec c
ret z
LineYyy:
inc l ; ++y
ld a, e
LineYdd:
add 0
ld e, a
ld a, b
jp c, LineYp
rrca
ld b, a
jp nc, LineYm
inc h
jp LineYm
Как тебе такой алгоритм эллипса
Алгоритм хороший, и если бы не локальные утолщения, то был бы замечательным. Насчет требуемых разрядностей - я сделал 16-разрядными t и t1.
если бы не локальные утолщения
Нет ничего невозможного :)
Вот новый вариант, постарался сделать максимально похожим на алгоритм окружности, чтобы было видно саму идею:
const circle = function(r) {
let t=r/2,x=r,y=0;
while(x>=0) {
pset(x,y);
if(t>=0) { ++y; t-=y; }
if(t<0) { --x; t+=x; }
}
}
const ellibase = function(r,r1,swap) {
let t=r/2,x=r,y=0,t1=t,y1=0,py=0;
while(x>=0) {
py=y1; if(swap) pset(y1,x); else pset(x,y1);
if(t>=0) { ++y; t-=y; if((t1-=r1)<0) { t1+=r; ++y1; } }
if(t<0) { --x; t+=x; if(py==y1 && t>y && t1<r1) { ++y; t-=y; t1+=r-r1; ++y1; } }
}
}
const ellipse = function(rx,ry) {
if(rx>ry)
ellibase(rx,ry,0);
else
ellibase(ry,rx,1);
}
Код выделенным шрифтом убирает утолщения.
Ссылка для тестирования та-же (https://bashkiria-2m.narod.ru/test.html).
Попробуй (64,16) или (16,64). Для этих случаев картинка чуть изменилась, но утолщения на концах остались.
Нет, в этом алгоритме (со "сплющиванием" окружности) похоже совсем идеальный эллипс не нарисовать.
Идеальный вот:
const ellipse = function(rx,ry) {
let ky=rx*rx/ry;
let t=rx*rx/6,x=rx,y=0,dx=rx*ry,dy=0;
while(x>=0) {
pset(x,y);
if(t>=0) { ++y; dy+=ky; t-=dy; }
if(t<0) { --x; dx-=ry; t+=dx; }
}
}
- - - Добавлено - - -
В целых числах (но тут третья степень радиусов):
const ellipse = function(rx,ry) {
let kx=ry*ry,ky=rx*rx;
let t=ry*ky/6,x=rx,y=0,dx=rx*kx,dy=0;
while(x>=0) {
pset(x,y);
if(t>=0) { ++y; dy+=ky; t-=dy; }
if(t<0) { --x; dx-=kx; t+=dx; }
}
}
Вероятно я ошибся в реализации, у меня на картинке занижает радиус по y.
Или дело в потере дробной части
В js нет потери дробной части, но когда радиус по оси Х маленький, то тоже занижает. Странно, видимо, особенность алгоритма.
А вот с утолщениями нормально.
- - - Добавлено - - -
Могу только предложить идею с перестановкой координат из второго варианта (со сплющиванием).
Могу только предложить идею с перестановкой координат из второго варианта (со сплющиванием).
Это помогло.
Единственный недостаток по сравнению со средней точкой - "Jeskoвые" ромбы при самых маленьких радиусах, зато при больших красиво. Этот вариант получился средний по красоте, размеру и скорости между этой (https://zx-pk.ru/threads/32189-demonstratsionnye-programmy-dlya-spetsialista.html?p=1218333&viewfull=1#post1218333) твоей модификацией Jesko и средней точкой. Теперь есть из чего выбрать.
CityAceE
17.09.2025, 21:53
Подробности здесь (https://www.asvcorp.ru/darch/asv/demo2009/index.html).
https://www.asvcorp.ru/darch/asv/demo2009/screen.png
Прямая ссылка (https://www.asvcorp.ru/darch/asv/demo2009/VSCROLL.RKS) на скачивание RKS.
На мой субъективный взгляд в такой беспощадной рванине мало смысла, это тяжело смотреть и еще тяжелее получать какое-то удовольствие. Есть 2 основных варианта борьбы с разрывами:
1. Выравнивание кода до кратности кадру + ручная подстройка, как здесь (https://zx-pk.ru/threads/30001-spetsialist-grafika.html?p=996126&viewfull=1#post996126) (кстати, теперь это работает и в emu и в современных версиях emu80). Таким макаром можно выводить (очень простую, состоящую из повторяющихся в столбце блоков 8x6) динамическую картинку разрешением примерно до 2/3 спековского экрана (256x128 или близко). Пример того, что можно реализовать - первый эффект из векторовской демы From Sunset To Dawn (https://caglrc.cc/scalar/ware/16/). Основной ограничивающий фактор - сложно поддерживать постоянный период выполнения кода по мере его усложнения.
При наличии таймера очевидно все резко упрощается, один раз подстроились в начале, потом пользуемся без особых ограничений.
Забыл сразу написать про второй ограничивающий фактор - сейчас существуют клоны специалиста с отличающимися параметрами развертки. Тут все зависит от желания и возможностей по отладке, или можно поддержать один самый распространенный вариант или те варианты, к которым есть доступ.
2. Не полное устранение, а уменьшение заметности разрывов. 1) Построчный (не постолбцовый) вывод из теневого буфера, 2) бОльшую часть картинки должны занимать однородные (сплошные черные или белые) участки. Пример реализации такого подхода - jet set. Ну и тут неприятная зависимость - чем меньше FPS, тем реже разрывы.
А что, если таким образом выводить текст? Понятно, что символы не 6х8, а 8х10, но всё же. Я думаю ускорение будет заметно. Какой-нибудь скроллер забабахать. Шрифт, правда, в два раза распухнет...
Powered by vBulletin® Version 4.2.5 Copyright © 2025 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot