Java-Gaming.org Hi !
Featured games (91)
games approved by the League of Dukes
Games in Showcase (804)
Games in Android Showcase (239)
games submitted by our members
Games in WIP (868)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 ... 125 126 [127] 128 129 ... 216
  ignore  |  Print  
  What I did today  (Read 3666516 times)
0 Members and 2 Guests are viewing this topic.
Offline SirSoltex

JGO Coder


Medals: 33
Exp: 1 year


Pixel-man, Programmer. Lover of the pancreas


« Reply #3780 - Posted 2016-02-23 07:16:45 »

Took out my old memories with cubing, my very first rubik's cube (not exactly rubik's, but a duplicate one I bought for ~half a dollar).

Here's most of my collection! There's about 10 or so more around the house or in my car/bag.


how would even solve those Huh they have like, 7 sides and multiple colors

Are you humans? I don't know.
Offline ra4king

JGO Kernel


Medals: 508
Projects: 3
Exp: 5 years


I'm the King!


« Reply #3781 - Posted 2016-02-23 07:20:14 »

I.... oh dear.... I'm avoiding Vulkan for a bit.

Offline J0
« Reply #3782 - Posted 2016-02-23 09:28:25 »

Went through the Vulkan thread.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline ShadedVertex
« Reply #3783 - Posted 2016-02-23 10:15:02 »

I don't think I'll touch Vulkan for a couple of months (1500 lines just to clear the darn screen? Damn!). But temptation usually prevails when it comes to exciting new libraries.
Offline KaiHH

JGO Kernel


Medals: 796



« Reply #3784 - Posted 2016-02-23 10:25:04 »

I don't think I'll touch Vulkan for a couple of months (1500 lines just to clear the darn screen? Damn!). But temptation usually prevails when it comes to exciting new libraries.
Yes, I did not think that it would be such a lot of work to get a clear screen to work.
But the good thing is that most of that code is general setup which you need to do in any case. And once you've cleared the screen you've already covered about 80% of the whole Vulkan API. Smiley
It is really a clean and well thought-through API, which makes OpenGL look really patchworky, tangled up and cumbersome to use (more than it used to be).
Which means that adding anything on top of a simple clear screen app, like rendering a triangle, is not that difficult to do.
So in essence: With Vulkan you get more control over your setup, which is good, but it has a much steeper learning curve than OpenGL. But once you have that down, you know already pretty much everything there is and programming in it should become much smoother afterwards.

So do have a try with it. I think the LWJGL project will get some demos and also some boilerplate reducing utility classes/methods to make working with Vulkan a lot more pleasure.

EDIT: Also noteworthy: The most effective Vulkan learning in my opinion is by reading the Mantle programming guide (besides example code): https://www.amd.com/Documents/Mantle-Programming-Guide-and-API-Reference.pdf
Offline NegativeZero

JGO Kernel


Medals: 357
Exp: 1 month or less


Zero but not.


« Reply #3785 - Posted 2016-02-23 11:44:55 »

Also noteworthy: The most effective Vulkan learning in my opinion is by reading the Mantle programming guide (besides example code): https://www.amd.com/Documents/Mantle-Programming-Guide-and-API-Reference.pdf

I'll add that to the links in the Vulkan thread.

Offline KaiHH

JGO Kernel


Medals: 796



« Reply #3786 - Posted 2016-02-23 12:33:58 »

To be fair, KaiHH was first. Slam him some medals...
In my opinion Spasi deserves all the medals.
He provided the LWJGL Vulkan bindings in such short time, that I find it unbelievable how he did this. Smiley
And the binding is close to (if not already) perfect right now.
So, absolutely fantastic work of him!
Offline ShadedVertex
« Reply #3787 - Posted 2016-02-23 12:57:36 »

To be fair, KaiHH was first. Slam him some medals...
In my opinion Spasi deserves all the medals.
He provided the LWJGL Vulkan bindings in such short time, that I find it unbelievable how he did this. Smiley
And the binding is close to (if not already) perfect right now.
So, absolutely fantastic work of him!

I think it's hard to find anyone who'd disagree with that. Awesome job, Spasi!
Offline Hydroque

JGO Coder


Medals: 25
Exp: 5 years


I'm always inspiring a good time.


« Reply #3788 - Posted 2016-02-23 13:24:28 »

Why not slam them both medals? Why not both?

You think I haven't been monitoring the chat? http://pastebin.java-gaming.org/c47d35366491fHere is a compilation <3
Offline theagentd
« Reply #3789 - Posted 2016-02-23 15:25:38 »

