Hires Graphics
Moderator: Moderators
- Mike
- Herr VC
- Posts: 4888
- Joined: Wed Dec 01, 2004 1:57 pm
- Location: Munich, Germany
- Occupation: electrical engineer
How about this?GreyGhost wrote:Though not what I'd call random.
Code: Select all
1 S=1
2 @ON:@CLR
3 FORT=1TO65536
4 S=75*S:S=S-65537*INT(S/65537):R=S-1
5 IFR<30720THENY=INT(R/160):@1,R-160*Y,Y
6 NEXT
7 GETA$:IFA$=""THEN7
8 @RETURN
Michael
- Mike
- Herr VC
- Posts: 4888
- Joined: Wed Dec 01, 2004 1:57 pm
- Location: Munich, Germany
- Occupation: electrical engineer
This is number theory. The numbers from 0 to 65536 form a field, and 75 is relative prime to 65537 (the number of elements in the field).
That means:
is a sequence of numbers from 1 to 65536, which all appear exactly once (as you've guessed). The choice of the base 75 results in a seemingly random distribution. It is the same random generator that is used in the ZX81 and ZX Spectrum.
I then subtract 1 from the generated numbers to get a range from 0 to 65535, and then throw away all numbers from 30720 to 65535 as they don't correspond to pixels on the screen.
Michael
That means:
Code: Select all
k
S = 75 mod 65537
k
I then subtract 1 from the generated numbers to get a range from 0 to 65535, and then throw away all numbers from 30720 to 65535 as they don't correspond to pixels on the screen.
Michael
- Mike
- Herr VC
- Posts: 4888
- Joined: Wed Dec 01, 2004 1:57 pm
- Location: Munich, Germany
- Occupation: electrical engineer
MINIGRAFIK 4.02
New version 4.02 of MINIGRAFIK!
- The draw commands and the point test function now also support multi-colour mode,
- @SAVE, @LOAD commands have been added for disk and tape access,
- faster start-up time (no more slow POKEing into memory from READ-DATA statements during start-up).
Edit: The executable of MINIGRAFIK is now part of the MG batch suite. The manual of MINIPAINT also contains instructions for using MG commands in your own programs.
- The draw commands and the point test function now also support multi-colour mode,
- @SAVE, @LOAD commands have been added for disk and tape access,
- faster start-up time (no more slow POKEing into memory from READ-DATA statements during start-up).
Edit: The executable of MINIGRAFIK is now part of the MG batch suite. The manual of MINIPAINT also contains instructions for using MG commands in your own programs.
Last edited by Mike on Thu Mar 15, 2012 10:02 am, edited 2 times in total.
I haven't had a chance to test it yet but I copied and pasted the program into Power20 and saved the result out here. That should save you some typing. Being able to paste into the VIC's BASIC editor is such a lovely feature.
Update: Michael was kind enough to send me a working copy of the program along with the loader. Both are available on a d64 at the previously provided link.
Update: Michael was kind enough to send me a working copy of the program along with the loader. Both are available on a d64 at the previously provided link.
Last edited by gklinger on Wed Apr 02, 2008 9:22 am, edited 1 time in total.
In the end it will be as if nothing ever happened.
- Mike
- Herr VC
- Posts: 4888
- Joined: Wed Dec 01, 2004 1:57 pm
- Location: Munich, Germany
- Occupation: electrical engineer
I found a bug in version 4.01, in the newly introduced @SAVE command. A typical variant of code 'optimization' gone wrong, which in that case corrupts the colour RAM information of the saved image.
The bug has been fixed in 4.02.
Michael
Thanks to Michael, version 4.02 is available from http://www.vex.net/~falco/petscii/minigrafik.zip.
In the end it will be as if nothing ever happened.
- Mike
- Herr VC
- Posts: 4888
- Joined: Wed Dec 01, 2004 1:57 pm
- Location: Munich, Germany
- Occupation: electrical engineer
3D Pie Chart
Adding another 3D program for MINIGRAFIK, this is a pie chart:
Line 25 contains the number of pieces.
Code: Select all
10 REM ** 3D PIE CHART
11 READN:DIMA(N-1):S=0:FORT=1TON:READA:S=S+A:A(T-1)=S:NEXT
12 POKE36879,127:POKE646,2:@ON:@CLR:K1=79:K2=112
13 FORU=0TO56:V=INT(SQR(6241-U*U)+.5)
14 @1,K1+U,K1+V:@1,K1+U,K1-V:@1,K1-U,K1-V:@1,K1-U,K1+V
15 @1,K1+V,K1+U:@1,K1+V,K1-U:@1,K1-V,K1-U:@1,K1-V,K1+U
16 @1,K1+U,K2+V:@1,K1-U,K2+V:@1,K1+V,K2+U:@1,K1-V,K2+U
17 NEXT:@1,0,K1TO0,K2:@1,2*K1,K1TO2*K1,K2:@1,K1,K1TOK1,0
18 FORT=1TON-1:A=2*{PI}*A(T-1)/S:U=INT(K1*SIN(A)+.5):V=INT(K1*COS(A)+.5)
19 @1,K1,K1TOK1+U,K1-V:IFV<0THEN:@1,K1+U,K1-VTOK1+U,K2-V
20 NEXT
21 GETA$:IFA$=""THEN21
22 @RETURN:END
23 :
24 REM ** CHART DATA
25 DATA 8
26 DATA 3,8,4,5,5,7,1,9
Some questions about the MINIGRAFIK:
1) is its source code available?
2) why the odd screen size 20x24 which uses only 480 characters instead of the standard size 22x23 that uses 508 characters?
3) in your opinion, is this graphic mode suitable for developing games, like C16 and Plus4 games where there are no hardware sprites?
1) is its source code available?
2) why the odd screen size 20x24 which uses only 480 characters instead of the standard size 22x23 that uses 508 characters?
3) in your opinion, is this graphic mode suitable for developing games, like C16 and Plus4 games where there are no hardware sprites?
- Mike
- Herr VC
- Posts: 4888
- Joined: Wed Dec 01, 2004 1:57 pm
- Location: Munich, Germany
- Occupation: electrical engineer
1) is its source code available?
Yes. You are the first one who asks for this. Currently the source code uses the inline assembler of HI BASIC, and would need some work to port to DASM.
2) why the odd screen size 20x24 which uses only 480 characters instead of the standard size 22x23 that uses 508 characters?
When doing bitmapped graphics, one usually uses double-height characters to minimize the space for the text map. So MINIGRAFIK actually only uses 240 chars to display the graphics. MINIGRAFIK is designed to be interoperable with BASIC. The lower 1K therefore cannot be used to store the text map. MINIGRAFIK stores char map and bitmap entirely in the space $1000-$1FFF.
The maximum resolution possible under these circumstances derives as follows: you need 17 bytes (1 byte in the text map, 16 bytes char definition) to display a 8x16 block. 4096/17 ~= 240,9. 240 chars nicely fit into a 20x12 grid, which gives the 160x192 (=20*8 * 12*16) resolution. Since the pixels have a rectangular shape, you'll still also get an rectangular shape of the whole display.
3) in your opinion, is this graphic mode suitable for developing games, like C16 and Plus4 games where there are no hardware sprites?
Yes. VicTragic's Parachute uses this mode. Since the bitmap is built in column-major order, the addressing is indeed even simpler, than with the hires-mode on the other CBMs.
Greetings,
Michael
Yes. You are the first one who asks for this. Currently the source code uses the inline assembler of HI BASIC, and would need some work to port to DASM.
2) why the odd screen size 20x24 which uses only 480 characters instead of the standard size 22x23 that uses 508 characters?
When doing bitmapped graphics, one usually uses double-height characters to minimize the space for the text map. So MINIGRAFIK actually only uses 240 chars to display the graphics. MINIGRAFIK is designed to be interoperable with BASIC. The lower 1K therefore cannot be used to store the text map. MINIGRAFIK stores char map and bitmap entirely in the space $1000-$1FFF.
The maximum resolution possible under these circumstances derives as follows: you need 17 bytes (1 byte in the text map, 16 bytes char definition) to display a 8x16 block. 4096/17 ~= 240,9. 240 chars nicely fit into a 20x12 grid, which gives the 160x192 (=20*8 * 12*16) resolution. Since the pixels have a rectangular shape, you'll still also get an rectangular shape of the whole display.
3) in your opinion, is this graphic mode suitable for developing games, like C16 and Plus4 games where there are no hardware sprites?
Yes. VicTragic's Parachute uses this mode. Since the bitmap is built in column-major order, the addressing is indeed even simpler, than with the hires-mode on the other CBMs.
Greetings,
Michael
Michael thank you for the replies. I've learned something I didn't knew about double height mode, namely that is spans over 4K bitmap, where normal characters use only 2k.
Now I see why everything was made the way it is.
I instead assumed that the bitmap mode was made with a raster trick, by flipping 36868 between 253 and 254 at start and middle of the page, so that characters would be read from 5120 and 6144, overcoming the 2K bitmap limit.
And, yes, I am interested in the source, I need only the screen and pointers setup part.
Now I see why everything was made the way it is.
I instead assumed that the bitmap mode was made with a raster trick, by flipping 36868 between 253 and 254 at start and middle of the page, so that characters would be read from 5120 and 6144, overcoming the 2K bitmap limit.
And, yes, I am interested in the source, I need only the screen and pointers setup part.
The VIC-I chip itself can actually address up to 16K, of which 10K is present in a real VIC-20 (4K ROM, 1K colour nybbles, 5K RAM) and the rest is unconnected address space as explored in most recent demos.
Of course a fully bitmapped screen without using raster tricks could not be bigger than 256*16 = 4K, plus some memory for screen matrix and colour matrix, but with e.g. more RAM the bitmap could be double buffered.
Of course a fully bitmapped screen without using raster tricks could not be bigger than 256*16 = 4K, plus some memory for screen matrix and colour matrix, but with e.g. more RAM the bitmap could be double buffered.
Anders Carlsson