Java-Gaming.org Hi !
Featured games (84)
games approved by the League of Dukes
Games in Showcase (549)
Games in Android Showcase (139)
games submitted by our members
Games in WIP (594)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
   Home   Help   Search   Login   Register   
  Show Posts
Pages: [1] 2 3 ... 92
1  Game Development / Newbie & Debugging Questions / Re: Access violation with glDrawArrays on: 2015-01-29 15:09:45
Fixed...
2  Game Development / Newbie & Debugging Questions / Re: Access violation with glDrawArrays on: 2015-01-29 13:26:29
Performance is excellent. I used to simply draw each instance by itself and upload the skeleton data into a uniform matrix array. The random access of the texture buffer is at least as fast as uniform array access it seems, and in addition I can randomly access any amount of data in the shader which allows for instancing and more bones per instance. The maximum number of uniform variables quickly becomes a limit in my case, but with texture buffers I'm only limited by the precision of my bone ID vertex attribute, which is currently 1 byte. 256 bones per model ought to be enough for anyone (tm).
3  Discussions / General Discussions / Re: Schemes to teach the masses to code on: 2015-01-29 04:59:37
We have those cooking and household classes in Swedish high schools too.
4  Game Development / Newbie & Debugging Questions / Re: Access violation with glDrawArrays on: 2015-01-29 04:14:59
you prefer TBO's over SSBO's ?
Yes, since I'm limited to OGL3 I haven't looked into SSBOs very much.

For skinned models, I also batch up all the skeleton data into one MASSIVE VBO which is accessed as a texture buffer, which I can strongly recommend if you have data that is reused between vertices like skinning data.

Could you explain what data you refer when you say skeleton data?
Each skeleton animated instance needs a skeleton. Our player model has around 70 bones. Each of these need to be available in the vertex shader for random access (up to 4 per vertex), so I dump each bone into a TBO as a 4x3 matrix and can easily get whatever bone I need that way.
5  Game Development / Newbie & Debugging Questions / Re: Access violation with glDrawArrays on: 2015-01-28 20:42:11
I basically do the same as Cas. I try to batch up as much data as possible into as few VBOs as possible. I currently batch up all my model vertex data into a single VBO and all indices in a second VBO. For skinned models, I also batch up all the skeleton data into one MASSIVE VBO which is accessed as a texture buffer, which I can strongly recommend if you have data that is reused between vertices like skinning data.
6  Game Development / Newbie & Debugging Questions / Re: Experienced game developers opinions needed! on: 2015-01-28 18:03:33
Seriously though, you should consider getting a better name. >___<
7  Game Development / Newbie & Debugging Questions / Re: Experienced game developers opinions needed! on: 2015-01-28 17:57:30
Fortran Assembly Program Master 6.9? I see no problem...
8  Game Development / Newbie & Debugging Questions / Re: Access violation with glDrawArrays on: 2015-01-28 16:12:10
God damn it, kappa, your GIF logo is messing with my GPU benchmarks. >___<
9  Game Development / Newbie & Debugging Questions / Re: Access violation with glDrawArrays on: 2015-01-28 16:03:41
is that a question ?
Yes, it is.
10  Game Development / Newbie & Debugging Questions / Re: Access violation with glDrawArrays on: 2015-01-28 15:50:27
I just tried drawing by filling the mapped buffer only once and the speed didn't increase so dramatically, which makes me confused so as to what's slowing me down. When I can play Counter-Strike: Global Offensive at solid 120 FPS, why can't I draw 6000 vertices?

The vertices are fast to process, but the GPU chokes on filling all your pixels.

It runs faster Grin

So the goal in the end is reducing overdraw as much as possible?

Some numbers for you:
 - 1920x1080 = 2 073 600 ≈ 2 million pixels
 - 100 fullscreen passes * 2 073 600 pixels ≈ 200 million pixels filled per frame
 - Theoretical fillrate of a GTX 770: 33.5 gigapixels/sec, or 33 500 000 000 pixels per second.
 - Theoretical FPS of a GTX 770: 33.5 / 0.2 = 167.5 FPS
 - Actual FPS of a GTX 770 using this code: 166-168, seemingly fluctuating.

