I've decided to forgo studying Japanese this weekend in order to actually
attempt to write some original 2600 code. I'm not going to be doing
anything fancy. I'll just be drawing a picture with playfield graphics.
So I was prepairing for this work tonight by making myself some graph
paper for plotting the graphics on.
Now, correct me if I'm wrong, but the resolution for playfield graphics
would be 40x192. But, since one half of the screen is identical or
a mirror image of the other half (without getting into fancy tricks
like changing the playfield in mid scan) then I only need to have a
graph that is 20x192. So I made that.
But then I remembered what I had recently been told about most programmes
only updating the scan lines every two lines. This basically cuts the
vertical resolution in half. So I made myself a nice 20x96 grid.
But then I got thinking, "Hey, if I only change the playfield graphics
every x number of lines, I can save on memory. If I change it every
4 lines I'll only use 20x48 bits. If I change it every 6 lines I'll
only use 20x32 bits. And if I change it every 8 lines I'll only use
20x24 bits." Not bad, but of course the vertical on my playfield gets
blockier and blockier.
So I made myself 20x48, 20x32, and 20x24 grids.
Looking at a lot of the early games it looks like they probably went with
the 20x24 method. You could go with updating it every 16 lines but then
you only get a 20x12 grid. Not much you can do with that.
Anyways, I eventually refined all these grids down to one grid using
different colours for the lines on the grid to represet different
graphic modes.
Two things have occured to me...
1) It might be possible to set up a chunk of ram in the Supercharger as
psuedo-video ram for the playfield graphics if you have a game that
modifies the playfield graphics a lot with player interaction.
2) It might be possible to write a PC-Programme specifically for editing
playfield graphics.
It would have a 20x192 grid on it. You select from a menu if you want
to do graphics in 20x192, 20x96, 20x48, 20x32, or 20x24 mode.
It then modifies the grid to the selected graphic mode. You click on the
squares of the grid and it will toggle that bit on or off.
When you finish editing you can preview the playfield either in either
normal or mirror mode. The playfield graphics could then be saved as
a text file looking something like this
(example of for a 20x24 mode graphic)
LLLLL byte, $xx ; PF0
byte, $xx ;
byte, $xx ;
byte, $xx ;
byte, $xx ;
byte, $xx ;
byte, $xx ;
byte, $xx ;
byte, $xx ;
byte, $xx ;
byte, $xx ;
byte, $xx ;
byte, $xx ;
byte, $xx ;
byte, $xx ;
byte, $xx ;
byte, $xx ;
byte, $xx ;
byte, $xx ;
byte, $xx ;
LLLLL byte, $xx ; PF1
byte, $xx ;
byte, $xx ;
byte, $xx ;
byte, $xx ;
byte, $xx ;
byte, $xx ;
byte, $xx ;
byte, $xx ;
byte, $xx ;
byte, $xx ;
byte, $xx ;
byte, $xx ;
byte, $xx ;
byte, $xx ;
byte, $xx ;
byte, $xx ;
byte, $xx ;
byte, $xx ;
byte, $xx ;
LLLLL byte, $xx ; PF2
byte, $xx ;
byte, $xx ;
byte, $xx ;
byte, $xx ;
byte, $xx ;
byte, $xx ;
byte, $xx ;
byte, $xx ;
byte, $xx ;
byte, $xx ;
byte, $xx ;
byte, $xx ;
byte, $xx ;
byte, $xx ;
byte, $xx ;
byte, $xx ;
byte, $xx ;
byte, $xx ;
byte, $xx ;
You could maybe even include a binary representation of the data in the
rem segment. In anycase this text file could be cut and pasted into your
source code. You'd just have to go in and change the LLLLL to whatever the
actual location in your source code is, but that's not that difficult.
And it would sure as heck save on graph paper when it comes to editing
graphics.
Is this a doable thing? Would this be a helpful utility?
Would it work good for generic graphic purposes?
Or am I just completely screwed up in my understanding of playfield graphics.
Also, a PC sprite editor might be an option. Something where you specify
the vertical resolution of a sprite and then it gives you a grid of
8x??. You click on the grid squares to toggle them and then you can preview
the sprite in the different width modes. When you're done it saves the
data similar to the playfield editor so that you can easily cut and
paste the data into your source code.
I could probably sit down and write a programme to do this on the C-64...
That is, if my C-64 still works. But I don't think it would be that terribly
useful to any of us since I'm sure most of us are using PCs for our 2600
coding. unfortunately I know SFA about programming a PC. Does anyone out
there think they can do it? (that is, if it's even a worthwhile idea).
It seems to me that it would eliminate some of the tediousness from
programming 2600 graphics. I hate plotting stuff on graph paper and then
converting the binary images into hex.
So am I on to something or am I just talking out my ass?
CRACKERS
(buried under homemade graph paper from hell!!!!!)
--
Accordionist - Wethifl Musician - Atari 2600 Collector | /\/\
http://www.freenet.hamilton.on.ca/~ad329/Profile.html | \^^/
Bira Bira Devotee - FES Member - Samurai Pizza Cats Fan| =\/=
--
To unsubscribe, send the word UNSUBSCRIBE in the body of a message to
stella-request@xxxxxxxxxxx
