Benimo12 2022-05-22 18:01
I’ve been working on UBite for a while and I’ve been experimenting with scripts that work for cells and sprites (whether controlled or ai) all in the name of making a suitable LowRes Engine but I’ve never been able to get cell collision rightly.
With the scripts I’ve been trying out, they either: Don’t work, Teleport the colliding sprite to a different coordinate or… Only let 2 sides of a cell collide at a time.
Is there anything I’m missing?
Benimo12 2022-05-22 18:03
By the way, I’ve been able to create a basic lighting system for both sprites and cells
McPepic 2022-05-22 18:25
In the case of sprite to cell collision, there are a couple of things to keep in mind.
You can only check one pixel at a time, so you have to make sure to limit it to checking just enough to close off the edges of the sprite.
This can be done by checking for collision at the four corners of the sprite, as well as every 8 pixels along the sprite’s border (which is the width of a single cell)
Just take the pixel coordinates where you want to check, integer divide by 8 on the x and y, and check the value of cell.c at the new coordinates.
I usually store the current and target coordinates for the sprite. That way, when you want to move it, you change the target position, check the appropriate pixels relative to the target position, and check if at least 1 of those collision checks returns true.
If none of the checks finds a wall/collidable cell, you can set the current position to the target position. Otherwise, you set the target back to the current position.
Ideally, this will all be in a sub program, so you can just put in the coordinates you want to check, and it will do all the necessary collision checks.
was8bit 2022-05-23 03:29
Since your layout matches cell layout, i would recommend simulated smooth movement... that is, movement begins and ends precisely inside and lined up with each cel block...
This is accomplished by checking if cell you want to move into is "empty" (orthogonally or diagonally) then perform 8 pixel movements into that cell.. then stop
Continuous movement in one direction may appear smooth, but it is always in sets of 8 pixels at time, ensuring movement always ends inside a cell block
was8bit 2022-05-23 03:32 (Edited)
I do this trick quite often...
Benimo12 2022-05-23 21:31
Thanks was8bit, your method actually works. You’re such a lifesaver
Benimo12 2022-05-23 21:49
What I did was to make a “hitbox” 2x the size of a cell with BX the Cell’s X+1 and the BY the Cell’s Y+1. If X or Y (Both divided by 8) is equal to any of the variables (including the cell’s X and Y) then updates of X and Y are reversed not totally cancelled.
Benimo12 2022-05-23 21:50
I made it to check for just the specified cell not if the cell is empty
Benimo12 2022-05-23 21:51
Thanks for all the help guys
was8bit 2022-05-23 23:04
Glad to help :)
Now IF your background doesnt all fit into the cell grid, another approach is to read all 4 surrounding cells your sprite character COULD collide with and add 4 sprites that match those both in position as well as character image... THEN do a SPRITE HIT check on each of those 4 added sprites..
This is abit cumbersom, but the advantage is that SPRITE HIT checks for collisions at the PIXEL level, making it VERY accurate...
I have an example of that...
was8bit 2022-05-23 23:09
Oh, just remember that you have to remove those 4 added sprites right after you finish your SPRITE HIT check...
So thats what makes it so cumbersome... for each pixel movement you want to do, you have to ...
1) read all 4 nearby cells, and duplicate them with 4 sprites..
2) temporarily move your player sprite
3) do a SPRITE HIT check with your player sprite and each of the added sprites
4) IF a hit is detected, back up your player sprite to its original position
5) remove all 4 temporary sprites...
Benimo12 2022-05-23 23:53
I see, I see but, I don’t think there’ll be a need for that… I’m making an open source game engine and just wanted a program that creates a collision for all possible entities (sprites) and not one focused one. This is why I used your earlier method and not McPepic’s although both of your contributions are equally valid.
Benimo12 2022-05-23 23:56
I don’t think I have any more graphic space for a GUI so, I guess I’ll just release the fully articulated code so that you’ll see everything that’s going on the moment I decide UBite is finally ready for release. Till then, I guess I’ll keep working on it
was8bit 2022-05-24 01:28
Cell to cell IS the simplest approach :)
Benimo12 2022-05-24 15:16
I may are have stupid :(
was8bit 2022-05-25 05:28
Benimo12 2022-05-25 06:06
Never mind, I have to do everything again
was8bit 2022-05-25 15:48
Well, I made what could be considered a "game engine" in that all of the levels are randomly created...
Here, the initial background (cells 0,0 to 19,15) are all that is needed to create an interactive environment...
My idea here was that each screen is a mini game (no screen scrolling as scrolling increases the complexity of the code).... and the background is initially read by the code, and it looks for key characters... the code then converts these key characters into sprites (at the start, all sprites are first cleared so new sprites can be created)... for simplicity I pre assigned blocks of sprites #'s to specific kinds of things... so the code simply tracks which sprites are active or not...
Code already exists to processes each active Sprite type... the player Sprite is of course always exists but for all others will only exist as the background initially dictates...
The overall idea is this... that the background is largely ignored, and random contact with random things is mostly between player Sprite and any other active Sprite, not with the background images... this not only simplifies contact detecting but also make said contact detection pixel perfect ;)
It wasn't easy to pull off, but it does prove that this approach is possible.. :)
was8bit 2022-05-25 15:52
One "could" dynamically assign any kind of thing to any Sprite #, but that would add code complexity to track what kind of thing each Sprite is, and such...
Each "thing" may require different variables to function properly, having blocks of sprites assigned to one "thing" made it super easy to focus on each block and tailor the code for that specific thing...
was8bit 2022-05-25 16:00
I think the few non sprite events in my game was leaving the screen via moving off the screen, and staying on top of a floor (upper or lower)... this are not done via sprites...
In your game, if you were using this system, you would then need "wall" sprites if you wanted walls that things couldn't move thru...
The nice thing about sprites in NX is that they can be 1x1 or 2x2 or 3x3 or 4x4 in size... so you can use up to a whole 4x4 block of graphics for one Sprite ;)
Benimo12 2022-05-25 22:34
Oh, please can I see it? I would like to see which functions I can use.
Benimo12 2022-05-25 22:48
For your scrolling problem, there’s two solutions; my own and that of Timo’s.
In mine, I’ll be using a previous version of my abandoned Datamon program.
Basically, what you’ll do is to create an X and Y variable for the map to copy and another pair for the map to update to with bounds to avoid illegal memory access.
The X and Y variables are now inversely proportional to the player’s movement and the cell collision will update itself as the background is moved.
The reason I wouldn’t advise this method outside of a Top-down game is because of it’s choppy movement. This requires just a singular line of code actually with two pairs of variables so, not so advanced
Using Timo’s method, the sprite has pixel perfect collision which is a whole other thing I’m not getting into but, you could also use the cell’s perceived position on screen by updating your cell variables in 8ths. This requires entire sub programs to make this work properly.
was8bit 2022-05-26 05:30
I "can" get scrolling to work... but as i usually code when i am sleepy, the simpler approach is aways best for me ;) when i am sleepy i can often get stumped as to why my code isnt working right, when in reality it is usually something simple i coded wrong... but my tired brain overlooks it..
In my cloudy mountain game, the scrolling effect is simplified by keeping the player in then center of the screen, so that eliminates the players positioning effecting anything...
was8bit 2022-05-26 05:32
Were you wanting to see my LLAFTIP's Hidden Treasure (adventure game)... i have the link to it posted above.... (actually a variation of PITFALL)
Benimo12 2022-05-26 22:36
Yh, the center at screen for the main character is actually very easy to do but, I don’t really like the void/map drags/parallax effects that come with it but, I’m still figuring it out.
Benimo12 2022-05-26 22:37
I’ve seen LLAFTIP and I think I’ll extract some code from it where it comes to saves.