"Interference" oldschool effect - what's the trick?
category: code [glöplog]
Quote:
yay we're going to have a flamewar in addition to theoretical democoding in this thread!called "Kefrens Bar"
more like alcatraz bars, ye?
Yes, Alcatraz bars from their Megademo 3, from part "We are first"
https://www.pouet.net/prod.php?which=14533
https://www.pouet.net/prod.php?which=14533
Metalwar's bars :P
Quote:
So here's the question. Is it possible on a PC (in 13h mode) to do something from the 4th point? Since this effect is available in the "Wish" demo, it is possible :)
outp(0x3D4, 0x0013);
:D
The CRTC Offset register (0x3D4 index 0x13) controls offset (or, rapther, pitch of current framebuffer) which is added to current display pointer at the start of next line or character. usually it would have been set to (bytes_per_scanline) / (k); k = 2 for byte mode, 4 for word mode, 8 for dword mode
so, for mode 0xD it's ((320/8) / 2) = 20, for modes 0x12/13 ((640/8) / 2) = 40, mode 0x13 is weird here because of 256-color and internal VGA organization, I guess;
If we set it to 0, each scanline is fetched from same memory offset, effectively stretching it across every screen or until next write to offset register (which is fortunately not double buffered, unlike many other VGA CRTC registers)
after this, you only need to sync for each retrace via port 0x3DA and draw new bar position on top of line, change palette registers and so on :)
p.s. by the way, you can control height of scanline from 1 to 32, using Maximum Scan Line register, index 0x9 - 200-line modes contain 0x01 here so each scanline is repeated twice, for text modes it controls charachter height. Also, this register contains doublescan bit wich doubles every (both text and graphics) scanline for CGA/EGA compatibility
typo2: outpw, not outp -_\\ or simply mov edx, 0x3d4 / mov ax, 0013 / out dx, ax
wbc\\bz7, thanx ;) Доходчиво объяснил )
Quote:
Quote:yay we're going to have a flamewar in addition to theoretical democoding in this thread!called "Kefrens Bar"
citing random shit i found on hornet in 1995
citing random shit i found on hornet in 1995
citing random shit i found on hornet in 1995
citing random shit i found on hornet in 1995
citing random shit i found on hornet in 1995
that sums it up right?
get the_cop.zip
mod of distances of two points xored
Yeah, try implementing it like that on a 286. ;)
I'd go for the 0xD EGA/VGA bitplane mode as mentioned, that would need writing 16k to the vram, possible for the 286 to do fast.
But I had a theory, would it be possible to reduce that to 8k if the hardware scrolling is used. I am not entirely sure if this mode has it, the total vram is 32k and there are 64k and you can possibly move the vram address offset with the CRTC reg12/13, but that will look smooth vertical but not horizontally as I think the vram offset is 2 bytes aligned.
So, if you hardware scroll the first layer of circles, the only the second pattern residing in a different bitplane has to be written (so only 8k needs to be moved). This one has to take in a count the hardware scroll offset when copied too. And I wonder if it's possible to smoothen the X movement too by having preshifted patterns in the other bitplanes and switching the off/on somehow (or with the palette?). With just some trickery and having to move only 8k that could be possible on 8088 maybe.
I also couldn't get the Wish demo run on my 8088. It says something like "file error". The nfo file says requirements 286, so I don't know.
But I had a theory, would it be possible to reduce that to 8k if the hardware scrolling is used. I am not entirely sure if this mode has it, the total vram is 32k and there are 64k and you can possibly move the vram address offset with the CRTC reg12/13, but that will look smooth vertical but not horizontally as I think the vram offset is 2 bytes aligned.
So, if you hardware scroll the first layer of circles, the only the second pattern residing in a different bitplane has to be written (so only 8k needs to be moved). This one has to take in a count the hardware scroll offset when copied too. And I wonder if it's possible to smoothen the X movement too by having preshifted patterns in the other bitplanes and switching the off/on somehow (or with the palette?). With just some trickery and having to move only 8k that could be possible on 8088 maybe.
I also couldn't get the Wish demo run on my 8088. It says something like "file error". The nfo file says requirements 286, so I don't know.
Early DOS demos have some kudos coming... copying Amiga/16-bit effects you say, well the 286 was also 16-bit, and when something had to move on the screen, PC had to work harder. (Like an Amiga with RTG.)
As for the interference "trick" it's similar to moire patterns. With clever palette colors, you can move two bitplanes to make the bit combination form cool patterns, while using very little resources. (But as per previous paragraph, only if can has bitplanes.)
Screenshot in OP has too thick lines, not the best example of interference. The eye can separate the two layers and see both circle patterns. XOR might have been better and this is also used in many prods including recently.
As for the interference "trick" it's similar to moire patterns. With clever palette colors, you can move two bitplanes to make the bit combination form cool patterns, while using very little resources. (But as per previous paragraph, only if can has bitplanes.)
Screenshot in OP has too thick lines, not the best example of interference. The eye can separate the two layers and see both circle patterns. XOR might have been better and this is also used in many prods including recently.
What early PC-Dos-Demos had "copied Amiga effects"? Thx!
Photon,
On PC side, depends on what GPU u used back in time. Trident was slowest, S3 and Et400 were faster. ET400 just blitted everything faster(memory chips were faster) and it supported some crazy resolutions "in hardware" while trident cards did not(tho ists was possible via third party vbe TSR).
On PC side, depends on what GPU u used back in time. Trident was slowest, S3 and Et400 were faster. ET400 just blitted everything faster(memory chips were faster) and it supported some crazy resolutions "in hardware" while trident cards did not(tho ists was possible via third party vbe TSR).
@moredhel to create a minimal interference pattern, you need two transparent layers sliding over each other (IRL e.g. two OH transparent slides with tight regular patterns). You can do this with just a few cycles of CPU time if a GPU / Chipset / VDU has hardware layer scrolling and a bit recombination (or bitmapped) mode.
The Amiga has both, so it can do it in ~1/500th of a frame. VDUs without both will require software or hardware rendering of the effect, i.e. work much harder to achieve it.
The low-level magic is in the recombination of bits to form a pixel color. Any mode that allows bit recombination, such by binary logic e.g. OR also allows this. But the high-level magic, the third pattern, emerges from the original two when they're slightly offset. So this recombination must be processed together with scrolling or by moving pixels separately, if the VDU doesn't have individual hardware scrolling for at least one of the layers.
The Amiga has both, so it can do it in ~1/500th of a frame. VDUs without both will require software or hardware rendering of the effect, i.e. work much harder to achieve it.
The low-level magic is in the recombination of bits to form a pixel color. Any mode that allows bit recombination, such by binary logic e.g. OR also allows this. But the high-level magic, the third pattern, emerges from the original two when they're slightly offset. So this recombination must be processed together with scrolling or by moving pixels separately, if the VDU doesn't have individual hardware scrolling for at least one of the layers.
@Photon,
Still, I don't understand the interference trick on the PC platform (for slow machines like 80286 with ISA bus).
Let me explain point by point:
- Pre-render to buffer and then draw to segment A000 - too slow.
- In VGA mode-x we can only scroll one layer in hardware. But we cannot add the second layer of circles and move it overtop.
- We could use latch-copy (vram to vram) and use ALU by setting the XOR mode. But to do this, we still need to do a dummy read and write to the A000 segment (once every 4 pixels) . This nullifies all efforts, because it is very slow.
So I still don't understand what tricks can be used here :(
Still, I don't understand the interference trick on the PC platform (for slow machines like 80286 with ISA bus).
Let me explain point by point:
- Pre-render to buffer and then draw to segment A000 - too slow.
- In VGA mode-x we can only scroll one layer in hardware. But we cannot add the second layer of circles and move it overtop.
- We could use latch-copy (vram to vram) and use ALU by setting the XOR mode. But to do this, we still need to do a dummy read and write to the A000 segment (once every 4 pixels) . This nullifies all efforts, because it is very slow.
So I still don't understand what tricks can be used here :(
@BiTL: use the 16 color planar modes for faster drawing :)
mode 0xD, use two bitplanes, AND is for free, moving has to be done manually with MOV ... the rest is fine tuning, not as easy as it sounds ;) ..
Since T(oo) Young is written in assembly just disassemble or debug to get an idea
Since T(oo) Young is written in assembly just disassemble or debug to get an idea
oops, not AND, it's OR :)
like britelite mentioned as well, 16 color planar is where its at
without opening a new topic, I'll try to continue... in the hope that someone from the enlightened will look here again ;)
coming back to this:
I needed the 320x100 mode, that is, doubling the line height. As wbc\\bz7 wrote, this can be achieved by writing the value 0x03h to the Maximum Scan Line register (port 3D4h, index 0x9).
It works. Both in DosBox and on my PC 486 DX.
But I have a question, is it safe? Does it work everywhere? By default, after the initialization of the 0x13 VGA mode, this CRTC Data Register contains the value 65 (0x41). At least in DosBox, this is the case. From the documentation, we learn that in addition to the bits that we need, there are high 3 bits responsible for some things. I'm not sure if we should keep them in their original state?
In old source codes, I found that it was done like this:
That is, here the programmer saves the last 3 bits in their original form, and only changes the first 5.
Does it really matter when it comes to 256-byte intros? :)
Because, of course, the code
pretty short :)
coming back to this:
Quote:
- by wbc\\bz7p.s. by the way, you can control height of scanline from 1 to 32, using Maximum Scan Line register, index 0x9 - 200-line modes contain 0x01 here so each scanline is repeated twice, for text modes it controls charachter height. Also, this register contains doublescan bit wich doubles every (both text and graphics) scanline for CGA/EGA compatibility
I needed the 320x100 mode, that is, doubling the line height. As wbc\\bz7 wrote, this can be achieved by writing the value 0x03h to the Maximum Scan Line register (port 3D4h, index 0x9).
It works. Both in DosBox and on my PC 486 DX.
But I have a question, is it safe? Does it work everywhere? By default, after the initialization of the 0x13 VGA mode, this CRTC Data Register contains the value 65 (0x41). At least in DosBox, this is the case. From the documentation, we learn that in addition to the bits that we need, there are high 3 bits responsible for some things. I'm not sure if we should keep them in their original state?
In old source codes, I found that it was done like this:
Code:
mov dx,3d4h
mov al,9
out dx,al
inc dx
in al,dx
and al,0e0h
add al,3
out dx,al That is, here the programmer saves the last 3 bits in their original form, and only changes the first 5.
Does it really matter when it comes to 256-byte intros? :)
Because, of course, the code
Code:
mov dx, 3d4h
mov ax, 309h
out dx, axpretty short :)
generally, if your code is running in signe mode like 320x200 8bpp (aka mode 0x13), you can use hardcoded value for CRTC register, as it won't differ from one VGA card to another
in fact, many older demos/intros (including mine :) use hardcoded CRTC values for tweaked modes like 320x240, and it works flawlessly everywhere :)
in fact, many older demos/intros (including mine :) use hardcoded CRTC values for tweaked modes like 320x240, and it works flawlessly everywhere :)
to wbc\\bz7:
Well, I trust your experience ;)
By the way, for unchained Mode-X 320x200 the double height line trick works only in the "safe" version, when we do not set the 3 high-order bits to zero. Otherwise, there is a glitch on the screen.
Well, I trust your experience ;)
By the way, for unchained Mode-X 320x200 the double height line trick works only in the "safe" version, when we do not set the 3 high-order bits to zero. Otherwise, there is a glitch on the screen.