Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (780)
Games in Android Showcase (233)
games submitted by our members
Games in WIP (856)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  which is faster?  (Read 2106 times)
0 Members and 1 Guest are viewing this topic.
Offline PRW56

Senior Newbie

« Posted 2012-12-31 07:48:45 »

For collision detection, I can either find out whether or not 2 sprites are in the same rectangular areas (up to 4, since they can be on the edge) at the same time before doing collision detection, or simply check every sprite on the entire map every time. Can anyone tell me which they think would be optimum, or rather at what point (as in after how every many collision detections need to take place) does this start saving speed? Also which is faster == or >,<,<=, and >=?
Offline Phibedy

Senior Devvie

Medals: 9

« Reply #1 - Posted 2012-12-31 08:13:29 »

How many sprites do you have?
I don't think, that you will recognise any "speedboost", for example there's no difference in the "running-time of one loop" of my game if I just have to check 1 or 500 collisions.
It might be worth it, if you got huge polygons and therefore a lot of verticles to check.
What you could do is creating a circle around each sprite and check before if they collide (circle vs circle collision is faster then rect vs rect), but I in my opinion that's not worth it, too.
best regards
Offline Cero
« Reply #2 - Posted 2012-12-31 15:58:27 »

There are many threads on jgo about "not looping through the whole array everytime"
here is one:

One thing you can use is a quad tree.
Grids are kinda nicer I think and to quote Riven
Quadtrees are not efficient in today's CPUs. Use a grid instead.

It's both incredibly easy to develop, and much, much faster.
Click on the quote link to get to a whole thread about this kinda topic

But overall it really depends what you are doing.
For example if you are doing collision detection with static geometry, you can just set a very limited loop in that area.

Also which is faster == or >,<,<=, and >=?
I think that not even at assembly level, that there is a difference - talking about this in Java is krazy, with a K =D

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline matheus23

JGO Kernel

Medals: 138
Projects: 3

You think about my Avatar right now!

« Reply #3 - Posted 2012-12-31 17:00:55 »

What you could do is creating a circle around each sprite and check before if they collide (circle vs circle collision is faster then rect vs rect), but I in my opinion that's not worth it, too.
best regards

Oughh... I'd be careful with that. It gives you an incredible performance boost.
(I assume we're talking about SAT collision testing now)
In case you have lots of polygons, especially polygons with lots of vertices (in my case I had 'only' Cool, circle pre-checks can improve the performance a lot. They're pretty much eqivalent to one single, simplified SAT axis test + two multiplications Wink

Also, if you think of using pre-checks I'd really suggest circles instead of rectangles.
Rectangles have the problem, that you usually need to re-compute them if you for example rotate the polygon.
Circles are circular, therefore you don't need to re-compute the radius, as it is the same all the time Wink

But I agree to Cero: Using some kind of grid will improve the performance a lot as well (after that comes the circle-check).

If we're not talking about SAT, but AABB collision tests, then you shouldn't really need to do the circle check, but the space partitioning (Grids, etc, see Cero's post) should help you.

I don't know which is the fastest from == >, <, <=, >=.
My guess is, it's ==. (As far as I know it needs a subtraction and another instruction for testing whether something is 0, but that actually only applies for native code. Java is mostly interpreted, even if everything is JIT-ted. Idk whats the case then.).

See my:
    My development Blog:     | Or look at my RPG | Or simply my coding
http://matheusdev.tumblr.comRuins of Revenge  |      On Github
Offline PRW56

Senior Newbie

« Reply #4 - Posted 2012-12-31 21:08:47 »

I read over that thread a bit, I love the idea of checking within a set rectangular grid, but it becomes a lot more complicated when you try to deal with sprites along the edges of any rectangle in the grid, because a single sprite can be in up to 4 at once (if its in the midddle of them)...
Offline Roquen

JGO Kernel

Medals: 518

« Reply #5 - Posted 2012-12-31 21:33:11 »

Compares cost are equal.  Everything else pretty much depends.
Pages: [1]
  ignore  |  Print  

hadezbladez (712 views)
2018-11-16 13:46:03

hadezbladez (355 views)
2018-11-16 13:41:33

hadezbladez (699 views)
2018-11-16 13:35:35

hadezbladez (175 views)
2018-11-16 13:32:03

EgonOlsen (2368 views)
2018-06-10 19:43:48

EgonOlsen (2502 views)
2018-06-10 19:43:44

EgonOlsen (1465 views)
2018-06-10 19:43:20

DesertCoockie (2131 views)
2018-05-13 18:23:11

nelsongames (1927 views)
2018-04-24 18:15:36

nelsongames (2600 views)
2018-04-24 18:14:32
Deployment and Packaging
by mudlee
2018-08-22 18:09:50

Java Gaming Resources
by gouessej
2018-08-22 08:19:41

Deployment and Packaging
by gouessej
2018-08-22 08:04:08

Deployment and Packaging
by gouessej
2018-08-22 08:03:45

Deployment and Packaging
by philfrei
2018-08-20 02:33:38

Deployment and Packaging
by philfrei
2018-08-20 02:29:55

Deployment and Packaging
by philfrei
2018-08-19 23:56:20

Deployment and Packaging
by philfrei
2018-08-19 23:54:46 is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!