Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (495)
Games in Android Showcase (114)
games submitted by our members
Games in WIP (563)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 ... 24 25 [26] 27 28 ... 39
  ignore  |  Print  
  TUER: Truly Unusual Experience of Revolution, FPS using JOGL  (Read 207453 times)
0 Members and 1 Guest are viewing this topic.
Offline gouessej
« Reply #750 - Posted 2010-04-02 14:13:47 »

I would be absolutely stunned to learn that transforming and lighting 1000ish vertices is a bottleneck here.
Are you sure this will help?
What do you mean exactly? The very experimental version sends the whole level to the graphics card without using any spatial subdivision (I don't have enough time to port all my source code from JME 2 to Ardor3D). It means that hundreds of thousands triangles are currently sent to the graphics card whereas the optimization that he suggested will allow me to send only about 10 000 triangles to the graphics card. Obviously this optimization is efficient mostly on very orthogonal levels. Are you still skeptical?

Online Roquen
« Reply #751 - Posted 2010-04-02 16:55:27 »

Humm, limited to the geo. to a reasonable potentially visible set first would be the best move.  The gains of merging is very minor in comparison.
Offline ryanm

Senior Member


Projects: 1
Exp: 15 years


Used to be bleb


« Reply #752 - Posted 2010-04-02 17:16:11 »

Oh I see now, didn't realise the whole level was being rendered.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline gouessej
« Reply #753 - Posted 2010-04-02 17:43:39 »

Humm, limited to the geo. to a reasonable potentially visible set first would be the best move.  The gains of merging is very minor in comparison.
Actually, I will try to do the both but I won't limit the geometry to potentially visible set first because I think maybe a part of the algorithm used to build big squares could be used later and modified to compute cells. Why do you think the gains of merging is very minor? Sending 500 000 triangles to the graphics card is obviously slower than sending only 10 000 triangles, isn't it?

Oh I see now, didn't realise the whole level was being rendered.
I understand it is confusing as the alpha version and the version relying on JME do not render the whole level.

Online Roquen
« Reply #754 - Posted 2010-04-02 20:13:16 »

I mean that the merging will reduce your rendering cost, but no where near as much as trimming to a reasonable PVS.
Offline gouessej
« Reply #755 - Posted 2010-04-02 21:17:06 »

I mean that the merging will reduce your rendering cost, but no where near as much as trimming to a reasonable PVS.
When I used a reasonable PVS, it was between 2 and 4 times faster. After some more calculations, I think that only 4000 triangles will be necessary after the merging, it is about 100 times less. I don't think it will reduce the rendering cost by a factor of 100 but, as the VBO will be 100 times smaller (maybe less because I use indices), it will be noticeably faster with my graphics card above all because its implementation of VBO consists in using vertex arrays, it means the data are sent for each frame.

Offline a2370010

Innocent Bystander





« Reply #756 - Posted 2010-04-03 10:40:35 »

With resonable culling you could add many more rooms to your level with zero performance hit
With your merging algorithm, if you add more rooms, you get a non zero performance hit!

To be honest I don't think you should stick with levels made out of primitive quads anyway.
Offline gouessej
« Reply #757 - Posted 2010-04-03 11:19:25 »

With resonable culling you could add many more rooms to your level with zero performance hit
Yes, you're right, I already know that.

With your merging algorithm, if you add more rooms, you get a non zero performance hit!
Yes but if I add no room, my merging algorithm will improve the performances in comparison with what is done currently.

To be honest I don't think you should stick with levels made out of primitive quads anyway.
Yes, you're right. See this as a step. It is easier to implement frustum culling and cells-and-portals algorithm on primitive quads than on complicated levels. At first, I have to handle "simple" levels efficiently and then I can plan to support more complicated structures. Proceeding like this is easier than trying directly to support complicated levels.

I plan to put this into TUER in a far future:

It is better than the current level, isn't it?

Edit.: bobjob and someone else confirmed that TUER works reliably with Windows 7. I remind you that the frame rate is capped as I use the vertical synchronization in order to remove the screen tearing as cylab advised me some months ago.

Offline gouessej
« Reply #758 - Posted 2010-04-26 09:18:53 »

Hi!

While implementing the merge of adjacent and identical faces, I realized that I need to be able to use one texture per face. I succeeded in making a first partial implementation of this merge but now I have to implement a mechanism to create a separate node (of a scene graph) per kind of face, it is not very complicated, it will require a few hours. I will let you know when the performances are better Wink

The code used by JFPSM to generate the levels is very memory-hungry, I will have to do something to reduce the minimal memory requirements because at least one student failed to use it on a laptop with only 1 GB of RAM. Using only indirect NIO buffers when direct buffers are not required might help a bit.

Online Riven
« League of Dukes »

JGO Overlord


Medals: 798
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #759 - Posted 2010-04-26 19:48:12 »

Using only indirect NIO buffers when direct buffers are not required might help a bit.

Direct buffers don't need to consume more memory than heap buffers.

If you allocate lots of tiny direct buffers the overhead is massive (4K per allocated buffer) but if you allocate one large direct buffer, and slice() it, the overhead becomes negligible.


Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline bienator

Senior Member




OutOfCoffeeException


« Reply #760 - Posted 2010-04-26 23:25:22 »

the main problem with direct allocated buffers is that they can't be allocated everywhere. In fact they are allocated somewhere in the permgen (-> not in the regular heap) which limits the max usable amount of memory.

(remember direct memory does not change the position which has advantages and disadvantages. e.g fragmentation, but on the other hand this makes them to the best vehicle to transfer mem between jvm and native libs)

@see -XX:MaxDirectMemorySize=foobar

if you are running out of direct memory (on latest JREs) you will see the info usually in the exception message.

as riven said, use big buffers and slice them and prevent allocating direct buffers again and again.

[edit] latest version of visualvm + jre6 can track direct memory usage, nice tool for debugging.

Offline gouessej
« Reply #761 - Posted 2010-04-27 13:10:59 »

the main problem with direct allocated buffers is that they can't be allocated everywhere. In fact they are allocated somewhere in the permgen (-> not in the regular heap) which limits the max usable amount of memory.
I see what you mean, I increased the perm gen size with:
Quote
-XX:PermSize=1024m

(remember direct memory does not change the position which has advantages and disadvantages. e.g fragmentation, but on the other hand this makes them to the best vehicle to transfer mem between jvm and native libs)
That is why I'm going to try to use direct NIO buffers only when they are going to be used by JOGL.

@see -XX:MaxDirectMemorySize=foobar
What is the difference with -XX:PermSize?

if you are running out of direct memory (on latest JREs) you will see the info usually in the exception message.

as riven said, use big buffers and slice them and prevent allocating direct buffers again and again.

[edit] latest version of visualvm + jre6 can track direct memory usage, nice tool for debugging.
When I need to allocate some temporary NIO buffers, I will rather use indirect ones, thanks. I will use jvisualvm if I fail in tracking direct memory usage, I already used it in order to find the high memory consumption in TextRenderer Wink

Direct buffers don't need to consume more memory than heap buffers.

If you allocate lots of tiny direct buffers the overhead is massive (4K per allocated buffer) but if you allocate one large direct buffer, and slice() it, the overhead becomes negligible.
What do you mean by "overhead"? Why 4K? Can you explain it to me a bit more please? It is unclear to me.

I have never used the slice() method. As far as I know, I don't need to use several buffers sharing the same content but maybe it will be useful to share only a part of a buffer with another one.

Online Riven
« League of Dukes »

JGO Overlord


Medals: 798
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #762 - Posted 2010-04-27 13:19:43 »

What do you mean by "overhead"? Why 4K? Can you explain it to me a bit more please? It is unclear to me.


All because MappedBuffers must be page-aligned (pages are 4K on most systems) all direct buffers are page-aligned Roll Eyes

allocating a direct buffer basically looks like:

1  
2  
3  
4  
5  
int bytes = ...;
final int pageSize = 4096;
long pointer = sun.misc.Unsafe.malloc(bytes + pageSize);
long base = (pointer + (pageSize-1)) / pageSize * pageSize;
Buffer buffer = createBufferAt(base);

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Offline gouessej
« Reply #763 - Posted 2010-04-27 13:24:46 »


All because MappedBuffers must be page-aligned (pages are 4K on most systems) all direct buffers are page-aligned Roll Eyes

allocating a direct buffer basically looks like:

1  
2  
3  
4  
5  
int bytes = ...;
final int pageSize = 4096;
long pointer = sun.misc.Unsafe.malloc(bytes + pageSize);
long base = (pointer + (pageSize-1)) / pageSize * pageSize;
Buffer buffer = createBufferAt(base);

Shocked Now I see what you mean, I have to avoid using direct buffers to store tiny data, it was a huge waste of memory.

Offline gouessej
« Reply #764 - Posted 2010-04-28 22:27:38 »

Hi!

Now JFPSM needs 8 times less memory to do the same job, I thank Bienator and Riven for their advices. In the past, I was creating about 3 millions of small direct float buffers.

Online Riven
« League of Dukes »

JGO Overlord


Medals: 798
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #765 - Posted 2010-04-29 08:59:56 »

Hi!

Now JFPSM needs 8 times less memory to do the same job, I thank Bienator and Riven for their advices. In the past, I was creating about 3 millions of small direct float buffers.

Nice. I put it on my blog, with easy to use sample code:
http://riven8192.blogspot.com/2010/04/slicing-direct-buffers-to-workaround-4k.html

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Offline gouessej
« Reply #766 - Posted 2010-04-29 10:40:14 »

Nice. I put it on my blog, with easy to use sample code:
http://riven8192.blogspot.com/2010/04/slicing-direct-buffers-to-workaround-4k.html
It is an excellent and comprehensible explanation, thank you Smiley

I don't understand why direct buffers have been implemented so that they are page-aligned.

Online Riven
« League of Dukes »

JGO Overlord


Medals: 798
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #767 - Posted 2010-04-29 10:56:44 »

It is an excellent and comprehensible explanation, thank you Smiley

I don't understand why direct buffers have been implemented so that they are page-aligned.

Some lazy bastard at Sun didn't want to write two codepaths...

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Offline princec

JGO Kernel


Medals: 378
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #768 - Posted 2010-04-29 13:02:02 »

It's a perfectly reasonable optimisation when you consider how bytebuffers are meant to be used. They're specifically meant to be allocated rarely, as very big buffers, and sliced up into little bits as needed, and used solely for bulk I/O operations (be that network, audiovisual, or file). If you're doing anything else with them - that is anything other than streaming data in or out of them - you're not using them for what they're intended.

Cas Smiley

Online Riven
« League of Dukes »

JGO Overlord


Medals: 798
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #769 - Posted 2010-04-29 13:33:29 »

It's a perfectly reasonable optimisation when you consider how bytebuffers are meant to be used. They're specifically meant to be allocated rarely, as very big buffers, and sliced up into little bits as needed, and used solely for bulk I/O operations (be that network, audiovisual, or file). If you're doing anything else with them - that is anything other than streaming data in or out of them - you're not using them for what they're intended.

Cas Smiley

Ofcourse, but few people know that.

In Java you can do new float[1] with hardly any overhead (maybe 32 bytes), yet an allocated DirectFloatBuffer of 1 element (4 bytes) has an overhead of 4096 bytes, and a HeapFloatBuffer of 1 element is not having that kind of overhead too.

It simply comes as a surprise to most people, if noticed at all.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Offline princec

JGO Kernel


Medals: 378
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #770 - Posted 2010-04-29 16:42:55 »

Ah, I thought everyone knew that... but that's probably because I've had my head buried in this stuff since before it was even officially released in 1.4  Cool

Cas Smiley

Offline DzzD
« Reply #771 - Posted 2010-04-29 16:54:12 »

Nice. I put it on my blog, with easy to use sample code:
http://riven8192.blogspot.com/2010/04/slicing-direct-buffers-to-workaround-4k.html

1  
2  
3  
4  
currentBuffer.limit(currentBuffer.position() + size);
ByteBuffer result = currentBuffer.slice();
currentBuffer.position(currentBuffer.limit());
currentBuffer.limit(currentBuffer.capacity());


I am far to be an expert of ByteBuffer but according to the javadoc about slice "capacity and its limit will be the number of bytes remaining in this buffer"
maybe the code should rather look like the following, no, yes ?

1  
2  
3  
ByteBuffer result = currentBuffer.slice();
result.limit(size);
currentBuffer.position(currentBuffer.position() + size);

Online Riven
« League of Dukes »

JGO Overlord


Medals: 798
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #772 - Posted 2010-04-29 17:00:03 »

maybe the code should rather look like the following, no, yes ?
No Smiley

that remark is about the newly created buffer, not the original buffer.

ByteBuffer a = ...;
ByteBuffer b = a.slice();

b = the range between a.position() and a.limit()

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Offline DzzD
« Reply #773 - Posted 2010-04-29 17:04:39 »

that remark is about the newly created buffer, not the original buffer.
ha ok sry, I did not understand the docs....

Offline gouessej
« Reply #774 - Posted 2010-04-30 12:07:30 »

It's a perfectly reasonable optimisation when you consider how bytebuffers are meant to be used. They're specifically meant to be allocated rarely, as very big buffers, and sliced up into little bits as needed, and used solely for bulk I/O operations
Why does the alignment with pages improve the performances then?

Online Riven
« League of Dukes »

JGO Overlord


Medals: 798
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #775 - Posted 2010-04-30 13:10:13 »

Why does the alignment with pages improve the performances then?

For your average direct bytebuffer: a negligible reduced amount of cache misses.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Offline princec

JGO Kernel


Medals: 378
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #776 - Posted 2010-04-30 13:45:26 »

Well, not just that, but it helps the OS malloc the stuff more easily without wasting in the first place. But nonetheless the intended use of DirectByteBuffer is such that you shouldn't construct many of them anyway.

Cas Smiley

Online Riven
« League of Dukes »

JGO Overlord


Medals: 798
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #777 - Posted 2010-04-30 13:49:15 »

Well, not just that, but it helps the OS malloc the stuff more easily without wasting in the first place. But nonetheless the intended use of DirectByteBuffer is such that you shouldn't construct many of them anyway.

Cas Smiley

As you can see, the malloc by the OS is unaligned. The *Java* code aligns it.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Offline gouessej
« Reply #778 - Posted 2010-05-19 08:31:45 »

Hi!

My project stagnated for some weeks because I was busy with the interviews, I was in a reality TV show... I hope to find some time to work on it in June.

Offline Eli Delventhal

JGO Kernel


Medals: 42
Projects: 11
Exp: 10 years


Game Engineer


« Reply #779 - Posted 2010-05-19 14:10:16 »

Hi!

My project stagnated for some weeks because I was busy with the interviews, I was in a reality TV show... I hope to find some time to work on it in June.
Haha woah cool, when can I see it? What show was it? Why were you selected?

See my work:
OTC Software
Pages: 1 ... 24 25 [26] 27 28 ... 39
  ignore  |  Print  
 
 

 

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

The first screenshot will be displayed as a thumbnail.

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

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

TehJavaDev (73 views)
2014-09-10 06:39:09

Tekkerue (37 views)
2014-09-09 02:24:56

mitcheeb (57 views)
2014-09-08 06:06:29

BurntPizza (43 views)
2014-09-07 01:13:42

Longarmx (27 views)
2014-09-07 01:12:14

Longarmx (34 views)
2014-09-07 01:11:22

Longarmx (34 views)
2014-09-07 01:10:19

mitcheeb (40 views)
2014-09-04 23:08:59
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!