Java-Gaming.org Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (731)
Games in Android Showcase (217)
games submitted by our members
Games in WIP (798)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 ... 8 9 [10]
 91 
 on: 2017-06-12 02:45:07 
Started by Kain - Last post by Kain
I'm not familiar with that program, but are you sure you're interpreting this correctly? Isn't it saying that there are a crapload of ShaderProgram objects, and they're all stored in a single Object[]? Wouldn't that simply mean that you may be loading shaders, throwing them on an ArrayList somewhere and forgetting about them, preventing them from being garbage collected?
Oh yeah I was. What I meant was that I never used ShaderPrograms or stored them anywhere. I actually don't even have any Object arrays.

Anyway, I resolved the issue by mistake. After dividing my rendering tasks into more evenly grouped SpriteBatches the memory leak disappeared. Sorry for a very vague solution, but that's what I did.

 92 
 on: 2017-06-12 02:43:23 
Started by orange451 - Last post by CopyableCougar4
What library are you using to decode the audio, and are you streaming it or storing it in one buffer?

 93 
 on: 2017-06-12 02:41:00 
Started by CopyableCougar4 - Last post by CopyableCougar4
Thanks for the notes. I have already implemented some of them and will post some updated timings when I'm done implementing the rest. But so far the scene renders at 75fps Smiley

 94 
 on: 2017-06-12 02:00:57 
Started by orange451 - Last post by orange451
Hello.

I've noticed that the last second (there abouts) of any audio clip gets cut-off when I play it in my game. To play the sound I am using: alSourcePlay(id);

The "quick-fix" is obviously to add some sound-less noise to the end of the clip. But this is just a workaround. Any ideas?

 95 
 on: 2017-06-12 01:56:08 
Started by orange451 - Last post by orange451
I'll give it a try Smiley Thanks Ecumene.

 96 
 on: 2017-06-12 01:41:10 
Started by Kain - Last post by theagentd
I'm not familiar with that program, but are you sure you're interpreting this correctly? Isn't it saying that there are a crapload of ShaderProgram objects, and they're all stored in a single Object[]? Wouldn't that simply mean that you may be loading shaders, throwing them on an ArrayList somewhere and forgetting about them, preventing them from being garbage collected?

 97 
 on: 2017-06-11 21:50:38 
Started by Unimatrix325 - Last post by meva
Thanks!

Wow! I see how deep your game is:). I really appreciate your work.
I admire when people are working alone on such complex games.

I will practice play a little bit and then I will give you more feedback.

 98 
 on: 2017-06-11 19:52:35 
Started by BurntPizza - Last post by theagentd
Today I reworked a large part of RF's rendering pipeline. I finally added proper sRGB support throughout the pipeline, and the fake bloom just looks so much better with it. We'll need to re-tweak a lot of colors as all non-texture colors (e.g. hardcoded float color values for as vertex colors or uniform color values) will look significantly brighter now, but it'll just be a tiny amount of work to fix.

A very common problem I've encountered is essentially wanting to scale something nicely without aliasing, but still retaining the pixely look of GL_NEAREST filtering. Essentially, I want antialiased edges between the different texels, but the actual interior of each texel to be just a single color from the texture. I found the solution to this: I enable linear filtering and then use a shader to "sharpen" the texture coordinates before sampling. This lead to very good results.

What I actually wanted to use this for was to upscale the entire rendered scene in Robot Farm to screen resolution. Our tiles are 16x16 pixels big, which meant that we needed to render those tiles (and everything else) at a scale that was a multiple of 16. We then realized that having a higher screen resolution or simply lowering the tile scale meant that the player would be able to see much further than intended, which gave the player a big advantage when exploring. To keep the view distance fixed, we needed to support arbitrary scaling with of tiles without them looking like absolute crap. For example, here are our 16x16 tiles drawn as 17x17 quads.

The issue here is that with nearest neighbor filtering, the pixels from the original tiles end up covering either 1 or 2 pixels, which causes heavy distortion of objects depending on where they are on the screen. This is especially visible during motion, but the anti-aliased text drawn at tile resolution shows the issue very well in a still image. The numbers look choppy and have weird thickness here and there. When using the new shader to upscale, here's what I get:

In this case, the new shader essentially works as bilinear filtering of the screen as the upscaled resolution is so similar to the original resolution, but it is a tiny bit sharper than bilinear filtering at least. Not too impressive actually...



Looking at a more zoomed-in result where we upscale from 16x16 to 34x34, we get the following result with nearest neighbor filtering:

Ugly again, the fact that each pixel is upscaled to either 2 or 3 pixels causes visible differences and artifacts in the text again. Let's try bilinear filtering:

Well, it's soft and all, but it's also very blurry. How about the new shader?

Perfect! The image is as sharp as it can be without introducing aliasing, but still filtered to the point where the pixels in the text look perfectly even. Try switching between this and the unfiltered image and see the massive difference without a significant loss of sharpness.

Essentially, what the new shader does is give you the output of extremely super-sampled nearest neihgbor filtering, without requiring rendering at a higher resolution. It looks great and costs pretty much nothing! =D



 99 
 on: 2017-06-11 16:15:45 
Started by Kain - Last post by Kain
Hi, I've noticed a dip in performance as time goes on in my game and decided to boot up JConsole and MAT (eclipse memory analyzer). To my surprise and from what I can see (I'm not very informed when it comes to memory), none of my classes seemed to be the suspect in leaking memory; the culprit was LibGDX's ShaderProgram.

I'm not sure if I'm suppose to interact with the class, but so far in my code I have not referenced it. I did a quick google search if there have been any problems with it- nothing showed up. I went deeper and checked out what references ShaderProgram to see if I'm referencing it indirectly, and I found that SpriteBatches have a method to create a default ShaderProgram. But I don't call it.

Here's what MAT spit out for its suspect:


Here's the dominator tree:


I still have the heap up in MAT if you have further inquiries.

TL;DR LibGDX's ShaderProgram class is leaking memory (one time it got up to 1.5GB)

 100 
 on: 2017-06-11 15:06:51 
Started by Mordan - Last post by abcdef
Why don't you get one then?

Pages: 1 ... 8 9 [10]
 
Archive (335 views)
2017-04-27 17:45:51

buddyBro (533 views)
2017-04-05 03:38:00

CopyableCougar4 (975 views)
2017-03-24 15:39:42

theagentd (1011 views)
2017-03-24 15:32:08

Rule (991 views)
2017-03-19 12:43:22

Rule (970 views)
2017-03-19 12:42:17

Rule (968 views)
2017-03-19 12:36:21

theagentd (1068 views)
2017-03-16 05:07:07

theagentd (982 views)
2017-03-15 22:37:06

theagentd (758 views)
2017-03-15 22:32:18
List of Learning Resources
by elect
2017-03-13 14:05:44

List of Learning Resources
by elect
2017-03-13 14:04:45

SF/X Libraries
by philfrei
2017-03-02 08:45:19

SF/X Libraries
by philfrei
2017-03-02 08:44:05

SF/X Libraries
by SkyAphid
2017-03-02 06:38:56

SF/X Libraries
by SkyAphid
2017-03-02 06:38:32

SF/X Libraries
by SkyAphid
2017-03-02 06:38:05

SF/X Libraries
by SkyAphid
2017-03-02 06:37:51
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!