Finally, I also got my streaming working and did my first dev stream, never been quite so mistake prone as I was when working with the stream running!

Be careful about accidentally showing up passwords and private stuff.If you have got multiple monitors it's a wise thing to stream only one of them and keep the log in, mail and other businesses on the other one.Also I would be glad to watch your dev streams, can you give me a link please?

Today finished work on all the basic area code in the new UI library. So now I've got fully resolution independent UIs which can lay themselves out every frame, with a listener/event model that can handle mouse movement, button presses, clicking and multiple clicking, and full drag and drop capability. What's more every UI element can have its layout interpolated between positions nicely, and its appearance, depending on state. Pleasingly it can cope with thousands of nested widgets being laid out and processed in realtime with almost no noticeable use of CPU (most of the time, widgets are idle, and only wake up when they need to animate or receive an event from the input system).

Now I'm "porting" my old widget code to the new stuff - checkboxes, scrollbars, scrollpanes, textfields, etc. Should have it ready by end of the week, and then I can start converting Battledroid to use the new UI.

I foresee it being a fairly useful library for UIs in general, as it makes it so easy to make resolution and aspect independent UIs.

ja, do you use any space partitioning ? .. nothing, a grid or a tree ? just curious

Scroll back a few posts and you'll get the general gist of it... basically I traverse the tree from the root to the leaves, applying constraints to the widths and heights of each component, first from its parent (a component can never be bigger than its parent), then its own constraints. Then recurse down to the children. When all the children are done (or if there are none) we ask the component how big its contents are going to be based on the constraints we've been given, and that becomes our minimum size. The contents is the larger of any text area, or child component, or the size of any calculated layout.

Maximum size overrides minimum size. If we discover that our maximum size now equals our mimimum size, we're done at this level and we know exactly how big we are going to be, and that means we can tell all our child components that they can now position themselves within our bounds, recursively. Where any child component does not yet have matching minimum or maximum size we decide to use the minimum size.

That's the layout part.

The interpolation part isn't all that complicated or clever and literally just interpolates things like colours and constraints.

The event handling stuff is... more fiddly Basically it's a tick-based state transition manager which receives events from the input system every tick (it's possible to get several mouse events per video frame, which is how often the LWJGL input system is polled). Every component gets every event every tick. Then they all sort of figure out what's happened in isolation from each other, leading to events being fired.

It will doubtless end up open-sourced at some point in Battledroid, the plan for which is most likely to give the source away in some charitable event one day.

Looked at Rust, discovered some willfully teeth-grinding grammatical irritations. Wonder if someone might care to remake Rust using Java-like standards of readability and grammatical consistency. Core concept behind Rust is great, and well prepared for hundred-core home computers. Probably it needs an appropriately designed operating system too though, which more or less means, not Unix or Windows.

I've been waiting for a viable C++ replacement for longer than some kids here have been on the planet...maybe someday I'll get my wish.

Or you know, you could just learn C++.

I know it's quite a pain but lots of devs are using it and it's not so hard to get used to.I develop both in Java, C# and C++ and once you get over the most annoying little things like using headers, manually deleting pointers, makefiles, compiler options (yes, that's actually quite a lot to learn) it's not that bad. However, I still prefer Java out of these 3 because of the JIT compiler and the cross-platform capabilities.

It it not all done today, I have been working on it for ages, now and again on and off. For a long time, it turned into my "tech demo" where I was just updating the rendering to VBO's, and trying to get more performance, as well as playing with shaders.

The game started out with just Immediate Mode rendering, then I learnt how to do VBO's more, so I changed the rendering. Then it became my text rendering test. I then decided to learn more about shaders, so I had to learn how to send the VBO data to the shader, and started to learn how to create lights.

By about the time that I learnt all of those, I set the project as "tech demo", planning to never finish the game, but use the current state to just learn new stuff. University started shortly after, and I didn't do much for a while, other then redo my text rendering, it is definitely not great, but idea was, lets just get text working, how ever ugly it looks, then polish it later, not just the code, but the image for the text is definitely not great and some letters are to far over, or to far up.

I then improved on the rendering again, fairly recently (within the last 2 or 3 weeks), I use to cap my lights at 10 or 20, because I would started to get like 300 FPS, down from like 2500 FPS with like 2 lights, and any more it would just go down a lot more. By the time i fixed the rendering, I was getting about 5000 FPS with 2 lights, and 300 FPS with about 126 lights. I can probably increase it a bit better, at the current state, the light is not limited to a certain distance. As well as making the puzzles a lot more easier and cleaner to implement into the game.

What I have done today, and yesterday was removed the limitation of having the level restricted to 32x20 pixels, as well as made the camera follow the player, but not go past the edge of the level, the player will stay in the middle until the camera locks to the side, then the player can gets unlocked until moved in the opposite direction to unlock the camera. I have also decided that I am going to remove it from my "tech demo" and try and finish the game, I have always wanted to, but never got around to it.

Looked at Rust, discovered some willfully teeth-grinding grammatical irritations. Wonder if someone might care to remake Rust using Java-like standards of readability and grammatical consistency. Core concept behind Rust is great, and well prepared for hundred-core home computers. Probably it needs an appropriately designed operating system too though, which more or less means, not Unix or Windows.

Cas

One of the things they're working hard on at the moment is ergonomics, they are well aware of some of the thorns. Although if you mean things like abbreviated keywords then I think most of that is there to stay.My main issue with it right now is the constant breaking changes, but once 1.0 hits I'll be reading the docs and tutorials through and through.

Finally started on a lighting system that runs at 60fps. This was the sixth and final option I tried, so this victory is long overdue It's still very primitive and ugly but it's "smart", reacts to it's surroundings, goes well with other lights, and runs well overall.

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