Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (481)
Games in Android Showcase (110)
games submitted by our members
Games in WIP (548)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 [2]
  ignore  |  Print  
  HDR Fireworks + Particle Engine benchmark  (Read 7252 times)
0 Members and 1 Guest are viewing this topic.
Offline kappa
« League of Dukes »

JGO Kernel


Medals: 76
Projects: 15


★★★★★


« Reply #30 - Posted 2011-11-08 21:34:15 »

doesn't work here on linux, seems like you're setting the path to the native folder inside your code using a backslash "\", you should always try use one of the following

- use a forward slash "/"
- or System.getProperty("file.separator")
- or File.separator

This will allow it to work on windows and linux (and mac too).

Cool that you have a windows batch file to launch the program, if you want you can add a linux and mac shell script for the other two platforms, just put the following in a text file with the extension .sh

Quote
#!/bin/sh
java -server -Xmx1200m -XX:+UseParNewGC -jar HDRFireworks.jar

alternatively I noticed that you created a fat jar (all your jars into one), so why not just put the natives in the jar file too, so you just have a single clickable/launchable jar, you could use a tool like JarSplice (which also allows you to put vm parameters into the jar).
Offline theagentd
« Reply #31 - Posted 2011-11-09 08:50:54 »

I would never program something that requires OpenGL 3, only if its really just experimental, just saying - but we talked about this before

If I would want to use new fancy pancy OpenGL, I would at least check what version is available and write code that works on machines until GL1.1

and I what theagentd would say, but the bottom line is - if you don't already have an audience /major publisher, then, filtering your audience like this will not help
I would never use OpenGL 1.1 and its built-in crap unless I had to. There are so many glEnable switches that you can forget to enable or disable. Just forgetting to enable GL_TEXTURE_2D has made me search for bugs for hours until I found the problem. How everything is so convulated makes it so goddamn hard to know the state of the client at a certain point in your code. Just that should be enough to convince you to only ever use OpenGL 3+, as it has a lot less things that can go wrong.
Why would I prioritize OpenGL 1.1? Do you even know how old it is? Do you even know how old OpenGL 3 cards are? We're talking the NVidia 8000 series. Even the GTX 7000 series had support for the functions I use. According to the Steam Hardware Survey over 90% of the cards used have support for DirectX 9. Over 60% have support for DirectX 10 / OpenGL 3. With the functions I use right now I have support for 90% of the computers used by people on Steam. I could easily limit myself to OpenGL 2 + extensions or even OpenGL 3.0 and not lose too many potential players. Besides, I like graphics programming so using newer features is interesting. It's not like I released a full game. It's a demo showing fireworks for god's sake. You can stick with your OpenGL 1.1 support if you want, but I will have a hard time not calling you grandpa. xD

doesn't work here on linux, seems like you're setting the path to the native folder inside your code using a backslash "\", you should always try use one of the following

- use a forward slash "/"
- or System.getProperty("file.separator")
- or File.separator

This will allow it to work on windows and linux (and mac too).

Cool that you have a windows batch file to launch the program, if you want you can add a linux and mac shell script for the other two platforms, just put the following in a text file with the extension .sh

Quote
#!/bin/sh
java -server -Xmx1200m -XX:+UseParNewGC -jar HDRFireworks.jar

alternatively I noticed that you created a fat jar (all your jars into one), so why not just put the natives in the jar file too, so you just have a single clickable/launchable jar, you could use a tool like JarSplice (which also allows you to put vm parameters into the jar).
Ah, you're right. I've been randomly using both forward and back slash until now because I didn't think it mattered. Forward slash it is from now on then! And you're right again. My releases are basically manual merges of all the jars. JarSplice looks like a very convenient tool. I will definitely have a look at it. From looking at the front page, it seems to support native files like you said, but how do I get it working with LWJGL? Does it automatically extract them somewhere? What do I have to do to get it working?

Myomyomyo.
Offline princec

JGO Kernel


Medals: 362
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #32 - Posted 2011-11-09 09:24:09 »

You might want to rethink your position though when I give you the following statistics.

Since January 1st 2011 I've had 27,396 users install my games. My users are a very good statistical spread of casual gamers and hardcore gamers from all over the web, though chiefly the US and UK, with France and Germany making up much of the remainder.

Of those, 17% of them had only OpenGL 1.5 or below, and 54% had OpenGL 2.1 or below. These numbers are so significant you can't really afford to ignore them if you really want people to see your stuff.

By and large I stop supporting something when its penetration level is under 10%. So still quite a long time to go before I can even ditch OpenGL 1.4.

