Java-Gaming.org Hi !
Featured games (88)
games approved by the League of Dukes
Games in Showcase (681)
Games in Android Showcase (196)
games submitted by our members
Games in WIP (744)
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 ... 357
1  Discussions / Miscellaneous Topics / Re: What I did today on: 2016-06-27 08:21:10
If you were shrewd you'd basically implement Unity's shader language... thereby having access to thousands of free and awesome shaders and a huge amount of amassed expertise...

Cas Smiley
2  Discussions / Miscellaneous Topics / Re: What I did today on: 2016-06-23 12:12:15
Musing... what's the average length of such a linked list in a typical scene? And the longest?

Cas Smiley
3  Discussions / General Discussions / Re: Virtual Reality on: 2016-06-22 17:27:42
Oh, I still am. It's amazing but I don't think it's of general interest to general consumers yet because it's inconvenient, massively expensive, and gimmicky. When it comes with every Playstation shipped by default it'll get some traction.

Cas Smiley
4  Java Game APIs & Engines / OpenGL Development / Re: Discussion: The mother of all shading languages on: 2016-06-22 12:20:08
You'd use it if you were too impatient to respect the low-hanging limited fruits of the hardware available and work within your means. I mean look at the tricks people have pulled over the years to squeeze performance out of hardware, spending months and months and losing most of their hair, only for it all to be rendered completely irrelevant a mere 18 months later by the hardware simply being twice as fast. Life's too short. Relatedly:

Quote from: theagentd
The best code is the code that does the job, is readable and doesn't take years to write. There's no point in optimizing something if a simpler solution is just as fast, making it the best solution.
Hint hint Smiley

Cas Smiley
5  Discussions / General Discussions / Re: Virtual Reality on: 2016-06-22 12:17:15
The Vive is just insane. I cannot really put into words just how much my mind was blown by it, except that the only thing that has gotten close to it in terms of experience was mushrooms, and it's been a few years since I had any of those.

Mushrooms, however, grow out of the ground everywhere and are completely free*

Cas Smiley

* They will, of course, do your head in eventually.
6  Java Game APIs & Engines / OpenGL Development / Re: Discussion: The mother of all shading languages on: 2016-06-22 10:26:08
precision qualifiers... "we want this crappy device to do 3D but it's a bit too crappy, but we can make everyone's lives more annoyingly complicated to squeeze out pointless extra performance so you can make games for it that nobody will play".

I wish they'd stop doing this sort of shit.

Cas Smiley
7  Java Game APIs & Engines / OpenGL Development / Re: Discussion: The mother of all shading languages on: 2016-06-22 09:13:20
My brilliant plan is to just get theagentd to write all my shaders, which is working out nicely  Pointing

Cas Smiley
8  Java Game APIs & Engines / OpenGL Development / Re: Discussion: The mother of all shading languages on: 2016-06-21 22:34:17
Thanks for the input. I'm gonna roll with a minimal GLSL preprocessing system just to get things running in the first place, but it doesn't feel like a good long-term solution.

Is it common for people to just write the same shader for different languages?
Most of the work in shaders is actually working out what they have to do. So it's probably just easier to write the same shader in several dialects, especially as compared to the rest of the code, they're not particularly huge.

Then again, see Unity shaders.

Bah, Unity again.

Cas Smiley
9  Discussions / Java Gaming Wiki / Re: Java Data structures on: 2016-06-21 21:18:40
Android ain't Java, though Wink

Cas Smiley
10  Discussions / Miscellaneous Topics / Re: What I did today on: 2016-06-16 21:35:44
Because you ask the player to make a choice, up front, about how good they think they are, at a game they've never played before, using criteria they don't yet know. And they cannot choose the right answer! They'll feel like they're missing out if they choose "pweez don't hurt me"; they'll moan vociferously but refuse to back down if they choose "kill me now!!"

Far better to just design a game at which everyone has fun and sort of creates the difficulty level of their own making, so to speak.

