Forums

Topic: Petit Computer

Posts 9,121 to 9,140 of 9,621

SmokedSausage

damolii wrote:

SmokedSausage wrote:

FINALLY SOMEONE BESIDES ME HAS THE FREAKING STANDALONE!? Omg, we should play sometime.

??? The..standalone...??

Wow, did i seriously just quote the wrong reply...my bad...

Hi, I'm SmokedSausage and i like meemoos :^)

Twitter:

Mariominer

Hey! I noticed that GRP data is my favorite way to store map information. For these following reasons I support this claim: 1. GRP data is easily changeable and modifiable, 2. You can easily save map data by just saying "SAVE "GRP:NAME", and 3. With 256X192 pixels, it can save large amounts of data.
My first reason is that GRP is easily changeable (GRP is really just short for Graphic). You can call commands to modify 1 block or a whole section using a single command- GPSET or GFILL or GLINE or a whole ton of graphical commands. Graphic is also easily read because of the 255 numbers they can store. And if you take two spaces you can hold 255255 (EDIT: No. You can't. You could with 6 pixels though 030). All you need to Use if GSPOIT().
Saving map data is really easy. You can write the inventory using some FOR NEXT and GPSET. Then all you need to do is load it and read the inventory and, if you use GRP in the entire program, no reading is needed for the map.
Lastly, GRPs can hold massive amount of data. with 255*191 pixels, you can hold a 255*190 map and still have enough room to have a 255 item inventory! They can hold all your variables, as long as you make sure the map isn't too big, or you'll run out of space. You still probably won't run out of room. I have a map that is the entire screen with 1 block map tiles, and I can still put WAAAAAAAY more data in there.
As you can see, I can bring a GRP debate to the table. Consider what I thought, and vote for the Affirmative team! Totally debate!

Edited on by Mariominer

Like a boss? Please, I AM a boss. You're welcome

3DS Friend Code: 1543-5315-3818 | Nintendo Network ID: Storybookten9

Discostew

@Mariominer A little off on your numbers. It can hold 256x192 bytes worth of data. 2 pixels can hold a value up to 65535 (p1*256+p2). It's the best way to hold raw data, but unfortunately, its rather slow to read/write to it.

Discostew

3DS Friend Code: 4425-1477-0127 | Nintendo Network ID: Discostew

Mariominer

Ha ha ha. I knew the first numbers were wrong- I just assumed of the coordinates at first. The data of 2 pixels I just estimated as a string value thing type-
A$=STR$(GSPOIT(X,Y))
B$=STR$(GSPOIT(X+1))
A=VAL(A$+B$)
I'm not sure if that would work, but thanks for saying what I was off from.

Edited on by Mariominer

Like a boss? Please, I AM a boss. You're welcome

3DS Friend Code: 1543-5315-3818 | Nintendo Network ID: Storybookten9

Discostew

Mariominer wrote:

Ha ha ha. I knew the first numbers were wrong- I just assumed of the coordinates at first. The data of 2 pixels I just estimated as a string value thing type-
A$=STR$(GSPOIT(X,Y))
B$=STR$(GSPOIT(X+1))
A=VAL(A$+B$)
I'm not sure if that would work, but thanks for saying what I was off from.

Technically, it wouldn't work because it would not allow all the values between 0 and 255255. A value like 1830 is possible, but now you have to base it on either "18"+"30" or "183"+"0". Now, what about a value of 100001? In string concatenation with 2 values from 0 to 255, you'd attempt something like "100"+"001". You can get "100" easily, but how would you get "001"? Or what about the value of 100830? "100" is possible, but not "831" as that exceeds 255.

Discostew

3DS Friend Code: 4425-1477-0127 | Nintendo Network ID: Discostew

Mariominer

Yes. I always get SOMETHING wrong. Maybe you could do something odd to make it work like
IF A$!="0" AND LEN(B$)<3 THEN B$=B$+"0"*(3-len(B$))
As for the 100831 example, you have a good point. AGAIN I'm not sure if that code bit would work, as it's untested.

Like a boss? Please, I AM a boss. You're welcome

3DS Friend Code: 1543-5315-3818 | Nintendo Network ID: Storybookten9

TexMurphy

Having trouble with Mortal Kombat. I have 32x32 sprites for all character images which includes low kicks and high kicks. For throwing fire, I check the missle sprite with a target box based on the target's x,y position. If the character jumps the target box follows. Using SPHITRC. This allows the character to jump over an missle. But, with a simple kick the x,y position of the target doesn't change for standing or ducking. This is always at the base of the sprite in the center. The only way I think a high kick can miss a ducking character would be to record the sprite index and compare that for any of the 7 or 8 characters. Does anyone know a better way?

TexMurphy

damolii

@TexMurphy You could have a "collision area" for the fighters, and if a sprite enters that collision area, a result commences. Then, you could alter the collision area so that ducking sprites don't get hit by the missile.... just a suggestion :/...

Edited on by damolii

I don't have a 3DS so what do I put here? -Damolii

Pixelrobin

@Discostew I need help. How did you handle collisions between megaman and bg tiles? In my case, the bg tiles are "standard 8x8 size" (unlike mm2 I believe) and I could also check from a 2D array. I have a basic system in place, but it glitches out a lot. My character is 16x16 pixels and moves freely (as in not fixed on a grid). Oh and it's a platformer and I do have velocity.

Everybody do a chirp. CHIRP.

3DS Friend Code: 3007-9228-5126

Discostew

@Bluerobin2 First off, Megaman has a location within the level, so be sure to be tracking that in your own project. Do not use the screen position for testing collision when using a scrollable background. Use velocities to determine which edges of your sprite need to check for collisions. If moving downward, then you'll be checking the bottom edge of the sprite. If moving right, then check the right edge. No need to check the opposite edges. Let's use the right edge for this example.

Using the sprite's position relative to the level, you offset towards the edges to get their spacial areas. In this case, the right edge. If the center of your 16x16 sprite is straight dab in the middle, and it was moving right, then you'd check the edge 8 pixels to the right, from top (-8 pixels) to bottom (+8 pixels). Technically, it would be +7 pixels because the center counts as 1 pixel, and +7 is the next 7 pixels, making 8. Just imagine a 16x16 pixel sprite broke up into 4 8x8 pixel blocks forming a square. Because the center has to exist on a pixel, that pixel would be located in the bottom-right block.

You won't need to examine all 16 pixels though, just a couple based on your sprite size and the tile sizes. The two points that make up the edge (in a vertical line, the top and bottom points) are mandatory as they describe the extremes of the edge. You'll also have to check every 8 pixels of the edge too based on your 8x8 pixel tilemap. Why? Well, if we only checked the top and bottom points of the edge of this 16x16 sprite against an 8x8 pixel tilemap, a tile defined as solid could go straight through the middle of the sprite if the points ended up above and below. Therefore, we have to check in between. Checking every 8 pixels is optimal of this vertical edge because the height of the tiles are 8 pixels, so in no way can a tile be able to pass through. If the tiles were 16 pixels high, then you'd check every 16 pixels. So, with a 16 pixel tall sprite with a center right in the middle, you'd check POSY-8, POSY, and POSY+7 (as explained above).

So now, in this case, you have 3 points to examine, all on the right side defined as POSX+7 (again, for the same reason above). Now I assume you have a 2D array that holds your collision data (one entry per tile, so a 32x32 tile map would make 32x32 collision entries). For each of the points you are examining, just use them in the array, converting them into tile-space (which is dividing by the width/height of the tiles), so if the array is called COLDATA, then to check the top-right corner of the sprite, you'd do this...

COLCHK = COLDATA((POSX-8)/8,(POSY-8)/8)

You'd be checking all 3 points for the same value, which can be combined into one line if you wish.

COLCHK = COLDATA((POSX-8)/8,(POSY-8)/8) OR COLDATA((POSX-8)/8,POSY/8) OR COLDATA((POSX-8)/8,(POSY+7)/8)

Then, when you examine the result, like, if COLCHK is 0, then then no collision was found. But, if it is not 0, then you found a collision. Now, other than finding a collision, you must have the sprite react to the collision, where in this case, make sure it stops at the solid tiles and not go through it. No need for checking the collision table after this. You only need to align the sprite against the tile's width/height boundaries (which in this case, are 8x8 pixels). During the edge testing phase, your sprite is considered partially in the wall, so you want it to be moved in the opposite direction just enough to be lined up right against the wall (not too little to still be in the wall and not too much or else your sprite will start doing some rubber-banding against the wall). You do this by taking the horizontal position of the sprite's edge (POSX+7), finding out the position within tile space ((POSX+7)/8), get the integer value (FLOOR((POSX+7)/8)), convert back into pixel space (FLOOR((POSX+7)/8)*8), and then shifting by the horizontal distance from the center to the edge in the opposite direction of the horizontal velocity (in which you would then use 8 instead of 7).

POSX=FLOOR((POSX+7)/8)*8-8

That can be quite a bit of math, but if you understand bitwise operations, you can reduce the amount of calculations done, using AND to take the place of FLOOR, divide by 8 and multiply by 8. For instance, using a maximum of 4096 pixels wide for any given level, you can use a bitwise operation of AND 4088 instead.

POSX=((POSX+7) AND 4088)-8

So why 4088? Well, 4088=4096-(width of tile). This grants alignment to 8 pixel boundaries. If the tiles were 16x16, the bitwise value would need to be 4080. This only works with sizes that are powers of 2 (2,4,8,16,32,etc), so don't expect sizes of something like 13 to work.

At any given time, you'll either end up having to test 1, 2, or 0 edges, based on velocities. Hope I didn't make your head explode.

Discostew

3DS Friend Code: 4425-1477-0127 | Nintendo Network ID: Discostew

Zalkia-ent

hey guy's! im working on 2 new project' s. the first one is a cave story demo.the next one is cave story 2
there all too (unfinished) to release right now. but when they are released I hope you like them

email:[email protected]
if facebook,myspace,instagram and twitter were all shut down, 90% of the teenage population would go insane. if your one of the 10% that would be laughing at them, copy&past this to your signature and hope it happens. Wait... NO!

Pixelrobin

@Discostew no it didn't. My method I was using was similar, but I didn't do the 2nd part. I'm not THAT much of a noob . Just a little...

Thanks

Everybody do a chirp. CHIRP.

3DS Friend Code: 3007-9228-5126

bigdog00

Getting a new PC Sunday night, so I can work on more petit computer QRs codes and stuff.

I like petit computer! Asphault 3d is awesome!

3DS Friend Code: 0473-8697-6288 | Twitter:

Pixelrobin

@Discostew I'm really sorry but I can't do it. I've tried and tried, but I cannot fix the glitches I originally had, even after putting some of your code in. Could you take the time to take a look at it? I know you will probably rage about my terrible coding but please try understand it; its not that long. I've made no progress in the last 3 days. The biggest glitch is where you fall through corners because the game is checking the tile after. I haven't added a collision check at the top of the character yet because it always didn't work properly. There are also some resources it needs of which I did not include, but it'll be fine without them.

Untitled

Thank you .

Everybody do a chirp. CHIRP.

3DS Friend Code: 3007-9228-5126

Discostew

@Bluerobin2 I'll give it a look when I have time. I should be in bed right now.

Discostew

3DS Friend Code: 4425-1477-0127 | Nintendo Network ID: Discostew

Discostew

@Bluerobin2 ok, I've made some modifications, and it should work the way you want it.

Untitled

A few notes:

I changed the SPHOME to the center of the sprite at <8,8> instead of <8,0>, so expect changes to collision checking to be offset by this.
Rather than allowing left/right movement if no collision is found collision, moving left/right is done prior to checking for collision, and then will align sprite if collision found. This will allow complete alignment if you choose to to use a different speed that isn't an integer.
Instead of two separate spots for vertical downward collision, I combined them into one, while also doing the same thing as I did with horizontal movement by having the gravity/position calculated first, then collision checked, followed by alignment.
The labels @COL and @COL2 have been removed
@Jump was changed to check for more than just directly below the sprite's center point, because it wouldn't jump if on an edge with that center point above an open area.

Edited on by Discostew

Discostew

3DS Friend Code: 4425-1477-0127 | Nintendo Network ID: Discostew

SmokedSausage

I have a question. So, I have a FOR loop set up to spawn 98 sprites with a random value of 1-12 and to move them randomly across a 1000x1000 field.

FOR E=0 TO 98
SPSET E,RND(12),0,0,0,0
SPOFS E,RND(1000),RND(1000)
NEXT

Now, here is my real question. I want to check collision between another sprite and any of the sprites that are randomly spawned. Just a rough draft, here is pretty much what I want to do -

IF SPHITSP(E, 99(Cursor Sprite)==1 THEN DO STUFF

Obviously, that won't work. What I am looking for is to check collision between my cursor(99) and any one of the 98 randomly spawned eggs (Did I just give away what I am making? Whoops.) And maybe to be able to move every single sprite as a group. Can someone help?

Hi, I'm SmokedSausage and i like meemoos :^)

Twitter:

Pixelrobin

oh thank you @Discostew sorry about the col subroutines, they were leftovers from my previous system and they used to have way more code in them. I owe you one.

Everybody do a chirp. CHIRP.

3DS Friend Code: 3007-9228-5126

TexMurphy

@SmokedSausage How do you use SPCOL? It has a "group" as the last parameter. Could this work? Otherwise you would have to have a FOR loop to cycle through all of the sprite numbers and check the collision. GOTO out of the loop if collision is true. Then use the loop number for the sprite that you collided with.
FLAG=0
FOR i=0 to 98
If SPHITSP( i, 99)==1 THEN FLAG=1:GOTO @SKIP
NEXT
@SKIP
IF FLAG==0 GOSUB @MISS
IF FLAG==1 GOSUB @HIT
END
@HIT
SPOFS i,0,0
RETURN

Edited on by TexMurphy

TexMurphy

Pixelrobin

@SmokedSausage in your case, just use SPHIT(99). This will check your cursor sprite against ANY OTHER sprite. Otherwise look into sprite groups if you want multiple cursors or something.

Everybody do a chirp. CHIRP.

3DS Friend Code: 3007-9228-5126

Top

Please login or sign up to reply to this topic