Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (498)
Games in Android Showcase (117)
games submitted by our members
Games in WIP (564)
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  
  2d particle system efficiency  (Read 1363 times)
0 Members and 1 Guest are viewing this topic.
Offline nerb
« Posted 2013-07-07 11:51:40 »

Howdy,

Just for a bit of fun, I'm thinking about making a very simple 2d particle system. It will essentially spit out different coloured pixels. However I have a few questions about the design for those of you who are more well-versed in computer science than me.

A lot, if not all of the examples I have found on the net treat each particle as an instance of a Particle class, which holds its own variables and has an update method. That's all well and good, and makes sense, but wouldn't having a method call for each particle in each run of the update loop introduce extra performance overhead?

I'm more inclined to hold all particle information within arrays, perhaps in a ParticleEmitter class. Then instead of calling update() on separate instances of Particle, it would just be a case of doing some basic operations on a few arrays.

So my question is, are my assumptions about the overhead of a method call correct, and would the difference in performance between the two designs be considerable or negligible??? (Keeping in mind there may be quite a few particles involved).

Cheers,
nerb.
Offline relminator
« Reply #1 - Posted 2013-07-07 14:36:54 »

Even on android, the overhead of calling methods is negligible.

My bullet-hell game could pump 2k bullets easily on an 80mhz single core at 60fps.

Your main concern for embedded systems is usually how you design your container and limiting GC.

Offline joen

Senior Newbie


Projects: 1



« Reply #2 - Posted 2013-07-07 14:55:38 »

You'll probably get a better return on your development time by limiting GL calls than optimizing the java side.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline nerb
« Reply #3 - Posted 2013-07-08 06:11:53 »

Even on android, the overhead of calling methods is negligible.

My bullet-hell game could pump 2k bullets easily on an 80mhz single core at 60fps.

Your main concern for embedded systems is usually how you design your container and limiting GC.



Great bit of advice, thanks relminator. Might go with the Particle class based system just for simplicity.

Cheers,
nerb.
Offline relminator
« Reply #4 - Posted 2013-07-08 06:54:57 »

Oops  I meant 800mhz. 
Offline sproingie

JGO Kernel


Medals: 202



« Reply #5 - Posted 2013-07-08 17:11:54 »

There goes running your shmup on my 486 Wink
Offline relminator
« Reply #6 - Posted 2013-07-09 00:38:27 »

Funny you should mention a 486 because I developed this shmup on a 486 dx 66mh compaq. Smiley

You'll need dos with ems to run this though:

www.rel.phatcode.net/index.php?action=contents&item=Frantic+Journey
Offline Redocdam

Senior Member


Medals: 17



« Reply #7 - Posted 2013-07-09 17:26:21 »

After playing around with different ways implementing particles, I'm compelled to offer up the idea of a GPU system.
When I first read about this, I began trying to guess how many animal sacrifices I would need to get this magic to work.
Turns out it wasn't that bad at all. In many ways I found it easier.

The whole idea centers around ping-ponging between two Transform Feedback Buffers (I'll call them TBO for short). TBOs are buffers you can draw into and from.
When you draw from one TBO to the other, you use a Shader to update particle information like position, velocity, age and so on. You also tell OpenGL to skip the rasterize step when you do this. Then all you really need to do is stuff this bad boy into a particle emitter class and tell it to draw when you want.

This ends up being extremely fast. When I compared it with my other particle systems, it was like a race between an Olympic Sprinter Vs. A Walmart Scooter Jockey (sans scooter).

You can use Geometry Shaders for updating, spawning and destroying particles, as well as using them for creating the billboards.
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Grunnt (20 views)
2014-09-23 14:38:19

radar3301 (14 views)
2014-09-21 23:33:17

BurntPizza (31 views)
2014-09-21 02:42:18

BurntPizza (22 views)
2014-09-21 01:30:30

moogie (20 views)
2014-09-21 00:26:15

UprightPath (29 views)
2014-09-20 20:14:06

BurntPizza (33 views)
2014-09-19 03:14:18

Dwinin (48 views)
2014-09-12 09:08:26

Norakomi (75 views)
2014-09-10 13:57:51

TehJavaDev (108 views)
2014-09-10 06:39:09
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
java-gaming.org 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‑gaming.org
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!