Gigascreen

On Speck there is a subject hardware modification (2 flicker-free screens are combined)
what principle does it work on? As I understand it, we need to speed up fetching
data from memory by 2 times. Doesn't this cause memory slowdown? Or is the subject -
is it just an interlaced output of screens 1 and 2?

Maybe someone has a diagram of it?

Which port does it turn on?

Bye, All.
WBR, Vivid^Brainwave.

AM> unite) on what principle does it work? As I understand it, we need to speed up data retrieval from memory by 2 times
AM>. Doesn't this cause slowdown in working with
AM> memory? Or the subject is just an interlaced output of 1 and 2
AM> screens?

───────────────────────────── 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 Jun 98 00:03:00

To : All

Subj : ?=?

────────────────── ────────────────────── ────────────────────── ──────────────────
Good afternoon All, if not, then turn on the light. :-)

Here I was sitting, there was nothing to do
and I decided to come up with something.
GIGASCREEN!
-----------
I've watched a lot of demos here.
In many screens they blink to get more colors.
And then I thought.
-Why not do this in hardware.
And he did it using the interglaze method, that is, the blinking of the image stopped.
And bit 4 in port #EFF7 is free, so I hung it on it.

And here is the diagram forPENTAGONа.
----------------------------

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: When buying a computer, buy a soldering iron for it! :-) (2:5026/18.44)
────────────────────────────── end of g_screen.W
────────────────────────────── ─

December 01, 2001 you pressed the buttons, and I drank coffee and read:

AM> On Speck, the subject hardware modification (2 flicker-free screens
AM> are combined) on what principle does it work? As I understand it, we need to speed up data retrieval from memory by 2
AM> times. Doesn't this cause slowdown
AM> in working with memory? Or is the subject just an interlaced
AM> output of screens 1 and 2?

AM> Maybe someone has a diagram of it?
there is, only for the Pentagon
AM> Which port is it turned on through?
It seems through #EFF7

Bye, Aleksey, I wish you a lot of luck and a dacha by the sea ;-) ...

RA9...@LAND.RU ICQ 112172827

01 Dec 01 12:41, Aleksey Malov wrote to All:

AM> On Spec, the sabzhe hardware modification (2 screens without flickering
^^^^^^^^^^^^^^^^^^^^^^^^
AM> are combined) on what principle does it work? As I understand it, we need to speed up data retrieval from memory by 2
^^^^^^^^^^^^^
AM> times. Doesn't this cause slowdown
AM> in working with memory? Or is the subject just an interlaced
AM> output of screens 1 and 2?

The fact of the matter is that all this is fake, nothing is united there, the screens
still flicker, only not through the frame, but through the line. This can be done programmatically
.

AM> Maybe someone has a diagram for it?

Yes.

AM> On Spec, the subject hardware modification (2 flicker-free screens
AM> are combined) on what principle does it work? As I understand it, we need to speed up data retrieval from memory by 2
AM> times. Doesn't this cause slowdown
AM> in working with memory? Or is the subject just an interlaced
AM> output of screens 1 and 2?

Interlaced. G)

AM> Maybe someone has a diagram of it?

:) Yes.

Sun 2 Dec 2001, at 00:27:52 Kirill Frolov told Aleksey Malov about Gigascreen

KF> The fact of the matter is that all this is fake, nothing is united there, the
KF> screens still flicker, only not through the frame, but through the line. This and
KF> can be done programmatically
KF>.

For example, we did this in Stellar Contour. Pheel (honor and praise to him) drew a beautiful two-screen picture for
this purpose.

AM> On Spec, the subject hardware modification (2 screens without
AM> flicker are combined) on what principle does it work? As I
AM> understand, it is necessary to speed up data retrieval from memory by 2 times.
AM> Doesn't this cause a slowdown in working with memory? Or is the subject -
AM> just an interlaced output of screens 1 and 2?

AM> Maybe someone has a diagram of it?

NP> Alexey, install Lara 4.6 for yourself! :)))))))))))))))))

Why? What is it about it that 4.5 can’t do? If only autodetection
of cities, then I don’t really need this canoe, since the upper memory under my
ram disk is used.

NP> If you please send me something, only for LEHINGRAD 2, or explain
NP> the theory of how Gigascreen works!

Looks like one line is taken from one, and the other from another screen.

NP> + Origin: Don't f#ck yourself. This is why God created girls. (2:467/81.30)

Hmm. I'll take note. ;)

Bye, Nick.
WBR, Vivid^Brainwave.

NP> If you can share something with me, only for LENINGRAD 2, or explain the theory
NP> of how Gigascreen works!

To the author! 2:5026/51.12 Dmitry Pugachev.

AM> It looks like one line is taken from one, and the other from the other screen.

No, the colors of the two screens are simply mixed, just like when switching
each int of two screens, only without flickering.

Bye!
Pa...@nm.ru www.realsoft.hotbox.ru [RC 2.0] [Real Software]

PK> No, the colors of the two screens are simply mixed, just like when switching
PK> every int of the two screens, only without flickering.

The circuit is in the studio. If what you said is true, then the video circuit's access to
memory should occur 2 times more often, because you need to read 4 bytes at once
(attribute and pixels from 2 screens at once).

Bye, Pawel.
WBR, Vivid^Brainwave.

AM>> screen.
PK> No, the colors of the two screens are simply mixed, the same as when
PK> switching every int of two screens, only without flickering.
No. One line is scr0, the second is scr1, etc.

Bye, Pawel! >>.. tigr...@mail.ru >>.. http://brainwave.dax.ru

AM>> screen.
PK> No, the colors of the two screens are simply mixed, just like when
PK> each int of the two screens is switched, only without flickering.

Nothing can be mixed in small logic. Everything as AM wrote.

PK> No, the colors of the two screens are simply mixed, just like when switching
PK> every int of the two screens, only without flickering.
there is flickering. But its degree depends on various factors: what colors are on
the screens, how old the TV is used, etc.

In Stellar Contour and in our 4k (Sabotage) Gigascreen is implemented in software,
by the way...

JseveN from the 4th Dimension...

16 Dec 01 *12:36*, _*Aleksey Malov*_ ·─═ */Pawel Kislyak*/:

AM> Scheme for the studio. If what you said is true, then the
AM> video circuit accesses to memory should occur 2 times more often, because you need
AM> to read 4 bytes at once (attribute and pixels from 2 screens at once).
Sorry for interrupting the conversation. I haven’t read it from the beginning.
I wanted to ask, is there a scheme for the subject for Scorpio?

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> In Stellar Contour and in our 4k (Sabotage) Gigascreen is implemented in software,
VK> by the way...

An interesting feature: hardware and software subjects together neutralize
each other friend.

Bye, Vassili.
WBR, Vivid^Brainwave.

IT> No. One line is scr0, the second is scr1, etc.
and next. the frame is the opposite - scr1, scr0, scr1, etc.

The only joke is that it is impossible to programmatically determine in which
frame which lines are visible;). This can only be checked visually, i.e. with
the help of the user. I became interested in this question immediately after the publication of the 1st
version of rules with Enforce, where the organizers “threatened” to attract demo makers
to write effects for the subject. But, this visual control, which needs to be done every time you start, and constant monitoring slow down the use of the subject in demos. The software implementation, although not simple, is more universal - there are still more Pentagons than computers equipped with Gigascreen (although installing a subject is much easier than removing the wait feature;).

In connection with this question. As far as I understand, there are basically 2 categories of wait computers: 1) Leningrad-like ones - the processor slows down anywhere in the beam when executing an odd-clock command; 2) proprietary ones - the processor is slowed down only when the beam passes across the screen and does not depend on the number of clock cycles of the current command (by the way, in this case the wait is not generated, but CLK is disabled). So, here’s the question:), I’m interested in whether the above information is correct (special doubts
on point 2) and whether it’s possible to somehow find out whether, say, ld
a,(hl), performed30 thousand cycles after the interrupt arrives, how many cycles will it slow down, etc. In short, is it really possible to make a software
emulator of a branded computer?

JseveN from the 4th Dimension...

IP> Sorry for interrupting the conversation. I haven’t read it from the beginning.
IP> I wanted to ask, is there a scheme for the subject for Scorpio?

No idea. To be honest, I don’t work with iron. ;)

Bye, Ivan.
WBR, Vivid^Brainwave.

VK> and next. the frame is the opposite - scr1, scr0, scr1, etc.

It’s strange that when Igor assembled it for himself, each frame was the same. And only
when double screen was used in demos or anywhere else, the flickering decreased.

VK> Will say ld a,(hl), executed 30 thousand cycles
VK> after
VK> the arrival of the interrupt, be slowed down, how many clock cycles will it slow down, etc. In short
VK> is it really possible to make a software emulator of a branded computer?

What’s stopping you from inserting a setup in which you can control the number of cycles in a
line and synchronization relative to the beginning of the frame? Of course, for dynamic
multicolors, in which the effect is calculated in parallel with the subject, this
canoe will not help, but when displaying static gigascreen images, it is quite
possible to tune in to any computer, regardless of its waitness.

Bye, Vassili.
WBR, Vivid^Brainwave.

AM> An interesting feature: the hardware and software subjects together neutralize
AM> each other.
but not in your demo, where the screens do not change through the frame, i.e. always
even lines from one screen and odd lines from the other. Or am I wrong?
Taking this opportunity, I want to express respect for the implementation (as far as I understand
for the first time) of multicolor 4x1, although you have 30 acquaintances, but you can do 32
without problems.

JseveN from the 4th Dimension...

AM> And what prevents you from inserting a setup in which you can control the number of
AM> clock cycles in a line and synchronization relative to the beginning of the frame? Of course, for
AM> dynamic multicolors, in which the effect is calculated in parallel with
AM> the subject, such a canoe will not help, but when outputting static gigascreen
AM> pictures, it is quite possible to tune in to any computer, regardless of its
AM> waitness.
That’s the point, what is needed for the effects, without wasting a lot of clock cycles (of which
there are so few) on unnecessary tuning ldir. In short, the point is that the entire effect is
divided into small procedures and it is calculated in advance how many of them
to cram in before and after multicolor. If you are interested in details, write to the soap.

JseveN from the 4th Dimension...

AM>> neutralize
AM>> each other.
VK> but not in your deme, there the screens do not change through the frame, i.e.
VK> always
VK> even lines from one screen, and odd lines from the other. Or am I wrong?

Nope. In the first frame I have scr0,scr1,..., and in the second - scr1,scr0,...

VK> Taking this opportunity, I would like to express respect for the implementation (as far as I
VK> understand
VK> for the first time) multicolor 4x1, although you have 30 acquaintances in X, but you can also do
VK> 32
VK> without problems.

