| |
Burglar
Registered: Dec 2004
Posts: 1137 |
Release id #249805 : Codeboys & Endians
There are too many wtfhow moments in this demo that I want to understand:
1. bitmap splitter
wtfhow, such a clean split, must be sprites there?? but you have that multiplexer? and the d800cols+screenram colors dont match? wtf?
2. turn disk picture/part flipper
wtfhow?! I understand the general technique, w/o badlines yet colorful, but side+upper+lower border too? and so clean!
3. char explosion
ok, graham method that doesn't zoom/wobble, but keeps em clean, super clever :) (if not, wtfhow?)
4. mahoney bars
animation or wtfhow?
5. huge bitmap stretcher
same method as trident used recently, and in that hawkeye pic? but wtfhow did u use such a big pic?
now you may explain yourself! ;) |
|
... 13 posts hidden. Click here to view all posts....
|
| |
HCL
Registered: Feb 2003
Posts: 731 |
Nope guys, the "char explosion" is not just Master Graham's zoomer with sprites. If you look in detail what Graham's zoomer does, each char displays a small part of the picture fully unscaled. Zooming or shrinking only appears "between" the chars. Since each char is 4 mc-pixels wide, you can just add 4 to your char index each step to regenerate the original picture, add 3 if you want to scale it up, or add 5 if you want to shrink it down. Put accurate calculations on top of that, and it's looking really good :D.
This one however, puts 4-pixel wide chunks across char bounderies, so each chunk must be represented by two chars and at the same time possibly display the next chunk within the same char with variable distance. On micro-level this becomes a totally different problem, but you can do the figuring yourselves of how to implement it, how many chars per chunk you actually need and how large piece of graphics you can have. ..and still you will only achieve a world-second :D |
| |
HCL
Registered: Feb 2003
Posts: 731 |
..and best of all: I didn't code it :D |
| |
Jetboy
Registered: Jul 2006
Posts: 357 |
Well, the only case where usual Graham Flexer would not work is the case where there is one pixel gap between chars. And that only for half the chars. All the others can be done with usual setup plus masking. I guess it is Graham Flexer with some modification. Of course calculations would be a little bit more complex, but since usually everything is cleverly tabelarized on the c64 it doesn’t really make big difference.
Anyway , clever improvements, and a great FX! |
| |
Oswald
Registered: Apr 2002
Posts: 5126 |
wow, good point HCL, I als fell into this trap, after your post I spent 10-20 min thinking on it, but came empty handed.
@jetboy, I dont think so. what is if our consecutive pixels are abcde...
if defaukt char is abcd, then you can also have a cases
like:
a..b
b..c
c..d
d..e
a.bc
b.cd
..
.
ab.c
bc.d
..
.
so 1 OR 2 pixel gaps have to be handled differently.
I think there is some kind of symmetry here used, that we dont see yet. if one would dig out the charset for 1 row it could be unearthed, maybe more fun to think about it :) |
| |
Oswald
Registered: Apr 2002
Posts: 5126 |
OR maybe its "just" vertical charset splitting ? :P looking at my above post 1 charset can handle 16 chars, so maybe 2 charset per row? I dont know how wide it is, 40 chars?
edit: ok but we need a badline per row for the different rows, maybe that is hidden in the "fld"-ed lines? idk |
| |
Jetboy
Registered: Jul 2006
Posts: 357 |
Quoting Oswaldso 1 OR 2 pixel gaps have to be handled differently.
I stand corrected. I ended my thinking prematurely, and skipped some important cases. Some 1 or 2 pixels gaps can be achieved by just masking already present combinations. But there are many new ones introduced that require new chars. |
| |
Jetboy
Registered: Jul 2006
Posts: 357 |
Wait!
Since we are moving entire characters, gaps can only go between characters not in the middle.
So the situation
a.bc
ab.c
etc.
will never happen
we just need to take care of the borders, that is:
d.ef
cd.e
d..e
The rest is in standard GF. So we only need 3 extra characters per column.
In GF we can fit 64 columns in one generator.
In this routine we can fit 36 columns per generator, if i didn't mess up something again :) |
| |
Burglar
Registered: Dec 2004
Posts: 1137 |
@hcl, thanks for explaining the details! I'd like to think we were in the right direction, cuz sprites are used for masking, right? and vertical masking is fld ftw :)
@jetboy, the pic is 36x18 chars, so that checks out \o/
youtube link to effect |
| |
Oswald
Registered: Apr 2002
Posts: 5126 |
wow, great insight mr Jetboy |
| |
HCL
Registered: Feb 2003
Posts: 731 |
Hi guys, i posted an extensive answer last week, but the browser *ate* it, then i got bored :P..
So here are my thoughts one more try.. Again, Pernod knows the answer but since he's not writing, you have to bear with me..
So on micro-level we have 4-pixel chunks of gfx that need to be able to move around freely across chars, possibly displaying two different chunks within the same char. Let's examine what possible situations can occur with a chunk ABCD followed by EFGH:
|ABCD|
|BCD.| --- Same
|BCDE| -´
|CD..| --- Same
|CD.E| -´
|CDEF|
|D...| --- Same
|D..E| -´
|D.EF|
|DEFG|
"." will be covered by sprite, so we don't care what is there, thus |BCD.| and |BCDE| can be represented by the same char -> 7 unique chars to represent ABCD sliding from centered to leftmost position. We need sliding out to the right also you may think, but that is actually already covered! If we instead examine EFGH, possible situations are:
|EFGH|
|.EFG|
|DEFG|
|..EF|
|D.EF|
|CDEF|
|...E|
|D..E|
|CD.E|
|BCDE|
..and all can be found up there already. 7 chars per chunk -> 256/7 ~= 36 chunks, which (i think) is what Pernod's effect is showing. |
| Previous - 1 | 2 | 3 - Next |