That was surprisingly accurate. o___o

I'm assuming theagentd is referring to ARB_buffer_storage when talking about persistently mapped memory.

If so, he's right in that its the fastest way now, only downside is that it seems to require pretty new hardware (OpenGL 4.3+) making it pretty much unusable for applications targeting the masses (unless you want to have an application with multiple rendering paths). Once such hardware becomes mainstream its definitely the way to go.
It is however easy to make a flexible interface which can be implemented using glBufferData(), unsynchronized mapped buffers and persistent mapped buffers and that can dynamically switch between them. See this again: http://www.java-gaming.org/topics/maximizing-vbo-upload-performance/32169/view.html

Here's the performance of the Insomnia test program with a shitload of shadow maps being rendered and buffers being mapped:

Unsynchronized: 36 FPS, ~26.5 ms per frame spent on doing OpenGL calls.
Persistent: 58 FPS, ~9.8 ms per frame spent on doing OpenGL calls as driver multithreading kicks in once buffer mapping isn't causing synchronization anymore.


Would anyone be interested in an extensive graphics performance optimization article about identifying and solving bottlenecks?
11  Game Development / Newbie & Debugging Questions / Re: Access violation with glDrawArrays on: 2015-01-28 14:39:02
Don't create arrays for each vertex. Also, it looks like you're drawing fullscreen quads. 100 fullscreen passes = 10-20 FPS.
12  Game Development / Newbie & Debugging Questions / Re: Access violation with glDrawArrays on: 2015-01-28 14:31:52
How are you mapping your buffer now? What are you writing to it? What are you drawing? What GPU do you have?
13  Game Development / Newbie & Debugging Questions / Re: Access violation with glDrawArrays on: 2015-01-28 14:30:36
Persistently mapped memory most definitely is faster. You completely get rid of the map operation and also get rid of some driver-internal synchronization. Sequential writes to write-only persistently mapped memory is barely slower than normal direct ByteBuffers. Using LibGDX with read-write persistent GPU memory is slow, since you're essentially reading and writing incoherently directly to VRAM. When it comes to uploading data to the GPU, you cannot beat persistent mapped buffers.
14  Game Development / Newbie & Debugging Questions / Re: Access violation with glDrawArrays on: 2015-01-28 13:36:59
Why am I getting such slow speeds with just 600 vertices
What are you comparing with? Buffer mapping is an expensive operation, so you should try to map as little few times per frame as possible. Mapping is more useful for very large VBOs. If you're mapping so little data, the mapping operation may be expensive enough to bottleneck the program at a few thousand FPS. You may want to take a look at persistent mapped buffers for optimal performance.
15  Discussions / General Discussions / Re: Schemes to teach the masses to code on: 2015-01-28 05:36:12
It sounds like schools in Germany are ahead of schools in the US and the UK. Most schools here don't offer any "computer science" other than "typing", which is usually taught by a librarian.
Jesus Christ, for real?! The Swedish high school system is a bit different, but we basically pick/apply for a set of classes, like social studies, natural sciences, etc, and this is the main emphasis. In addition there are different versions of them all. For example, in natural science some of them focus extra on science, some on computer science, some on math, etc. I went to one that had extra focus on math and computer science. We had:
 - Computer science (basically typing class, sucked)
 - Computer communication + operating systems (Cisco stuff mostly)
 - Programming in Java
 - Programming in C