Cas Smiley
11  Discussions / General Discussions / Re: Question: Bit-exact floats on different computers? on: 2016-06-16 20:54:26
... which is exactly what strictfp does, at the occasional expense of a bit of performance here or there Smiley Even so it's probably going to be quite hard to find bugs in your client when they inexplicably diverge at some point.

Cas Smiley
12  Discussions / Miscellaneous Topics / Re: What I did today on: 2016-06-16 20:51:25
Don't you have difficult levels?                                                   
I consider difficulty levels a failure in game design.

Cas Smiley
13  Discussions / General Discussions / Re: Question: Bit-exact floats on different computers? on: 2016-06-16 10:33:23
Model the world on the server; model the special effects on the client. If something is critical to the gameplay, the server should be the arbiter. If it's just eye-candy, let the client do whatever it likes.

Cas Smiley
14  Discussions / Miscellaneous Topics / Re: What I did today on: 2016-06-16 08:29:23
I am looking forward to it. Tho I hope i am better at it than titans revenge.
I am in a perpetual battle with Alli to stop the game being ludicrously difficult. I spent all day arguing with him that the game was too hard, but he just couldn't see it. Even though I, who know how the game is designed, couldn't get past level 1 75% of the time, and had never even seen level 3. Eventually he capitulated with a 5-line code change and oh! Look I can get to level 3 finally. Sheesh.

Here's a top tip: don't ever listen to yourself when it comes to difficulty testing. Listen to the testers.