One last note about Steam: unless you're actually making something specifically for Steam, I wouldn't go thinking they are representative of your target audience. They are a pretty eclectic bunch of hardcore PC enthusiasts who spend way above average on their gaming systems and games in general. They are generally about 3-4 years ahead of the great unwashed which make up the rest of the internet. Not only that but Steam is unfortunately quite an exclusive club, so if you're trying to make something that's for Steam but fail to get in - as 99% of submissions do - you'll be left targeting a bunch of people who probably can't run your stuff. This is of course generic advice rather than specifically aimed at anyone here.

Hence: all my stuff is still OpenGL 1.3 compatible. Might even be 1.2. Actually it definitely is, 'coz I've got 1.1 logs in my database.

Cas Smiley

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline kappa
« League of Dukes »

JGO Kernel


Medals: 76
Projects: 15


★★★★★


« Reply #33 - Posted 2011-11-09 10:20:02 »

Does it automatically extract them somewhere?
Yup, basically it will extract your native to a temp folder, then start your app, after your app closes it will clean up (delete) the temp and the extracted natives.

how do I get it working with LWJGL? Does it automatically extract them somewhere? What do I have to do to get it working?... What do I have to do to get it working?
Pretty easy to use with LWJGL, just do the following:

1) Add all your project jars to the jar tabs - this includes a jar containing your project (including any resources like images, sounds etc), lwjgl.jar, asm.jar, lwjgl_util.jar and any other external jar you may be using.

2) Add all the natives to the natives tab - thats all the LWJGL *.dll (windows), *.so (linux) and *.dylib,*.jnilib (mac) natives files to the natives tab.

3) On the main class tab enter your main class: fireworks.tests.FireworkTest (you can also add any vm arguments on this tab).

Thats it, click create jar.
Offline kappa
« League of Dukes »

JGO Kernel


Medals: 76
Projects: 15


★★★★★


« Reply #34 - Posted 2011-11-09 10:24:22 »

Of those, 17% of them had only OpenGL 1.5 or below, and 54% had OpenGL 2.1 or below. These numbers are so significant you can't really afford to ignore them if you really want people to see your stuff.

Oh, 17% still below OpenGL 2.0, was hoping that OpenGL 2.0 would be a good target to aim for these days. Since with 2.0 you can pretty much go full shaders, vbo's and can avoid almost all of the functionality depreciated in OpenGL 3.2+. Also OpenGL ES 2.0 is similar and pretty much the standard now on mobile devices. So you can write code that ports much easier to ES.

Do you reckon that in about a year, computers with an OpenGL version less than 2.0 will be below 10% ?
Offline princec

JGO Kernel


Medals: 362
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #35 - Posted 2011-11-09 10:28:46 »

Well, eventually. But it seems to be taking a long time.

Cas Smiley

Online EgonOlsen
« Reply #36 - Posted 2011-11-09 11:16:05 »

@EgonOlsen
I think I've actually seen this problem before! A loooong time ago when I was doing 2D lighting for a RPG Maker style game I had an FBO which I drew the lighting and shadows to. Now, on our really old Radeon card in my family's computer, this turned out black and white. I never really checked into it (it was a really old computer), but it could very well have been the same problem.
I have no idea what's causing it though. The only thing I do for mouse clicks is change a boolean which controls if the bloom is rendered and added to the screen after the particle rendering or not. I'm not even unloading and reloading anything. I'm sadly gonna have to blame it on the Radeon drivers...
But my system is a current system with a modern OS and the graphics card isn't that old either and with current drivers. It might be a driver problem, but i wouldn't be so sure about it. I can try it on another Radeon HD on another machine and see if it works there...i'll keep you posted.

Offline Cero
« Reply #37 - Posted 2011-11-09 12:33:06 »

Besides, I like graphics programming so using newer features is interesting. It's not like I released a full game. It's a demo showing fireworks for god's sake.
yeah I said only if its really just experimental...


You can stick with your OpenGL 1.1 support if you want, but I will have a hard time not calling you grandpa. xD
It's just the mentality or ideology, that "every game has to work with every machine".
Since this is not console programming "every" is a stretch, but consciously leaving machines out - and even 71% according to Cas here - is something that would be... unethical ! =D


and again the bottom line: you can write code that works on 1.1 and when 2+ or even 3+ is available it utilizes those features.

Offline gouessej
« Reply #38 - Posted 2011-11-09 12:46:46 »

You can stick with your OpenGL 1.1 support if you want, but I will have a hard time not calling you grandpa. xD
Actually, some developers think their programs work on OpenGL 1.1 whereas I succeeded in crashing some of them with my previous graphics card supporting OpenGL 1.3, it was the case with several major 3D engines. There is sometimes a noticeable difference between words and facts.

