| |
Rudi
Account closed
Registered: May 2010
Posts: 125 |
DYPP
Hi,
DYPP - Different Y Pixel Position.
I don't seem to find an explanation on this effect on C64 on codebase or anywhere. Maybe its in another thread here on csdb, then please provide an link.
I know the basics of sines, ive made sinescroll on PC, but its easier there since you can look up the framebuffer directly, via sine-tables and so on.
Im wondering how this effect is easily made on C64. I believe there are more than one way, but i guess one way is slower than the other; for example moving each column-bit (inside a char) in realtime. The other way I think is having the chars animated, similar to a twister. Though, im thinking each angle is used for lookup table. I just dont seem to get it right in my mind to start coding on this effect. I've seen several early cracktros and demos that does this very fast, but haven't had the time to reverse-engineer the binaries. If you have any tips and info i'd appreciate it, or even better; write an explanation for codebase.
Thanks |
|
... 43 posts hidden. Click here to view all posts....
|
| |
Rudi
Account closed
Registered: May 2010
Posts: 125 |
Quote: Nope. it's exactly the same DYPP code when i show 1 and 2 scrolls. When showing 1 DYPP there is a double y-sinus, but when showing 2 DYPPs there are single y-sinuses.. simply because i don't have time to calculate TWO double y-sinuses :(. despite calculating 39 chars instead of 40 :P
|
| |
Rudi
Account closed
Registered: May 2010
Posts: 125 |
Quote: I wonder if the char-transpose approach (swap pixel rows and columns in an 8x8 pixel grid) discussed in https://csdb.dk/forums/?roomid=11&topicid=121737#139125 may in practice really be useful for things like DYPP. =)
Actually, I had that in mind when I started that thread :) |
| |
Rudi
Account closed
Registered: May 2010
Posts: 125 |
Crap. how do I delete faulty comments? |
| |
Lubber
Registered: Jan 2002
Posts: 26 |
My DYPP in the last part of Screech had a fixed sinus. Although the font is hires, the sinus is always 2 bits wide, so it was possible to have less animation positions to save memory.
https://www.youtube.com/watch?v=rU07Amaad1A&t=10m |
| |
Rudi
Account closed
Registered: May 2010
Posts: 125 |
@Lubber: Nice! |
| |
Raistlin
Registered: Mar 2007
Posts: 659 |
here are a few different ways to do DYPPs...
1) real-time... this hasn’t been done well yet AFAIK and I’m not sure that there’s much point in doing so as, yeah, it would be much slower than a precalc’ed one;
2) char-based with multiple charsets... this is the method I used in The Dive. Use a large font built out of pieces from a columnised font (eg. If you have a 7x7 char, 56x56 pixel font, try to make that font using 32 1x7 char strips). Have an offline program that essentially plots the full screen sinus into a buffer - and then for each screen line, work out all the chars that would be needed in a charset to draw that line (ie. iterate over the 32 strips and place each one). When your program finds that the new chars on a line give a charset with more than 256 chars, mark off the charset for the previous line and start the current line again with a new charset. Using this method you’ll probably find you need 5, 6 or 7 different charsets, depending on how good your font is. Using this method you can also generate some really nice fully unrolled plot code... since each char is built using 1 of 32 strips, you end up with just “LDA FontLookupData_PartXXYY, y”, “STA ScreenAddress + YLine * 40, x” or something to that effect.
3) plot-based, such as the all border DYPP in Rivalry... this uses a similar technique - but you instead look at packing each line of each font character into lookup tables... this can take a lot of memory of course. The effect in Rivalry was much harder than you might imagine as, iirc, there was ~30k of that data... and then the fully unrolled plot code interleaved into the border opening and sprite multiplex code... not to mention the bitmap memory, animation data, etc etc.
Maybe a Codebase article might be a good idea to do sometime to describe some of these things properly..? |
| |
HCL
Registered: Feb 2003
Posts: 727 |
I think that pretty much sums up the original question of this thread. Everyone knows how a DYPP looks, but there is in fact no straight forward way of doing it on the c64. Either you use one of the mentioned techniques, with their pros and cons, or you try to be really clever and find out something new that suits your needs. |
| |
Sam
Registered: Aug 2010
Posts: 13 |
The one-color DYPP in Typical was a sort of a real-time, it draws the advancing character line and then removes the tail in real-time. This only works with one-color filled chars that are simple enough, no script etc. |
| |
zscs
Registered: Sep 2010
Posts: 48 |
Last time I really coded something newly, that was in 1994 so I'm sorry in advance, if I would write something stupid. :D
In 1993, I was keen of trying to copy other's stuff by my own and created a kind of realtime DYPP in Attempt one. File "2...SCROLLDYPPER" PRG<
(I don't know what demo/intro was the inspiration here)
I'm just trying to check the code, as I can see, 16x16 chars matrix is a kind of saving rastertime here and I definitely chosen the multicolor because it also doubles the rastertime, but... I also did an interlace here. I dunno why and dunno how, however, can give a cool idea to someone for something more clever (maybe). ;-)
Use joystick to control speed and axis. Press key 1 or press 2 to start interlace ON/OFF.
(I know, I know, lame code, but I was 15 years old here and this is a one-person 'demo group') :) |
| |
Scan
Registered: Dec 2015
Posts: 111 |
Quoting zscs
In 1993, I was keen of trying to copy other's stuff by my own and created a kind of realtime DYPP in Attempt one. File "2...SCROLLDYPPER" PRG<
I think it looks really nice, but I can't stop wondering how DYPPER would be pronounced. ;) |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 - Next |
