After writing this I'm fairly certain I would have screwed up the rules without it. Trying to detect mistakes from the behaviour of the rules would be nearly impossible I think..
Mouse over cells to see the matches.
Thursday, October 8, 2015
Symmetry
I'm making a Cellular Automata on a hex grid. Before I actually write the code for the cells I had to write this visualisation to ensure I got the rules correct, The same rule should apply for all cells of the same structure regardless of orientation, so all rotations and flips get the same rule.
Wednesday, September 30, 2015
Charged Particles
I wrote this little program while I waited for some SDKs to download. It's just a toy to play with the dynamics of charged particles. While not directly accurate to any real world physical model (not least because it is only 2D), it can demonstrate some principles of chemistry. The principles of molecules and chemical reactions can be seen as charged particles attract, assemble and react to the presence of new charges.
Left, Middle, and Right mouse buttons place particles of -1, random, +1 respectively
Use number keys 1-9 & 0 to place particles in a range of -1 to +1
Wednesday, September 16, 2015
Stack Machine generated Textures
This is something I made Just a few weeks ago. You feed it Strings and it gives you Textures, It's not an easy thing to use but I find it quite fun. The goal was to provide the ability to include small textures inside code.
The images are generated in a reverse polish notation stack expression. The expression is calculated for every pixel in the image, with x and y indicating the current pixel location within the image. The codes that stackie understands are:
x : push x (x is in range 0...1)
y : push y (y is in range 0...1)
0...9 : push constant 0...9
P : push PI
d : duplicate top item on the stack
: : swap top two items on the stack
; : swap top and third items on the stack
s : sin
c : cos
q : sqrt
~ : abs
! : flip 1-a implemented as push(1-pop())
# : round to nearest integer
? : threshold ( value<=0 becomes 0, value>0 becomes 1 );
p : perlin noise (using top two stack values)
w : wraparound perlin noise using three stack valuesx,y,size
W : wraparound perlin noise using 4 stack values x,y,x_size, y_size
a : atan2
+ : add
- : subtract
* : multiply
/ : divide
^ : pow
> : max
< : min
While the final strings can look incomprehensible, writing a texture code is easier than it seems. You can build it up by constructing simple pieces and mixing them together
x and y make simple vertical and horizontal gradients.
! inverts the value
Multiply two gradients together, or add them together and divide by 2 for a simple average
p generates perlin noise. For higher frequency noise multiply the x and y values by a scale factor
By combining simple sequences together you can construct more complex images.
Have a play around with it in the iframe
Stackie is on github
The images are generated in a reverse polish notation stack expression. The expression is calculated for every pixel in the image, with x and y indicating the current pixel location within the image. The codes that stackie understands are:
x : push x (x is in range 0...1)
y : push y (y is in range 0...1)
0...9 : push constant 0...9
P : push PI
d : duplicate top item on the stack
: : swap top two items on the stack
; : swap top and third items on the stack
s : sin
c : cos
q : sqrt
~ : abs
! : flip 1-a implemented as push(1-pop())
# : round to nearest integer
? : threshold ( value<=0 becomes 0, value>0 becomes 1 );
p : perlin noise (using top two stack values)
w : wraparound perlin noise using three stack valuesx,y,size
W : wraparound perlin noise using 4 stack values x,y,x_size, y_size
a : atan2
+ : add
- : subtract
* : multiply
/ : divide
^ : pow
> : max
< : min
While the final strings can look incomprehensible, writing a texture code is easier than it seems. You can build it up by constructing simple pieces and mixing them together
 |
 |
| x | y |
 |
 |
| x! | y! |
 |
 |
| xy* | xy+2/ |
 |
 |
| xyp | x8*y8*p1+2/ |
 |
 |
| x9^ | y9^ |
 |
 |
| x9^ y9^ + | x9^ y9^ + x!9^ y!9^ + + |
By combining simple sequences together you can construct more complex images.
 |
 |
| x8* y3* p 1+ | x9^ x!9^ + y! + + |
 |
 |