Offline theagentd
« Reply #39 - Posted 2011-11-09 13:00:28 »

Okay, okay, I get it. But I still think supporting OpenGL 1.1 is overkill. I'm planning on making an awesome 3D demo with the latest graphical effects as a test of my skills, why would I support OpenGL 1.1? I wouldn't be able to do any fun shader effects there, and in the end the game would be so slow that it wouldn't run very well anyway. I can understand why you would want to support OpenGL 2, but 1.1? You guys are forgetting that the performance on those cards don't really make them viable for anything demanding more performance than casual 2D games (no insult to anyone's games!!!). I've seen Intel cards in action with CS 1.6, and the game lagged so hard with 2-3x screen overdraw, while my laptop can handle 10 times that amount. I mean, I wouldn't be able to do anything at all as a graphics programmer for such a card.

Myomyomyo.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Cero
« Reply #40 - Posted 2011-11-09 13:12:15 »

You guys are forgetting that the performance on those cards don't really make them viable for anything demanding more performance than casual 2D games (no insult to anyone's games!!!).

yeah no, my game is really fast paced and not a casual/mini game at all; and it might be true, a video card that only supports 1.1 may even be too slow too even run the game at all..
Well not sure, hard to find suitable hardware. The low performance machine I like to test our game on is a Acer Aspire, low RAM, slow CPU, crappy video card which doesnt vsync and supports, I don't know 1.7 or so

on the other hands I don't think I need anything higher; well I will see if going to 1.4 or 1.5 makes a difference when we introduce lightsources
but oh well light sources in 2D are quite simple anyway...

Offline ReBirth
« Reply #41 - Posted 2011-11-09 13:25:38 »

@cero @theagentd
thanks both of you.

because I love my lappy, I tried 1 - 15 - yes and got 32000+ particles on..... 27 fps :3

Offline theagentd
« Reply #42 - Posted 2011-11-09 13:52:37 »

After finally getting some time off from studying for tests (went pretty well xD) I managed to finish my GPU accelerated particle test. It's the same test as the one I got Ra4king to test. That test was basically optimized as far as possible for CPUs. Multithreading, mapped objects, object pooling and other optimizations I've added have made it pretty much as fast as possible. It doesn't scale very well on multiple cards though, due to the single-threaded copying of the particle data to the OpenGL mapped buffers. It's not very expensive, but the more CPU's you throw at the buffer updating, the lower scaling you get. See Amdahl's law.

Ra4king's testing showed a 200-250% scaling and 2.7-2.8 million particles at 60 FPS on a hyperthreaded quad core CPU
My own hyperthreaded dual core gave me about 160% scaling and ~1 million particles at 60 FPS.


---BORING TECHNICAL EXPLANATION STARTS HERE---

Simply put: I need to avoid the copying the data to the GPU each frame. The solution is to keep everything on the GPU and update it there. My implementation keeps 3 textures for this: A RGBA 32-bit float texture for xy position and xy velocity, a RGB 8-bit color texture for particle color, and a RG 16-bit life texture which stores the particle's life time and current remaining life. Particle alpha = current life / life. The 2D textures are made big enough to fit the target number of particles. The theoretical maximum number of particles for a single set of textures is 8196 * 8196 16384x16384, more than 64 268 million particles, but performance obviously becomes the limit long before that.

I add particles by adding all the new particles for a frame into a ByteBuffer and drawing each particle as a point to all the textures using MRT. I simply add particles in a row for row, column for column, continuing where I left off the last frame. I simply assume that when I have written all particles to the whole texture and have to start at the beginning again, that particle has already died. I basically overwrite the oldest, hopefully dead particle each time. This avoids the need to have to find an empty place in the buffer each draw.

The next step is updating the particles. They are updated through a simple shader which is applied to all the pixels (= particles) in the textures.  I obviously only do this to particles which life is over 0. It updates the velocity with gravity, approximated air resistance and screen edge collision bouncing, and then position based on velocity. I also reduce the current life by 1. I actually have two position/velocity and life textures, so that I can ping-pong the updating between them each frame.

Finally I draw them. I do this using a single glDrawArraysInstanced() call. I have a buffer with integers running from 0 to the particle texture height. I then draw (particle texture width) instances of this data. The final texture coordinate in the shader becomes this:
1  
texPos = ivec2(gl_InstanceID, y); //y is the value from the buffer

In other words: I draw a point for each particle. This texture coordinate is passed to the geometry shader, which first samples the life texture and checks if it is alive. If it isn't, it returns and no more textures are sampled and nothing is drawn. If it is, it samples the position/velocity texture for the position, the color texture for the color and calculates the alpha the life time. The fragment shader just writes the particle color.

