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 ... 64 65 [66] 67 68 ... 82
976
« on: July 16, 2010, 06:53:00 pm »
.ATST
0->C . Since we're always displaying 12 sprites on the screen, you only need one var to keep track of position in the data.
DiagnosticOff
ClrDraw
Zeroes(8)->Pic1 . just a different way of writing it.
[FFFF03030303FFFF]
[FFFFC0C0C0C0FFFF]
[386CD6AAFED6D67C]
[FFFFE7C3C3E7FFFF]
[FFE7C38181C3E7FF]
Data(1,4,4,4,4,4,4,4,2,1,1,1,1,1,4,4,4,4,2,4,1,2,4,4,3,3,1,2)->GDB1 . unchanged data.
Repeat getKey(15)
C!=16 and getKey(3) - (C!=0 and getKey(2))+C->C . "!=" is does not equal. they're used to be boundaries, so we don't scroll into undefined data.
Pause 150 . pauses for 150 milliseconds to slow the program down.
ClrDraw
For(A,C,C+12
pt-On(A-C*8,56,{GDB1+A}*8+Pic00 . A-C instead of A so we always start displaying the sprites at (0,56).
End
DispGraph
End
i think this gives the desired effect. i got the 16 as a boundary from the number of pieces of data in GDB1 (there are 28). since in the for loop i have the ending value 12 higher than C, the maximum boundary before we start scrolling into random data is the amount of data (28) minus how far in front of our counter variable (C) we're going to use. (12). therefore the boundary of C is 16. you can adjust the pause to make the program scroll faster/slower. one last thing to explain, {GDB1+A}*8+Pic00. {GDB1} returns 1, because it's the first number in the sequence in Data(). it's also defined as the number starting at the static pointer GDB1. {GDB1+A} returns whatever number is A spaces after the beginning of Data() so if A is 3, {GDB1+A} returns a 4. We multiply by 8 because each sprite takes up 8 bytes of space. Since {GDB1+A} returns the byte at the pointer (think that it returns the number A spaces in front of the 1 in Data() if you're confused on pointers), we multiply by 8 to skip through the sprites. I think you already understand this, matthias, i'm just checking anyway.
977
« on: July 16, 2010, 04:06:09 pm »
new release (:
some new things:
-primitive tile selection menu
-saving and loading!
-better navigation
those are the big improvements, now for describing how to use the program
main menu:
1- create a new tilemap and tileset, asks for size of tiles afterwards, 4-8.
2- load a map. if you try to load a nonexistent map, the program exits.
3- doesn't actually quit. what can i say? i'm lazy on the easy things.
clear- quits.
tileset editor:
arrow keys - move cursor
2nd - invert pixel
+ - go to the next tile, if tile number is not 15.
- - go to previous tile, if tile number is not 1.
mode - invert all pixels of the tile
del - clear the tile.
window/F2 - go to the tilemap editor
tilemap editor:
arrow keys - move cursor
2nd - display the next tile in the tileset. loops to 0 if the current tile is the last in the tileset
alpha - display previous tile in the tileset. loops to the end of the tileset if the current tile is blank.
clear - quit.
0 - clear the tile. (set it to 0 in the tilemap)
math - bring up tileset menu. press 2nd to select a tile in the tileset menu.
y=/F1 - go to tileset editor.
enter - save to the appvar. there are 3 slots to save to.
known bugs:
- sometimes the correct tile size will not be loaded from the appvar. to prevent this, restart the program then create a new tileset with the desired size. restart the program again and loading a tileset will have the desired size.
- in the tilemap editor, tile selection using 2nd and alpha will not work if you didn't exit the tileset editor on the last tile. so say you have five tiles 1 2 3 4 and 5. in order for the program to work, when you exit the tileset editor to the tilemap editor, make sure the tile you're on is tile 5. i *think* this is only a bug for loaded tilesets. it's especially annoying because i need 3 more bytes in the appvar to specify the number of tiles in the tileset so the tilemap editor will loops correctly.
let me know of any bugs... the appvar name is TILEMAP.
978
« on: July 16, 2010, 03:35:52 pm »
hexpix? what program is that?
979
« on: July 16, 2010, 03:29:47 pm »
Disp A gives you the garbage located at pointer A.
Disp A>Dec gives you the decimal value of A.
Disp A>Char/>Frac gives you the corresponding ASCII character.
so to answer your question, add >Dec on the end of A to display the value.
980
« on: July 14, 2010, 09:04:13 pm »
it already has a use, so it may be a bit confusing to use. i'm not sure what token would be used, just thought it seemed like a relatively simple operation. i imagine you could do this with the exch() command and some very tricky modular arithmetic in the free RAM area L6, if anyone wants to try... i'll probably attempt later.
981
« on: July 14, 2010, 08:45:44 pm »
.SPRITE . header
DiagnosticOff . turn off indicator/done
10->X->Y . initialize sprite position
[3C7EFFFFFFFF7E3C->Pic0 . squares are for squares. therefore, a black circle is stored to pic0.
Repeat getKey(15) . repeat until clear is pressed
X+getkey(3)-getkey(2)->X . movement
Y+getkey(1)-getkey(4)->Y . code
Pt-Change(X,Y,Pic0 . draw sprite to buffer
DispGraph . display what's on the buffer
Pt-Change(X,Y,Pic0 . draw same sprite to buffer. since it's pt-change, the sprite is erased on the buffer, leaving no
End . residue from movement.
ClrHome . clear the screen, move cursor to upper left corner of the screen.
ClrDraw . clear the buffer.
you can use a subroutine for pt-change() if those 10 bytes you save are really important to you.
982
« on: July 14, 2010, 08:13:51 pm »
the three sprite routines quigibo posted earlier sound great. i would love to see them implemented.
also, someone spoke about rotating/flipping sprites as a built in command. instead of that, could we have a pxl-swap() command? the syntax would be something like pxl-swap(x1,y1,x2,y2). so if (0,0) is a black pixel and (0,1) is a white pixel, pxl-swap(0,0,0,1) would make (0,0) white and (0,1) black. i think this would greatly simplify the process of rotating and flipping sprites 90° can be implemented with some linear algebra and a pxl-swap() command.
983
« on: July 11, 2010, 12:00:11 am »
i know, i thought i would ask here though, since you would probably know as the designer of the parser. a quick addendum, would it be faster to draw the 4x4 black rectangle then pixel-off the 4 in the center? or is this again about the same speed? i have some testing to do...
EDIT: speed over size in this scenario. even if speed is marginal for 200 bytes, i'll take it.
984
« on: July 10, 2010, 11:52:16 pm »
which is faster:
drawing a 4x4 black rectangle, then inverting a 2x2 in the center to make a 4x4 outline rectangle
or
8x8 pt-on sprite.
985
« on: July 10, 2010, 05:33:01 pm »
darl, what kind of game would you might be implementing it into?
986
« on: July 09, 2010, 10:36:39 pm »
another advantage of OS variable support would be if you were developing a basic program and had a routine that just managed/sorted data but took a long time because it's written in BASIC, you could write a quick axe program to do the same thing with the data in the basic variable, compile the program and then run the compiled axe program in the middle of your basic program to do its job in a quick way.
987
« on: July 09, 2010, 10:25:05 pm »
Correct. The only way it helps is if you want a tilemapper or something to be able to export to a string. Case in point.
988
« on: July 09, 2010, 07:13:56 pm »
perhaps have a line emanating from the character constantly, showing where the next portal is going? the keypad would function as usual, so no matter where the line is pointing, if you press 8 the line jumps to 0 degrees, or pointing upwards. then you could press the addition button to make it move a little clockwise, and subtraction counterclockwise? or use the paranthesis buttons to control counter/clockwise. new-ish idea: you have a line that controls where your next portal goes. ( = move counterclockwise couple degrees ) = move clockwise couple degrees. 1-9 = move to corresponding angle and auto-fire a portal.  ? = fire portal
989
« on: July 09, 2010, 06:56:47 pm »
i think you should do it if it's fairly easy to implement. would it be possibly to have the user press a button, and you go into a mode where you can shoot at any angle? so you press a button, then a line appears above the characters head, and when you press the right arrow key it moves a couple degrees clockwise, and the left key makes it go counterclockwise. then the user presses a button and a portal is fired in that direction? if you can't do that/feel it's unnecessary, i'd definitely go for trying 22.5 degree angles.
990
« on: July 09, 2010, 01:10:50 pm »
i agree with deep thought. what if the programmer was debugging the code and tried to draw a circle with a negative radius, and then nothing happened? wouldn't it be much more useful to debug if some sporadic fractal appeared? this way they can easily post on omnimaga or somewhere else where someone can say "yep. that's what happens in axe when you try to draw a circle with a negative radius." also, the problem can easily be fixed with abs(radius) so that it never goes negative..
Pages: 1 ... 64 65 [66] 67 68 ... 82
|
Show Posts