This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - nemo
Pages: 1 ... 51 52 [53] 54 55 ... 82
781
« on: September 12, 2010, 12:01:31 am »
There aren't any typos. Dispgraphrr is dispgraphrr
Sorry im being brief im on an ipad
782
« on: September 11, 2010, 11:54:24 pm »
{^r}=^r and {input} means the byte at Input, input being the token
783
« on: September 11, 2010, 11:00:32 pm »
i made a simple grayscale editor where you can define the height and width of your title screen and edit it pixel-by-pixel. when you enter a number in, it has to have two digits. meaning "6" is not a valid input, it should be "06". it's pretty simple right now.. you move a cursor around where [2nd] inverts the pixel on the buffer, and [alpha] inverts the pixel on the backbuffer. mode inverts the buffer, xton inverts the backbuffer, del clears the buffer, stat clears the backbuffer. they literally use drawInv and ClrDraw, so when you invert the buffer, not only will your title screen be inverted, but also the rest of the buffer.
unfortunately, i don't have access to a link cable right now.. so here's the source code, if you feel like typing it in. the source is only 440 bytes, the executable is just over a thousand. here's the source:
.PICEDIT
ClrDraw
ClrDraw{^r}
DiagnosticOff
Disp "HEIGHT"
{input}^r->C^256-48*10+(C/256-48)->H
ClrHome
Disp "WIDTH"
{input}^r->C^256-48*10+(C/256-48)->W
0->X->Y
Repeat getKey(9)
If getKey->K=54
Pxl-Change(X,Y
End
If K=48
Pxl-Change(X,Y)^r
End
If K=55
DrawInv :End
If K=40
DrawInv ^r:End
If K=56
ClrDraw:End
If K=32
ClrDraw^r:End
K=3 and (W-1!=X)-(K=2)+X->X
K=1 and (H-1!=Y)-(K=4)+Y->Y
Pxl-Change(X,Y
DispGraphrr
Pxl-Change(X,Y
End
"0123456789ABCDEF"->Str1
GetCalc("Str1",W/8+(W^8!=0)->L*H->U*4)->A
12-L->B
For(Z,0,U-1
{{Z/L*B+L6+Z}->C/16+Str1}->(Z*2+A}
{C^16+Str1}->{Z*2+1+A}
{{Z/L*B+L3+Z}->C/16+Str1}->(Z*2+(U*2)+A}
{C^16+Str1}->{Z*2+1+(U*2)+A}
End
784
« on: September 11, 2010, 11:27:44 am »
if you're using the entire screen, your possible sizes are 4x4 and 8x8. personally, i'd go with 6x6 and have a 4 pixel progress bar at the bottom of the screen. this makes a 16 wide by 10 tall playing field, or 160 possible squares a snake place could be. depending upon how fast the snake moves, grayscale could be ugly.. so you *may* want to keep it monochrome.
edit: and 12x12 would give you an 8 by 5 playing field, 40 possible squares, with a 4 pixel white space on the bottom
785
« on: September 11, 2010, 12:39:04 am »
how much data do you explicitly define..? i would think you would need under 100 bytes for all the sprites, do you know what's taking up all the memory?
786
« on: September 10, 2010, 07:13:50 pm »
well, what size are you thinking each block of the snake should be? also, will you have an HUD displaying lives or anything, or will you utilize the whole screen?
787
« on: September 08, 2010, 10:44:19 pm »
"_
For(A,1,dim(LW
For(B,1,.5+.5int(log(LW(A
Ans+sub("AaBbCcDdEeFfGgHhIiJjKkLlMmNnOoPpQqRrSsTtUuVvWwXxYyZzΘ0123456789",iPart(E2fPart(LW(A)/10^(2B))),1
End
End
sub(Ans,2,length(Ans)-1→Str1
i think this still works.. but it's late, and i'm tired, so i'm not completely sure.
788
« on: September 07, 2010, 11:45:24 pm »
i was going to show her, but didn't after she took a student's calculator away when the student made a program to do sigma notation (i lol'd, thinking of the sum(seq([EXP],[Var],[start],[end])) trick.
789
« on: September 06, 2010, 01:29:29 pm »
for those who don't go to cemetech, you may want to read this thread. it basically suggests we should redo the screen and backlight polls. why? because the chances of us finding exactly what we want is very slim. i tried to find a 192 x 128 backlit 4 bit grayscale LCD, and google returned a ton of links to Omnimaga and Cemetech talking about some OTZ80 calculator. i'm suggesting we should redo the poll. instead of having hardware features to vote on, we should have the actual LCD's to vote on. that way, when we come to a consensus on what to buy, we already know where to find it. if you're against this idea, i have a challenge for you. try to find the 192 x 128 16 level grayscale with a backlight LCD that we want. if you can't find it, my case in point. if you can, that's wonderful, and we can move on.
790
« on: September 06, 2010, 01:58:30 am »
would it be unreasonable for an operator to get the half-byte of a location? maybe {PTR}#^r where # is 1-4, which half-byte you're trying to access?
791
« on: September 06, 2010, 01:49:04 am »
yeah, i thought that too, since A now holds a value 0-255 as specified by {GDB1+X}. regardless, this is a cool way to access high/low bytes of variables
792
« on: September 06, 2010, 01:42:15 am »
thanks for the explanation. what about the following? is there any difference?
{GDB1+X}->A
A/16->B
A^16->C
.or
{GDB1+X}->A
{L1-54}/16->B
{L1-54}^16->B
793
« on: September 06, 2010, 01:28:47 am »
/256 is 3 bytes and ^256 is 2 bytes, so i don't think so.
-55 and -54 are 4 bytes each. i'm not sure how many bytes accessing a byte at a pointer is though.
794
« on: September 06, 2010, 12:11:33 am »
wait, so you can get the high/low bytes of variables by accessing a certain part of RAM? can someone tell me where this RAM starts and where it ends? is it {L1-55} to {L1-1}? that leaves 54 bytes / 2 = 27 variables..
would the following be an optimization?
{GDB1+B}^r->A
A/256->C
A^256->D
.optimizes into..
{GDB1+B}^r->A
{L1-55}->C
{L1-54}->D
of course, i'm talking about speed optimization. i know it's a bigger size.
795
« on: September 05, 2010, 10:02:23 pm »
pressing [ON] while in the input routine causes the calculator to go into an infinite loop (i think. the run indicator kept going for about two minutes before i pulled a battery. also, i had DiagnosticOff at the beginning of the program).
Pages: 1 ... 51 52 [53] 54 55 ... 82
|
Show Posts