This is obviously pretty slow even if I don't have any alive particles, so it's important to keep the texture size as low as possible. Simply updating and rendering the empty 1000x1000 particle textures takes about 5 ms.

---BORING TECHNICAL EXPLANATION ENDS HERE---


My performance? 3 million particles at 60 56 FPS. Yup. A three followed by six zeroes. The catch? I had to disable GL_POINT_SMOOTH. For my CPU based test, all antialiasing was free due to the fact that it was so very CPU limited that any GPU eye candy was free. I don't think that's really the problem here though. I seem to be fragment limited. Yeah, what the hell? Enabling GL_POINT_SMOOTH makes the points cover 4 pixels instead of just 1 pixel, plus the extra coverage computations. With antialiasing, I get about 2.4 2.1 million particles at 60 FPS. I think I've basically reached the limit of what my graphics card can possibly ever accomplish. I could optimize my draw calls and my texture layout, but I seriously doubt I can crank any more performance out of this. I might be able to improve the constant FPS cost of simply updating and drawing all the dead/uncreated particles a lot by developing a better draw algorithm, but the performance wouldn't be better when you actually have that many particles.

Now, if I only had a certain someone to test this on his 3 times as powerful GTX 570, we'd be able to see some real performance.

EDIT: I had some incorrect data, not all particles were alive. Not a big deal though. =P

Myomyomyo.
Offline ra4king

JGO Kernel


Medals: 345
Projects: 2
Exp: 5 years


I'm the King!


« Reply #43 - Posted 2011-11-09 16:59:30 »

Ooooh me me! Pick me!! Tongue

Offline theagentd
« Reply #44 - Posted 2011-11-12 05:50:45 »

I guess this will be my final post in this thread unless anyone has any questions.

Ra4king tried the little bastard of a program out and got 5 million smoothed particles dancing over his screen. I could very easily port the GPU accelerated particle engine to this firework test, but it would be rather useless as the particle engine would compete with the bloom filter over the GPU.

To just shortly dive into the OpenGL 1.1 vs OpenGL 3 discussion again: This would be completely impossible to do without OpenGL 3.0. Framebuffer objects, float textures (for particle positions and velocities) and geometry shaders are all needed, but one of the most important things needed is instancing. Using instancing every single particle of those five million particles is drawn using a single draw call. This reduces the CPU cost of drawing everything to basically nothing. For creating new particles, updating and drawing, I'm doing far under 100 draw calls.

Well, if I ever want to learn OpenCL, I guess I know what to do...  Wink

Myomyomyo.
Online EgonOlsen
« Reply #45 - Posted 2011-11-15 13:33:36 »

Doesn't look right on a Radeon HD 5770 on Windows 7 64bit using the 11.9 drivers either after pressing the mouse button. It's not 100% b/w but only the rockets look normal. The explosions are pretty much b/w pixels like in my screen shot except that they get some subtle coloring when fading out. But at least it's possible to return to the normal rendering when pressing the mouse button again.

Offline theagentd
« Reply #46 - Posted 2011-11-15 18:38:53 »

Doesn't look right on a Radeon HD 5770 on Windows 7 64bit using the 11.9 drivers either after pressing the mouse button. It's not 100% b/w but only the rockets look normal. The explosions are pretty much b/w pixels like in my screen shot except that they get some subtle coloring when fading out. But at least it's possible to return to the normal rendering when pressing the mouse button again.
There's not much I can do, actually. I'm stuck on a laptop with an Nvidia card. In Japan. It works on most cards, but not on some Radeon cards. It has to be a driver bug, and since I'm unable to test it myself, the only thing I can actually do is send you the source code for you to experiment with it for yourself. I mean, I'm interested in the results and so, but I don't really want to bug test a driver on someone else's computer over a forum. It's a little bit too slow... >_>

Myomyomyo.
Pages: 1 [2]
  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.

atombrot (26 views)
2014-08-19 09:29:53

Tekkerue (24 views)
2014-08-16 06:45:27

Tekkerue (23 views)
2014-08-16 06:22:17

Tekkerue (14 views)
2014-08-16 06:20:21

Tekkerue (22 views)
2014-08-16 06:12:11

Rayexar (60 views)
2014-08-11 02:49:23

BurntPizza (39 views)
2014-08-09 21:09:32

BurntPizza (30 views)
2014-08-08 02:01:56

Norakomi (37 views)
2014-08-06 19:49:38

BurntPizza (67 views)
2014-08-03 02:57:17
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!