Multicolor not 4*1, but 4*4, i.e. 0 and 2 lines are equal, 1 and 3 lines are also equal.
But you can achieve the display of 36 different colors, or 2 translucent
8-color bitplanes.
This is not the first time this has been implemented... This happened first in Eye Ache-2, then in Anamnesis.
However, in both cases gigascreen (i.e. changing even and odd lines of a 4*4 block) not
used.
As for the width: in effects where multicolor and a regular picture are mixed in X, I have 32 familiar spaces (but this is implemented practically for free).

32 familiar spaces in width can be made: in eyeache2 this is done, BUT: there the output
goes through

ld hl, xx
push hl

so there are clocks for everything enough. This method is good for static images.
I am not at all happy with it, since my image is first
built in a Munky (from the word multicolor chunky) buffer, which hasquite normal structure - 1 byte = 1 munk. Then the munks are recoded into attributes (54 clock cycles per pair of munks).

The multicolor hatch itself could have been torn out from the anamnesis, but:

1. Stealing is not good.
2. Multicolor from anamnesis works normally if the beginning of the int fluctuates slightly, which is quite suitable for most 2D effects. Those. made a halt,
drew a multicolor, calculated part of the 2D effect, halt again, etc. When drawing 3D, you have to hang multicolor on ints. Since halts are no longer used (for example, when drawing polygons an interruption can easily occur), the beginning of the int can jump +-20 cycles. As a result, multicolor desynchronization will be noticeable in the corners of the screen. Therefore, we had to
combine 3 output methods at once:
pop hl:ld (),hl
popa:pusha
ld hl,nnn: push hl

Moreover, during the upper border, instead of nnn, specific attributes are substituted
from framebuffer.

═══════════════════ MCOLOR .t ══════════════════

popld - macro pop hl:ld (),hl

Innerloop multicolor.

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> is the essence of what is needed for effects, without wasting a bunch of cycles
VK> (of which
VK> are already few) on unnecessary trimming ldir. In short, the point is that the entire
VK> effect is divided into small procedures and it is calculated in advance how many
VK> of them to cram in before and after multicolor. If you are interested in details, write to
VK> soap.

Yes, in principle, I used a similar canoe in Stellar Contour, only there everything was even
more confusing. For example, during the upper border I had music playing (the player always consumed 861 bars). In almost all
multicolor 3D effects, after the image in the framebuffer
was formed, I set a special checkbox, and the intelligent procedure
seeing this, cleared the background during the top border and under the multicolor (in the texture cube I also zoomed in on the background texture, in lens flares according to the lookup table (half of which was in the screen area, but was not visible on the pentagons) built the inside of the sphere and re-encoded
munks into attributes took place). In general, I tried to squeeze out the maximum benefit from the 7-8 thousand clock cycles that were left from the upper border (the transfer of data from the framebuffer to the ld hl, nn:push hl command area for multicolor output still took some time). Naturally, in one frame suchIt was not possible to do “useful” work
in almost all effects, so some of it was postponed until
the next frame. For example, in lens flares, recoding munks into attributes and rendering the sphere took a total of 5 frames (hung, of course, on
interrupts). So, each frame had to be manually synchronized,
and all this was done through deep ()(). Perhaps I was more perverted with the code only in multicolor doom.

The funny thing is that all the multicolor 3D effects in SC (except for doom) were
written in about a week and a half. In general, it was a hot time, the computer was glitching from the heat, and I slept little. So a situation could well have arisen where we would not have had time to assemble the demo. And on that lousy Kai or on 128 Pentagon, which were on CC, I
could not have been able to assemble a demo. I need a ramdisk for these purposes, because the source code even
from it took 20 seconds to compile (doom in the final version
compiled in 30 seconds).

By the way, about Lifeforms. Vortex and I decided to take a look at why the bump was so slow there, and, to put it mildly, we were shocked: Cyrus screwed up there so badly! I
could only expect this from Phantom Lord - 92 clock cycles to calculate a chunk!
By the way, you can do it at a speed of 95 clock cycles for a PAIR of chunks with absolutely
the same appearance. True, this will require a little more memory, but
speedthe calculation is almost 2 times higher! In general, I can only understand Cyrus because he wrote the demo in a hurry and did not have enough time for this kind of optimization.

Bye, Vassili.
WBR, Vivid^Brainwave.

17 Dec 01 14:22, Vassili Klimov wrote to Aleksey Malov:

VK> but not in your demo, there the screens do not change through the frame, i.e.
VK> there are always even lines from one screen, and odd lines from the other. Or am I wrong
VK> right? Taking this opportunity, I would like to express respect for the implementation
VK> (as far as I understand for the first time) of multicolor 4x1, although you have 30 acquaintances in X
VK>, but you can do 32 without problems.

10.5 cycles per byte, 32 bytes == 336 cycles per line. In reality there are
only 224 clock cycles.
Information needs to be updated for 7 of the 8 lines. It just doesn't work out. Or are there two
screens
used? Well then 6 out of 8. :-/

KF> Information needs to be updated for 7 out of 8 lines. It just doesn't work out. Or are there
KF> two screens
KF> used? Well then, 6 out of 8. :-/

Vasily just didn’t get it. There is no 4*1 multicolor. I have 4*4 multicolor everywhere there. And what he took for 4*1 is the same 4*4, only 0 and 2
lines are the same and 1 and 3 lines are also the same.

2 screens are used.

Well, multicolor 1 pixel high can be done for a maximum window 20
width wide.

Bye, Kirill.
WBR, Vivid^Brainwave.

KF> 10.5 clock cycles per byte, 32 bytes == 336 clock cycles per line. In reality there are
KF> only 224 clock cycles.
KF> Information needs to be updated for 7 out of 8 lines. It just doesn't work out. Or are there
KF> two screens
KF> used? Well then, 6 out of 8. :-/
there it is enough for 3 lines in a row to have different colors, i.e.:
col1 - 0th line of the familiar place
col2
col1 \
col2 - what, in fact, is not multicolor 4x1 ?
col3 /
col4
col3
col4 - 7th line familiar places

JseveN from the 4th Dimension...

AM> Nope. In the first frame I have scr0,scr1,..., and in the second - scr1,scr0,...
why then does “garbage” appear on the screen in some effects on non-pentagons?

AM> Multicolor is not 4*1, but 4*4, i.e. Rows 0 and 2 are equal, rows 1 and 3 are also
AM> equal. But you can achieve the display of 36 different colors, or 2
AM> translucent 8-color bitplanes.
see message 2KF
AM> This is not the first time this has been implemented... This happened first in Eye Ache-2, then in
AM> Anamnesis.
AM> However, both have gigascreen (i.e. changing even and odd lines of the
AM> block 4*4)
AM> was not used.
well, mcolor 4x4 is a classic...

AM> the output goes through
AM> ld hl, xx
AM> push hl
in EA2 (as far as I understand you are talking about slide show) it was done in a very unclear way -
the output code is modified, apparently depending on the next Y color

AM> so there are enough clock cycles for everything. This method is good for static
AM> pictures.
AM> It doesn’t suit me at all, since my image is first
AM> built in a Munky (from the word multicolor chunky) buffer, which has
AM> a completely normal structure - 1 byte = 1 munk. Then the munks are
AM> recoded into attributes (54 clock cycles per pair of munks).
you did not understand my idea;) the effect is 100% calculated in advance, not includingoutput
multicolor and then each interrupt is automatically clogged (before and after
mcolor output) as if in small pieces of code. Those. you write an effect,
debug it and then install Call Adress commands wherever possible, then
each user runs the installer and the output table is _automatically_ generated.
All that remains is to launch the demo and enjoy the multicolors. By the way, for
widespread computers you can leave ready-made tables.

AM> 2. Multicolor from anamnesis works normally if the beginning of the int fluctuates slightly
AM>, which is quite suitable for most 2D effects. Those. did
AM> halt, drew multicolor, calculated part of the 2D effect, halt again, etc.
AM> When drawing 3D, multicolor has to be hung on ints. Since
AM> halts
AM> are no longer used (for example, when drawing polygons
AM> an interruption can easily occur), the beginning of the int can jump +-20 clock cycles. Using the installer, this problem automatically disappears. By the way, on
computers with software controlled turbo it will be possible to speed up calculations without breaking
multicolor

AM> MCNF0 ld sp,#3131
AM> L0_0 EQU $-2
AM> exx
AM> pop ix,iy,bc,de
AM> pop hl:exx
well, that’s it ^^^^^^^^^^^ no one thought of it before

JseveN from the 4thMeasurements...

VK> you did not understand my idea;) the effect is 100% calculated in advance, without including
VK> multicolor output and then each interrupt is automatically clogged (before and
VK> after mcolor output) as if in small pieces of code. Those. you write an effect,
VK> debug it and then put the Call Adress commands wherever possible, then
VK> each user runs the installer and the
VK> output table is _automatically_ generated. All that remains is to launch the demo and enjoy the multicolors. By the way
VK> for widespread computers you can leave ready-made tables.

That is. do you propose to calculate x lines of effect before multicolor, y after, z
before multicolor in the next int, etc.? This trick won't work with 3D.

AM> Yes, in principle, I used a similar canoe in Stellar Contour, only there
AM> everything was more confusing. For example, during the upper curb I
AM> played music (the player always consumed 861 bars). In almost all
AM> multicolor 3D effects, after the image in the
AM> framebuffer was formed, I set a special checkbox, and the
AM> intelligent procedure, seeing this, cleared the background during the upper border and under the
AM> multicolor (in the texture cube, I also zoomed in the texture
AM> of the background, in lens flares by the lookup table (half of which was located
AM> in the
AM> area of the screen, but was not visible on the pentagons) built the inside of the
AM> sphere and recoding of munks into attributes took place). In general, I tried
AM> to squeeze out of those 7-8 thousand clock cycles that remained from the upper border
too tricky, especially for debugging

AM> for a total of 5 frames (hung, of course, on interruptions). So, each
AM> frame
AM> had to be manually synchronized, and all this was done through
AM> deep
AM> ()(). Perhaps, I was more perverted with the code only in multicolor doom.
but here my method will not help ;)

AM> The funny thing is that all the multicolor 3D effects in SC (except for doom) were
AM> written somewhere ina week and a half. In general, it was a hot time, the computer was glitching from the heat, I slept little. So a situation could very well arise that we would not have time to collect the demo
AM>. And on that lousy Kai or on 128 Pentagon, which were
AM> on CC, I would not have been able to assemble a demo. I need a ramdisk for these purposes, because
Kaya has a ramdisk

AM> By the way, about Lifeforms. Vortex and I decided to look at why
nAM> bump
AM> was so sluggish, and, to put it mildly, we were shocked: Cyrus screwed up so bad there!
AM> I could only expect this from Phantom Lord - 92 clock cycles to calculate a
AM> chunk!
AM> By the way, you can do it at a speed of 95 clock cycles for a PAIR of chunks with
AM> absolutely the same appearance. True, this will require slightly more memory
AM>, but the calculation speed is almost 2 times higher! In general, I can understand
AM> Cyrus only because he wrote the demo in a hurry and did not have enough time for this kind of optimization
AM>.
the saddest thing is that first he first draws the entire C2P buffer, and then
a sprite is superimposed using a mask and even with attributes...

