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 - LemonDrop
1
« on: November 15, 2013, 10:55:08 pm »
So I was trying to think of a system to do a sort of fog of war system based on tiles that can be seen by the player (not relatively complex), but was having a hard time doing so. The first idea I had involved having a sort of nested for loop x/y system which would check all the sprites in a diamond shaped area (in a certain order of course) and if it hit a solid tile, abort that row. Sadly mid-coding it I realized it would only work on one axis so I decided the only other way would be to do actual raycasting checks to see if anything is in the way of each "light beam" to a tile (in a diamond area pattern again). I planned it to go something like: - Index all (solid) tile coordinates (tile x*8, tile y*
 in a 7x7 area to some temp location. (Square because calculating a diamond is more costly) - For each tile in the view diamond loop, use the start and end point of the "line" made from the player to the tile to check if any of the x/y coordinates in the previous step are within 8 pixels of it. (Math behind it: http://stackoverflow.com/a/14554286/2085551)
- Finally display the ones as they pass the test
As fast as axe is at math however I feel like this many calculations may slow down my frame times too much, so I was wondering if there's some crazy optimized calculator method of "dynamic lighting" or whatever for tile-based games.
2
« on: November 03, 2013, 02:45:52 pm »
Yea that was the old system and I did get it working but it had a lot of weird issues such as sometimes the bullets would have really sharp paths and sometimes they would just go for a bit then dive straight down depending on what its target was, that is probably my fault but I'll test around some more to see if this is better.
3
« on: November 03, 2013, 01:59:27 pm »
So I tried my idea of using a constantly stacking radius vs adding on to previous coordinates and got this:  Thanks for the help guys (wouldn't have thought of that without all this talk about it).
4
« on: November 03, 2013, 02:50:54 am »
Ah I'll try that out. I also just thought, maybe I shouldn't be adding to the previous frames coordinates, and maybe just re-calculate the coordinates alltogether just with the "velocity" being the thing that stacks each frame. I think that will give it a lot more precision or something.
5
« on: November 03, 2013, 02:35:10 am »
Well... divide by 127 ?
Be sure though not to divide right after you made the (co)sine calculation or you'll always get 0 or 1 or -1. For example, if you have to do sin(a)*r, do sin(a)*r/127 and not sin(a)/127*r.
Also, if you don't care about losing a bit of precision, divide by 128 instead of 127. It is a less ugly number.
Problem with that still is if the r value (or velocity, whatever you want to call it) is something like 1, and the result from the sin/cos isnt 127, it will just round down to 0 or whatever and not move. I was thinking about multiplying the coordinates by 2 then dividing them again to get more precision or something but that doesn't seem like it would fix the problem.
6
« on: November 03, 2013, 01:41:58 am »
So I have been trying to make a bullet movement system based off a concept like this:  (I am pretty sure this math is correct) The inverse tangent function makes sense with how it returns a number between 0-255 but I don't really get how the sine and cosine ones work. They accept the same angle the arctan one outputs, but then they output a value between -127 to 127 which is odd. Like I guess that 127 is supposed to represent the value 1 and -127 as -1, but I don't know how I would make a conversion like that inside code. Heres what I was working on: (X and Y are firing coordinates and W and Z are the target coordinates (x and y respectively). If getKey(27) and (R=0) and (B<10)
.MAKE NEW BULLET
22->R
B+1->B*6+50+L1->I
Y->{I}
X->{I-1}
.SET SIGNS / WIDTH / HEIGHT (1 being positive, 0 being negitive)
If Y>Z
0->{I-2}
Y-Z->J
Else
1->{I-2}
Z-Y->J
End
If X>W
0->{I-3}
X-W->K
Else
1->{I-3}
W-X->K
End
.ANGLE
tan^-1(K,J)->{I-4}
.VELOCITY
1->{I-5}
End
.BUL_PROCESS
For(I,1,B)
6*I+50+L1->J
.FIND NEW DISPLACEMENT VIA ANGLE/HYP (VELOCITY)
cos({J-4})/127*{J-5}->K .This is where I have no idea what I am doing
sin({J-4})/127*{J-5}->L
.UPDATE POSITION BASED ON SIGN
If {J-2}
K+{J}->{J}
Else
K-{J}->{J}
End
If {J-3}
L+{J-1}->{J-1}
Else
L-{J-1}->{J-1}
End
.REMOVE OUT OF BOUNDS
If ({J}=57) or ({J}=0) or ({J-1}=89) or ({J-1}=0)
Copy(6*B+50+L1,J,6)^^r
B--
I--
End
EndI know the problem lies somewhere with how I am using the sine and cosine functions (or atleast tried to), but I dont know how to fix it because theres no much documentation on stuff like this. Anyone see a way to fix this?
7
« on: November 01, 2013, 11:40:22 am »
Thats a pretty good idea of refrencing them with another set of data, I'll have to try that later.
I was wondering also why you use ° when you store the data, because ° returns the memory location of the variable apparently but I don't see why you would want to store it to that or something. Also Is a while loop with a conditional end more efficient than a repeat or are you just doing that so the code is executed before it checks if it exited.
8
« on: November 01, 2013, 03:00:53 am »
So I got some code that allows the user to move around on the screen with 8 directions (holding down multiple buttons), but mapping sprites to that is something I am challenged with. For 4 directional movement, you can just have some sort of directional value and store the key pressed (or some sort of state value) to there, and multiply it by 8 to get an offset in a spritesheet. Problem with 8 directional is you can have a lot of key combos (even weird ones like all 4 at once). I thought of doing the same thing and just adding the directional values together to get the offsets but its kind of silly and it skips a whole sprite at the end (number 10):
1-d
2-l
3-d+l
4-r
5-d+r
6-l+r
7-u
8-u+d
9-u+l
11-u+r
I was wondering if anyone had a better system than this because its been annoying me for a bit. Thanks.
9
« on: September 05, 2013, 06:42:43 pm »
Apparently after all this time I still cannot figure out how to make an effective AI system for enemies (firstly what values to even store for each enemies, and also how the ai would work). I could easily just make enemies come down from the top of the screen or do a space-invaders style thing but I wanted them more to actually have more curved movements (some enemies just coming down at angles, others trying to run into players or avoid bullets, etc) but it is complex to try to make a system that allows them to do this type of movement, and also calculates positions for them to go to in the first place. I guess the best way for me to learn is to look at examples of other stuff with the same style (shooter space game thingy) so if anyone knows a game like that that is open source, sharing it would be helpful so I can learn.
10
« on: August 06, 2013, 08:19:36 pm »
That looks great! I was in town earlier today with no obligations, so I programmed for a bit and converted my BASIC code to Axe and then modified it a little. It currently only does one bullet at a time, but I am going to add in code to have a bullet buffer. I managed to figure out a way to make sure bullet movement was not bugged except for one case with an acceptable bug (I think). Shooting vertically will cause it to shift 1 pixel off course, but I don't think that should be a problem. Anyways, see the screenshot 
EDIT: Updated the code, now it uses a bullet buffer. It currently handles 64 bullets on screen at a time and it is still at 6MHz. Feel free to use any of the code or look at it or whatever!
Nice, I'll definitely have to check that code out, might use something from it. My next thing to be dealing with however is the enemy movement. I see you have some sort of AI in that second image so I'll see how you did that too and maybe get some ideas.
11
« on: August 06, 2013, 01:04:11 am »
-snipped-
Ok so I completely fixed my code: On line 41 and 44 X should've been Y, thats just a stupid mistake, but there was also a problem with the pseudo code of your algorithm I was basing my calculations off of. You mixed up the width and height calculations for the accumulator, causing it to not work properly. Just because I was completely out of Ideas I just switched them in my if statement and it worked perfectly (well sometimes the bullets take really sharp turns but its only in certain positions). Heres an image:  So thank you so much and sorry it took so long to get something working, but couldn't have done it without your algorithm.
12
« on: August 05, 2013, 11:30:56 pm »
Hmm, I recognise the problem, but I did not see the issue in your source code immediately. Hopefully I will take a look at it tomorrow and possibly figure out the issue.
I would also like to point out that you can do signed comparisons. For example, {J-6}<<0 to see if it went below zero. I think Axe probably does an auto-optimisation for that.
I tried my attempt above and found that it doesn't work (I forgot some of the nuances of Axe  ). I did get it to work in BASIC, though.
Well if you can show me the basic code that would be nice because I know that really well, also I would be using singed numbers except a 8bit one is limited to -127 to 126 or whatever, and there is a possibility of the accumulator exceeding that (its maximum possible value is 250)
13
« on: August 05, 2013, 11:02:32 pm »
I've been looking at the behaviour and I may have another idea why it's not completely working, though it's hard to explain and I'm not sure it happens all the time. When you move vertically up, your x value doesn't change, perhaps your program isn't always calculating the change in y value, and because the x value is not changing, the program isn't calculating a new angle for the bullets to shoot to.
Just a suggestion.
I really dont think thats the problem, or atleast I dont think that would happen in axe, but I'll check it out.
14
« on: August 05, 2013, 10:30:09 pm »
That's weird, sometimes there's some sort of delay of the bullets changing direction as the player moves around the screen, sometimes it happens much more quickly
8*I+L1->J
So that definition defines J, which then calculates the bullets' positions. Could this be it? Also how is the code for taking the player's position on the screen taken into account?
If you look at the code where the bullets are created, you can see that X and Y are subtracted in a way that gives a width and height value. Because there can be no signed numbers, I check to see if they are less or greater than the fixed position of the enemy (44,25) and then set the "x and y speed" accordingly so when the operations are preformed later it simply adds that value minus one to the x or y position of the bullet when needed. Its pretty hard to explain and its based off the algorithm the person above that post came up with so any more information lies in there.
15
« on: August 05, 2013, 06:34:10 pm »
-lots of helpful stuff- Ok so I spent the night writing my own axe test code based on the way I store data and calculate bullets and came up with this based off the way you explained your math calculations:  But as you can see it really doesn't work too well. Heres the source of the test: .ANGLEA
[00003C3C3C3C0000]->Pic1
[0000001818000000]->Pic2
DiagnosticOff
ClrDraw
DrawInv
StorePic
.FIRING POS: 44,25
30->X
54->Y
0->B
Repeat getKey(15)
RecallPic
sub(D
DispGraph
If getKey(2) and (X!=1
X-1->X
End
If getKey(3) and (X!=87
X+1->X
End
If getKey(4) and (Y!=1
Y-1->Y
End
If getKey(1) and (Y!=55
Y+1->Y
End
.BULLET STRUCUTRE: {PTR-7}-None {PTR-6}-Accumulator {PTR-5}-Width {PTR-4}-Height
.{PTR-3}-XSpeed {PTR-2}-YSPEED {PTR-1}-X {PTR}-Y
!If rand^(8)
.MAKE NEW BULLET
B+1->B*8+L1->I
25->{I}
44->{I-1}
.SET X AND Y SPEED (2 being 1, 0 being -1)
If 25>Y
0->{I-2}
25-X->{I-4}
Else
2->{I-2}
X-25->{I-4}
End
If 44>X
0->{I-3}
44-X->{I-5}
Else
2->{I-3}
X-44->{I-5}
End
.SET ACCUMULATOR, W, H (I-7 is nothing)
{I-5}->{I-6}
{I-5}*2->{I-5}
{I-4}*2->{I-4}
0->{I-7}
End
For(I,1,B
8*I+L1->J
.CALCULATE BULLETS POSITION
If {J-6}>{J-5}
{J-1}+{J-3}-1->{J-1}
{J-6}-{J-5}->{J-6}
Else
{J}+{J-2}-1->{J}
{J-6}+{J-4}->{J-6}
End
.DELETE OFFSCREEN BULLETS
If ({J}=57) or ({J}=0) or ({J-1}=94) or ({J-1}=0)
8*B+L1->K
Copy(K,J,8)^^r
B-1->B
I-1->I
End
End
End
Lbl D
.DISPLAY BULLETS/SHIPS
For(I,1,B
8*I+L1->J
Pt-Change({J-1},{J},Pic2)
End
Pt-Change(44,25,Pic1)
Pt-Change(X,Y,Pic1)Is there something wrong with it which would make the bullets not really target the player (ignoring the check for if width=0, I skipped that because its easy to do)? Or is this just how its supposed to work.
|
Show Posts