All of those were obligatory. We have whole high schools dedicated to computer science. Jesus Christ.
16  Game Development / Newbie & Debugging Questions / Re: Access violation with glDrawArrays on: 2015-01-28 05:15:26
You've misunderstood how vertex attributes and buffers work. glVertexAttribPointer() inherently uses the currently bound VBO at the moment when you call that method (not when glDrawArrays() is called), and since you have none bound you're essentially telling it to read from an invalid memory address. Once you call glDrawArrays() the read is actually executed, so that's where it crashes. You need to bind the correct VBO before calling those methods. In the same way, your glBindBuffer() in
public void drawBuffer(Unsync buffer)
currently does nothing. Since you're using Riven's unmapped buffer code, you need to redo all your glVertexAttribPointer() calls with the correct buffer bound each frame since the buffer you want to read from changes each frame.
17  Game Development / Newbie & Debugging Questions / Re: Access violation with glDrawArrays on: 2015-01-27 20:17:11
Almost always means that you've told OpenGL to read outside a buffer boundary, either through how you set up your vertex attributes or by drawing too many elements (if using glDrawElements()).
18  Discussions / Miscellaneous Topics / Re: What I did today on: 2015-01-27 20:14:39
The red triangle is transparent (I think alpha=0.8 in that picture), but it doesn't look perfect just yet. I'm trying to figure out if it's possible to improve it a bit. I have a few tricks, but they all have their drawbacks.
Have you yet published paper from that technique. Looks absolute amazing.
Still working on that. Also, accidental medal. Enjoy. >___>
19  Discussions / Miscellaneous Topics / Re: What I did today on: 2015-01-26 23:01:08
The red triangle is transparent (I think alpha=0.8 in that picture), but it doesn't look perfect just yet. I'm trying to figure out if it's possible to improve it a bit. I have a few tricks, but they all have their drawbacks.
20  Discussions / Miscellaneous Topics / Re: What I did today on: 2015-01-26 21:54:29
Finally implemented my order-independent transparency algorithm into We Shall Wake. Looks pretty great.

Before:

Note specifically that the smoke "cube" looks hollow, and that the huge triangles are completely incorrectly sorted.

After:

Smoke in the cube is correctly sorted, so only the surface of the smoke cube is visible. The triangles are also correctly blended with the smoke, and it's easy to see where they disappear into the smoke.
21  Game Development / Performance Tuning / Re: Fast way to filter through data on: 2015-01-26 21:42:39
If you can cheaply sort the list or the list is already sorted, then it's simply a matter of cutting off all elements after a certain index, which can easily be found using a binary search in the sorted list.
22  Java Game APIs & Engines / OpenGL Development / Re: Fill Ellipse from a fragment shader on: 2015-01-26 21:40:34
Don't use discard() directly. It's more flexible to simply output the alpha to the alpha channel and then do the rest using glEnable()s. Want fast but aliased result? Enable the alpha test. Want alpha-to-coverage? Just enable it. Want supersampling? Enable alpha test+sample shading. If you discard in the shader, you can't use it for alpha-to-coverage. Even discarding on alpha==0.0 is slower, as the if-statement is more expensive than the writing.
23  Games Center / Featured Games / Re: State of Fortune on: 2015-01-19 18:06:38
*bows*
24  Game Development / Newbie & Debugging Questions / Re: OBJ Mutli-Vertex Attribute Indices on: 2015-01-19 17:05:34
You can store your data in textures and sample it manually in your vertex shader, but it'll be a lot slower.  You'd lose vertex caching and the overhead of the texturing will most likely be noticable. I doubt you have enough data to make it worth the memory savings. Just duplicate them.

EDIT:
It'll almost certainly not be worth it. Even with hundreds of thousands or even millions of vertices, we're talking about memory usage of 10s of megabytes at most in the first place, and with that number of vertices, you'd need 32-bit indices for each attribute as well, which means that each "vertex" is essentially 4*3 bytes of index data, which is pretty huge. Normals (and sometimes tex-coords) can be stored as shorts, which means that they use fairly little memory. A normal can with some clever packing be stored as 2x16-bit shorts + a sign bit to reconstruct Z, while texture coordinates often don't need 32-bit float precision so they can also be stored as (unsigned) shorts. This means that both normals and texture coordinates only use 32 bits of memory in the first place, so replacing them with 32-bit indices plus a massive table of data would actually use even more memory.

Even caching vertex positions this way will hardly be worth it. In a normal 3D model, it is usually pretty rare to have two vertices which have the same position but not the same normal or texture coordinates. This usually indicates a UV-seam, which your models shouldn't have a significant number of as they both look like crap and complicate a lot of things, so indexing the vertex positions would not save very much. I'd say that less than 20% of the vertices would need to be duplicated at all, and the additional memory used by the position indices you'd need to add would probably outweigh this. IN ADDITION, you'd need to store the 3D-position in a RGBA texture since the GPU automatically pads 3-channel textures to 4 channels, so you'd essentially need to add 33% more memory there as well, unless you store it in a GL_R32F texture and do 3 samples per vertex, which would just be ridiculous.

