Show Posts

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 ... 78 79 [80] 81 82
1186
Art / Re: Sprite help for Axe game
« on: June 07, 2010, 06:01:49 pm »
8x8 size, i'm assuming. what do you want the sprites to look like?

1187
Miscellaneous / Re: Programming Tutorials, Help, Etc.
« on: June 07, 2010, 04:29:30 pm »
i completely second meishe91. i still remember picking apart in BASIC why If max(A={1,2,3 worked only if A was 1 2 or 3. anyway, i am also interested in good explanations or tutorials on pointers, memory addresses, bytes, hexadecimal storage, RLE and other types of compression for maps, etc. anywhere you learned something from searching online, please share it

1188
you can delete a post in the upper right hand corner there's a delete button. or just edit your code out if you can't get deletion to work. there's so little code there anyway, i'm not sure how strict DJ is with this.

edit: i'm late :(

1189
Axe / Re: Tilemapping efficiently
« on: June 07, 2010, 03:30:22 pm »
Quote
Say I had the number 98.  If I were to do 98 mod 10, it would give me 8.  If I were to do 98/10, and because Axe doesn't keep decimals, I get 9.  Those are the two parts.
this makes an astounding amount of sense to me. NOW i get why in the tutorial for tile-mapping you had to ^16 and /16. thank you! however, in my game i think i'll work on the physics of it and then when quigibo adds tile-mapping support i'll work on the maps. i'm still messing around with this concept however. this thread has been helpful

1190
Axe / Re: Tilemapping efficiently
« on: June 07, 2010, 01:50:56 pm »
thank you

1191
Axe / Tilemapping efficiently
« on: June 07, 2010, 12:43:03 pm »
does anyone know what routine is best for tilemapping? i only need 8 or so different tiles. builderboy's method seems pretty good, but i was wondering if there's a more efficient way to manage a tilemap? also, size plays a factor. i'd rather not use
deltalist(_tilemap data_)->GDB1
as that takes up a lot of size.

1192
Art / Re: space ship
« on: June 07, 2010, 12:39:08 pm »
lol thanks but no thanks. the game i made with the ship sprite is under your projects post and critique in the axe subforum. no enemy ships needed (:

1193
Art / Re: space ship
« on: June 07, 2010, 11:38:50 am »
thanks DJ! i'll stick with that one.

1194
Axe / Re: Making Axe subroutines?
« on: June 07, 2010, 11:16:36 am »
don't quote me on this, but i think it's around 8000 bytes. and it isn't a contest limitation, but i think the ti 84 series of calculators just doesn't support programs larger than the limit (which is somewhere in the 8000+ range). as for chaining them together, i don't think it's possible as of now. except one way might be you have two source programs, prgmSOURCEA and prgmSOURCEB, and you compile them into prgmPARTA and prgmPARTB using a program online, you could unsquish prgmPARTB into hex code, and then in prgmPARTA use Asm(_hex of PARTB here_). but, that's against the rules. you may be able to clear it with dj if you show prgmSOURCEB though.

1195
Axe / Re: How does 4-level greyscale work in Axe?
« on: June 06, 2010, 09:27:21 pm »
yes, but a sprite is 8x8, right? so if you use a blank 8x8 sprite it'll also erase anything close to the sprite on the buffer. pt-change ONLY changes the black pixels of the sprite to white, which makes it perfect to use. also, if you wanted to, you could use pt-off, which would do the same thing. pt-off clears the 8x8 area.

1196
Axe / Re: How does 4-level greyscale work in Axe?
« on: June 06, 2010, 09:02:13 pm »
yes, it is. except unlike using the space character in basic, which updates the screen automatically, in axe you have to manually turn off the sprite on the buffer after displaying the buffer... if that makes sense. but yes, you're correct.

1197
Axe / Re: How does 4-level greyscale work in Axe?
« on: June 06, 2010, 08:55:03 pm »
yeah it's kind of hard to understand. i don't even want to start to understand what would happen without the pt-change's in my grayscale example. it works, that's all i need to know lol. it's one of those situations where a computer does exactly what you tell it to do, and the only way to understand it would be to go step by step through as if you were a computer  :P

1198
Axe / Re: How does 4-level greyscale work in Axe?
« on: June 06, 2010, 08:43:09 pm »
basically the second set of pt-change( 's turn off the sprites so there's no left over residue from movement. i'll try to show you visually.. pardon me if this fails spectacularly. i'm just going to do this in black/white so i can use paint to show you.
1 is a black pixel. 0 is a white pixel. pretend the screen is a grid 3x3 pixels
010
111
010
for example, this would be a cross.
pretend your sprite is:
11
11
or a black rectangle. now, let's jump to the code.
after the first two pt-change('s, your little black rectangle is on the buffer. then it's displayed:
110
110
000
now look what happens without the next two pt-change's. the movement code comes. let's say the user moved the black rectangle one to the right.
101
101
000
what just happened? think about it.
what should've happen was this:
011
011
000
however, since the buffer already has this painted onto it:
110
110
000
and it's inverting the pixels at the new position:
1|10|
1|10|
000
you get...
101
101
000
with the two pt-change's after the dispgraph, it prevents this from happening since the buffer doesn't have any sprite residue left over. hopefully this made sense. and sorry for the long post i tried to be as thorough as possible

1199
Axe / Re: How does 4-level greyscale work in Axe?
« on: June 06, 2010, 08:01:02 pm »
did you get that to compile? i think you meant clrdraw and clrdraw^r, not clrhome. also, it does work, but since the whole screen is being drawn gray, you perceive it as if the contrast had been changed darker. try this:
Code: [Select]
.GRAY
ClrHome
ClrDraw
ClrDraw^R             //clear buffers
[FFFFFFFFFFFFFFFF->Pic1      //16 F's. a black square. which we will make.. gray (:
0->X->Y                            // coordinates
Repeat getKey(15)
Pt-Change(X,Y,Pic1           // draw the black square
Pt-Change(X+8,Y,Pic1)^r    // draw a black square on the back buffer 8 pixels to the right
DispGraph^r                     // draw buffer (with black square) and draw the square on the back buffer with a checkerboard pattern
Pt-Change(X,Y,Pic1           // to create grayscale
Pt-Change(X+8,Y,Pic1)^r
X+getKey(3)-getKey(2)->X
Y+getKey(1)-getKey(4)->Y        // Movement code
End
it just makes a rectangle, one half of it is black and the other half gray so you can see the difference. and, you can move it.

1200
The Axe Parser Project / Re: Your Projects - Post and Critique
« on: June 06, 2010, 07:40:52 pm »
1. no, i don't think it is.
2. i'm not sure. i guess it could be useful in a whack-a-mole game, where the user is trying to cheat by holding down the keys. so you could have a section of your code be
Code: [Select]
repeat getkey(0)=0
end

that way they don't cheat.. but otherwise i haven't ran into a use for it.

Pages: 1 ... 78 79 [80] 81 82