Graph Paper

Share graphical tips, notes and queries related to our favourite screen layout and its editors.
User avatar
Posts: 86
Joined: Mon Nov 13, 2017 8:50 am
Location: Bristol

Re: Graph Paper

Post by Morkin » Fri Dec 08, 2017 1:36 pm

R-Tape wrote:
Sat Dec 02, 2017 10:30 pm
Rorthron wrote:
Sat Dec 02, 2017 6:53 pm
No. I built an Excel spreadsheet for the whole screen, manually input each pixel as a 1 or 0 and used formulae to convert these into a string of values for 0x4000 and beyond (I hope I got that right).
Rorthron wrote:
Sat Dec 02, 2017 6:53 pm
I did something similar for the attributes.
I'm struggling to visualise this (I get the pixels), I'll have to try it. How on earth did you decide how to place the attributes? DId ZX-Paint not come into this somewhere?!
Rorthron's 'graphics-by-Excel'...


A couple of the formulas were wrong unfortunately... I was going to ask him to correct them without telling him which were wrong, but I thought it might give him a nervous breakdown... :lol:
1 x

Posts: 83
Joined: Tue Nov 14, 2017 10:26 am

Re: Graph Paper

Post by Joefish » Fri Dec 08, 2017 2:30 pm

Joefish wrote:
Sun Dec 03, 2017 4:32 am
The sprites and font in Buzzsaw+ were designed as binary data statements in the PASMO listing!
R-Tape wrote:
Sun Dec 03, 2017 3:26 pm
It works! Though I assumed you used contemporary packages, I pictured you agonising over every pixel for months.
I wrote a sprite routine to display the 16x16 sprites, then cut and pasted a load of 00000000b,00000000b lines into the code, switched the edit cursor to overwrite and typed in the 1s I wanted, compiling and running every so often to see what they looked like! Nothing was done in an art package or on paper. To be honest, when you are trying to see what can be achieved with narrow attributes and you're changing one pixel at a time back and forth for ages, it doesn't really matter what you're doing it in - the only thing that counts is what it looks like when you display it in the game. Particularly for attributes - you can fiddle with some mouse-driven setting system or just overtype 1s and 0s in your data - it doesn't take any longer, and in some ways it's easier as you don't then have the hassle of translating your images into code later on.

The original LDI version of my multicolour code could only change every second attribute on every second line, so the atttributes were 8x2 but offeset one pixel vertically in the two halves of the sprite. You can still see the after-effects of designing that way in the sprites, particular on levels 5-10 where the sprites have coloured masks and headbands that don't always go straight across.

The font was done the same way - loads of 00000000b in blocks of 8 with a comment to say which character it is, filled in with 1s by hand!

I have gone onto the graph paper for my Bertrand Bubblethwaite sprites, to get the hang of designing for 8x2 multicolour. This involves scrolling though so it's getting tricky to work out what can go where. And although I can sketch out animations on paper or in a paint program, there's still no substitute for actually seeing them animated in the game code. And given that I'm going for Manic Miner-style, combining the animation with the pre-shifting, that means I need a moving sprite routine up and running to start with.
0 x

Post Reply