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 > Three pixel period pattern on upper/lower border
2010-04-10 16:24
Monte Carlos

Registered: Jun 2004
Posts: 359
Three pixel period pattern on upper/lower border

Any idea, how to create a hires pattern like this:

110110110110110110110110110110110110...

on the upper/lower border over the full width. Every trick allowed.

Btw: $3fff trick does not work, because then the pattern has a period of eight instead of three. Sprites cover only a width of 192 pixels!

Thank you Monte!
 
... 16 posts hidden. Click here to view all posts....
 
2010-04-11 17:41
Oswald

Registered: Apr 2002
Posts: 5094
looking at the above ascii art gave me an idea:

bb0aa0bb
0bb0aa0b
a0bb0aa0
aa0bb0aa


sprites are X stretched, aa is made of sprite '1', bb is made of sprite '2', 0 is background, change the X coords each line to get the tilt effect, and you're done!! :D

edit: oh, I do realize the above is not the wanted pattern :) ok how about then:

aa0bb0aa0bb
aa0bb0aa0bb
aa0bb0aa0bb
aa0bb0aa0bb
aa0bb0aa0bb

tech teching is not needed, even simpler, tho full width is not possible... :/

edit2: ok case SOLVED!!!!

aa is made of X stretched sprites, and bb is made of $3fff. the bb pattern is 8 bits: bb0000bb, and the aa pattern is 8 bits aswell aa0000aa, only the sprite X coords are used to push them in place.

I is teh win! :)
2010-04-11 17:58
Hein

Registered: Apr 2004
Posts: 954
wow, was that your dream, Oswald? I'm affraid bb will shine through..
2010-04-11 18:51
WVL

Registered: Mar 2002
Posts: 902
oswald, what have you been using? :D

Think about your patterns again, and then draw how it should work for > 1 char please.. ;)
2010-04-11 18:53
Oswald

Registered: Apr 2002
Posts: 5094
oh shit >1 char case is wrong indeed :D
2010-04-11 18:58
JackAsser

Registered: Jun 2002
Posts: 2014
You can extend the correct pattern 7 or 8 lines into the lower border if you like. :) No further though.
2010-04-11 19:02
Oswald

Registered: Apr 2002
Posts: 5094
12345678123456781234567812345678
aa0000aa0000aa0000aa0000aa
   bb0000bb0000bb0000bb0000bb
   12345678
aa0bb0aa0bb0aa0bb0aa0bb0aa0bb


needed patterns:

aa0000
bb0000

:/
2010-04-11 19:41
Monte Carlos

Registered: Jun 2004
Posts: 359
Oh wow, i'm really overwhelmed by all those replies.
Thought i have to repeat, that all the pixels are meant to be in a single rasterline. Anyway, a x size of 243 pixels would be enough instead of full width.

I make a short summary:

Skate: Use unexpanded hires sprites, leave 8 pixel gaps between sprites. -> The $3fff pattern is always black, the sprites are white or black. In any case, some pixels of the $3fff pattern must be anulled, some pixels in white must be added. As the sprite is single color, this does not work.

Monte Carlos: Use expanded single color sprites over $3fff -> If the sprites are white, the double pixels of the sprites cannot be half hidden by the $3fff raster at all positions.
If the sprites are black, no white pixels can be added -> failed

Oswald: Use shifted expanded single color sprites over $3fff pattern. Leave 4 pixel gaps and fill then in the middle -> The x size is not large enough. The intended $3fff pattern has a period of six instead of eight and is therefore not possible.

2010-04-11 21:07
Skate

Registered: Jul 2003
Posts: 494
@Monte Carlos: Thanks for the nice puzzle. You can have this pattern by using some kind of an interlace mode (toggling X position of expanded sprites by 3 pixel each frame). But that would look awful of course :)
2010-04-12 10:26
Frantic

Registered: Mar 2003
Posts: 1648
I am not really a VIC coder, so I probably miss something, but couldn't you use unexpanded sprites and then 16 pixel gaps between the sprites, which shows two instances of the $3fff byte.

...and then you change the pattern of $3fff exactly at the cycle where the second $3fff byte in each pair of $3fff bytes would be shown, in order to make the first byte different from the second, in each pair. I think that would be each 5:th cycle (the sprite is 3 chars wide, and then there are 2 chars width of 3fff bytes = 5 chars = 5 cycles), so you should be able to do it in time. Yeah?

If so, then you would have 8*24 pixels from the sprite, and for each sprite there would also be 8*2*8 pixels from the 3ffff bytes:

(8*24)+(8*16) = 320 pixels

Perhaps someone said this already, or perhaps I did indeed miss something. I didn't really think hard now...
2010-04-12 10:38
Skate

Registered: Jul 2003
Posts: 494
@Frantic: Your approach is the better version of mine but fails for the same reason. $3fff will be visible on sprite areas as well. So you cannot get that pattern correctly even if you can get the correct pattern for the gaps.

Btw, changing $3fff every 5th cycle is trickier than every 4th cycle.

lda #%11011011
ldx #%01101101
ldy #%10110110
sta $3fff-%01101101,x ; 5 cycles
stx $3fff ; 4 cycles
sty $3fff ; 4 cycles

It can be possible but harder. Illegal opcodes should help I guess.
Previous - 1 | 2 | 3 - Next
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
ΛΛdZ
Bob/Censor Design
Worluk
Mihai
REBEL 1/HF
Sychamis
BokanoiD
B.A./QUANTUM
Quetzal/Chrome
Narciso
Guests online: 145
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 Triad  (9.3)
5 Censor Design  (9.3)
Top Musicians
1 Rob Hubbard  (9.7)
2 Mutetus  (9.7)
3 Jeroen Tel  (9.7)
4 Linus  (9.6)
5 Stinsen  (9.6)

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