JseveN from the 4th Dimension...

VK> the saddest thing is that first he draws the entire C2P buffer, and
VK> then
VK> a sprite is superimposed using a mask and even with attributes...

That is. Are the attributes re-applied there every time? Horror!

In general, a Cyrus bump that works for 6-7 int can be done for 4
int.

Bye, Vassili.
WBR, Vivid^Brainwave.

18 Dec 01 17:18, Aleksey Malov wrote to Kirill Frolov:

AM> Well, multicolor 1 pixel high can be done at most for a window
AM> with a width of 20 spaces.
For 24 it is also possible.
ZX-Guide #2 has the source.

- Alone Coder [team ZX-Guide]

AM> That is. do you propose to calculate x lines of effect before multicolor, y after,
AM> z before multicolor in the next int, etc.? This trick won’t work with 3D.
ok, I’ll write it in detail now;)
We have an effect cycle (approximately):
1. buffer cleaning, etc.
2. calculations
2.1. rotation of points
2.2. projections
2.3. calculation of visible edges, sorting
2.4. drawing edges
3. all sorts of blurs, etc.
4. C2P (regular pixel chunks)
5. switch screens, go to step 1
The corners are hanging on the ints.
We debug the effect, insert Call Adr into each cycle, compile
monky2planar instead of C2P, add multicolor output (as a separate procedure), run
the installer.
The installer has at the input:
1) compiled effect - without multicolor output
2) offset in measures from the beginning of the int for multicolor output and number of measures
after output until the end of the int (if there is a software turbo, then we multiply the last number by 1.3-1.7)
The installer works like STS, only in addition it counts clock cycles (between the specified
Calls). The result is approximately the following table:
frame1: number of Calls from the beginning of the int to drawing mcolor, offset in clock cycles before
drawing mcolor, number of Calls until the end of the int
frame2: similar - and so on for the entire effect
The manager in the demo itself will be like this:
Adress ld a,nn:dec a:ld (Adress+1),a:ret nz
Tab_adr ld hl,tab:ld a,(hl):inchl: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
There remains one problem - what to do with variables hanging on interrupts,
I have some ideas, but maybe I’ll come up with something smarter.

AM> bump like this

Has it already been completed and released to the people? If yes, then please throw it
in the echo, otherwise I only saw it on a cassette and then not completely.

On this mustache. Bye, 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> ok, I’ll describe it in detail now;)
VK> We have an effect cycle (approximately):
VK> 1. clearing the buffer, etc.
VK> 2. calculations
VK> 2.1. rotation of points
VK> 2.2. projections
VK> 2.3. calculation of visible edges, sorting
VK> 2.4. drawing edges

That's the whole point: drawing a triangle with a texture can take
a lot of cycles, especially if the face is large (for example, 1-2 ints). And if
it is not broken down into several smaller subtasks (calculating displacements, drawing
each line, etc.), then nothing will come of it.

VK> 3. all sorts of blurs, etc.
VK> 4. C2P (regular pixel chunks)
VK> 5. switching screens, going to step 1
VK> They hang on the ints corners.
VK> We debug the effect, insert Call Adr into each cycle, compile
VK> monky2planar instead of C2P, add multicolor output (as a separate procedure),
VK> run the installer.

So, interesting...

VK> The installer has at the input:
VK> 1) compiled effect - without multicolor output
VK> 2) offset in clock cycles from the beginning of the int for multicolor output and the number of bars
VK> after the output to the end of the int (if there is a software turbo, then the last number
VK> is multiplied by 1.3-1.7)

This is understandable.

VK> The installer works like STS, only in addition it counts bars (between
VK> the specified Calls). The result is something like this table:
VK>frame1: number of Calls from the beginning of the int to drawing mcolor, offset in clock cycles
VK> before drawing mcolor, number of Calls until the end of the int

Again, the drawing of one polygon may not fit either before or
after multicolor. You'll either have to insert dynamic breakpoints into the procedure itself
(the most hemorrhoidal part), or give up on this idea.

VK> frame2: similarly - and so on for the entire effect
VK> The manager in the demo itself will be like this:
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> There is one problem left - what to do with variables hanging on interrupts,
VK> there are some ideas, but maybe something more clever I'll come up with an idea.

If you implement 3D in multicolor, and precisely according to this idea, I will put you in first place for this alone (if I
vote). Just tell me, why isn’t it easier in multicolor 3D to calculate in advance the coordinates of the output polygons in each frame and then simply draw in real time (under multicolor hanging on ints)triangles?
The speed will be faster. And there are fewer hemorrhoids. ;)

DB> For 24 it’s also possible.
DB> There’s a source in ZX-Guide #2.
I looked it up just now, it’s really cool;), but why isn’t this in any demo
? I'll have to try using this mode in some 3D effect.

PS: what is t(c)s doing there, didn't you put a screw on the controller?

JseveN from the 4th Dimension...

AM> Again, the drawing of one polygon may not fit into multicolor,
AM> or after. You will either have to insert dynamic breakpoints
AM> into the procedure itself (the most hemorrhoidal part), or give up on this idea.
you need to either cram in more of these Calls, or let the installer arrange them himself - at first I wanted to do this, but it may
turn out that the Call will be inside a short loop and the installer will not
know how many iterations have passed and how many are left - i.e. there will be an error in the table

AM> If you implement 3D in multicolor, and precisely according to this idea, I will put your
AM> in first place for this alone (if I do
ha;), but how will you determine this, by speed?
In general, with this approach you can write a bunch of multicolor outputs, and besides
in an arbitrary place on the screen or even with dynamic movement, that's
only this will need to be fixed under non-wait, and 2 types of wait computers.
By the way, the question about the possibility of fixing under a branded computer is still open.

AM> vote). Just tell me, isn’t it easier in multicolor 3D
AM> to pre-calculate the coordinates of the output polygons in each frame and then
AM> just draw only
AM> triangles in real time (under multicolor hanging on ints)?
AM> The speed will be faster. Yes andless hemorrhoids. ;)
I don’t agree. Firstly, it will be relatively slow, because you can’t use time
to multicolor, and if you use it in conjunction with my method, then
the volume of left data increases and after a couple of effects you will have to go to the disk.
Secondly, (for some this is a very sore point;) they will again start shouting that
this is a complete anima. Although it’s difficult to say this about 3D, frequent access to the
disk is a clear sign of animation (or a large amount of pre-calculated
data).

VK> is this where the water zooms? there you can see how the flash jumps on the cube

And there too. Even in Tryptomine Dream on Fong's bun you can see sometimes the left
pixels skip.

VK> CJ came up with something like: pop hl:jp (hl):ex de,hl:ld (hl),n:inc h...:ex
VK> de,hl
VK> I don’t remember exactly;-), faster than the standard one, but slower (but it eats up less memory
VK>) than 82t.

SerzhSoft came up with the following (takes up 8 kilobytes and can easily sit in
the second half of page 7):
Chunks have numbers from #e0 to #fe (even):

#e070
l00:
ld h,a ;a - st. address byte in screen
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
...

Instead of n, you can enter b, c, d or e, previously storing #00, #ff, #aa and
#55 in them, respectively.

As a result, the speed on some pairs of chunks can reach 70 clock cycles per
pair of chunks, if all values are taken from registers.

This canoe takes up, IMHO, even less than CJ's.

Bye, Vassili.
WBR,Vivid^Brainwave.

DB> There is a source in ZX-Guide #2.

We should take a look...
HO:
ld sp,nnn ;10
rept 10
ld hl,nn:push hl ;10*21=210
endr
nop
=============
224 tact.

Either it was done somehow crookedly, or one of two things.

Bye, Dima.
WBR, Vivid^Brainwave.

JseveN from the 4th Dimension...

SK> Has it already been completed and released to the people? If so, please throw
SK> in the echo, otherwise I only saw it on cassette and not in full.

The post-party version of Placebo was not released and, it seems, will not be released, although
planned. The fact is that Placebo currently has some project, Cyrus
is busy with “don’t play around.”

If necessary, I can ask the moderator via netmail (someone remind me of the address)
permission to post the party version of the demo in the echo in small pieces.

Bye, Slavka.
WBR, Vivid^Brainwave.

Thu 20 Dec 2001, at 23:57:25 Vassili Klimov told Vassili Klimov about
Gigascreen

VK>> less) than 82t.
VK> I caught up a little :). In fact, C2P is like this:
VK> inc e:pop hl:ld l,(hl):jp (hl)
VK> and ld h,d:ld l,e:ld (hl),n:inc h:...:jp (ix)
VK> invented CJ&BG (c), first used in jaundice

70 + 8 + 15 = 93 tact.
Memory also takes up about 8 kilobytes, like SerzhSoft's (with ret:jr),
used for the first time in C2H5OH1,2, and subsequently brazenly torn out by me
(the decrementer, however, I wrote myself. But SerzhSoft's innerloop) and used
in Technogen in a somewhat optimized form.

Bye, Vassili.
WBR, Vivid^Brainwave.

V> We should take a look...
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 tact.

V> Either it was done somehow crookedly, or one of two things.
Not every attribute line changes there, but only 6 out of 8 (the top 2 are at the beginning
of the interruption). And not only PUSH is used. It all starts and ends with
commands like LD (...), rp.
Throw source soap?

AM> I have never seen the Exploder one. Once I corresponded with him, he
AM> said that he had perspective correction applied there (why is it in
AM> chunks
well... here he drives, IMHO
AM> it’s needed, besides on the Spectrum). What did Exploder have in the source code?
yes standard: a,h:add hl,de:exx:b,h:add hl,de:c,a:a,(bc):exx:ld (bc),a:inc c

AM> A a'
AM> ooo
AM> o ooo
AM> o ooo
AM> o ooo
AM> o ooo B
AM> o ooo
AM> ooo
AM> C

AM> Notice that segment AB is flat, and its topmost line Aa' has
AM> length
AM> 3 pixels. If necessary, then somehow I’ll sort out the sources and throw in my
AM> procedure
it’s still not clear why the formulas are different :-)

JseveN from the 4th Dimension...

AM> The post-party version of Placebo was not released and, it seems, will not be released, although
AM> was planned. The fact is that Placebo now has some project, Cyrus
AM> is busy with the “don’t play around” thing.
on ZX, I hope?

AM> If necessary, I can ask the moderator by netmail (someone
AM> please remind me the address)
AM> permission to post the party version of the demo in the echo in small pieces.
maybe it’s better not to underdo...

JseveN from 4th Measurements...