TL;DR: Pack your data, don't index attributes.

Not to mention that if you have a million vertices in a single .obj file, you're doing something wrong in the first place.
25  Game Development / Newbie & Debugging Questions / Re: OBJ Mutli-Vertex Attribute Indices on: 2015-01-19 13:03:47
What about 3 texture coordinates? That's allowed too.. xD

you mean, tex-coords like x and xy and xyz and probably xyzw ?
I'm pretty sure he means multiple sets of 2D texture coordinates. It can be useful if you want to read from shared textures or light maps in addition to normal textures. I don't think .obj supports this. Light map coordinates are usually generated by your own engine, so you can store them in your own format.

... Copy?
i mean, when you setup a array-buffer (vertices) you can just copy all unique vertices as provided by the .obj file. thats pretty good. then when you continue with the element-array-buffer (indices) and again you can just reuse all the face definitions (f v//..) as they come in, but everything else (normals, tex-coords) are unique by the format but there is no way to pass a end element-array-buffer (afaik) which points into a array-buffer of normals.
I think what he's trying to say is that there's no way to directly draw a vertex with OpenGL the way .obj files store them. You can't just dump your list of vertex positions, vertex normals and vertex texcoords into a VBO each and then have one index buffers for each attribute. OpenGL only supports a single index buffer, so when creating your VBO you essentially need to store every single unique combination of position+normal+texcoord that you have in the .obj file. If all three are identical you can store it once and just index it, but even if only the normal differs for example, you'd still need to store the position and tex-coords again.
26  Java Game APIs & Engines / OpenGL Development / Re: Fill Ellipse from a fragment shader on: 2015-01-18 16:22:49
The easiest way to do this in a fragment shader is to NOT rely on gl_FragCoord. If you rotate the coordinates, the result stays the same. A better idea is to assign "texture" coordinates to each corner and have the shader rely on those instead, since those coordinates will be and interpolated correctly after rotation.
27  Discussions / Miscellaneous Topics / Re: What I did today on: 2015-01-18 03:24:34
Follow-up on my grass...
No AA:


8xTSRAA with supersampled alpha test:


Screenshot comparison: http://screenshotcomparison.com/comparison/110083
28  Discussions / Miscellaneous Topics / Re: What I did today on: 2015-01-17 22:26:06
Fixed my TSRAA to work with my grass renderer...



PNG lossless comparison: http://screenshotcomparison.com/comparison/110034
29  Game Development / Newbie & Debugging Questions / Re: LWJGL Lighting Bug on: 2015-01-16 02:26:25
Don't forget to normalize it.
30  Discussions / Miscellaneous Topics / Re: What I did today on: 2015-01-15 04:36:03
I think he didn't plug in his DVI cable all the way in. At least that's the closest thing I can think of that's happened to me...
Pages: [1] 2 3 ... 92
 

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

The first screenshot will be displayed as a thumbnail.

Archive (18 views)
2015-01-29 04:26:08

theagentd (19 views)
2015-01-28 15:33:52

GamerIDGoesHere (27 views)
2015-01-27 01:23:23

GamerIDGoesHere (28 views)
2015-01-27 01:22:15

CopyableCougar4 (36 views)
2015-01-27 00:34:41

CopyableCougar4 (22 views)
2015-01-26 04:47:56

Olo (16 views)
2015-01-25 21:26:00

Olo (21 views)
2015-01-25 18:44:22

Robo11 (38 views)
2015-01-25 06:14:26

basil_ (32 views)
2015-01-17 22:29:32
2D Dynamic Lighting
by ThePixelPony
2015-01-01 20:25:42

How do I start Java Game Development?
by gouessej
2014-12-27 19:41:21

Resources for WIP games
by kpars
2014-12-18 10:26:14

Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

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
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!