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 - Xeda112358

Pages: 1 ... 74 75 [76] 77 78 ... 317
1126
Grammer / Re: Grammer 3-Concepts, ideas, requests
« on: February 19, 2013, 12:42:24 pm »
Actually, I already have the code for pixel-testing along lines, circles, sprites, and rectangles (but pixel testing rectangular regions already exists in Grammer). In fact, here is an example where I used my sprite pixel testing:

It doesn't return how many pixels there are, though, it only checks if there are any pixels. (so it returns 1 or 0). As a note, that is not a Grammer program or a Grammer 3 program :P

1127
Other Calc-Related Projects and Ideas / Re: OmniRPG - Sprites
« on: February 19, 2013, 07:42:30 am »
@willrandship: Those tiles look very nice. To accomplish the grayscale, I will need to set the tile animation speed to the fastest, but that shouldn't be a problem. And yes, the plan is to have it 8x8 tiles,  but a bunch of them will be pieces of 16x16 tiles, if that makes sense. This will make the tilemapping much easier and it provides a good balance of detailed tiles (16x16 tiles) and detailed tilemaps (detail is down to 8x8 tiles).

1128
Other Calc-Related Projects and Ideas / Re: OmniRPG - Coding
« on: February 19, 2013, 07:36:35 am »
That does sound rather cool, matrefeytontias! If I have time later, I was thinking about how some battle animations might work. I don't think it would at all be difficult to make a lightning bolt come from the sky and hit a square or to launch a fireball in an arc and have it pummel a square.

1129
Miscellaneous / Re: High level languages are vexing
« on: February 18, 2013, 09:55:25 pm »
I am not talking about complexity but about calculating in calculations. You will never be able to write this in basic:
Line(8,+1→A,,*2)
In Basic, you'll have to write:
9→A
Line(8,A,A,A*2)
Psh, in BASIC you just do:
Code: [Select]
9
Line(8,Ans,Ans,Ans+Ans

1130
Miscellaneous / Re: High level languages are vexing
« on: February 18, 2013, 12:51:08 pm »
Yeah, I felt this way many times with Axe. One good solution, though, is to use a high level compiled language (Axe/C/C++) with some assembly mixed in every now and then. That way you get the best of both worlds. It's what I do.
Yeah, I usually end up mixing in assembly to make things work faster. I often do this for programs that don't allow you to extract the remainder and integer part from a division x.x

1131
Grammer / Re: What's wrong with this code ?
« on: February 18, 2013, 12:47:52 pm »
Yes, sorry, I always forget to activate the token hook XD 'prgm' turns into 'call '

Also, very funny Adriweb >.> :P

1132
Grammer / Re: What's wrong with this code ?
« on: February 18, 2013, 07:57:55 am »
Yep, if Grammer isn't installed and you try to run the program, it will be run as a BASIC program, so it exits. If it is run as a Grammer program, the first "." tells it that it is a label, so it skips the line.


And here is the code:
Code: [Select]
:.0:Return
:31→Y
:47→X
:0→L
:30→M
:1→P
:ClrDraw
:While Y=abs(Y
:Line(0,59,5,96,1
:randInt(0,86
:Line(,59,5,12,2
:1→F
:For(A,1,M
:getKey→K
:If K=10
:Full
:If K=11
:Full0
:K=3
:-K=2
:+Ans+X
:If <86: and !Line(Ans,Y,6,6,15
:→X
:If Y<52: and !Line(X,Y+6,1,6,14
:IS>(Y
:Repeat 1
:Return→Z
:Line(X,Y+1,4,6,2
:Line(X+1,Y,6,4,2
:End
:DispGraph
:prgmZ
:If P xor 1→P
:Tangent(1,8:Y-!!Line(X,Y,7,6,15→Y
:End
:If L+1→L=5: and M>14
:Then
:0→L
:M-1→M/30
:If θ': and P>0
:P-1→P
:End
:End
:Stop

1133
Other Calc-Related Projects and Ideas / Re: OmniRPG - Coding
« on: February 18, 2013, 07:40:49 am »
First, that is an awesome transition scene!

As to using Buf(), there may be a problem. Does Axe store the buffer in the program? If so, that will be a waste of 896 bytes because I only need it temporarily.

1134
Other Calc-Related Projects and Ideas / Re: OmniRPG - Coding
« on: February 17, 2013, 03:08:39 pm »
Yeah, it doesn't support scrolling yet. For all of the things I am thinking about adding, it will probably have its speed cut in half. I think the easiest way to have the sprite display and the LCD updating interleaved will be to have 8x8 tiles, but we can use those to form 16x16 tiles. I am working toward creating a movement engine that features pixel based collision with bottom layer of sprites (the mask) and there will be a buffer holding damage zones for when enemies are on the screen, or anything that can cause damage. So for those, I will need two 768-byte buffers  (plotSScreen and saveSScreen) and then AppBackUpScreen can hold all sorts of special info about where monsters are, open menus, and all that good stuff. I am planning to insert a 14*64 byte buffer using bcall(_InsertMem) at the end of the program to work as a buffer for the screen instead of using plotSScreen and this should really help with scrolling.

1135
Other Calc-Related Projects and Ideas / Re: OmniRPG - Coding
« on: February 17, 2013, 10:33:57 am »
I have some sprite movement started :) I don't have actual player sprites, so I just used an 8x8 sprite. I am working on making the data for some sample 16x16 sprites, but once I actually have the data in there, it won't be difficult to add in 16x16 player sprite movements.


EDIT: Also, I need to come up with a less distracting animation XD

1136
Introduce Yourself! / Re: This is Samos!
« on: February 17, 2013, 08:03:32 am »
@xeda Do you want some help for your french homework?   :angel:
Hehe, if I have anything too difficult, I usually ask on IRC. Usually it isn't that difficult, there is just lots of homework o__o

1137
Sadly, it doesn't :(
Apparnetly it's still 0 or 1.

But that could be a feature request.
So that means that pxl-Test( is available, though :D This could definitely be something that can be done as an assembly program or tool, too. If they still allow parser hooks, then we could intercept the pxl-Test( command or something.

1138
And as a number, hopefully x.x It wouldn't be nearly as useful if you had to do something like:
Code: [Select]
If Green=pxl-Test(Y,X

1139
Other Calc-Related Projects and Ideas / Re: OmniRPG - Coding
« on: February 16, 2013, 02:25:32 pm »
I modified the source to the animated, masked tilemap routine and it is now 43 bytes larger. I am not sure how much faster this is, but WabbitEmu says it is about 150% faster. Basically, instead of using bcall(4744h), I used direct key testing which cost an extra two bytes but is much faster, and instead of using bcall(_GrBufCpy) (EF6A48), I used a custom LCD updating routine which I believe should be pretty fast and I can make it even faster since it is inline code.

Anyways, see below for what it currently looks like (I took about a 1 second screenshot, so it is on a loop). Now if I can get it to handle scrolling, that would be awesome, but I am pretty sure I will have a difficult time with that. I might be able to get a movable sprite on there, though. Also, the grayscale looks better on an actual calculator.

AMASK is for the most part hexadecimal with some labels (it is meant to be compiled with prgmASMCOMP) and prgmMASKEDTM is the assembly program.

EDIT: I rewrote the program to draw the tilemap while updating the LCD and doubled the speed to about 73 FPS according to WabbitEmu. It is also 27 bytes smaller :) At some point I should make actual tiles for this.

1140
Then that is still 4 bits :] and that means 12-bit numbers can fit in 3 pixels so 0~4095 :D

Pages: 1 ... 74 75 [76] 77 78 ... 317