VK>>> less) than 82t.
VK>> I caught up a little :). In fact, C2P is like this:
VK>> inc e:pop hl:ld l,(hl):jp (hl)
VK>> and ld h,d:ld l,e:ld (hl),n:inc h:...:jp (ix)
VK>> invented by CJ&BG (c), first used in jaundice

20 Dec 01 19:11, Aleksey Malov wrote to Vassili Klimov:

AM> SerzhSoft came up with the following (takes up 8 kilobytes and can easily
AM> sit in the second half of page 7): Chunks have numbers from #e0 to #fe
AM> (even):

AM> #e070
AM> l00:
AM> ld h,a ;a - st. address byte in screen
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> Instead of n, you can enter b,c,d or e, having previously stored in them
AM> #00,#ff,#aa and #55, respectively.
What is this SerzhSoft? This is a real Monster/Sage.
See. article in Born Dead #5, or link in ZX-Guide #3, or review of ZX-Guide in #4

VK> on ZX, I hope?

No, at work. And his girlfriend also demands attention. ;) Paracels hasn't seen him for about a month.

VK> nope, 2 times less

Hmm.. Indeed, 2 times less.. In principle, SerzhSoft's version, although it takes up 8 k
, there are "holes" there that can also be used for something...

Bye, Vassili.
WBR, Vivid^Brainwave.

VK> it’s still not clear why the formulas are different :-)

Well, for example, when we draw the upper half of a triangle, along the edge AC
the offset along X is equal to (C.X - A.X)/(C.Y - A.Y), and along the edge
AB = (B.X - A.X + 1)/(B.Y - A.Y + 1), moreover, you need to scan not along edge
AB, but along edge a'B, i.e. along the left edge we walk along the left border, and along the right
edge we walk along the right border.

Otherwise (when everything fits the same comb), then the triangle can
turn out like this:

A
o
ooo
o oooo
o oooo
o ooo B
o ooooО
o
C

You see how Does the triangle look dark? Because of such a canoe, it may
happen that holes between the polygons will be generally visible, as in Hell Raiders
by Die Krupps (however, for them this may be connected with something else, but
the possibility is not excluded).

Bye, Vassili.
WBR, Vivid^Brainwave.

Fri 21 Dec 2001, at 21:54:30 Dima Bystrov told Aleksey Malov about Re:
Gigascreen

DB> What kind of SerzhSoft is this? This is a real Monster/Sage.
DB> See the article in Born Dead #5, or the link in ZX-Guide #3, or the review of ZX-Guide in
DB> #4

Monster has not ret: JR nn, but ret: JP nn, which gives a gain of 2 clock cycles, but
occupies 16 kilobytes. Serge takes 8 kilobytes, but runs 2 clock cycles slower. Although, of course, Serge probably used Monster's idea.

I don't need to talk about BornDead, I read that article. ;)

Bye, Dima.
WBR, Vivid^Brainwave.

22 Dec 01 14:17, Aleksey Malov wrote to Dima Bystrov:

AM> Monster has not ret:JR nn, but ret:JP nn, which gives a gain of 2
AM> clock cycles, but takes up 16 kilobytes. Serge takes 8 kilobytes, but
AM> runs 2 clock cycles slower. Although, of course, Serge probably
AM> used Monster's idea.
Well, imagine: I came up with a super-duper high-speed procedure for withdrawing
chunks. So, this means: there are chunks with numbers
#c0, #c2, #c4, #c6, #d4, #e2, #f0, #fe
And everything is the same as above, but chunk handlers #c6, #d4, #e2, #f0, #fe
do not contain the JR command. It's easy to see that I overtook the Monster by 5.5 clock cycles :)
So, now I'm a cool coder? Where are the monuments placed here? ;)
Or here's an idea: a transparent chunk containing only INC L:RET
You can use such chunks only on every second frame, or on all
frames. You will get a very interesting video effect :)
Probably, you can even rotate 3D on top of the picture like this.
Similarly, translucent chunks: only 2 lines out of 4 are filled.
What I mean is that the main idea is.

- Alone Coder [ZX-Guide] [AC Edit]

Tue 25 Dec 2001, at 22:58:04 Dima Bystrov told Aleksey Malov about Re:
Gigascreen

DB> Well, imagine: I came up with a super-duper high-speed output procedure
...
DB> So, now I'm a cool coder? Where are the monuments placed here? ;)

You will erect a monument to yourself at your own expense. ;)))

DB> Or here's an idea: a transparent chunk containing only INC L:RET
DB> You can use such chunks only on every second frame, or you can use it on
DB> all
DB> frames. You'll get a very interesting video effect :)

DB> Probably, you can even rotate 3D on top of the picture like this.

It's too late to rush around. Already multicolor 3D on top of the picture (though translucent) was spun. And the chunky star on top of the picture was spinning back in
RIZC by Extreme in 2000. ;)

DB> Similar to translucent chunks: only 2 lines out of 4 are filled.

The idea is not new. Back in 98, such chunks were used, albeit for interlaced
motion blur.

DB> What I mean is that the main idea is.

For example, in Stellar Contour the following was used for the first time:

1. Translucent multicolor on top of the picture.
2. Multicolor motion blur.
3. Multicolor 3D
4. Multicolor "doom".

So what? Some people have given up on multicolor and continue to do so. ;)) I, in
principle, don’t care. I write as best I can and don’t point another finger.

The output of chunks itself is not the main thing. Muchharder to write the effect itself.
Bye, Dima.
WBR, Vivid^Brainwave.

I wanted to say that Monster came up with an original method.
Although the stack call was used back in 1985 at Technology Research :-/
But that’s not why it was used there ;)

AM> For example, in Stellar Contour it was used for the first time:
AM> 4. Multicolor “doom”.
by the way, there are interesting thoughts on this issue...
2 J7N: you are also invited to discuss :)

AM> So what? Some people have given up on multicolor and continue to do so. ;))
Those who don't work, those also ^^^^^^^^^ :)

AM> The output of chunks itself is not the main thing. It is much more difficult to write the
AM> effect yourself.
Of course, plus for speed, the output of chunks should be selected
according to the effect. It is best if the chunks are output directly in the main
loop,
but this is not always possible.
Which c2p for 2 chunks in 1 byte is currently considered the fastest?

By the way, please specify what kind of inner loop you had for scaling
"fractal".

DB> For those who don’t work, those also ^^^^^^^^^ :)

It doesn’t work for me on my scorpion. So I don't do that. ;))

DB> Which c2p for 2 chunks in 1 byte is now considered the fastest?

DB> By the way, please clarify what kind of inner loop you had for scaling
DB> “fractal”.

Patience, my friend, and patience again! The article in which I described my
implementation of effects (together with ZXASM sources and their compiled
variants) can be seen in Scream-#2, whose release was delayed only
because of my article. :((5-6 days ago Megus sent them the sources of 4 of my
effects (they are zipped, if sclerosis serves me right, about 120
kilobytes).
Sources of the following effects:

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)

The Free directional tunnel algorithm is also described.

Well, if you are still interested in innerloop zooming, then there is not just one, but as many as 28
or 27 (I don’t remember exactly ;)) Here is one of them. them:

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>> scaling the “fractal”.
AM> Patience, my friend, and patience again! The article in which I
AM> described my implementation of
AM> effects (together with ZXASM sources and their
AM> compiled versions)
AM> can be seen in Scream-#2, whose release was delayed
AM> only because of my article.
AM> :(( 5-6 days ago Megus sent them the source codes of 4 of my
AM> effects (take up in zipped
AM> form, if sclerosis serves me right, about 120 kilobytes).
AM> Sources of the following effects:
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)

Sorry, I'm a complete novice in the above-described effects, but
I really want new overlays for Zasma.

But not with my feet, I won't do it anymore ;)

Excuse me the date...

AM> The Free directional algorithm is also described. tunnel.
AM> Well, if you are still interested in the innerloop of zooming, then there is not just one of them, but as many as 28
AM> or 27 (I don’t remember exactly ;)) Here is one of them:
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>> The fact is that Placebo now has some kind of project, Cyrus is busy with
AM>> the most “don’t play around”.
SK> Are the details unknown?

The placebo people themselves haven’t seen Cyrus for more than a month (he’s work, girl,
iron door at the entrance). The project is nearing completion. I won’t
tell you the details.

AM>> remind me) permission
AM>> to post the party version of the demo in the echo in small pieces.
SK> It would be nice.

I won’t throw it away. Because Few people need this. It’s better to ask people you know from St. Petersburg
Ask.

Bye, Slavka.
WBR, Vivid^Brainwave.

Tue 1 Jan 2002, at 02:30:16 Mihail Zharov told Aleksey Malov about Re:
Gigascreen

MZ> Big sorry, I'm a complete novice in the effects described above, but
MZ> I really want new overlays for Zasma.
MZ> Just not with my feet, I won't do it anymore. ;)

I don't like writing under "black boxes". If I have no choice on PC, then on
Speccy I write everything from scratch. I haven’t used someone else’s ready-made procedures for 3-4 years (TRDOS ones don’t count). If I need to write something, I
write from scratch. Even when Tigra wrote some little thing for the demo, I rewrote it almost completely. I know that this is wrong, but I
don’t want to rewrite ZXASM from scratch... Besides, we have different projects now...

MZ> May the date excuse me...

Come on, I’m already sober. ;)

Bye, Mihail.
WBR, Vivid^Brainwave.

AM> Are there any doubts about the real-time calculations? Wait for Scream-2, there
AM> the source code for this effect will be there.
No, there is an idea to simplify the algorithm.
What percentage of your time does scaling + transferring to the screen take?
Well, or at least how many clock cycles per pixel?
In my Wolf it takes more than half the time. Maybe set the scaling
to multicolor and the rest outside?

AM> Patience, my friend, and patience again! The article in which I described
AM> my implementation of effects (together with ZXASM sources and their
Why don’t you use ALASM?
AM> compiled versions) can be seen in Scream-#2, whose
I would like to see the first issue ;(

AM> Phong shading and mapping environment (from Tryptomine Dream)
Without multicolor is not interesting ;))

03 Jan 02 00:10, Dima Bystrov wrote to Aleksey Malov:

DB> ld a,(hl)
^^^^^^^^^
DB> inc l/nop
DB> ldi
MAMA! What's wrong with me??? When out of 3 teams there is one extra one - this is really bad ;(
It seems that I ate something wrong for the New Year%)
In general, the moral is this: why is Mandelbrot not fullscreen?

DB> No, there is an idea to simplify the algorithm.
DB> How much time does it take for you to scale + transfer to
DB> the screen?
DB> Well, or at least how many clock cycles per pixel?

In my case, the rays are traced until they intersect with the wall, and the edges are not drawn right away.
It’s not possible to calculate it differently in parallel with multicolor.

