|
Post by johnno56 on Apr 4, 2019 4:42:40 GMT -6
I am experimenting with "non grid" platformer and figured I would start with basic (no pun intended) movement. (left, right and jump) This example is ultra simple but I am not sure as to log this as "help" or "bug". First I need to know if I have the logic right. (run the example "as is".) Then modify the example to run "full screen". This is where the problem exists... Running "windowed" the example runs without error. Left and Right (with a bit of friction...) and Up - Jump - (smooth jump and a little bounce when landing) Run full screen and the getPixel() command seems to be ignored and the player falls through the "ground" and eventually gets a "segmentation" error. movement.zip (2.4 KB)
|
|
|
Post by n00b on Apr 4, 2019 10:07:43 GMT -6
I will look at it when I get home. I would also like to recommend that if you want to do pixel based collision, don't use getPixel to do it. Remember RCBasic uses hardware accelerated rendering (SDL2) and sdlBasic uses software rendering (SDL). GetPixel is far slower in RC than it is in sdlBasic because all images and even canvases in RCBasic are textures which means they exist in video memory rather than ram. That means the texture must be pulled from video memory to ram each time you want to sample a pixel color. It is not all that efficient for purposes where you are constantly calling it. Its a trade off you make when using hardware acceleration. But there are still ways of solving the problem of pixel perfect collision. You could just create an array that represents the screen. Then treat that array like your screen when checking whether your pixels overlapped. Its still not that efficient but probably 20 times faster than getPixel.
|
|
|
Post by johnno56 on Apr 4, 2019 12:56:24 GMT -6
Understood. Getpixel too slow. Hmm.. Perhaps the jumping and friction can be salvaged... lol
Do you have an example of the SDL2 method? I would be curious to see the difference....
Many thanks for the assist. Much appreciated.
J
|
|
|
Post by n00b on Apr 5, 2019 6:51:00 GMT -6
Hey Johnno, sorry for the late reply but I got off work really late last night. I will post an example of what I am talking about later today. I looked at the code you posted. I am not really sure what would be causing that but if I can find the issue I will post an updated build with the fix as soon as possible. Thanks for reporting it.
|
|
|
Movement
Apr 5, 2019 15:20:16 GMT -6
via mobile
Post by tbird on Apr 5, 2019 15:20:16 GMT -6
I am simply doing box, circle, and polygon collision. When my level loads it looks at the entities involved then sets there collision masks, and the collision engine only looks for a collision if the entities are in the same "cell" or 512x512 partition.
So basically a function looks at your level and says oh you have 50 blocks with collision masks @ 0,0-32x32 + their world coordinates or in your case X,Y x 32. Then do AABB box collision against your player collision mask.
Thats my .02 lol
|
|
|
Post by johnno56 on Apr 5, 2019 16:15:22 GMT -6
TBird,
I had thought about AABB, and for the current example, that would be fine. But when it comes to multiple platforms and landing areas AABB might get a bit cumbersome. ie: A collision detection for each non-connected platform sections... But, with that being said, is still a viable option.
I will try AABB for "this" example, on both windowed and full screen, just to see if my problem is either screen or detection related...
n00b,
Whenever you get some free time will be fine... I'm still not sure as to why it happens... I'll run the 'above' test and get back to you...
J
|
|
|
Post by johnno56 on Apr 5, 2019 16:41:48 GMT -6
Ok. Added the AABB system to the example and the collision detection functioned flawlessly in both windowed and full screen modes. Attached is the current version. movement2.zip (2.53 KB) Attachments:movement2.zip (2.53 KB)
|
|
|
Movement
Apr 5, 2019 16:49:56 GMT -6
via mobile
Post by tbird on Apr 5, 2019 16:49:56 GMT -6
Well it would be cumbersome, agreed. Although my function is not that big and it handles...well infinte tiles or entities or whatever I made a quick platformer test level it has 187 entities and it works perfectly and its no more work than 2.
|
|
|
Post by johnno56 on Apr 5, 2019 20:22:56 GMT -6
No more work than 2, you say? You must show me how you did that? When you can find the time of course.... lol
J
|
|
|
Post by tbird on Apr 5, 2019 20:42:44 GMT -6
Well I should have put....no more work then 2 now lol. It's after how many hours into the framework creating helper functions, the CollisionEngine_Init() Function is called in the loading phase and then the CollisionEngine_Update() is used in the loop. So the Collision Engine doesn't care if there is 2 entities or 500 it's all the same to it, and no extra work on my part...now.
|
|
|
Post by tbird on Apr 6, 2019 9:48:35 GMT -6
Although johnno the way you do your level layout with a grid, creating a algortithm to create bounding box's for you would be trivial. As long as you are keeping everything 32x32 it would be very easy to do, if you wanted.
|
|
|
Post by johnno56 on Apr 6, 2019 14:40:06 GMT -6
I had been thinking of some 16x16 items and perhaps 64x64 bosses and then... nah... 32x32 is the preferred medium... lol
|
|
|
Post by tbird on Apr 6, 2019 15:28:21 GMT -6
Well that is fine also, I had another thought...what If it simply created bounding boxes on the image size so instead of setting it to a hard 32x32 you could simply have it run through each image and gathering what the dimensions are and bam all the AABB Info is stored. Also by "each" image I mean each parent image not each object in your game, so if you have 80 32x32 bricks they obviously share the same collision mask.
|
|
|
Post by n00b on Apr 6, 2019 17:01:31 GMT -6
Hey guys, I have a quick update. I found the issue with GetPixel and have already fixed that along with 2 other bugs. Be expecting a new release tomorrow. I am also adding some new functions and making some improvements to other functions. I am also working on a better demo to show how to use the networking functions.
|
|
|
Movement
Apr 6, 2019 17:40:30 GMT -6
via mobile
Post by tbird on Apr 6, 2019 17:40:30 GMT -6
Awesome! I am so close to doing some more network stuff, and more functions, nice, always welcome. Good stuff.
|
|