| x8* y3* p 1+ x9^ x!9^ + y! + - | Palette xy!1+* |
Stackie is on github
Tuesday, September 15, 2015
8 bit machine
I have been making a 8 bit emulator for a non existent machine. The specs of the machine are
There is a 512x392 24bit FrameBuffer that exists as a necessity for rendering onto a canvas. The CPU does not have direct access to the buffer and cannot read from it at all.
If I were writing an emulator that was closer to 8-bit machines of years past, There would be no framebuffer. In those days Pixels were all about timing. You coloured the pixel as the video beam went past. Video chips (or sometimes the CPU itself) had do construct the image line-by-line. Few systems had enough memory to hold a completed grid of pixels ready to go.
The transience of the display was also an advantage for those old machines. By changing the video hardware parameters during the screen update you can achieve a variety of effects. Display hardware that could show a limited number of sprites could have more appear on screen than there actually were, because you can shift them around after the video beam has passed in order to be seen by the beam a second time later down the screen. You could bend and colour things on the screen using similar so-called raster effects. What was an advantage for the old is however a disadvantage for the new. Emulators that strive for accurate emulation of old video hardware must put in a great deal of extra work to measure the timing and to generate an image from an emulated video beam on an emulated video display. Usually emulators will have to do this to fill a FrameBuffer image that will be placed on-screen by the operating system as a single bulk operation.
I decided to make the FrameBuffer a defined part of this emulator in order to reduce the workload of the emulator, It means the raster effects of old video displays will not be possible but in return there will be some advantages for the machine where it can construct a frame at a time instead of as a series of sequential pixels.
The FrameBuffer that the emulator uses is 802,816 bytes. In its raw form it would be cumbersome and slow for an 8 bit processor to write to. The CPU interface to the FrameBuffer aims to allow as much as possible for as little data and processing as possible.
There are 16 I/O ports associated with the video output ( Currently based at I/O port 0x20, may change ).
The CPU controls when the virtual Framebuffer is transferred to the screen. Writing a zero to port drawFrameBuffer will show the lowres portion of the framebuffer (pixel doubled). writing a one will show a 480x360 portion of the framebuffer. In the framebuffer to screen transfer the top left corner of the source can be offset by the displayShift register. 4-bits of x and 4-bits of y. This allows for 16 pixels of horizontal and vertical 'hardware' scrolling.
Writing values 0x10 or higher will fill the framebuffer with data from CPU ram using different display modes. So far I have only defined one mode. A 1.777 bit per pixel (9 pixels per 2 bytes) as per many old 8-bit systems colour data and pixel attribute data can be treated differently and the starting address for reading either can be adjusted, Adding individual increment and line increment allows the structure of the data to be arranged and optionally interleaved to assist the task at hand.
To show you my thinking on this design, I'll first go into a quick overview of how things used to be done. Display modes on old 8 bit computers varied quite a great deal. A large part of their design was structured around how to get the most expressive images from the fewest bytes. It would have been less work for video hardware to read a single pixel and output it to the screen and repeat the process for every pixel on-screen. Unfortunately, the cost of the ram would have been prohibitive and the CPUs of the day would have been far too slow to move that amount of memory around anyway. The simplest alternative was the bit-per-pixel display where memory was loaded into a register and then shifted off one bit at a time to make pixels. But that only got you on or off pixels. You didn't have colour. There were many ways to add colour for just a little more data, The ZX-Spectrum took the extremely simple approach of sharing the same colour value for 64 pixels. An 8x8 block of pixels then used 8 bytes for the pixels and an additional byte for the colour (averaging 1.125 bits per pixel) . It got you colour but it also got you attribute clash. Other systems fared better than the spectrum largely due to the presence of sprites. Sprites were rendered onto the display independently of the main screen data so did not have to worry about attributes, They conserved memory from the simple fact that they were not very large. The C-64 and some other systems let you double the pixels of your sprites essentially allowing them to cover more space for zero cost in storing or fetching memory. Sprites enabled consoles to go even further, They eschewed even the bit per pixel approach and embraced tiled displays. This was extending the concept of colour attributes back to the pixels themselves. You could only change the screen data a cell at a time. This makes it very hard to do independently moving objects, but that task was almost completely handed over to sprites. The data savings gained by reducing the flexibility was spent on adding more colours.
The tl;dr of all that is This: If you can make a better looking image at the cost of being able to manipulate it, that's not so bad if you can draw on top of it afterwards.
For Mode-0 in my emulator I use two bytes per 3x3 cell. One byte is colour data. Colour A gets 4 bits, Colour B gets 4 bits. A and B are colours in the first 16 entries of the palette. The other byte is the pixel data. Top left pixel is always colour A, the other 8 pixels in the cell correspond to A or B depending on if the Bit in the pixel data is a zero or a one. All pixels are individually modifiable. Flipping a bit in the pixel data can change a single pixel on 8 of the 9. The top-left is a special case where it can be toggled by swapping A and B and Flipping all the pixel data bits. This gives a 1.77 bit per pixel display with the limitations that only 2 colours may appear in any 3x3 cell. It uses slightly more data than the ZX-Spectrum approach but has significantly less potential for attribute clash. It has the additional cost of being rather awkward to address. Which is why we draw things on top...
Instead of implementing sprites as a structured display hardware sprite system, The existence of a FrameBuffer allows the CPU to provide a sprite-like layer in a more direct manner. The display interface has an address for writing to pixels directly. In addition to being able to set individual pixels in this manner it also allows a limited amount of blending. Writing a byte of data to the serialPixel_set, serialPixel_mul, and serialPixel_add triggers a set, multiply or add using a palette colour. To a sprite where some pixels are transparent you can set the non-transparent pixels and add 0 for the transparent pixels (to advance the pixel write address). If you consider palette colours as being premultiplied alpha, You can use a combination of multiply and add to render variable levels of transparency, You can theoretically write the entire screen with this process, but the CPU cost would be substantial. Using it as a sprite-style solution means you can gain flexibility at a few places where you most need it.
Pixel values written to set, mul, and add ports are taken from a fixed 256 colour palette. The first 16 colours are from Arne's 16 colour palette. The rest of the palette contains a greyscale and a 6x6x6 colour cube where the gradients of the red green and blue components have been shifted to more equally match brightness (to avoid a preponderance of dark blue etc.)
I'll probably add a few more varied screen modes soon, Next up should be mouse, keyboard and time though. Then I can make some games in it.
This is the emulator as it stands right now.
It still lacks a few Instructions, and undoubtedly has minor bugs in some of the implemented ones, but it is running my sample program ok.
| Processor | 8-bit AVR |
| Intruction Set | Arduino Compatible |
| Program Memory | 128k (0000-FFFF x 16-bit) |
| RAM | 64k (0000-FFFF x 8-bit) |
| Display | 480x360 / 240/180 |
There is a 512x392 24bit FrameBuffer that exists as a necessity for rendering onto a canvas. The CPU does not have direct access to the buffer and cannot read from it at all.
If I were writing an emulator that was closer to 8-bit machines of years past, There would be no framebuffer. In those days Pixels were all about timing. You coloured the pixel as the video beam went past. Video chips (or sometimes the CPU itself) had do construct the image line-by-line. Few systems had enough memory to hold a completed grid of pixels ready to go.
The transience of the display was also an advantage for those old machines. By changing the video hardware parameters during the screen update you can achieve a variety of effects. Display hardware that could show a limited number of sprites could have more appear on screen than there actually were, because you can shift them around after the video beam has passed in order to be seen by the beam a second time later down the screen. You could bend and colour things on the screen using similar so-called raster effects. What was an advantage for the old is however a disadvantage for the new. Emulators that strive for accurate emulation of old video hardware must put in a great deal of extra work to measure the timing and to generate an image from an emulated video beam on an emulated video display. Usually emulators will have to do this to fill a FrameBuffer image that will be placed on-screen by the operating system as a single bulk operation.
I decided to make the FrameBuffer a defined part of this emulator in order to reduce the workload of the emulator, It means the raster effects of old video displays will not be possible but in return there will be some advantages for the machine where it can construct a frame at a time instead of as a series of sequential pixels.
The FrameBuffer that the emulator uses is 802,816 bytes. In its raw form it would be cumbersome and slow for an 8 bit processor to write to. The CPU interface to the FrameBuffer aims to allow as much as possible for as little data and processing as possible.
There are 16 I/O ports associated with the video output ( Currently based at I/O port 0x20, may change ).
| + 0x00 | pixelData_diaplayStart_L | |
|---|---|---|
| + 0x01 | pixelData_displayStart_H | 16-bit address |
| + 0x02 | colorData_displayStart_L | |
| + 0x03 | colorData_displayStart_H | 16-bit address |
| + 0x04 | pixeldata_increment | |
| + 0x05 | colorData_increment | |
| + 0x06 | pixelData_lineIncrement | value << 3 to make 11-bits |
| + 0x07 | colorData_lineIncrement | value << 3 to make 11-bits |
| + 0x08 | displayShift XY | 4-bits X, 4-bits Y |
| + 0x09 | serialPixel_address_L | FrameBuffer pixel number |
| + 0x0A | serialPixel_address_M | |
| + 0x0B | serialPixel_address_H | 24 bit address |
| + 0x0C | serialPixel_set | pixel=palette[v], serialPixelAddress+=1 |
| + 0x0D | serialPixel_mul | pixel.rgb=(pixel.rgb*palette[v].rgb) >> 8 (does not advance address) |
| + 0x0E | serialPixel_add | pixel.rgb+=palette[v].rgb, serialPixelAddress+=1 (clamped add) |
| + 0x0F | drawFrameBuffer | 0=lowRes, 1=hires, 0x10=Mode 0 |
The CPU controls when the virtual Framebuffer is transferred to the screen. Writing a zero to port drawFrameBuffer will show the lowres portion of the framebuffer (pixel doubled). writing a one will show a 480x360 portion of the framebuffer. In the framebuffer to screen transfer the top left corner of the source can be offset by the displayShift register. 4-bits of x and 4-bits of y. This allows for 16 pixels of horizontal and vertical 'hardware' scrolling.
Writing values 0x10 or higher will fill the framebuffer with data from CPU ram using different display modes. So far I have only defined one mode. A 1.777 bit per pixel (9 pixels per 2 bytes) as per many old 8-bit systems colour data and pixel attribute data can be treated differently and the starting address for reading either can be adjusted, Adding individual increment and line increment allows the structure of the data to be arranged and optionally interleaved to assist the task at hand.
To show you my thinking on this design, I'll first go into a quick overview of how things used to be done. Display modes on old 8 bit computers varied quite a great deal. A large part of their design was structured around how to get the most expressive images from the fewest bytes. It would have been less work for video hardware to read a single pixel and output it to the screen and repeat the process for every pixel on-screen. Unfortunately, the cost of the ram would have been prohibitive and the CPUs of the day would have been far too slow to move that amount of memory around anyway. The simplest alternative was the bit-per-pixel display where memory was loaded into a register and then shifted off one bit at a time to make pixels. But that only got you on or off pixels. You didn't have colour. There were many ways to add colour for just a little more data, The ZX-Spectrum took the extremely simple approach of sharing the same colour value for 64 pixels. An 8x8 block of pixels then used 8 bytes for the pixels and an additional byte for the colour (averaging 1.125 bits per pixel) . It got you colour but it also got you attribute clash. Other systems fared better than the spectrum largely due to the presence of sprites. Sprites were rendered onto the display independently of the main screen data so did not have to worry about attributes, They conserved memory from the simple fact that they were not very large. The C-64 and some other systems let you double the pixels of your sprites essentially allowing them to cover more space for zero cost in storing or fetching memory. Sprites enabled consoles to go even further, They eschewed even the bit per pixel approach and embraced tiled displays. This was extending the concept of colour attributes back to the pixels themselves. You could only change the screen data a cell at a time. This makes it very hard to do independently moving objects, but that task was almost completely handed over to sprites. The data savings gained by reducing the flexibility was spent on adding more colours.
The tl;dr of all that is This: If you can make a better looking image at the cost of being able to manipulate it, that's not so bad if you can draw on top of it afterwards.
For Mode-0 in my emulator I use two bytes per 3x3 cell. One byte is colour data. Colour A gets 4 bits, Colour B gets 4 bits. A and B are colours in the first 16 entries of the palette. The other byte is the pixel data. Top left pixel is always colour A, the other 8 pixels in the cell correspond to A or B depending on if the Bit in the pixel data is a zero or a one. All pixels are individually modifiable. Flipping a bit in the pixel data can change a single pixel on 8 of the 9. The top-left is a special case where it can be toggled by swapping A and B and Flipping all the pixel data bits. This gives a 1.77 bit per pixel display with the limitations that only 2 colours may appear in any 3x3 cell. It uses slightly more data than the ZX-Spectrum approach but has significantly less potential for attribute clash. It has the additional cost of being rather awkward to address. Which is why we draw things on top...
Instead of implementing sprites as a structured display hardware sprite system, The existence of a FrameBuffer allows the CPU to provide a sprite-like layer in a more direct manner. The display interface has an address for writing to pixels directly. In addition to being able to set individual pixels in this manner it also allows a limited amount of blending. Writing a byte of data to the serialPixel_set, serialPixel_mul, and serialPixel_add triggers a set, multiply or add using a palette colour. To a sprite where some pixels are transparent you can set the non-transparent pixels and add 0 for the transparent pixels (to advance the pixel write address). If you consider palette colours as being premultiplied alpha, You can use a combination of multiply and add to render variable levels of transparency, You can theoretically write the entire screen with this process, but the CPU cost would be substantial. Using it as a sprite-style solution means you can gain flexibility at a few places where you most need it.
Pixel values written to set, mul, and add ports are taken from a fixed 256 colour palette. The first 16 colours are from Arne's 16 colour palette. The rest of the palette contains a greyscale and a 6x6x6 colour cube where the gradients of the red green and blue components have been shifted to more equally match brightness (to avoid a preponderance of dark blue etc.)
I'll probably add a few more varied screen modes soon, Next up should be mouse, keyboard and time though. Then I can make some games in it.
This is the emulator as it stands right now.
It still lacks a few Instructions, and undoubtedly has minor bugs in some of the implemented ones, but it is running my sample program ok.
Sunday, September 13, 2015
One from the past
I made this image more than 5 years ago. I posted it to /r/somebodymakethis
It seems appropriate to mention this around now. It appears somebody did. My motivation wasn't to stake a claim on the idea but to encourage it and hopefully prevent someone else jealously guarding the idea as their own private creation. Since I made the image, there have been a few active styluses turn up as third party devices. I doubt they copied my idea. I think it is more likely that it is a logical advance on touchscreen devices.
I haven't seen a great deal about the Apple Pencil yet, but I hope they have fully explored the potential beyond just a precise pointing device with pressure. The ability to use a stylus and a finger on the same surface and to be able to distinguish one from another adds a lot of options for user interface design. I mention in the image text a few of the possibilities I had imagined.
A program like SculptGL could make excellent use of fingers and stylus together. Rotate the model with your fingers and shape it with the stylus.
Sunday, September 6, 2015
Start
So here we are. I have made a Blog of sorts. I'm not naturally disposed to maintaining a regular journal, but I am someone who tends to make things and experiment with ideas. So this will be more for posting my creations and ideas. This will be predominantly technical and software oriented, but I might just throw in the occasional odd thing.
It is also worth noting that I happen to be a bit bi-polar, so I have a tendency to produce a bunch of things quickly then go into a down period where nothing happens. I have a strategy for handling this. It turns out that, by not creating this blog sooner, I have a substantial body of work that I can fall back on while I wallow in the pits of despair.
That means I'll be posting new things as I make them, and things from the mists of time that got made and then sat around not doing much. Perhaps some people will find them interesting.
It is also worth noting that I happen to be a bit bi-polar, so I have a tendency to produce a bunch of things quickly then go into a down period where nothing happens. I have a strategy for handling this. It turns out that, by not creating this blog sooner, I have a substantial body of work that I can fall back on while I wallow in the pits of despair.
That means I'll be posting new things as I make them, and things from the mists of time that got made and then sat around not doing much. Perhaps some people will find them interesting.
Subscribe to:
Posts (Atom)