DB> In my wolf - more than half time. Maybe set
DB> scaling
DB> to multicolor, and the rest outside?

Generally speaking, it takes about 1600 clock cycles to calculate one column in the buffer,
i.e. taking into account delays, 8 lines (1792 clock cycles) are drawn. Of these,
120-550 cycles are spent on column scaling, and the rest on
trace/delay. Tracing speed is about 85 clock cycles per card block. The scaling speed is about 12-20 clock cycles per pixel.
Throwing a frame buffer onto the screen takes the same amount of time as
it takes to draw 16 familiar places - 224*8*16 clock cycles:
rept 32
pop hl
ldi
endr

DB> MAMA! What's wrong with me??? When out of 3 commands there is one extra one - this is really bad
DB> ;(
DB> It seems I ate something wrong for New Year %)

Well, I didn’t understand either... ;))

DB> In general, the moral is this: why is Mandelbrot not fullscreen?

Now let’s figure it out... Here’s an innerloop:
ldi
nop/inc l

suitable for zooming bitmap 1 pixel/byte. And then you will need to
recode munky into attributes.
For fullscreen zooming, the bitmap must be 4 times larger than the window size.
i.e. 128*96 (for a 64*48 window). It would take up 12 kilobytes. You need
as many as 2 buffers => 24 kilobytes must be placed in the lower memory.
Zooming one line - 64 pixels will take 64*20 = 1280 clock cycles. 1280 * 48 lines
= 60000 cycles per zoom. Then recode it into attributes. You can't do it in one frame. And I have 50 fps in the effect.

Bye, Dima.
WBR, Vivid^Brainwave.

AM> Well, I didn’t understand either... ;))
Well, this related to the previous letter (about zoom)

AM> Now let’s figure it out... Here’s an innerloop:
AM> ldi
AM> nop/inc l

AM> suitable for zooming a bitmap of 1 pixel/byte. And then it will be necessary
Not only. It is also suitable for 2 pixels/byte
imagine that your texture is not stored like this:
%00000aaa %00000bbb %00000ccc
but like this:
%00aaabbb %00bbbccc %00cccddd etc
Is it clear now?
The scaling accuracy is not 100%, but not by eye note.

AM> still recode munky into attributes.
And there is no need to recode, everything is already broken down into bits :)
AM> For fullscreen zooming, the bitmap
AM> should be 4 times larger than the window size. those. 128*96 (for window
AM> 64*48). It would take up 12 kilobytes. You need 2 buffers

03 Jan 02 12:22, Aleksey Malov wrote to Dima Bystrov:

AM> I'm using a Zoom rotator, I just didn't allow it to go beyond the limits of the texture
AM> 128*128, limiting the amplitude of the swing. But there I didn’t do the output
AM> of polygons, so going beyond the limits was simply impossible.
And I did the same, but this is not a radical solution... How was it done in Illusion (Sonic part)
?

AM> In ACEdit, save the setup, otherwise I don’t like the default one.
AM> ;))
with v0.59 there is a saving of the setup with buttons SS/S, so I don't know anything :)
do you want to be a beta tester? I'll fail v0.60 :)

AM> My rays are traced until they intersect with the wall, but not immediately the edges
AM> are drawn.
No brainer! It’s the same in Wolf :)

AM> In general, it’s like this: it takes about 1600
AM> clock cycles to calculate one column in the buffer, i.e. taking into account delays, 8 lines are drawn (1792
AM> clock cycles). Of these, 120-550 clock cycles are spent on column scaling, and
AM> the rest is spent on tracing/latency. Tracing speed is about 85
AM> clock cycles per card block.
in Wolf only every second column is traced, interpolation between them.
do you trace through division? I have a step-by-step
inc a
add hl,bc
jr c/nc,zax
add iy,de
jr c/nc,zay
...
The battery accumulates a rough distance to the wall, and thenclarified
by the dichotomy method ;)
AM> Scaling speed is about 12-20
AM> clock cycles per pixel.
um...

[ld d,.../inc d]
[ld a,(de)]
ld (hl),a ;wall
inc h
...
...
ld (hl),c ;floor
inc h
...

right? I thought about this method...
but since this thing should hang on multicolor, then the slowest one from N scaling procedures is selected, and the rest should slow down to its level.

AM> Throwing a frame buffer onto the screen takes
AM> the same amount of time as it takes to draw 16 familiar places -
AM> 224*8*16 clock cycles: rept 32 pop hl ldi endr
well, that's understandable.
only ld (hl),...:inc l:ret will be faster
it turns out that the rest of your time is spent on ray tracing???
probably a slow algorithm!
And with a fast algorithm it would be like this:

frame#1:
1)scale
2)scale+multicolor
3)off-int calculations

frame#2:
1)c2p
2)c2p+multicolor
3)off-int calculations

if there was not enough time for off-int calculations, then
frame#3 appears:
1)dummy c2p
2)dummy multicolor
3)off-int calculations

on off-int and the trace would hang, so IMHO it’s easier...

AM> So after all, it came out in the summer.
So they don’t distribute it ;(

AM> My card is stored like this - 2 texels in one byte. Speed
AM> increase - no more than 54 clock cycles per pair of pixels. Store 1 pixelin
AM> 1 byte was not allowed due to lack of memory, because I have 2 buffers, and
AM> each 128*64. 4k per buffer. Plus page 7 must be active,
AM> because the magnification goes directly to the screen. I already have N number of scaling
AM> procedures.
I approximately answered there in another message...

AM> How is it that:
AM> ld a,(hl)
AM> inc l/nop
AM> ldi
AM> can perform scaling? ld a,(hl) why is it necessary?
That’s the point, it’s not necessary %)
I was lying there yesterday, you know, even falling asleep, suddenly bam - the thought: “what kind of nonsense am I
just sent it to the echo... where did the third team come from???”
So I wrote a second letter, a refutation, so to speak. :)

AM> The placebo people themselves haven’t seen Cyrus for more than a month (he has a job, a girlfriend,
AM> there’s an iron door at the entrance). The project is nearing completion. I won't
AM> tell you the details.
is the project at least for ZX?

JseveN from the 4th Dimension...

DB> No, you know what kind of demo maker I am... I only get to implement
DB> system
DB> programs ;)
that's it, but you read the ZX-GUIDE and start spitting: why write the best possible
implementation of this or that effect and in addition provide semi-source codes
that you don’t know whether they will work? Try to write at least some kind of demo - in the process you will simply forget about optimization both in terms of speed and size. The main thing is to finish it. The same opinion is shared by CJ (I hope he will write you a letter)
- algorithms/ideas without implementation are not worth much.

As for my projects, they were completed literally in the last hours before
departure, that’s why the quality is so ;-).

JseveN from the 4th Dimension...

28 Dec 01 17:46, Dima Bystrov wrote to Aleksey Malov:

DB> Which c2p for 2 chunks in 1 byte is now considered the fastest?
Okay, let's pose the question differently:
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
primitive.
plus limit to 255.
Like faster?

VK> project at least on ZX?

In general, Cyrus will soon become a father. The girl is 8 months pregnant.
;))

Nothing like that. I was just joking ;)). Cyrus will not become any kind of father in the near future, unless, of course, he takes proper precautions. ;) The project,
of course, on ZX. I also made my small contribution to this matter at the request of
Paracels.

Bye, Vassili.
WBR, Vivid^Brainwave.

Fri 4 Jan 2002, at 02:29:14 Dima Bystrov told Aleksey Malov about Re:
Gigascreen

AM>> suitable for bitmap zooming 1 pixel/byte. And then it will be necessary
DB> Not only. It is also suitable for 2 pixels/byte
DB> imagine that your texture is stored differently:
DB> %00000aaa %00000bbb %00000ccc
DB> but like this:
DB> %00aaabbb %00bbbccc %00cccddd etc
DB> Now is it clear?
DB> Scaling accuracy is not 100%, but not noticeable by eye.

I need to show the picture _reduced_ by 2, 1.95,... 1.05, 1 time. You
tell me: is it possible to do this using ldi/inc or not?

As for the scaling accuracy: implement it first, and then perceive it by eye. Even with accurate scaling, twitching is visible after
half a second when images are replaced.

DB> this is really a problem :-/
DB> but it can be solved - if you scale the even lines (2nd screen) from the page to the
DB> buffer, and transfer the buffer to the 7th page - roughly speaking, plus 10000
DB> clock cycles.
DB> we have clock cycles a lot...

Maybe....

DB> well, that’s understandable.
DB> only ld (hl),...:inc l:ret
DB> it turns out that the rest of your time is spent on ray tracing???
DB> is probably a slow algorithm!

For me, tracing and scaling are performed in parallel: the
column was traced and scaled. During this time, 8 pixel
lines were drawn. Because I don’t have time to do this in 4 pixel lines.

DB> And with a fast algorithm it would be like this:

DB> frame#1:
DB> 1)scale
DB> 2)scale+multicolor
DB> 3)off-int calculations

My tracing goes in parallel with the multicolor output, i.e. in the body
tracer I am switching screens.

DB> frame#2:
DB> 1)c2p
DB> 2)c2p+multicolor
DB> 3)off-int calculations

DB> if there was not enough time for off-int calculations, then
DB> frame#3:
DB> 1)dummy c2p
DB> 2)dummy appears multicolor
DB> 3) off-int calculations

DB> to off-int and the trace would hang, so IMHO it’s easier...

I don’t see the perversion. Time is wasted on c2p + multicolor.

In addition, my entire lower border is free. It was planned to start scrolling there along the lower curb. But I didn’t have time to do it, I had to score.

Bye, Dima.
WBR,Vivid^Brainwave.

AM> In general, Cyrus will soon become a father. The girl is 8 months pregnant.
AM> ;))
well, that’s mine, and you have jokes, sir;)))) It’s good that Sairoos doesn’t read this echo.

AM> Nothing like that. I was just joking ;)). Cyrus will not become any kind of father in the near future, unless, of course, he takes proper precautions. ;) Project
AM> naturally, on ZX. I also made my small contribution to this matter at the request of
AM> Paracels.
buzz, it smells like something new...

JseveN from the 4th Dimension...

DB> since v0.59 there is a saving of the setup with the SS/S buttons, so I don’t know anything :)
DB> do you want to be a beta tester? I'll fail v0.60 :)
no matter how hard I searched, I couldn't find it

JseveN from the 4th Dimension...

Sat 5 Jan 2002, at 13:28:42 Vassili Klimov told Aleksey Malov about Gigascreen

VK> well, that’s mine, and you have jokes, sir;)))) It’s good that Sairoos doesn’t read this echo.

Oh well, so what. Can't you make a joke? ;)

04 Jan 02 16:00, Vassili Klimov wrote to Dima Bystrov:

