I watched your first program video, and it only reinforced my suspicions about the double frame buffer. In your video, you showed that all 4 red blocks were rendered at the same time in each stage, and you explained that the white wool of the 4 blocks (pixels, whatever) was replaced with red wool. Does this mean that the GPU can only render one color at a time? My reasoning for this is that if the logic is as simple as replacing everything in step 1 with a certain color, then you could only place objects in that step that are the same color. I see how that would make things simpler, but on the other hand, if I wanted to place 16 different- colored dots on the screen, I would have to wait for 16 double frame buffers? Please explain.
Rollback Post to RevisionRollBack
@implementation NSObject: CollaborateQuestion
UILabel *question = [UILabel setText: @"Anyone want to collaborate on an iOS app?"];
if (yourResponse == YES){
UIImageView *myFace= [UIImage setImage: @"Happy Face! :D.png"] };
It will be available for download when it's done. It's almost done, I just need to finish documenting it, add a few more features, do some bug fixing and some other things. But I'm close!
I watched your first program video, and it only reinforced my suspicions about the double frame buffer. In your video, you showed that all 4 red blocks were rendered at the same time in each stage, and you explained that the white wool of the 4 blocks (pixels, whatever) was replaced with red wool. Does this mean that the GPU can only render one color at a time? My reasoning for this is that if the logic is as simple as replacing everything in step 1 with a certain color, then you could only place objects in that step that are the same color. I see how that would make things simpler, but on the other hand, if I wanted to place 16 different- colored dots on the screen, I would have to wait for 16 double frame buffers? Please explain.
No, you can use any combination of 16 colours. Let me explain the framefactory system again:
The first stage is the ANDEX tower. This draws 1 shape at a time by pushing out white wool blocks with pistons to make up a shape.
Step 2 copies the pushed blocks from stage 1 into stage 2, and replaces the blocks with the colour that shape is being drawn in. If you are drawing a red square, it will change all the currently white blocks in the shape to red ones.
Step 3 now copies the coloured shape into the current frame. If the current frame contains a blue and a green square which were drawn previously, they will stay there. Anything the new red square overlaps will become red. This is the stage you seem to be confused about. All colours of all shapes previously drawn are kept intact, and all 16 colours can be used in the same framebuffer.
Step 4 only activates when all the required shapes are drawn with steps 1 to 3. It simply copies stage 3 to the screen, allowing the user to see the finished image. Since the buffer the user sees and the buffer the program works on are separate, this is called "double buffering", and doesn't have to do with how many colours it supports at all.
I hope this clears things up for you.
In other news, I have a new demo program done and have expanded the program memory even further, to 256 slots (with 3 values per slot, that's a max of 768 scoreboard values!), though it's technically only 255 slots now because of a slight error in the ROM generator, which I hope to fix eventually.
The compiler program has a new UI as well. It's a lot simpler now and all the drop down boxes and functions actually work this time! Yay!
It also gives slightly more meaningful error codes than suddenly closing and printing a stack trace in the standard output now. Still very buggy though. It's my first 4 stage compiler (only missing the linker stage from a modern compiler, though the assembler has a basic linker for GOTO instructions) So it's not exactly the best, most foolproof compiler ever written. It's also missing an Operator-precedence parser, or any kind of decent math parser for that matter.
Incredible! That is quite impressive that you've created such a high level language for a redstone computer! Can't wait for the release of the map/compiler!
hay dude i need help.
here is my code, every so often it skipps a does not register a key!
note:run this java class at your own risk!
import java.awt.AWTException;
import java.awt.Robot;
import java.awt.event.KeyEvent;
import static java.awt.event.KeyEvent.*;
public class main {
public static Robot robot;
public static void main(String args[]) throws InterruptedException, AWTException {
Thread.sleep(10000);
robot = new Robot();
for(int i=0;i<1024;i++){
type("/scoreboard players set "+ i + " ROM 0");
type(VK_ENTER);
}
}
public static void type(String toType){
for(int i=0;i!=toType.length();i++){
switch(toType.charAt(i)){
case 'a':type(VK_A);break;
case 'b':type(VK_B);break;
case 'c':type(VK_C);break;
case 'd':type(VK_D);break;
case 'e':type(VK_E);break;
case 'f':type(VK_F);break;
case 'g':type(VK_G);break;
case 'h':type(VK_H);break;
case 'i':type(VK_I);break;
case 'j':type(VK_J);break;
case 'k':type(VK_K);break;
case 'l':type(VK_L);break;
case 'm':type(VK_M);break;
case 'n':type(VK_N);break;
case 'o':type(VK_O);break;
case 'p':type(VK_P);break;
case 'q':type(VK_Q);break;
case 'r':type(VK_R);break;
case 's':type(VK_S);break;
case 't':type(VK_T);break;
case 'u':type(VK_U);break;
case 'v':type(VK_V);break;
case 'w':type(VK_W);break;
case 'x':type(VK_X);break;
case 'y':type(VK_Y);break;
case 'z':type(VK_Z);break;
case 'A':typeShift(VK_A);break;
case 'B':typeShift(VK_B);break;
case 'C':typeShift(VK_C);break;
case 'D':typeShift(VK_D);break;
case 'E':typeShift(VK_E);break;
case 'F':typeShift(VK_F);break;
case 'G':typeShift(VK_A);break;
case 'H':typeShift(VK_H);break;
case 'I':typeShift(VK_I);break;
case 'J':typeShift(VK_J);break;
case 'K':typeShift(VK_K);break;
case 'L':typeShift(VK_L);break;
case 'M':typeShift(VK_M);break;
case 'N':typeShift(VK_N);break;
case 'O':typeShift(VK_O);break;
case 'P':typeShift(VK_P);break;
case 'Q':typeShift(VK_Q);break;
case 'R':typeShift(VK_R);break;
case 'S':typeShift(VK_S);break;
case 'T':typeShift(VK_T);break;
case 'U':typeShift(VK_U);break;
case 'V':typeShift(VK_V);break;
case 'W':typeShift(VK_W);break;
case 'X':typeShift(VK_X);break;
case 'Y':typeShift(VK_Y);break;
case 'Z':typeShift(VK_Z);break;
case '0':type(VK_0);break;
case '1':type(VK_1);break;
case '2':type(VK_2);break;
case '3':type(VK_3);break;
case '4':type(VK_4);break;
case '5':type(VK_5);break;
case '6':type(VK_6);break;
case '7':type(VK_7);break;
case '8':type(VK_8);break;
case '9':type(VK_9);break;
case ' ':type(VK_SPACE);break;
case '.':type(VK_PERIOD);break;
case '/':type(VK_SLASH);break;
default:System.out.println("charecter not suported");
}
}
}
public static void type(int i){
robot.keyPress(i);
robot.delay(50);
robot.keyRelease(i);
}
public static void typeShift(int i){
robot.keyPress(VK_SHIFT);
robot.delay(50);
robot.keyPress(i);
robot.delay(50);
robot.keyRelease(i);
robot.keyRelease(VK_SHIFT);
}
}
@c4ooo, I think it was stated earlier in the thread that minecraft can't handle key input at too fast of a rate, so maybe try simply increasing the delay? Also, I think you might need a delay in between the KeyRelease of one key and the next Key Press of another, not just between the KeyPress and KeyRelease of each key.
@dudearent006, No, Stage 3 wasn't what I was confused about, it was Stage 2. Your restatement of the steps still included the fact that every block in Step 2 was changed to a single color, meaning that you can only have one color at a time in the second buffer. So, I ask again, if I wanted to draw 16 differently-colored pixels, would I need to wait through 16 Stage 2 buffers?
Sorry if I sound rude or offensive; I really do like the system as a whole, and I'm not trying to undermine it.
Rollback Post to RevisionRollBack
@implementation NSObject: CollaborateQuestion
UILabel *question = [UILabel setText: @"Anyone want to collaborate on an iOS app?"];
if (yourResponse == YES){
UIImageView *myFace= [UIImage setImage: @"Happy Face! :D.png"] };
hay dude i need help.
here is my code, every so often it skipps a does not register a key!
note:run this java class at your own risk!
-snipped out code-
I haven't run this class yet, but from developing my own compiler I learnt a whole lot about how Minecraft handles text input.
Note that the below is pure speculation from what I've tested, it might actually work differently.
Firstly, minecraft checks every frame for new key presses. In this state it only cares about keys currently pressed down, not any keys pressed during the other frame. This is usually OK since humans can't press and release keys in a 30th of a second or faster, but your program can.
What's important to note though, is once the / or T key has been registered and the text menu opens, Minecraft's normal key handling system seems to de-initialize and re-initialize as a buffered key system that keeps track of all keys pressed throughout the frame in a buffer. This is great, actually. However, this discards any keys pressed immediately after the / or T key, and it won't accept any new keys for a while while the key system changes. Therefore, a larger delay is needed between pressing the / or T key and typing the next few letters, or Minecraft will skip them.
Additionally, minecraft's key buffer is pretty limited. Exactly 80 characters long. If you give more text than that in one go, it will ignore any characters after the 80th one. There's also a maximum amount of characters you can type in the chat, like 100 or so.
it would be SO much more power full if it edited the mc world save!
Or by using computer craft mod you could also check to see the value of a scoreboard player, how ever that would not look good in the eyes of the community (a computer mod to make an mc computer work)
Update:
[ANGRY] WHY DID MCEDIT HAVE TO BE WRITTEN IN PYTHON??? CANT EVEN MAKE A SIMPLE FILTER IN THAT CURSED LANGUAGE[/ANGRY]
it would be SO much more power full if it edited the mc world save!
It will eventually get a very basic peripheral API that allows you to send and recieve messages from different external peripherals. This should allow you to create peripherals that trigger command blocks, thereby allowing it to interact with the world in a way.
hay dude i need help.
here is my code, every so often it skipps a does not register a key!
note:run this java class at your own risk!
-snipped out code-
Just a hint to make your life easier, the Java Robot class characters have the same value as uppercase chars and numbers, so instead of having that huge case statement, you could just do this:
String command = "/scoreboard players set " + i + " ROM 0";
for (int j = 0; j < command.length(); j++) {
if (Character.isUpperCase(command.charAt(j))) {
robot.keyPress(KeyEvent.VK_SHIFT);
}
robot.keyPress(Character.toUpperCase(command.charAt(j)));
robot.delay(5);
robot.keyRelease(Character.toUpperCase(command.charAt(j)));
robot.delay(5);
if (Character.isUpperCase(command.charAt(j))) {
robot.keyRelease(KeyEvent.VK_SHIFT);
}
}
robot.keyPress(KeyEvent.VK_ENTER);
robot.delay(10);
robot.keyRelease(KeyEvent.VK_ENTER);
robot.delay(10);
Also, @dudearent006, do you plan on releasing your command block generator, because it would come in very handy in a project I'm working on.
One more question: to make the computer faster cant the global/local memory thing be handled by the compiler?
UPDATE:
ime starting on my assembler (not compiler mind you) wich will turn your code into numbercodes, fracture program names and store data to the rom.
One more question: to make the computer faster cant the global/local memory thing be handled by the compiler?
It sort of is, but you need to realize that for "real" local memory you can't just map variables to static addresses. If a function calls itself, for example, it needs to have its own local variables separate from the function that called it. Here'a a little demo program:
function count:
value
{
value--;
print(value);
ifnot(value=0)
{
count(value);
}
value++;
print(value);
}
function main:
{
count(5);
}
This program will print out 4,3,2,1,0, and then 1,2,3,4,5. This is because count calls itself but keeps its own local variables. if the "value" variable was given a static address, this program would not work. This isn't exactly a practical example, but there are uses for this.
just dont program in recursion
UPDATE:
How do you like my UI?
-image snipped-
PS
I cant wait to revers engineer your compiler
your UI looks...confusing
I assume you program with those windows as apposed to typing in a text file? I can't comment on it much since I have no idea how it works
Anyway, I've decided to make a last minute but quite highly demanded change: making the bottom right corner of the screen point (0;0) instead of point (1;1), so it starts at 0 now. Also writing some demo programs for both users and programmers (showing what the computer is capable of and how to use certain techniques or functions respectively)
thats what i thought... btw how much do you use mcedit?1/3 of my stuff is mceditedit/update:you do program in text files thats what the paths are for.
ps:put this command in a commandbloc and atach a very fast clock to it:"/execute @a ~ ~ ~ setblock ~ ~-1 ~ glowstone"
and olso set time to night time
update:
--snip--
Anyway, I've decided to make a last minute but quite highly demanded change: making the bottom right corner of the screen point (0;0) instead of point (1;1), so it starts at 0 now.
--snip--
AS I FEAL I HAVE TURNED YOUR THREAD INTO MY BLOG I HAVE STARTED MY OWN THREAD.
TALK YO YOU THER (AND LOOK AT THE PICKS) http://www.minecraft...h-16-color-gpu/
It's been a while since I've updated this. Here's what I've been doing in the meantime:
Documented the programming language and functions (just a little more to go)
Preparing the System Development Kit (SDK) for a public release
Making a miniature version of the uploader program for normal users who don't want to write programs themselves, only run programs others have made
Finding and fixing bugs
Creating demo programs for the SDK (to show how functions should be used), the user and trailer (to demonstrate the computer's power and make it useful...kinda)
Editing and recording the trailer
Still a lot to do, and a lot of my other real life projects are severely slowing this one down (New robot parts just arrived! :D), but we're almost there! Just some final touches (which often takes suprisingly long) on the manual, SDK and computer.
I also want to create some sort of peripheral protocol like I did for the Redgame 3. It will be pretty basic, but powerful enough to allow you to communicate with external devices that can speed things up, e.g. an hardware brensenham line drawing system. Since you can use command blocks, the peripheral could inject the pixels directly into the GPU. No memory protection and all that stuff, sort of a "trust that the peripheral doesn't mess things up" system. The other way works as well, for weird things would start happening if a hardware line drawer was running while the program was also using the GPU! It wouldn't give an error, it would just mess up the display.
Anyways, here's something interesting for you guys: Tic Tac Toe!
It's a demo intended to show how to use all the less used GPU functions. vert and hor draw the vertical and horisontal lines of a rectangle respectively, and were used to draw the grid. "dots" draws pixels and the 4 corners of a rectangle and were used to draw the cross (start at center, then enlarge outwards in a loop) and the circle (first a hollow rectangle in blue, then the corners of the rectangle in black to make it look more round).
It also uses double buffered mode and the extra frame buffer for when you're selecting a place to put your piece. Here's how selection works, by the way:
I placed an item on the pressure plate so I could show the display and D-pad simultaneously.
Your cursor is the blue pixel (red if next move is red) and you decide where to go by standing on the buttons. To select the center-top spot, you stand on the up button. To select the top-left spot, you stand on both the up and left buttons, like so:
Again, items instead of me, but you can actually stand on both buttons at the same time. You then press A to confirm. So this demo also shows some ways in which you can use the D-pad, and the D-pad multiplier functionality (makes more sense if you saw the source code for how it was used)
There's no AI or win detection, but the program currently uses 23% of program memory, so there's plenty to add it. There's also nothing stopping you from placing a cross on a circle or vice versa, but some simple GPU compare code might make it possible. All these features would significantly slow down the program, however.
The blue dot in the center of the circles is a small bug (I don't clear the selection pixel before drawing the circle) but if you want to prevent drawing a cross on a circle, you'd need that dot to be there. Unless you use a more complicated method...
I'm releasing a beta version of the compiler and documentation (not the computer itself yet, sorry) for you to test! Note that both the documentation and compiler is unfinished, and both will have errors and bugs respectively. The assembly instructions table is particularly still messy.
I know it's a little useless to have the dev kit without the actual computer, but there's still a lot you can do. If you manage to write a functional program, post it here (preferably the source code, so I can edit it if it doesn't work correctly) and I'll try and run it. I might release it as an official demo program (with your permission and you'll still be credited of course). If something isn't clear in the manual or the compiler acts strangely, please don't be afraid to report it!
I actually discovered a bug while adding comments to my example programs just before releasing the beta SDK. If you put quotation marks in a long comment, e.g. /* like "this" */, and you put that long comment outside of function declarations (e.g. at the very beginning of the program), it will incorrectly tell you that it expected a function deceleration, and found a "/" token instead. It's probably not ignoring the comment like it's supposed to because the token post processor detected a String, but I don't have enough time to fix the bug for this beta release. But this is the kind of bugs you could find!
Also, try anything in your power to make the compiler act strangely! Write gibberish code! Run it on Mac, Windows, and every Linux distro you know! Heck, run in on a Raspberry Pi and a Linux Virtual Machine on Android! (you don't have to, only if you really want to)
Also...the manual's 17 pages long. It covers everything related to the SDK, including installation and usage, language format, all functions, colour codes, assembly format etc. But you don't *need* to read all of it. Quite a bit of it is common sense, there's some functions you might never use and many things can be learnt from looking at the examples (5 examples included, more will be added later) or learning through experimenting. There will also be a video tutorial series after it's released.
I'll try to write the game called Nim for ya'. Lets see if I can figure this out...
EDIT: Is there any way to get more lever inputs on the thing, so that you could, for example, input 2 8 bit numbers?
Good luck, and awesome! Are you planning to make it with an AI, or as a 2 player game?
For inputting numbers, there's a special system in place for that. It's input(value); ,where value is where to save it to. the newInput flag will be true when the user has entered a number. Here's an example function:
function getInput:
value
{
until(newInput){}//wait for input
input(value);//store the input in value
return value;
}
It will be available for download when it's done. It's almost done, I just need to finish documenting it, add a few more features, do some bug fixing and some other things. But I'm close!
No, you can use any combination of 16 colours. Let me explain the framefactory system again:
The first stage is the ANDEX tower. This draws 1 shape at a time by pushing out white wool blocks with pistons to make up a shape.
Step 2 copies the pushed blocks from stage 1 into stage 2, and replaces the blocks with the colour that shape is being drawn in. If you are drawing a red square, it will change all the currently white blocks in the shape to red ones.
Step 3 now copies the coloured shape into the current frame. If the current frame contains a blue and a green square which were drawn previously, they will stay there. Anything the new red square overlaps will become red. This is the stage you seem to be confused about. All colours of all shapes previously drawn are kept intact, and all 16 colours can be used in the same framebuffer.
Step 4 only activates when all the required shapes are drawn with steps 1 to 3. It simply copies stage 3 to the screen, allowing the user to see the finished image. Since the buffer the user sees and the buffer the program works on are separate, this is called "double buffering", and doesn't have to do with how many colours it supports at all.
I hope this clears things up for you.
In other news, I have a new demo program done and have expanded the program memory even further, to 256 slots (with 3 values per slot, that's a max of 768 scoreboard values!), though it's technically only 255 slots now because of a slight error in the ROM generator, which I hope to fix eventually.
The compiler program has a new UI as well. It's a lot simpler now and all the drop down boxes and functions actually work this time! Yay!
It also gives slightly more meaningful error codes than suddenly closing and printing a stack trace in the standard output now. Still very buggy though. It's my first 4 stage compiler (only missing the linker stage from a modern compiler, though the assembler has a basic linker for GOTO instructions) So it's not exactly the best, most foolproof compiler ever written. It's also missing an Operator-precedence parser, or any kind of decent math parser for that matter.
Proud member of spigotmc.org.
here is my code, every so often it skipps a does not register a key!
note:run this java class at your own risk!
THE MICRO$OFT APOCALYPSE IS ON!!!
32 bit redstone computer with 64*64 pixel 16 color gpu:
http://www.minecraftforum.net/forums/minecraft-discussion/redstone-discussion-and/2116999-computer-command-block-computer-now-running-with
(giant banner removed out of modesty).
THE MICRO$OFT APOCALYPSE IS ON!!!
32 bit redstone computer with 64*64 pixel 16 color gpu:
http://www.minecraftforum.net/forums/minecraft-discussion/redstone-discussion-and/2116999-computer-command-block-computer-now-running-with
(giant banner removed out of modesty).
@dudearent006, No, Stage 3 wasn't what I was confused about, it was Stage 2. Your restatement of the steps still included the fact that every block in Step 2 was changed to a single color, meaning that you can only have one color at a time in the second buffer. So, I ask again, if I wanted to draw 16 differently-colored pixels, would I need to wait through 16 Stage 2 buffers?
Sorry if I sound rude or offensive; I really do like the system as a whole, and I'm not trying to undermine it.
I haven't run this class yet, but from developing my own compiler I learnt a whole lot about how Minecraft handles text input.
Note that the below is pure speculation from what I've tested, it might actually work differently.
Firstly, minecraft checks every frame for new key presses. In this state it only cares about keys currently pressed down, not any keys pressed during the other frame. This is usually OK since humans can't press and release keys in a 30th of a second or faster, but your program can.
What's important to note though, is once the / or T key has been registered and the text menu opens, Minecraft's normal key handling system seems to de-initialize and re-initialize as a buffered key system that keeps track of all keys pressed throughout the frame in a buffer. This is great, actually. However, this discards any keys pressed immediately after the / or T key, and it won't accept any new keys for a while while the key system changes. Therefore, a larger delay is needed between pressing the / or T key and typing the next few letters, or Minecraft will skip them.
Additionally, minecraft's key buffer is pretty limited. Exactly 80 characters long. If you give more text than that in one go, it will ignore any characters after the 80th one. There's also a maximum amount of characters you can type in the chat, like 100 or so.
I hope this helps!
Or by using computer craft mod you could also check to see the value of a scoreboard player, how ever that would not look good in the eyes of the community (a computer mod to make an mc computer work)
Update:
[ANGRY] WHY DID MCEDIT HAVE TO BE WRITTEN IN PYTHON??? CANT EVEN MAKE A SIMPLE FILTER IN THAT CURSED LANGUAGE[/ANGRY]
THE MICRO$OFT APOCALYPSE IS ON!!!
32 bit redstone computer with 64*64 pixel 16 color gpu:
http://www.minecraftforum.net/forums/minecraft-discussion/redstone-discussion-and/2116999-computer-command-block-computer-now-running-with
(giant banner removed out of modesty).
It will eventually get a very basic peripheral API that allows you to send and recieve messages from different external peripherals. This should allow you to create peripherals that trigger command blocks, thereby allowing it to interact with the world in a way.
Just a hint to make your life easier, the Java Robot class characters have the same value as uppercase chars and numbers, so instead of having that huge case statement, you could just do this:
Also, @dudearent006, do you plan on releasing your command block generator, because it would come in very handy in a project I'm working on.
UPDATE:
ime starting on my assembler (not compiler mind you) wich will turn your code into numbercodes, fracture program names and store data to the rom.
THE MICRO$OFT APOCALYPSE IS ON!!!
32 bit redstone computer with 64*64 pixel 16 color gpu:
http://www.minecraftforum.net/forums/minecraft-discussion/redstone-discussion-and/2116999-computer-command-block-computer-now-running-with
(giant banner removed out of modesty).
It sort of is, but you need to realize that for "real" local memory you can't just map variables to static addresses. If a function calls itself, for example, it needs to have its own local variables separate from the function that called it. Here'a a little demo program:
This program will print out 4,3,2,1,0, and then 1,2,3,4,5. This is because count calls itself but keeps its own local variables. if the "value" variable was given a static address, this program would not work. This isn't exactly a practical example, but there are uses for this.
UPDATE:
How do you like my UI?
PS
I cant wait to revers engineer your compiler
THE MICRO$OFT APOCALYPSE IS ON!!!
32 bit redstone computer with 64*64 pixel 16 color gpu:
http://www.minecraftforum.net/forums/minecraft-discussion/redstone-discussion-and/2116999-computer-command-block-computer-now-running-with
(giant banner removed out of modesty).
your UI looks...confusing
I assume you program with those windows as apposed to typing in a text file? I can't comment on it much since I have no idea how it works
Anyway, I've decided to make a last minute but quite highly demanded change: making the bottom right corner of the screen point (0;0) instead of point (1;1), so it starts at 0 now. Also writing some demo programs for both users and programmers (showing what the computer is capable of and how to use certain techniques or functions respectively)
ps:put this command in a commandbloc and atach a very fast clock to it:"/execute @a ~ ~ ~ setblock ~ ~-1 ~ glowstone"
and olso set time to night time
update:
piece of cake with mcedit.
THE MICRO$OFT APOCALYPSE IS ON!!!
32 bit redstone computer with 64*64 pixel 16 color gpu:
http://www.minecraftforum.net/forums/minecraft-discussion/redstone-discussion-and/2116999-computer-command-block-computer-now-running-with
(giant banner removed out of modesty).
TALK YO YOU THER (AND LOOK AT THE PICKS)
http://www.minecraft...h-16-color-gpu/
THE MICRO$OFT APOCALYPSE IS ON!!!
32 bit redstone computer with 64*64 pixel 16 color gpu:
http://www.minecraftforum.net/forums/minecraft-discussion/redstone-discussion-and/2116999-computer-command-block-computer-now-running-with
(giant banner removed out of modesty).
I also want to create some sort of peripheral protocol like I did for the Redgame 3. It will be pretty basic, but powerful enough to allow you to communicate with external devices that can speed things up, e.g. an hardware brensenham line drawing system. Since you can use command blocks, the peripheral could inject the pixels directly into the GPU. No memory protection and all that stuff, sort of a "trust that the peripheral doesn't mess things up" system. The other way works as well, for weird things would start happening if a hardware line drawer was running while the program was also using the GPU! It wouldn't give an error, it would just mess up the display.
Anyways, here's something interesting for you guys: Tic Tac Toe!
It's a demo intended to show how to use all the less used GPU functions. vert and hor draw the vertical and horisontal lines of a rectangle respectively, and were used to draw the grid. "dots" draws pixels and the 4 corners of a rectangle and were used to draw the cross (start at center, then enlarge outwards in a loop) and the circle (first a hollow rectangle in blue, then the corners of the rectangle in black to make it look more round).
It also uses double buffered mode and the extra frame buffer for when you're selecting a place to put your piece. Here's how selection works, by the way:
I placed an item on the pressure plate so I could show the display and D-pad simultaneously.
Your cursor is the blue pixel (red if next move is red) and you decide where to go by standing on the buttons. To select the center-top spot, you stand on the up button. To select the top-left spot, you stand on both the up and left buttons, like so:
Again, items instead of me, but you can actually stand on both buttons at the same time. You then press A to confirm. So this demo also shows some ways in which you can use the D-pad, and the D-pad multiplier functionality (makes more sense if you saw the source code for how it was used)
There's no AI or win detection, but the program currently uses 23% of program memory, so there's plenty to add it. There's also nothing stopping you from placing a cross on a circle or vice versa, but some simple GPU compare code might make it possible. All these features would significantly slow down the program, however.
The blue dot in the center of the circles is a small bug (I don't clear the selection pixel before drawing the circle) but if you want to prevent drawing a cross on a circle, you'd need that dot to be there. Unless you use a more complicated method...
(for a few more pictures, see http://imgur.com/a/VZpmq )
I'm releasing a beta version of the compiler and documentation (not the computer itself yet, sorry) for you to test! Note that both the documentation and compiler is unfinished, and both will have errors and bugs respectively. The assembly instructions table is particularly still messy.
I know it's a little useless to have the dev kit without the actual computer, but there's still a lot you can do. If you manage to write a functional program, post it here (preferably the source code, so I can edit it if it doesn't work correctly) and I'll try and run it. I might release it as an official demo program (with your permission and you'll still be credited of course). If something isn't clear in the manual or the compiler acts strangely, please don't be afraid to report it!
I actually discovered a bug while adding comments to my example programs just before releasing the beta SDK. If you put quotation marks in a long comment, e.g. /* like "this" */, and you put that long comment outside of function declarations (e.g. at the very beginning of the program), it will incorrectly tell you that it expected a function deceleration, and found a "/" token instead. It's probably not ignoring the comment like it's supposed to because the token post processor detected a String, but I don't have enough time to fix the bug for this beta release. But this is the kind of bugs you could find!
Also, try anything in your power to make the compiler act strangely! Write gibberish code! Run it on Mac, Windows, and every Linux distro you know! Heck, run in on a Raspberry Pi and a Linux Virtual Machine on Android! (you don't have to, only if you really want to)
Also...the manual's 17 pages long. It covers everything related to the SDK, including installation and usage, language format, all functions, colour codes, assembly format etc. But you don't *need* to read all of it. Quite a bit of it is common sense, there's some functions you might never use and many things can be learnt from looking at the examples (5 examples included, more will be added later) or learning through experimenting. There will also be a video tutorial series after it's released.
Finally, here's the link: https://dl.dropboxusercontent.com/u/43744321/beta SDK.zip
Have fun trying to crash my compiler!
Good luck, and awesome! Are you planning to make it with an AI, or as a 2 player game?
For inputting numbers, there's a special system in place for that. It's input(value); ,where value is where to save it to. the newInput flag will be true when the user has entered a number. Here's an example function:
http://www.ludumdare.com/compo/
THE MICRO$OFT APOCALYPSE IS ON!!!
32 bit redstone computer with 64*64 pixel 16 color gpu:
http://www.minecraftforum.net/forums/minecraft-discussion/redstone-discussion-and/2116999-computer-command-block-computer-now-running-with
(giant banner removed out of modesty).