| |
LHS
Registered: Dec 2002 Posts: 66 |
rotating chessboard
Hello, how to code a "simple" monochrome rotating (+zooming) chessboard, like the part after intro in Deus Ex Machina?
I'm thinking on line rutines for filled vector (when x' = x+1). Just draw on screen a few lines, then a few lines rotated 90dgrs, it gives a "chessboard net". But then the EOR filling doesn't fill corectly, because the first (upper) line isn't prepared. This first line is filled only by end-points of vector lines. Is this a right thought? How to prepare the upper line? |
|
| |
Cruzer
Registered: Dec 2001 Posts: 1048 |
Guess you could check whether the upper left corner is filled or not based on its position, then draw some lines between the chessboard lines' intersection with the upper line. |
| |
LHS
Registered: Dec 2002 Posts: 66 |
I was thinking on similar procedure - additionally fill the upperline between the intersections. But I wasn't sure, if is this usable (or if doesn't exist a better hint). Thanks. |
| |
WVL
Registered: Mar 2002 Posts: 902 |
If you really want to do it this way, then determining the first pixel and then EOR-filling-from-left-to-right in the first line is all you need to do.
After that, you can eor-fill from top-to-bottom.
But this is really not how the rotator in DeM or Dawnfall works. The rotators in PfP and Mekanix use a different technique also (completely unlike DeM and Dawnfall).
If you insist on programming it like this, then prepare for it to be really really slow, like really. |
| |
chatGPZ
Registered: Dec 2001 Posts: 11386 |
haha i coded one like this.... and i think wvl is underestimating the fact that it'll be like really really slow =D |
| |
WVL
Registered: Mar 2002 Posts: 902 |
OK, so how slow was it? :D Still measurable in frames per second, or did you need seconds per frame? ;)
Depending on the size, i'd guess a 16x16 char area would become like 10fps or so. |
| |
chatGPZ
Registered: Dec 2001 Posts: 11386 |
well my version was fullscreen und used a rather non optimized multicolor line drawer and even worse filler =) might have been a frame per second or.... maybe less =) |
| |
JackAsser
Registered: Jun 2002 Posts: 2014 |
Quote: If you really want to do it this way, then determining the first pixel and then EOR-filling-from-left-to-right in the first line is all you need to do.
After that, you can eor-fill from top-to-bottom.
But this is really not how the rotator in DeM or Dawnfall works. The rotators in PfP and Mekanix use a different technique also (completely unlike DeM and Dawnfall).
If you insist on programming it like this, then prepare for it to be really really slow, like really.
But those in PfP and Mekanix do not have rotation and zooming separated.... The one I did in Andropolis have those properties separated though but ofcourse have silly visual bugs (which I nowadays know how to remove thanx to the intro rotator in Mekanix).
All those rotators other than simple EOR-fillers are quite hard to explain actually and will take forever to elaborate here without pen and paper, honestly. All 50 FPS ones uses char mode though with predefined charsets and tricky methods for determining what charset and what char to display at each point. |
| |
WVL
Registered: Mar 2002 Posts: 902 |
Anyway, I'd suggest one using 3 buffers :
1 for drawing only lines in, and 2 for the final eored-picture.
This way, you only have to clear the lines in the first buffer when drawing a new frame, and not the whole eorred picture (saves a lot of cycles).
So :
1) draw lines in buffer 1
2) eor into buffer 2
3) clear lines in buffer 1
4) draw lines in buffer 1
5) eor into buffer 3
6) clear lines in buffer 1
7) draw lines in buffer 1
8) eor into buffer 2
repeat
Oh, and LOL at one second per frame :D
Oh, and also I'm willing to explain in detail how the charset bases rotators work, if anyone is interested. |
| |
Mace
Registered: May 2002 Posts: 1799 |
@WVL: I'm interested as long as it doesn't mean that I have to make one afterwards ;-) |
| |
chatGPZ
Registered: Dec 2001 Posts: 11386 |
hihi |
| |
WVL
Registered: Mar 2002 Posts: 902 |
crap. |
| |
LHS
Registered: Dec 2002 Posts: 66 |
@WVL, which way uses the Deus E.M. chessboard? I would like to code a small chessboard in sprites, with bitmap in background. (if is possible the routines easily explained). |
| |
WVL
Registered: Mar 2002 Posts: 902 |
I think the method in DeM is called a movelist, but I really can't explain that one to you :D |
| |
HCL
Registered: Feb 2003 Posts: 728 |
Yeah, how does that chess-zoomer in DeM and Dawnfall worx? I always wondered :). Graham? |
| |
JackAsser
Registered: Jun 2002 Posts: 2014 |
Quote: Yeah, how does that chess-zoomer in DeM and Dawnfall worx? I always wondered :). Graham?
We could ask Krill aswell since he perfected the routine in E2E4K. Krill? :D |
| |
Cruzer
Registered: Dec 2001 Posts: 1048 |
Always thought the Dawnfall style chessboard rotozoomers were done with eor-filling. Sure, there are more lines than would usually be possible with that framerate, but there's only two different slopes, so I assumed that could be used for some kind of optimization. But now that I think of it, maybe they're still a bit too fast for that. Damn, just when you thought you knew it all. ;) |
| |
Oswald
Registered: Apr 2002 Posts: 5094 |
Dawnfall style is done by using predefined patterns of various widths of lines of stripes drawn in slopes. :) so its basically lda eor sta, but the theory is more complicated than that.
ie one stripe looks like: AAAAABBBBBBAAAAAABBBBBB. It also uses the trick that's used to make the dawnfall texture mapper. basically you store the texture 4 times, each 1 multicolor pixel shifted horizontally.
so fex:
abcd efgh ijkl
you have the above 1 line texture stored 4 times shifted to the left:
abcd efgh ijkl
xabc defg hijk l
xxab cdef ghij kl
xxxa bcde fghi jkl
now lets zoom it with picking the right bytes:
abcd defg ghij
(each letter is one multicolor pixel) |
| |
WVL
Registered: Mar 2002 Posts: 902 |
@cruzer : it's definately not an EOR-filler. |
| |
LHS
Registered: Dec 2002 Posts: 66 |
Indeed, in the Krill's 4k intro this part is really cool! |
| |
Krill
Registered: Apr 2002 Posts: 2980 |
SHUT UP ALL OF YOU.. :)
(got some code cooking on the back burner here)
LHS: Thanks :)
Jackasser, HCL: Er, i got the source here, but back in the days i thought i was too leet for comments.. :) What Oswald said is basically right, some modified zoom-table approach for lda eor sta code, which comes with all the good and bad parts. Like speed and visual artefacts and such. :) |
| |
Cruzer
Registered: Dec 2001 Posts: 1048 |
Thanks for the explaination Oswald, I think I'm starting to get it. Pretty clever, as with everything Graham has invented.
|
| |
Krill
Registered: Apr 2002 Posts: 2980 |
Yeah. |
| |
LHS
Registered: Dec 2002 Posts: 66 |
Hey Oswald, I often wondered about this zoom technique, Krill explained it to me at a Padua meeting, but only from your example I understand it ;-) |
| |
JackAsser
Registered: Jun 2002 Posts: 2014 |
Quote: Hey Oswald, I often wondered about this zoom technique, Krill explained it to me at a Padua meeting, but only from your example I understand it ;-)
Now generalize that technique in two dimensions and you understand that you can zoom in the y-direction aswell.
Further more, realize that if you can pick chars to zoom you can also pick the chars so the display rotate just a tiny bit, f.e. by letting the adjacent char be one line down you get a slope of 1/8.
Now do some calculus how much you can slope using the same charset before too many errors occur and figure out when and how to switch charsets and you're extremly close to how the rotator in f.e. Amplifire and Mekanix work (i.e. the one in the beginning, not the chess zoomer). |
| |
WVL
Registered: Mar 2002 Posts: 902 |
Good, now i don't have to explain it any longer :D |
| |
JackAsser
Registered: Jun 2002 Posts: 2014 |
Quote: Good, now i don't have to explain it any longer :D
Well, still havn't explained why connecting rotation to zooming is a speed optimization, but it's quite simple:
A general roto-zoomer steps along Ux,Uy,Vx and Vy in the texture, per pixel. The U- and V- vectors are most often perpendicular to each other (i.e. the texture is just rotated/zoomed and not scewed or sheared).
Now to calculate the vectors one usually do something like:
Ux = cos(a)/zoom
Uy = sin(a)/zoom
Vx = Uy
Vy = -Vx
And the code in the plot loop:
for (int y=0; y<height; y++)
for (int x=0; x<width; x++)
{
int tx = x*Ux + y*Uy;
int ty = x*Vx + y*Vy;
screen[x+y*screenStride] = texture[tx+ty*textureStride];
}
But if you ignore zoom for a moment and consider the following vectors instead (imagine we move the vector around a square instead, the following code applies for moving along the top-edge):
Ux = a
Uy = 1
Vx = Uy = 1
Vy = -Vx = -a
Now, moving like this will result in differently scaled vectors, i.e. not unit size (or 1/zoom as in the previous example). I.e. there is an implicit zooming connected to the rotation like in PFP and Mekanix.
Plot code:
for (int y=0; y<height; y++)
for (int x=0; x<width; x++)
{
int tx = x*a + y;
int ty = -x + y*a;
screen[x+y*screenStride] = texture[tx+ty*textureStride];
}
As you see, one of the multiplications per component has been optimized away. Yay! Per pixel/char/unit/bum tx and ty only changes additively by a.
@WVL: Now I know you don't explain it like this, but this is what it becomes if you take it from the normal roto zoomer perspective.
|
| |
Skate
Registered: Jul 2003 Posts: 494 |
I know a different approach for rotators like these but I'm still working on it to add a flexable zoom ability. I don't know if my approach will work or not. I'm not actively working on it, either. But if it works, I'll tell you the details in the demo note file. ;) |
| |
LHS
Registered: Dec 2002 Posts: 66 |
About the mentioned texture mapper in Dawnfall, which rastertimer uses this efect?
One logo about 30*10 chars, two logos about 30*5 chars, zooming by the duplication of the edge pixels, any line of these logos however zoomed in arbitrary line of screen... FPP or FPD timer doesn't give this resolution. Or not?
Footnote: specially in the Dawnfall, this part is one of the early in onefile demo, I don't suppose use of all 4 VIC banks. |
| |
Oswald
Registered: Apr 2002 Posts: 5094 |
it's lda sta code. also dont forget you can also shrink by hiding the "edge" pixels. but better not think about it this way or it will fool you. the whole texture can be shifted trough the bytes and any pixel can be doubled, depends on the shift&zoom. |