Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
You are not logged in - nap
CSDb User Forums


Forums > C64 Coding > rotating chessboard
2010-10-14 07:43
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?
2010-10-14 08:15
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.
2010-10-14 08:41
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.
2010-10-14 10:47
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.
2010-10-14 11:01
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
2010-10-14 11:11
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.
2010-10-14 11:31
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 =)
2010-10-14 11:35
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.
2010-10-14 11:38
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.
2010-10-14 12:51
Mace

Registered: May 2002
Posts: 1799
@WVL: I'm interested as long as it doesn't mean that I have to make one afterwards ;-)
2010-10-14 12:58
chatGPZ

Registered: Dec 2001
Posts: 11386
hihi
2010-10-14 13:00
WVL

Registered: Mar 2002
Posts: 902
crap.
2010-10-14 13:04
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).
2010-10-14 13:06
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
2010-10-14 13:20
HCL

Registered: Feb 2003
Posts: 728
Yeah, how does that chess-zoomer in DeM and Dawnfall worx? I always wondered :). Graham?
2010-10-14 13:39
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
2010-10-14 14:30
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. ;)
2010-10-14 14:33
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)
2010-10-14 14:59
WVL

Registered: Mar 2002
Posts: 902
@cruzer : it's definately not an EOR-filler.
2010-10-14 18:24
LHS

Registered: Dec 2002
Posts: 66
Indeed, in the Krill's 4k intro this part is really cool!
2010-10-14 19:05
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. :)
2010-10-14 19:38
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.
2010-10-14 19:42
Krill

Registered: Apr 2002
Posts: 2980
Yeah.
2010-10-15 05:30
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 ;-)
2010-10-15 06:07
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).
2010-10-15 11:51
WVL

Registered: Mar 2002
Posts: 902
Good, now i don't have to explain it any longer :D
2010-10-15 12:08
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.
2010-10-15 12:32
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. ;)
2010-10-18 05:33
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.
2010-10-18 07:21
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.
RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Advanced
Users Online
kbs/Pht/Lxt
Tom/TRS
DeMOSic/MS^LSD^ONS
Acidchild/Padua
megasoftargentina
Jason Page/MSL
Tom-Cat/Nostalgia
Mike
Unicorn/TWA
Guests online: 101
Top Demos
1 Next Level  (9.7)
2 13:37  (9.7)
3 Mojo  (9.7)
4 Coma Light 13  (9.6)
5 Edge of Disgrace  (9.6)
6 What Is The Matrix 2  (9.6)
7 The Demo Coder  (9.6)
8 Uncensored  (9.6)
9 Comaland 100%  (9.6)
10 Wonderland XIV  (9.6)
Top onefile Demos
1 No Listen  (9.6)
2 Layers  (9.6)
3 Cubic Dream  (9.6)
4 Party Elk 2  (9.6)
5 Copper Booze  (9.6)
6 Dawnfall V1.1  (9.5)
7 Rainbow Connection  (9.5)
8 Onscreen 5k  (9.5)
9 Morph  (9.5)
10 Libertongo  (9.5)
Top Groups
1 Performers  (9.3)
2 Booze Design  (9.3)
3 Oxyron  (9.3)
4 Censor Design  (9.3)
5 Triad  (9.3)
Top Webmasters
1 Slaygon  (9.6)
2 Perff  (9.6)
3 Sabbi  (9.5)
4 Morpheus  (9.4)
5 CreaMD  (9.1)

Home - Disclaimer
Copyright © No Name 2001-2024
Page generated in: 0.207 sec.