An overlooked missing feature of OpenGL was that FPS was limited to 10 000 on Nvidia hardware. I'm glad to inform you all that the cap has been removed in Vulkan, so now I can enjoy my clears at over 20 000 FPS. I can't believe it took them so long to realize that 10 000 simply isn't enough for some people. Roll Eyes

Myomyomyo.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Hydroque

JGO Coder


Medals: 25
Exp: 5 years


I'm always inspiring a good time.


« Reply #3790 - Posted 2016-02-23 15:30:24 »

An overlooked missing feature of OpenGL was that FPS was limited to 10 000 on Nvidia...

What exactly is your purpose for frames 10k+?

You think I haven't been monitoring the chat? http://pastebin.java-gaming.org/c47d35366491fHere is a compilation <3
Offline SHC
« Reply #3791 - Posted 2016-02-23 15:31:56 »

An overlooked missing feature of OpenGL was that FPS was limited to 10 000 on Nvidia hardware. I'm glad to inform you all that the cap has been removed in Vulkan, so now I can enjoy my clears at over 20 000 FPS. I can't believe it took them so long to realize that 10 000 simply isn't enough for some people. Roll Eyes

I had seen the issue, even with game loops that plays catch up, and does use the rest of the time to do repeated frames, they still appear to be choppy, even when the framerate is at high numbers. I've tried to use an interpolation when rendering, but that didn't work out that great, since I don't know how to interpolate transformation matrices..

How and why are you needing that many framerates? and also how is it smooth?

Offline EgonOlsen
« Reply #3792 - Posted 2016-02-23 16:01:41 »

How and why are you needing that many framerates?
To make music! A lot of graphics cards' voltage regulators start to emit a high-pitched buzzing sound when rendering at a very high frame rate.

Offline elect

JGO Knight


Medals: 76



« Reply #3793 - Posted 2016-02-23 16:23:16 »

Vulkan is really exciting, there are mainly three reasons why one should choose it over OpenGL: multithreading rendering, lower overhead (although many would argue why choosing java in the first place and especially lwjgl) and full control.

Anyway, OpenGL has evolved a lot in the last years. OpenGL 4.5 and the AZDO extensions do bring some concepts close to Vulkan's philosophy but there are also things that will never die (such as the texture units).

Vulkan is actually a so-called double edge sword: huge powers bring huge responsabilities  Cool, this means a lot of code path, based on the resources available.

The OpenGL drivers are, yes, unpredictable sometimes, but they are also very well optimized, so in order to make it worth choosing Vulkan one should not only match the driver performances, but be faster.

Actually there are also another couple of reasons to choose Vulkan, if one needs extremely all the cpu power he can get, the cpu delta OpenGL->Vulkan may still  be very tempting and the compatibility, OpenGL ecosystem is quite fragmented, Nvidia is always first to implements the last features, but forgives a lot of errors, Amd closes, in general, quite quick the gap. And then we have the lazy window Intel team (because the linux team is different and they rock) and Apple, who really suxs. Vulkan is, under this point of view, somehow like OpenGL 3.3, it brings a fresh start. A difference compared to OpenGL is that Vulkan introduces also a couple of features to push vendors to keep their drivers updated and this is really excellent.

Vulkan is for the big Software Houses, small/indie devs will remain on OpenGL and if they want faster performances, they should consider moving on modern GL before jumping to Vulkan.

There is a small list of very intersting posts on the Nvidia website, here at the end of the page. Also the upcoming talks at the GDC will be really interesting, especially the comparison AZDO vs Vulkan (Nv command list ext seems to be even faster than Vulkan).

An overlooked missing feature of OpenGL was that FPS was limited to 10 000 on Nvidia hardware. I'm glad to inform you all that the cap has been removed in Vulkan, so now I can enjoy my clears at over 20 000 FPS. I can't believe it took them so long to realize that 10 000 simply isn't enough for some people. Roll Eyes

Funny, I have nv and I experience that cap with jogl but not lwjgl
Offline Grunnt

JGO Kernel


Medals: 143
Projects: 8
Exp: 5 years


Complex != complicated


« Reply #3794 - Posted 2016-02-23 16:36:58 »

One thing I might potentially like about Vulkan is the possibility of more userfriendly API's being developed on top of Vulkan. I have no interest in dabbling in supertechnical details, but maybe something easier / better than OpenGL built on top of Vulkan, who knows.

Offline Icecore
« Reply #3795 - Posted 2016-02-23 19:35:18 »

OpenGL was that FPS was limited to 10 000 on Nvidia hardware.
this is totaly Wrong concept (that i used, same, some long time ago ^^)
better way - use: System.nanoTime() for performance and FPS calculate =)