VK> just about there, but you read ZX-GUIDE and start spitting: why write how
VK> you can implement this or that effect more coolly and in addition bring
VK> semi-source codes that you don’t know will work? Try
VK> to write at least some kind of demo - in the process you will simply forget about
VK> optimization both in terms of speed and size. The main thing is to finish it. This
VK> opinion is shared by CJ (I hope he will write you a letter) -
VK> algorithms/ideas without implementation are not worth much.
Yes.

VK> No matter how much I searched, I couldn’t find it
1. Load AC Edit
2. You get into setup
3. Are you correcting any parameters
4. Without leaving SetUp, press Symbol Shift and at the same time S
:)))

05 Jan 02 11:05, Aleksey Malov wrote to Dima Bystrov:

AM> I need to show the picture _reduced_ by 2, 1.95,... 1.05, 1 time.
Reduced? I understand you :)
AM> Tell me: is it possible to do this using ldi/inc or not?
It’s better not to try ;)
It turns out that there is a faster and better method:
LD L,...
LD D,(HL)
LD L,...
LD E,(HL)
PUSH DE

if the stack is busy, then LD L,...:LDI

I just don’t know if this is possible call it realtime ;)

two textures (one is used, the other is generated) lie in the same
memory areas: one in #xx00-#xx7f, the other in #xx80-#xxff. 24k.

AM> As for the accuracy of scaling: implement it first, and then by eye
AM> perceive it.
I’m telling you, yesterday (01/06/2002) I checked it with my personal eye :)
AM> Even with accurate scaling, twitching is visible after
AM> half a second when images are replaced.
I noticed this in Stellar, I don’t understand why this is so happens ;(
The picture itself twitches a little, probably the increment
generator is not quite set up. At first I had the same thing in the intro to ZG4.

DB>> (Sonic part)
DB>> was done?
AM> The simplest way: do y or #80, then there will be no going beyond the texture limits
AM>. You can’t do it every time, but only when necessary. However,
AM> Dmitry Lomov lives here in the echo. He should know.
How was it done there?

AM> interpolation.
AM> I have each column traced.
Then here you have lost a little in speed.

AM> I jump straight through the map block, checking each time whether it is empty or
AM> not? I also have a projection of the beam onto the camera axis, from which I
AM> determine the distance to the wall and, as a consequence, the size of the column.
AM> Sometimes I have to use the clock procedure of multiplying a byte by a word to calculate the intersection point 204
AM>.
It’s clear. For me, perspective correction only affects the step size - the step for
the leftmost column and for the rightmost one is taken from the table of sines, and
intermediate ones are interpolated. Multiplication and division are not used.

The disadvantage of your method: you cannot implement doors.

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))))
Let's borrow :)
Your copyright?

DB> Not... lazy, I’d rather clean up the glitches in ACE ;)
DB> But, in principle, do you agree that fullscreen could have been possible?

Let’s do the math:

The bottom border takes up 40-24-10=6 character lines. One familiar
line is drawn in 1792 clock cycles. Consequently, 6 lines are drawn
in approximately 10800 clock cycles. Let our music player always run at the same time and we call it during the top border. Total: we have
11 thousand clock cycles free. If we increase one fractal phase in 32
ints (in SC - 28 ints), then to unpack the fractal phase we have
32*11000 = 352 thousand clock cycles for unpacking 6 kilobytes of texture (we will then unpack them into 12 kilobytes). This means that unpacking one byte of texture and
decreasing it into 2 bytes (for your innerloop zooming) should take
about 60 clock cycles.
In Stellar Contour, unpacking four kilobytes of texture without further
decreasing it 2 times. It takes 28*11000 = 308 clock cycles, i.e. 297/4 = 75
cycles per byte. And this is almost end-to-end (After unpacking a texture
on the Pentagon, there are about 8 thousand clock cycles left before unpacking the next texture (On
poorly packed textures - about 2-3 thousand, or even no clock cycles left at all). So, 75 clock cycles just for unpacking. Add here about 30 clock cyclesby
"expansion" of the byte with the texture, plus we'll slow down the unpacker a little, because It unpacks for us not in a single block of 4k, but in lines of 64 bytes. Total: this is
150*6000 = 900000/11000 = 80 ints for zooming one phase by 2 times. Let me just say that even when zooming 2 times at a speed of 37-38 ints, the single-frame feeling is not so strong. And with 80 ints, a 2x zoom will look like zooming at
a speed of 25 fps.

Moreover, texture buffers require as much as 24 kilobytes of lower memory, and in
Stellar Contour I have only 8.

If you store textures in pages unpacked, then 4 pages
will fit about 10 phases, which at a zoom speed of 32 ints per 2x zoom will give us 320 ints, i.e. 6.5 seconds of effect. And in Stellar Contour I have 30 kilobytes
of data, enough for 756 ints of single-frame zooming at a speed of 28 ints per
zooming of one phase. Those. with half the memory consumption, we have more than twice the duration of the effect.

Maybe, of course, I’m slowing down, but it’s impossible to write a packer and unpacker for 8 color
textures that would pack data 2-3 times and unpack one byte noticeably
faster than in 70 clock cycles on the Spectrum.

In general, I don’t yet see any worthy competitors for my multicolor
fractal zooming in a 60*32 window.

Dima, this is just an example of how little it is to write a quick innerloop. It's necessaryStill
think about whether it will satisfy the restrictions imposed on the memory occupied by
tables and buffers. After all, I didn’t immediately write fractal zoom out of the blue. I figured out how much memory the zooming internal loops would consume, where I should place them, and what kind of data packer I needed. By the way, for real-time
packing/unpacking of data, I first wanted to use RIP, but it unpacked 4
kilobytes (with 11 thousand free clock cycles at the end of the int) for about 120-150 ints. The crunch gave a result of about 70-80 int. Then I wrote my own packer for 8-color textures, which did not pack very well and unpacked
not fast enough - in about 45-50 ints. Then I once again wrote a packer, which compressed some (about 50%) textures better than hrust, and packed them at a speed of 4 kilobytes in 0.8 seconds and unpacked 4 kilobytes in 26-27
ints (with 11 thousand clock cycles remaining for unpacking). It was used during the final packing and unpacking of textures. You can even estimate the average
compression rate:
27 textures, each 4 kilobytes in unpacked form, occupy 108 kilobytes.
After packing with my packer, they occupy about 30.5 kilobytes. There is a packing of 3.5 times, which is not so bad, considering the high speed of unpacking.

So, writing a zoom fractal will probably be more difficult than giving birth to a hedgehog. ;))))

Bye,Dima.
WBR, Vivid^Brainwave.

AM>> there will be no texture. You can’t do it every time, but only when
AM>> necessary. However, Dmitry Lomov lives in the echo here. He should
AM>> know.
DB> How was it done?

This part is not mine, so I don’t know the specifics.
Some sources have been preserved, but this part is missing :(

All the best.
Dmitry. [ZX] [Quake]

np: Rage against the machine - Wake up

DB> Then here you lost a little in speed.

You see what’s the matter. There is no reason for me to trace through a column, because... I don’t have time to trace one column in 896
cycles. Sometimes this takes up to 1000 cycles. Plus 570 clock cycles for texture scaling. I just manage to complete the time
of drawing 8 lines. And if I just traced 32 columns, then in order
to keep within 896 clock cycles, I would have to reduce the tracing range
by at least 2 blocks (or even by all 3), and this is not good. Or trace under
multicolor (this would take just int 2). Then scaling 64 columns - 32 rows... Hmm. It would probably be possible to get it done in 2 ints. But
there is one thing BUT! If I trace through one column, then what should I do when I need to draw the i-th column with texture A, and the i+2nd column with texture B.
What texture should I draw the i+1st column and which column in the texture should I
draw? Will it look too crooked in multicolor? I mean
when the trace goes through one column?

08 Jan 02 20:55, Aleksey Malov wrote to Dima Bystrov:

AM> I found it, I just need to extract it. What kind of stupid habit is it to break one
AM> section into several messages? Lara doesn't understand this. There is no need to resend
AM>. I'll ask Megus to extract ACEdit 0.60 on PC.
It's strange, I only sent _one_ message :-/
By the way, a new fix has been released, so tell me directly how often you need to send them
and in what pieces ;)

AM> You see what's the matter. There is no reason for me to trace through a column, because
AM> I don’t have time to trace one column in 896 clock cycles.
I suggest moving the tracing to _OFF-INT_ to avoid hemorrhoids with
adjusting the tracing time.
AM> Sometimes it takes
AM> up to 1000 clock cycles to do this. Plus 570 clock cycles for texture scaling. Just
AM> I manage to complete the drawing time of 8 lines. And if I just
AM> traced 32 columns, then in order to keep it within 896 clock cycles, I
AM> would have to reduce the tracing range by at least 2 blocks (or even
AM> by all 3), and this is not good. Or trace under multicolor (on
AM> it would take just 2 ints).
Also a method :)
But it’s more complicated :(
AM> Then scaling 64 columns -
AM> 32 familiar place lines... Hmm. In 2 ints, probably, it would be possible
AM> to do it. But there is one BUT! If I tracethrough one column, then
AM> what should I do when I need to draw the i-th column with texture A,
AM> and the i+2nd column with texture B. What texture should I draw the i+1st
AM> column and which column in the texture should I draw?
Take the texture from the column on the left, and get the column number by interpolation (you can
even check for such a bummer: me, for example, in this case the number of the column
texture is repeated)
AM> Wouldn't it look too crooked
AM> in multicolor? I mean, when the trace goes through one
AM> column?
Completely unnoticed. This was the case in all three demo versions of Wolf, and there
the horizontal resolution differs from multicolor by only one and a half times.
In the first demo it is generally the same :)

AM> And when a collision with a wall occurs, how do you determine the height
AM> of the column?
I “multiply” (shift, that is, ;)) by a coefficient and get a step in the texture. And
you can already scale :)
AM> I store all the displacement in the map in advance (for each angle
AM> of rotation 0..63 for each column of the screen), because
AM> I don’t have enough clock cycles for interpolation (it takes a long time to calculate the projection onto the camera axis).
In principle, your tracing should be faster than mine, but I wouldn’t
undertake writing one ;)

AM> I didn’t set out to make doors as my goal. I set my task
AM> to do inrealtime tracing in parallel with multicolor output. And
AM> I succeeded.
And I wanted Wolf in multicolor, I’ve wanted it for a long time, I abandoned this idea ten times,
then I thought again, but I didn’t write anything on this topic;(
And now I’m just asking you about rapid-fire algorithms :o)

08 Jan 02 19:35, Aleksey Malov wrote to Dima Bystrov:

AM> All the same, in dynamics such zooming with errors will, IMHO,
AM> noticeably twitch.
see. in the soap there is an example of using this method
(more precisely, similar: INC L:INC L:LDI)

