| |
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....
|
| |
Sam
Registered: Aug 2010
Posts: 13 |
PAL, my DYPP from 1989 (Poor/Bias Crusher [fixed]) has two different color texts on top of each other, with per pixel y movement and no animated chars, there is also techtech to make it fluffier :-)
But I give it to you that yours is much nicer looking. |
| |
PAL
Registered: Mar 2009
Posts: 270 |
your is from 1989 andtherefor the best! I am a pixel artist, if I could code I would beat you all but I simply can not code... but I can get them things to be inside limits in a way thet few can.... I take off my hat for all your splendid code... but still I think mine is the best DYPP on the c64 ever... it is super huge and free feeling.... but yeah... I know what you say. |
| |
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: 581 |
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: 717 |
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. |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 - Next |