Last known State: Reassembled in Cyberspace
End Transmission....
..
.
Journey began Now)
Offline delt0r

JGO Wizard


Medals: 145
Exp: 18 years


Computers can do that?


« Reply #3796 - Posted 2016-02-23 19:58:17 »

If i use Vulkan it is because under the hood some game engine starts using it. The days of doing it all myself are long gone. I may add a feture or a special effect, or as in jME hack some mulitmonitor support. But outside that, na.

And today i registered as a Ltd company (incorporate). I also managed to get Unity to work again. We have models importing to both jME and Unity, but some slight issues with jME. Also in Unity there is no IK and everyone seems to use mecncia or whatever for animations.

Yea i will freeze the engine decision at the end of the week.

I have no special talents. I am only passionately curious.--Albert Einstein
Offline theagentd
« Reply #3797 - Posted 2016-02-24 00:33:33 »

What exactly is your purpose for frames 10k+?
Absolutely none. =P

Myomyomyo.
Offline elect

JGO Knight


Medals: 76



« Reply #3798 - Posted 2016-02-24 08:09:42 »

One thing I might potentially like about Vulkan is the possibility of more userfriendly API's being developed on top of Vulkan. I have no interest in dabbling in supertechnical details, but maybe something easier / better than OpenGL built on top of Vulkan, who knows.

If one wrappers Vulkan, he gets away from its design and closer to OpenGL one and then one might think what's the point if there is already OpenGL..
Offline theagentd
« Reply #3799 - Posted 2016-02-24 08:53:29 »

One thing I might potentially like about Vulkan is the possibility of more userfriendly API's being developed on top of Vulkan. I have no interest in dabbling in supertechnical details, but maybe something easier / better than OpenGL built on top of Vulkan, who knows.

If one wrappers Vulkan, he gets away from its design and closer to OpenGL one and then one might think what's the point if there is already OpenGL..
I'm gonna try to abstract away the graphics API used in NNGINE/We Shall Wake, so that I can switch between the two without having to change code. Sadly since Vulkan needs so much more information (memory barriers, image usage, etc) that's basically gonna mean that you have to code for Vulkan and all the extra info is discarded when running OpenGL, so that's not gonna help you very much. xd

Myomyomyo.
Offline Grunnt

JGO Kernel


Medals: 143
Projects: 8
Exp: 5 years


Complex != complicated


« Reply #3800 - Posted 2016-02-24 11:06:48 »

If one wrappers Vulkan, he gets away from its design and closer to OpenGL one and then one might think what's the point if there is already OpenGL..

I suspect there are many different abstractions possible that are very different from OpenGL. Very few people will actually develop games or applications using Vulkan directly (just as not too many people are using OpenGL directly). I'm just guessing that Vulkan will allow the open source community to develop some interesting new API's on top of Vulkan.

Offline princec

« JGO Spiffy Duke »


Medals: 1146
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #3801 - Posted 2016-02-24 11:57:11 »

I think... Vulkan is not for me. And never will be.

Cas Smiley

Offline Roquen

JGO Kernel


Medals: 518



« Reply #3802 - Posted 2016-02-24 12:13:47 »

This is the point of Vulkan.  OpenGL is a fungus growth attempting to be low-level, mid-level and high-level in different growth spurts.  Vulkan is supposed to be a low-level interface.  Everyone writing directly to Vulkan is like everyone writing there own low-level interface to all devices...that'd be crazy.  To have one final bitch about OpenGL that I haven't said before:  Did you know that Quake 3 allocated a fixed amount of memory for GL extensions?  And to keep the program from crashing OpenGL drivers detect and don't return too much.  How nuts is that?  Like I said...fungus growth.

------

For something completely different: #gamedev 12 tips for making the best use of your time by Mike Acton
Offline theagentd
« Reply #3803 - Posted 2016-02-24 12:21:58 »

I suspect there are many different abstractions possible that are very different from OpenGL. Very few people will actually develop games or applications using Vulkan directly (just as not too many people are using OpenGL directly). I'm just guessing that Vulkan will allow the open source community to develop some interesting new API's on top of Vulkan.
The thing is that Vulkan IS a better API, hands down. It's more complex, in some cases needlessly complex and you can make a wrapper for those parts, but the idea of building command buffers from multiple threads and later submitting them for execution does have use, even for OpenGL.

A frustrating part of OpenGL is that it's so difficult to thread. That means that you essentially need to split up non-OpenGL graphics tasks (culling, skeleton animation, etc), which means doing parallelizable work interleaved with OpenGL commands. Currently the optimal way of doing things is this:

1. Do culling with N worker threads. Save all visible objects in a list/lists.
2. Map buffer(s) on the OpenGL thread. Even with persistent buffers you may have to resize the buffer(s) so that all data can fit, which means OpenGL communication may be needed anyway.
3. Calculate matrices, skeletons, etc for all visible objects and store them in the buffer(s) using N worker threads.
4. Unmap buffers on the OpenGL thread.
5. Do all OpenGL commands on the OpenGL thread.

This maximizes parallelization and respects OpenGL's limitations. Mapping a buffer causes a synchronization point inside multithreaded drivers, so if you're going to map buffers you should map all of them at the same time, not interleaved with draw calls, as that causes needless stalls.
1  
2  
3  
4  
5  
Frame   | Frame 1 start                                                   | Frame 2 start                                                  |
        |                                                                 |                                                                |
Workers | ---Frustum culling---     ---Write data---                      |---Frustum culling---      ---Write data---                     |
OpenGL  |                      -map-                -unmap- --Draw calls--|                      -map-               -unmap- --Draw calls--|
Driver  |                                                   ---Driver thread processes frame 1---SYNC! ------<stalled>------ --Process frame 2 draw calls....

In other words, the driver offloads heavy OpenGL calls to an internal driver thread that processes stuff in parallel with the game. This system maximizes the amount of time the driver thread has to finish its job before mapping a buffer for the next frame, which forces a sync. The final draw call processing pretty much only does the draw calls decided on after the first culling pass.

With Vulkan we can throw that entire thing out and just map buffers on any thread, write data on any thread and generate command buffers on any thread. Sure, the vkQueueSubmit() calls to run the command buffers have to be done on a single thread, but you can actually run all your created command buffers with a single vkQueueSubmit() call, so it'll be fast. Very fast.

The thing is, this approach has uses in OpenGL too when threading things. Consider this loop:

1  
2  
3  
4  
5  
for(GameObject o : objects){
    if(frustumCuller.isVisible(o)){
        o.draw();
    }
}
Interleaving OpenGL commands and frustum culling is bad, since frustum culling can be very expensive (data structure queries, etc) so we want to do that on multiple threads, but OpenGL doesn't allow drawing from multiple threads. So we end up doing this:
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
//Parallel loop:
for(GameObject o : objects){
    if(frustumCuller.isVisible(o)){
        visibleObjects.add(o);
    }
}
//OpenGL loop:
for(GameObject o : visibleObjects){
    o.draw();
}

And, well, there's your home-made command buffer. So why not just queue up draw calls directly instead of objects? There's actually something to gain from doing that even in OpenGL, so it only makes sense to take that approach for a generic abstraction that supports both of them. Even if we can't make a GPU command buffer directly with OpenGL, we can (and should) still minimize the amount of extra work we do while doing all the draw commands.

TL;DR: Having command buffers in an abstraction that can run both OGL and VK under the hood is useful for OGL too, so an abstraction should feature command buffers.

Myomyomyo.
Offline elect

JGO Knight


Medals: 76



« Reply #3804 - Posted 2016-02-24 14:38:25 »

Best way to do culling is on the gpu itself so you exploit: cpu offload, gpu parallelism and data locality
Offline theagentd
« Reply #3805 - Posted 2016-02-24 14:58:02 »

Best way to do culling is on the gpu itself so you exploit: cpu offload, gpu parallelism and data locality
Not sure I agree. The GPU is a lot less flexible, so you won't be able to use any advanced data structures efficiently.

Myomyomyo.
Offline Spasi
« Reply #3806 - Posted 2016-02-24 15:00:07 »

The OpenGL spec + extensions is a very complicated environment to work on, especially for new users, and stuff like Nvidia's AZDO I find absolutely crazy and worse than Vulkan. Whenever I do any serious development with OpenGL, it feels like I'm in a constant fight with the drivers. So many details to get right, for all kinds of crazy reasons, so easy to get sub-optimal performance, so easy for things to just plainly don't work (even if you ignore driver bugs). The only other environment that feels like that is database SQL, where you often have to resort to vendor-specific functionality and you're battling the shitty decisions the optimizer makes all day long.

Screw that, never again.

I've gone through the Vulkan spec now and not once did I think "oh, that's doesn't make any sense". It's a very well-thought-out API. There are two aspects that are complicated and hard:

- Initial setup and figuring out supported features and various hardware limits/constraints. This is understandable, you have a cross-platform & cross-vendor API that also covers a wide range of hardware. From tiny, low-power, phone GPUs to Titan/Fury. It even supports tiled architectures out of the box. This aspect can easily be hidden away in libraries, used by many projects. Worst case, you'll only have to worry about it once (or once per market you're targeting).

- Safety under concurrency, the user is responsible and has to worry about a lot of stuff. But this unlocks opportunities for better performance. Also, I believe that over time it will get easier, once people have experience with the API and best practices are published. I don't think engines with proper architectures will have that many locks/waits in them.

Anyway, I just prefer a more verbose API over having to worry about what the driver is doing behind my back. The most important aspect though is performance. Even if you don't care about any of it, better fps or fancy graphics, if you think game mechanics is the top priority (like it should), the fact that Vulkan has the potential for optimal resource usage, is absolutely critical. Keep it simple, keep the same fps, keep the same graphics, just stop wasting power. Especially battery power on mobile devices.
Offline Roquen

JGO Kernel


Medals: 518



« Reply #3807 - Posted 2016-02-24 16:58:54 »

Best way to do culling is on the gpu itself so you exploit: cpu offload, gpu parallelism and data locality
Not sure I agree. The GPU is a lot less flexible, so you won't be able to use any advanced data structures efficiently.
Plus:  even if something is a good match to run on the GPU doesn't mean you'd want to run it there.
Offline Roquen

JGO Kernel


Medals: 518



« Reply #3808 - Posted 2016-02-24 17:01:56 »

Quote
... having to worry about what the driver is doing behind my back.
A super plus of low-level APIs is that if there's a bug in the code based on it, it's highly likely to be in user code.
Offline elect

JGO Knight


Medals: 76



« Reply #3809 - Posted 2016-02-24 19:22:09 »

Not sure I agree. The GPU is a lot less flexible, so you won't be able to use any advanced data structures efficiently.

I didn't test yet by myself, but this is what several presentations, sample and results from nvidia show

The OpenGL spec + extensions is a very complicated environment to work on, especially for new users

If that is a very complicated environment for new users, you can image Vulkan

and stuff like Nvidia's AZDO I find absolutely crazy and worse than Vulkan.

Which one exactly? Because most of them reflect the same concepts in Vulkan..

Whenever I do any serious development with OpenGL, it feels like I'm in a constant fight with the drivers. So many details to get right, for all kinds of crazy reasons, so easy to get sub-optimal performance, so easy for things to just plainly don't work (even if you ignore driver bugs).


That's a vendors' problem, not (really) an OpenGL's one, hopefully things with Vulkan will be different.

I've gone through the Vulkan spec now and not once did I think "oh, that's doesn't make any sense". It's a very well-thought-out API.

It'd have been weird if it wasn't like this...

Anyway, I just prefer a more verbose API over having to worry about what the driver is doing behind my back. The most important aspect though is performance. Even if you don't care about any of it, better fps or fancy graphics, if you think game mechanics is the top priority (like it should), the fact that Vulkan has the potential for optimal resource usage, is absolutely critical. Keep it simple, keep the same fps, keep the same graphics, just stop wasting power. Especially battery power on mobile devices.

As I said, it's a compromise, a double edge sword, it's always good to have choices  Wink
Pages: 1 ... 125 126 [127] 128 129 ... 216
  ignore  |  Print  
 
 

 
Riven (579 views)
2019-09-04 15:33:17

hadezbladez (5505 views)
2018-11-16 13:46:03

hadezbladez (2398 views)
2018-11-16 13:41:33

hadezbladez (5767 views)
2018-11-16 13:35:35

hadezbladez (1222 views)
2018-11-16 13:32:03

EgonOlsen (4660 views)
2018-06-10 19:43:48

EgonOlsen (5681 views)
2018-06-10 19:43:44

EgonOlsen (3196 views)
2018-06-10 19:43:20

DesertCoockie (4094 views)
2018-05-13 18:23:11

nelsongames (5114 views)
2018-04-24 18:15:36
A NON-ideal modular configuration for Eclipse with JavaFX
by philfrei
2019-12-19 19:35:12

Java Gaming Resources
by philfrei
2019-05-14 16:15:13

Deployment and Packaging
by philfrei
2019-05-08 15:15:36

Deployment and Packaging
by philfrei
2019-05-08 15:13:34

Deployment and Packaging
by philfrei
2019-02-17 20:25:53

Deployment and Packaging
by mudlee
2018-08-22 18:09:50

Java Gaming Resources
by gouessej
2018-08-22 08:19:41

Deployment and Packaging
by gouessej
2018-08-22 08:04: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!