Cas Smiley
15  Discussions / General Discussions / Re: Question: Bit-exact floats on different computers? on: 2016-06-16 08:27:22
I think because there were subtle differences in implementations on various processors over the last 20 years (f. ex. Intel using 80-bit internals for computation unless you use strictfp). That, and understanding exactly how floats work in all situations is very complicated (I don't really know myself) and there are better things to do with one's day.

Cas Smiley
16  Discussions / General Discussions / Re: Question: Bit-exact floats on different computers? on: 2016-06-15 21:31:43
strictfp will do this.

Cas Smiley
17  Discussions / Miscellaneous Topics / Re: What I did today on: 2016-06-15 20:10:09
Playtested a lot of Basingstoke this evening. It's slowly getting there.

Cas Smiley
18  Discussions / Java Gaming Wiki / Re: Java Data structures on: 2016-06-14 08:24:53
I think that there should be something about iterators and the enhanced "for each" loop. Using this syntactic sugar will create a new iterator every time it is called with the straight java implementations of lists and maps etc. If you are iterating over big collections in every cycle of your game loop you start to get some nice GC homework to do. This might not be so relevant on a Desktop or laptop, but on a mobile device this is something you really need to be aware of. LibGDX for example provides datastructures which reuse the iterators. You need to be careful about doing nested loops, but this has never hindered me in my own use of them.
Apparently not in the Hotspot VMs... it's somehow cleverly optimised away isn't it? (Anybody got a debug VM handy to spit out the machine code?)

Cas Smiley
19  Discussions / Miscellaneous Topics / Re: What I did today on: 2016-06-09 09:33:59
Still alpha! Months and months yet till beta :|

Cas Smiley
20  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL 3 - LMDB bindings on: 2016-06-09 09:31:14
What'll happen is that the world will largely divide into two camps, one camp being the World+Kitchen Sink camp (Spasi) and the other camp being the one-thing-done-well camp (me, and FWIW, Hydroque). We're all just tips of icebergs when it comes to sentiments but what will eventually happen is the kitchen sink camp will suffer from Magic Kebab Syndrome* and implode under the weight of unmaintained natives, and there will be someone who goes "bugger this I'm a gonna fork this" and boom! Schism. LWJGL3's core hives off and becomes a separate minimalist project and the whole effort is like watching waves break on the shore.

Cas Smiley

* Years ago, Chaz and I were horribly drunk and started speculating on what we'd like to eat, and eventually after many iterations we came up with the idea of a never ending kebab. That was fed to us by Michelle Pfeiffer. And so on. In other words, it was an endless spiral of additional fancies, each more improbable than the last.
21  Discussions / Miscellaneous Topics / Re: What I did today on: 2016-06-09 08:37:50
Uploaded a test build of Basingstoke to Steam.

Cas Smiley
22  Discussions / Miscellaneous Topics / Re: Graphics Cards on: 2016-06-08 09:03:23
Get a paper round Wink

(That's what we used to do, grumble, moan, other old man mutterings)

Cas Smiley
23  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL 3 - LMDB bindings on: 2016-06-07 19:54:27
Really, it's none of my business - I'm just suggesting an even more modular approach to that which Spasi is already undertaking that might ultimately be to the benefit of the LWJGL project as a whole, by minimising the maintenance footprint and focusing on the critical requirements. When I saw that list of stuff in LWJGL just then my mind just boggled at the thought of trying to use it in 5 years' time only to discover that it hasn't been maintained for 3 years and no longer works etc etc.

So, hurrah for the concept of the "Core" of basic windowing, OpenGL, OpenAL, input, and now Vulkan. But the rest? I think they would flourish far better if allowed to evolve separately. Even if it is still just Spasi maintaining them for the next few years it will still be easier for him to divest himself of them and hand over these other projects to other maintainers who will have more time and energy.

Cas Smiley
24  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL 3 - LMDB bindings on: 2016-06-07 11:57:52
Don't get me wrong, I love open source and I'm proud of what little I managed to accomplish, but the expected returns never quite materialised for me.

Cas Smiley
25  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL 3 - LMDB bindings on: 2016-06-07 11:37:43
This is why I waited for the 3.0.0 release before merging the LMDB branch. I expected some controversy and wanted to see if enough users would find it useful first. Currently LMDB only exists in a nightly build of 3.0.1. No harm has been done. This is also the 3rd time I have to mention in this forum that 3.0.1 will not be released without a solution for #100, which will break the LWJGL distribution in separate artifacts for each binding; you will be able to choose what you want or don't want in your application.
I think you're being a little defensive about my observations, Spasi! I'm quite aware of the 3.0.1 goals already. What I am questioning is that LWJGL is, as a whole, becoming quite a sprawling mess of functionality, and that (as you allude to below), it appears to be largely driven by you and your own personal needs and as such seems to me to have become a giant git repository with all of your open source work in it. This is an important observation, which I'll get to...

What it definitely isn't, modular or not, is a lightweight Java games/graphics library! It's no longer a lightweight project as it covers everything from GUIs to compute to audio to in-memory databases to hacking the Java language to get structs in. It's not Java any more as it now contains multiple binary libraries. It's not a single library now but a whole multitude of libraries. So there's that to think upon.

Quote
I bet no more than 5 users have ever used LWJGL's OpenCL bindings, yet I find them super-important and have spent countless hours working on them. Why aren't there any complains about those?

Because it still satisfies the original premise of LWJGL, which is the minimum and most direct binding to a native API possible to achieve something vaguely game-related. Personally I wouldn't have included it either, but I'll get to why in a mo...

Quote from: Spasi
Quote from: princec
or even in a Java context... I'm very reluctant to bind to native code to do stuff that Java code can do. The LWJGL was all about binding to native APIs that could not otherwise be done in Java
I don't agree with this either. Just because something can be implemented in Java does not mean it should.
There are many ways to implement functions, but the question is not which language something should be implemented in, but whether it should be implemented at all. The crux of the matter hinges on a comment you made about LWJGL 2:
Quote
- Look at the mess LWJGL 2 was in. There were dozens of bugs and no one to fix them. Who's going to write a decent windowing system in Java (or anything that touches lots of OS-specific APIs like GLFW and LMDB) and maintain it?

What LWJGL 3 is now is a vast collection of bindings, most of which are irrelevant to most people. What this means is that maintenance effort is going to be simply non-existent on it, and once you (eventually) grow tired of it, and you will, it'll just stagnate and get bitrot and become a large legacy which will distract people from otherwise creating separate efforts to solve specific issues.

I lost interest in maintaining LWJGL after a few years of developing on it, largely because it did everything I needed it to by that point, and also because I was seeing virtually no return on my efforts. I watched Markus accumulate two and a half billion dollars on the back of the literally months and months of effort I'd put in on the library he used to catapult himself into the realms of the unspeakably rich with barely so much as a thankyou, and that, for me, was the point at which I decided I couldn't be arsed with open source any more. I only have so much time left in the world and a lot of things I'd like to do, and making Markus richer wasn't on the list, so I diverted my efforts elsewhere. At some point, you too will find something more interesting and distracting, and you'll be leaving behind a huge, huge pile of stuff which no-one except you really cares too much about.

I strongly advise you to split LWJGL up into the bare minimum and then create separate, independent projects that build on top of or besides LWJGL for GUI libraries, structs, OpenCL, in-memory databases, vector math, etc.

Cas Smiley
26  Discussions / Miscellaneous Topics / Re: Graphics Cards on: 2016-06-07 09:27:39
I fear the internet has raised an entire generation of people who think everything costs nothing.

They are in for a terrible shock in a few years.

Cas Smiley
27  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL 3 - LMDB bindings on: 2016-06-07 09:11:01
I'm slightly shocked to discover I agree with something @Hydroque says! I'm really not at all sure how this fits in with LWJGL, either in a gaming context, a general purpose graphics context, or even in a Java context... I'm very reluctant to bind to native code to do stuff that Java code can do. The LWJGL was all about binding to native APIs that could not otherwise be done in Java - minimising the area of the native interface footprint to the bare minimum to get the job done - and it seems there's a bit of "kitchen sink" syndrome going on.

Cas Smiley
28  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL 3 - Nuklear bindings on: 2016-06-06 14:39:14
Hmmm ... IME GUI toolkits are never quite as trivial as they look. I wouldn't recommend this become part of "core" LWJGL but it'd be a welcome bolt-on library. That said... it would maybe just be better off as an entirely separate project dependent on LWJGL3? After all, Nuklear is going to be doing its own thing with releases.

Cas Smiley
29  Java Game APIs & Engines / JavaFX / Re: JavaFX For Pixel Games on: 2016-06-02 20:08:39
Couldn't care less about X11 Smiley Seriously, who actually uses that for real work?
Quote
Use HTML5 (javascript + html + css).
Now it's funny you should say that but I've looked quite seriously into the potential for this for game UIs but still have the same ol' problem of no libraries out there actually render directly natively to OpenGL. It's all render-to-a-system-texture-and-upload-it-every-frame. This is crap in two ways: 1. the whole copying it to OpenGL every frame thing 2. mixing it with OpenGL rendered parts means readbacks and thus terrible performance.

Cas Smiley
30  Java Game APIs & Engines / JavaFX / Re: JavaFX For Pixel Games on: 2016-06-02 14:34:58
That makes no sense at all.

Cas Smiley
Pages: [1] 2 3 ... 357
 
CopyableCougar4 (50 views)
2016-06-25 16:56:52

Hydroque (86 views)
2016-06-22 02:17:53

SwampChicken (87 views)
2016-06-20 13:22:57

SwampChicken (88 views)
2016-06-20 13:22:49

SwampChicken (82 views)
2016-06-20 13:22:26

Hydroque (126 views)
2016-06-15 08:22:50

Hydroque (120 views)
2016-06-13 06:40:55

DarkCart (238 views)
2016-05-29 02:30:33

Hydroque (202 views)
2016-05-26 14:45:46

Mac70 (187 views)
2016-05-24 21:16:33
Making a Dynamic Plugin System
by Hydroque
2016-06-25 00:13:25

Java Data structures
by BinaryMonkL
2016-06-13 21:22:09

Java Data structures
by BinaryMonkL
2016-06-13 21:20:42

FPS Camera Tutorial
by Hydroque
2016-05-22 05:40:58

Website offering 3D Models specifically for games for free
by vusman
2016-05-18 17:23:09

Website offering 3D Models specifically for games for free
by vusman
2016-05-09 08:50:56

Website offering 3D Models specifically for games for free
by vusman
2016-05-06 11:10:21

Website offering 3D Models specifically for games for free
by vusman
2016-04-29 12:56: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!