AM> But in the effect Kolbasing Kartinka (aka Moving shit, distorter
[ skipped ]
AM> in fullscreen multicolor worked at a speed of 25 fps.
By the way, what about moving shit also in whole bytes? ;)
AM> nothing in them I don’t understand (this is in my own source code!!!). How
AM> wrote this and why it still somehow works, I can’t imagine! ;-)))
It can’t be that this is such a complex effect :)

AM> I don’t believe it. It's still worse. The static picture may
AM> look normal, but in the dynamics it will twitch.
See source!!! doesn't twitch!!!

AM> Why does it twitch on its own? Because my
AM> textures are displayed in a reduced form. In 1 Kwak and 1 Karmageddon on the offtopic
AM> the textures in the distance also flicker for the same reason. This is dealt with using
AM> using mipmapping, but it won’t look good on spec due to the small
AM> number of colors.
in Carmageddon there is mipmapping, maybe too simple.
But I’m not talking about ripples (moiré) - the effect of raster overlay, but about displacement
of pixels. This is why it happens.
Generatorincrements works like this:
add a scale factor to the adder register, and when overflow
generate INC. Otherwise NOP.
Naturally, the result of this generator depends on the initial state
of the adder. If your screen is scaled symmetrically from the center, and the generator
always started from the zero adder, then we get a twitching with an amplitude of 1
pixel. This is what is observed in Fractal Zoom.

AM> The lower border occupies 40-24-10=6 character lines. One
AM> familiar line is drawn in 1792 clock cycles. Consequently, 6
AM> lines are drawn in approximately 10800 clock cycles. Let the music player at
AM> always run at the same time and we call it at
AM> during the upper border. Total: in the int we have 11 thousand clock cycles free.
Don’t forget the upper border - there may be procedures with a fixed time
AM> If we increase one fractal phase in 32 ints (in SC - for 28
AM> ints), then we have 32*11000 = 352
AM> thousand clock cycles left for unpacking the fractal phase 6 kilobytes of texture (we will then decompress them into 12 kilobytes). This means unpacking one byte
AM> of the texture and then decranching it into 2 bytes (for your innerloop
AM> zooming)
decrunching is better separately, in the upper border.
AM> 8 thousand clock cycles (For poorly packed onestextures - about 2-3 thousand, otherwise
AM> there are no cycles left at all). So, 75 clock cycles just for unpacking.
AM> Add here about 30 clock cycles for “expanding” the byte with the texture,
In the top, in the top :)
AM> plus
AM> let’s slow down the depacker a little, because It unpacks it not in a single
AM> block of 4k, but in lines of 64 bytes. Total: this is 150*6000 =
AM> 900000/11000 = 80 ints for zooming one phase by 2 times. I’ll just say that
AM> even when zooming 2 times at a speed of 37-38 ints, the single-frame feeling is not so strong
AM>. And with 80 ints for a 2x zoom,
AM> will look like zooming at a speed of 25 fps.
ofcoz :)
but if it were not zoom, but rotation, it would have worked ;)

AM> Moreover, texture buffers require as much as 24 kilobytes of lower memory, and
AM> in my Stellar Contour - only 8.
i proposed a solution a couple of days ago - buffers in the page, plus transfer of 768
bytes.

AM> Maybe, of course, I’m slowing down, but it’s impossible to write a packer and unpacker for 8
AM> color textures, which would pack data 2-3 times and unpack
AM> one byte noticeably faster than in 70 clock cycles, on the Spectrum it is impossible.
What method does the unpacker use from Stellar Contour?

AM> In general, I don’t yet see any worthy competitors for my multicolor
AM> fractal zoom in a 60*32 window.
Competitorthere is: multi-color 2x4 non-frame fractal zooming with reflection,
from Pressure trackmo by CPU ;)
But I don’t know if there was real time there ;))))

AM> even estimate the average compression ratio: 27 textures, each 4
AM> kilobytes in unpacked form occupy 108 kilobytes. After packing
AM> with my packer they take up about 30.5 kilobytes. There is a packing of 3.5
AM> times, which is not so bad, considering the high speed of unpacking.
Tell me the method, and then I will believe that it is IMPOSSIBLE :)

AM> So, writing a zoom fractal will probably be more difficult than
AM> giving birth to a hedgehog. ;))))
Hedgehogs are born without spines ;)

DB> It cannot be that this is such a complex effect :)

The effect itself is not complex. I couldn't figure it out in the decrementer. Synchronization for me is carried out via ()(). Those. I have one line swinging for about
1300 cycles. Screens must be switched every 896 clock cycles. For this purpose
it was necessary to dynamically insert breakpoints into the innerloop, the handlers
of which clicked the screens, removed the old breakpoint, and set a new one. I used this kind of perverted method of synchronization in Mirror Rotator (Tryptomine
Dream) and in Multicolor Voxels (Tryptomine Dream). The fact is that in multicolor sausage I did the synchronization manually (a table of delays was created, from which the breakpoint generator generated breakpoints). I no longer remember by what principle
I created the signs.

Fri 11 Jan 2002, at 18:52:38 Dima Bystrov told Aleksey Malov about Re:
Gigascreen

AM>> no need. I'll ask Megus to extract ACEdit 0.60.
DB> It's strange, I sent only _one_ message :-/

2 arrived. The first contains text and the beginning of the section. In the second - the second part
section.

DB> By the way, a new fix has been released, so can you tell me directly how often you should throw them
DB> and in what pieces ;)

Can you break them into 2-3 sections? One section per message. Submit no more often
than after 3-4 days.

By the way, in the version that you sent me, some kind of glitch appeared: It looks like something goes wrong with you when you move to another line (when the text does not fit into the current one), i.e. the cursor moves over the wrong line that is being edited.

Throw it here. I think it will be useful to many.

Nikolaj.
[REAL ZX]

AM> Well, okay, when you get scrim-2, try to find the increment generator in the source code
AM> and change #0000 to #0080.
This will not give anything! Read above! You need to generate increments from the center, since you scale from the center!

AM> Okay. But you still need to unpack one and a half times more bytes than
AM> in SC. You won't be able to double your int faster than 42-45 int. And
AM> in its packed form this thing will take up more memory.
read below

AM> You see, I still won’t repeat this effect just for the sake of
AM> fullscreen. Besides, this is already your idea.
I'm too lazy to write ;(

AM> Rotate is another matter. But you can't do it in one frame on the whole screen
AM>.
I don't know, I haven't thought about it yet, but I can think about it ;)

AM> The data is encoded something like this:
AM> #00..#3f - the byte is simply put into the buffer.
AM> #40..#bf - byte is added to the buffer N&F+2 times ((N-#40)>>1)|((N-40)>>4)
AM> (according to the table) #c0..#cf - the previous byte is added to the buffer N-#be
AM> times. #d0..#fe - N-#ce bytes are placed in the buffer, stored in 6-bit
AM> format #ff - end of file.
uh-huh.
I propose a 3-fold packing method, with minor losses.
One byte stores 3 adjacent pixels (aaa, bbb, ccc), they are decoded using an
abstract plate 768 bytes long,compiled by the packer.
(since there can be 512 all possible states of 3 neighboring pixels, then 256
the rarest ones will have to be replaced with the closest similar ones)

tabl %00aaa000
tabl+256 %00bbbaaa
tabl+512 %00cccbbb

fractal zoom will have 28 phases of reduction from 1 to 2 times, more precisely, from 1 to
2/(28th root of 2)≈1.95 times
the map will have a size of 128/(root...) by 96/(root...) pixels, that is
124x93 pixels. The X-coordinate is rounded to a multiple of 3: 126x93 pixels,
that is, 11718 bytes in unpacked form or 3906 in packed form.
The card (two pieces) is stored at address #a300 or #a380 until the end of memory in a certain
page (the page is wasted... it's a shame)

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 clock cycles for each unpacked byte.
after unpacking it turns out something like
%00aaabbb, %00bbbccc, %00cccddd, etc., i.e. it is already possible to scale.

unpacking goes from the lower memory to the page, so before unpacking (or
parallel to it) you need to transfer about 4k (or less if you save on
the piece unpacking below #c000, butthis is difficult to code).
4k are transferred in about 50000 clock cycles, and if divided by 28 - in about
8 raster lines (in the upper border)

since the unpacking will be completed in a fixed time, it is better to call it in the
upper border, which will take 375000/28=13400 clock cycles = 60 raster lines (in in the upper
border)

scaling goes from the page to the lower memory, so each frame needs
to transfer 768 bytes, which will take approximately 10,000 clock cycles (in the lower border)
Scaling should not scale the current frame, but the next one, for
synchronization.

the music will be directly in the registers, it will take I don’t know how many, seven hundred clock cycles.
thus, in our upper
the border will have about 2000 clock cycles left to change
the parameters of the scaling procedure, which is approximately 60 clock cycles per
LD L command,...

In my opinion, it’s quite possible to do it?

But it’s going to take a long time to write... still generating fractals, laying out the muse... work
for a week, and I can’t sit at one program for a week ;(
So here we are.
We, users, we will give advice, and you, the demomakers, will decide where the rational grain is here ;)

AM> Hedgehogs are born in the thousands. And the zooming fractal - one-two and
AM> was miscalculated. ;))
and Insane? What about Eyeache 2? What about Binary love? ;)))

DB>> Strange, I only sent _one_ message :-/
DB>> By the way, a new fix has been released, so tell me directly how often
DB>> you should send them
DB>> and in what pieces ;)

12 Jan 02 11:35, Aleksey Malov wrote to Dima Bystrov:

AM> Can you break them into 2-3 sections? One section per message. Send
AM> no more often than after 3-4 days.
ok, it was just easier for me to send one letter.
I have autouue set up now, it’s inconvenient, but I’ll use it.

AM> By the way, in the version that you sent me, some kind of glitch appeared:
AM> It looks like something is going wrong with you when you move to another line (when
AM> the text does not fit into the current one), i.e. the cursor runs on the wrong line
AM> which is being edited.
strange :-(
there were no lines in the text longer than 256 characters?
it could also be due to an error in initialization (that’s why the fix had to be done :)
just write in soap, otherwise I can’t keep up with you in the echo.

AM> Suck it out, of course. And wait for Scream-2. There are zxasm's source codes.
why are you against ALASM? ;(

AM> But your monsters turn out to be “crappy.”
“If you don’t like it, don’t eat it” ;)
AM> That is, they look like
AM> plywood poles.
not really: if there is no sky, then the background for the bottom of the monster is painted in the color of the floor, and
the color of the top is the color of the roof. of artifacts there is only the bottom. The top and bottom
are scaled separately.
AM> I would like for these plywood pillars to have
AM> holes through which the background would be visible.
this is significantly slower.
by the way, “plywood”"monsters" are better visible from afar :)))))

DB> I can't yet. I promised to start throwing at people only with
DB> the next version.
DB> is it really more useful to throw here, and not in ZX.SPECTRUM?

in ZX.SPECTRUM they throw a lot of different rubbish and I don’t
receive yuyuki from it.

Nikolaj.
[REAL ZX]

DB> uh-huh.
DB> I propose a 3-fold packing method, with minor losses.

DB> 3 neighboring pixels are stored in one byte (aaa, bbb, ccc), they are decoded
DB> by
DB> an abstract plate 768 bytes long, composed packer.
DB> (since there can be 512 all possible states of 3 neighboring pixels, then
DB> 256
DB> the rarest ones will have to be replaced with the closest similar ones)

DB> tabl %00aaa000
DB> tabl+256 %00bbbaaa
DB> tabl+512 %00cccbbb

You have 3 stored in one byte pixel. 126*93 = approximately 12000 pixels,
which will be compressed into 4 kilobytes.
My packer compresses 4 kilobytes (8192 pixels) into an average of 1.2 kilobytes,
i.e. almost 7 times.
Is the difference noticeable?

DB> fractal zoom will have 28 phases of reduction from 1 to 2 times, more precisely, from 1 to
DB> 2/(28th root of 2)≈1.95 times

Yes, you don’t have to worry too much. 32 phases are also quite enough for smooth zoom. We just needed to stretch the zoom to 760 ints. 28 ints per phase
were just right for this purpose

DB> the map will have a size of 128/(root...) by 96/(root...) pixels, then
DB> is
DB> 124x93 pixels. We round the X-coordinate to a multiple of 3: 126x93 pixels,
DB> that is, 11718 bytes unpacked or 3906 packed.

My packer compressedabout one and a half to two kilobytes. No losses.

DB> The card (two pieces) is stored at address #a300 or #a380 until the end of memory in
DB> some
DB> page (the page is wasted... it's a shame)

DB> 32 clock cycles for each unpacked byte.

The only advantage is the speed of unpacking, with a damaged picture and
twitching zoom. Isn't the price too high for a full screen that no one needs?
Here, in Stellar Contour, all the effects with the exception of the last Pheel's
gigascreen picture go to 2/3 of the height of the screen and are quite watchable.

DB> the music will be directly in the registers, it will take I don’t know how many, seven hundred cycles.

If stored stupidly in registers, then it will be 13 bytes/int. It can be stored in compressed
form (9 bytes/int) and played back in 861 (in my player) cycles.

DB> thus, in the upper border we will have about 2000 cycles left per
DB> changing
DB> parameters of the scaling procedure, which is approximately 60 cycles per
DB> one
DB> command LD L,...

DB> In my opinion, it is quite possible meet?

What's the point? What if it looks crooked? We don't need such a full screen. ;) Unless
someone (or even you) writes this effect so that it looks beautiful
and is full-screen.

DB> But it’s going to take a long time to write... still generating fractals, laying out the muse...
DB> work
DB> for a week, and I can’t sit in front of one program for a week ;(

No, if you called yourself a load, climb into the back. And the source code for a generic fractal
can be written in a couple of hours in C or Pascal. Don't worry about the music - I'll give you my player and converter. So it will take 3-4 days in total. ;) Yes, and you
obviously will be writing for at least 2-3 weeks.

DB> So here it is.
DB> We, users, will give advice, and you, demomakers, will decide where
DB> the rational grain is here ;)

The only rational link in your proposal is fullscreen. But the game
is not worth the candle because of the packer and the twitchy zoomer.

DB> why are you against ALASM? ;(

Because I’m used to ZXAsm. To its convenient editor. To the fact that I configured
it so that it sees my 896 kilobyte ramdisk. To the fact that it understands
macros and conditional translation directives, which make my life so much easier when
writing programs. I even did the layout of effects into pages and the creation of the demo kernel
automatically, by writing a short source code, when compiled
which created both page files and kernal at the same time.

AM> Because I'm used to ZXAsm. To its convenient editor. Moreover,
AM> configured it so that it sees my 896 kilobyte ramdisk.
and Alasm does not need a ramdisk, it is its own ramdisk - you can edit at least
twenty sources :)
AM> Besides
AM> that it understands macros and conditional translation directives,
But Alasm also understands!
AM> which so
AM> simplify I live my life when writing programs. I even performed the layout of the effects in
AM> pages and the creation of the demo kernel automatically, having written
AM> a short source code, during compilation of which both the files
AM> pages and the kernal were created at the same time.
However, in zasma it is inconvenient to select files for Load.
Zasm compiles slowly.
Source codes take up more.
In osm as much as 64k of memory for labels (for extra-large ones) projects)
Maybe you'll change your mind?

AM> Faster than 48 clock cycles per couple of pixels is impossible:
Well, why be so categorical :)
There is no fastest method, even LD:PUSH is not always the fastest, and
between your method and LD:PUSH there are so many intermediate methods ;)))
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> you can, of course, push, but the stack is better suited for storing
AM> addresses of breakpoints that synchronize multicolors.
However, if AGAIN you take 2 pixels per step (the angle of rotation on one
texture is no more than 30 degrees - slowly), then you can experiment with
ADD A,... ;\POP HL
inc h/nop ;/LD (...),HL
LD L, A
LD d/e, (HL)
1/2*push de

Wait... and how did the “accordion” in TD work?

AM> My packer compresses 4 kilobytes (8192 pixels) on average in 1.2
AM> kilobytes, i.e. almost 7 times.
AM> Is the difference noticeable?
And I have a code block, but then it packs well :))))

AM> Yes, you don’t have to worry so much. 32 phases are also quite enough for
AM> smooth zoom.
ugums

​​AM> The only advantage is the speed of unpacking, with a damaged
AM> picture and twitching zoom. Isn't the price too high for nobody
AM> not neededfullscreen? Here, in Stellar Contour, all the effects with the exception of
AM> the last Pheel's gigascreen picture go to 2/3 of the screen height
AM> and are quite watchable.
Well, you need at least one full screen in the demo. After all, it was in TD?

AM> What’s the point? What if it looks crooked? We don't need such a full screen.
AM> ;) Unless someone (even you) writes this effect in such a way
AM> that it looks beautiful and is full screen.

AM> No, you called yourself a milk mushroom - get into the back. And the source code of the generic
AM> fractals can be written in a couple of hours in C or Pascal. Don't worry about the music
AM> - I'll give you my player and converter. So it will take 3-4 days in total
AM>. ;) And you will obviously be writing thoughts for at least 2-3 weeks.

AM> The only rational link in your proposal is full screen. But
AM> the game isn’t worth the candle because of the packer and the twitchy zoomer.
That’s it, my friend, you’ll have to eat your hat ;))))))))))))))))))
Pass the salt and pepper?
.,-=-,. .,-=-,.
=======) =======]
\ salt/ \pepper/
\___/ \____/
;)))))))))))))))))))))))))))))))
Look for the effect in soap, you need to look at PENTAGON.
760 frames = 38*20.
Memory wants 4 pages, in the lower memory there is one and a half kilos free.
It twitches no more than in SC, and does not tremble :)
Sorry for the tyap-lyap coding (especially for the "asynchronous"unpacking"), in two days
you couldn’t write better ;))

By the way, I wondered why there was a “jump” between the main phases of the fractal in SC:
there is a trick in the mandelbrot generator, or rather, in the “maximum
index” parameter. When you increase it, additional curls appear on the hitherto black area of the fractal
appear. But you can’t use too large a “maximum
index” at a small scale - otherwise there will be dandruff on the edges of the fractal, similar to a ROM. And the generator that you used, someone wrote so that the maximum
index depends on the scale.

on *21.01.02* *1:14:11* you wrote a message to *Aleksey Malov*
about *"Re: Gigascreen"*.

DB> However, it is inconvenient to select files for Load.

hmm, why is that? Are you accidentally confusing ZAsm 3.10 with ZXAsm 3.00?

DB> Zasm compiles slowly.
DB> Sources take up more. Alasma has as much as 64k of memory for tags
DB> (for extra-large projects) Maybe you’ll change your mind?

appearance ;)

All the best, siril.4d.perm.ru.

DB>>> why are you against ALASM? ;(
AM>> Because I’m used to ZXAsm. To its convenient editor. To the fact that
AM>> I configured it so that it could see my 896 kilobyte ramdisk.

DB> That’s it, my friend, you’ll have to eat your hat ;))))))))))))))))))
DB> ;))))))))))))))))))))))))))))))

Indeed, Allah Akbar! ;)

DB> Look for the effect in the soap, you need to look at PENTAGON.
DB> 760 frames=38*20.
DB> Memory wants 4 pages, in the lower memory there is one and a half kilos free.
DB> It twitches no more than in SC, and does not tremble :)
DB> Sorry for tyap-lyap coding (especially for "asynchronous unpacking"), for two
DB> days
DB> you couldn’t write better ;))

Well done, one word. You should write demos. ;)

By the way, why does it zoom for 38 ints, and at least not for 32?

You, as I understand it, tore the music out by the roots. ;)

DB> By the way, I wondered why there was a “jump” between the main phases of the fractal in SC:
DB> there is a trick in the mandelbrot generator, or rather, in the “maximum
DB> index” parameter. When you enlarge it, additional curls appear on the hitherto black area of ​​the fractal
DB>. But you cannot use a too-large "maximum index" at a small scale - otherwise there will be dandruff on the edges of the
DB> fractal, similar to ROM. And the generator that you
DB> used, someone wrote it so that the maximum index depends on the scale.

I wrote the generator myself.My maximum index is constant for
all phases of the fractal (about 80 or 90, I don’t remember). I didn't have the opportunity to experiment with it, because... I wrote it and generated the phases for the fractal at
work (I only have a Spectrum at home), and wrote and debugged the effect itself at home.

Speaking of birds. I would like to write a packer that is no worse than mine, but suitable in
speed for unpacking large textures.

Bye, Dima.
WBR, Vivid^Brainwave.

DB> Alasma has as much as 64k of memory for tags (for super-large projects)
DB> Maybe you’ll change your mind?

I don’t like the Alasma interface.

Bye, Dima.
WBR, Vivid^Brainwave.

IV> appearance ;)

conceptual minimalism :)
has anyone complained about Gens for his poor appearance? :)

[Wizard Warz] Yurik aka Jerri / Alien Factory /I \
[No RAR allowed] [SoHm] [Conceptual Minimalism] \ZX/

21 Jan 02 12:07, Vassili Klimov wrote to Dima Bystrov:

VK> and incbins??? constantly load from disk;(
And you put a plus sign in front of inkbin - it will load only during the first
compilation.

DB> And you put a plus sign in front of the inkbin - it will load only during the first
DB> compilation.
ORGs and all sorts of left-handed writing... I usually put all loadings at the end of the source code and
make do with one ORG. And I use the good old save object ;-), which has not been in
alasm for centuries.

JseveN from the 4th Dimension...