Iâm working on power-ups for my game itâs the first time I have tried doing them but itâs going pretty well.
Iâm using a time based power up system at the moment and need to implement more UI for what weapon the player has etc but iâm pleased that I got it working first time. Below are some gifs ignore the coin giving the power-up, I wanted to make sure it worked before adding my art
Layout manager finally working⌠in one dimension. Next step⌠the perils of the second dimension!
For some reason itâs taken me a week and a half to get this far. Iâve been trying to come up with an elegant and simple algorithm that figures out how to lay out component hierarchies according to the usual sorts of constraints such as anchors and % width ratios of parents and so on, and also using layout managers that explicitly lay things out (in my case, specifically, I wanted a âFlow Layoutâ that arranged UI components as in AWT. I imagine a grid layout might come in handy too, and possibly a âformâ layout for pairs of labels and widgets).
The trouble arises when you need to get nested components to expand to the correct size, and subsequently resize parent components, and so on, up to the top, where youâve got the window.
So, what Iâve done, is I âinflateâ my components first, from the top of the tree down. Like putting a straw in them and blowing. At the very leaves of the UI, each component must at the very minimum declare a minimum size, which it exerts âoutwardâ pressure with. It may optionally be constrained by its own defined maximum size. And it is also restricted by its parentâs maximum size. The minimum size at any point may be determined by the largest child component, or the calculated minimum size by the layout manager at this level, or by the width of some text.
If, during the process of inflation, we discover that a componentâs minimum and maximum sizes converge on a single value, we know that the component is of a completely fixed size, and we can then âconstrainâ components from this point downwards. Constraining causes all the components underneath to have their maximum sizes clamped to their parent componentâs size. At this point we might apply the constraints at this level, which will converge the minimum and maximum sizes once again, and cause âconstraintâ to happen, recursively.
Once we know a componentâs actual size, and itâs parentâs actual size, we can then position it according to its anchor.
The whole process is neatly rounded off at the end of âinflationâ by the fact that the display window has a known size, which means it immediately sets about applying the âconstraintâ after itâs blown everything up inside it.
Itâs a bit like attaching a balloon to a compressor, and then putting it in a vice
Anyway, Iâm most pleased with myself for working it all out, because it was a complete embuggerance. The second dimension should hopefully âjust workâ alongside the firstâŚ
Today I learned about how to add extra indexes to an sql database table which all of a sudden sped up my high score page from taking 20 seconds to 1 second load times.
Last week I migrated my VPS from Linode (2GB RAM, 20$/mth) to RamNode (0.5GB RAM 6$/mth). Since I barely used 1% of the Linode VPSâs CPU or bandwidth resources and that plan was their minimum subscriptio,n I think the effort to move was warranted.
Your approach is interesting, but why not just use one of the countless layout managers that already exist? Swing, TWI and libgdx all have layout managers that you could pilfer or adapt for free.
I know that skinning components is hard to get right in any look-and-feel widget toolkit, but Iâve found that java layout managers work quite well (though html/css oneâs donât).
The geometry (CSG) and lighting (Multicolor Lightmaps) where made with the âRuntime World Editorâ (Download it, its awesome!), the textures are from Portal 2 (I love this Game), and the Game-Engine that renders the whole thing is one of my personal projects.
There is also physics and a First-Person Camera system (âKinematicRigidCameraâ), that can be swapped out with a âFreeCamâ, or the default JBullet camera (âKinematicCharacterControllerâ). Next on the ToDo-list is to refactor the code to allow multiple kinds of âEntitiesâ like levers, buttons, doors, boxes you can pickup and carry/throw around, NPCâs and Dynamic-Lights. Then I could actually make a small interactive World.
That is a âerrorâ in the lightmapper built into Runtime-World-Editor.
If I where crazy, I would set the lightmapper to use supersampling at a level of 8 (at which the dark corners go away), but lightmapping a map as simple as the shown staircase with a supersampling level of 2 already takes 20 seconds flat. Add to that the fact that with each ss-level the computation takes about two times longer, and you got a big time consuming problem.
I am already trying to get rid of the dark corners by applying some kind of filter to the generated lightmap, but I canât seem to get it working, since I donât know much about image processing.
So you didnât actually make the shadows or AO, you just used a lightmap generation program to do it for you and then just mapped the textures to some geometry?
If lightmaps only contain indirect component you can easily remap it to never go to zero. Just remember that if you can see something then light also can go there and its never pitch black.
Thanks for the tip, I will try that out some time soon.
Its not like fixing someone else lightmapper (that is written in Pascal) is my job/goal.
Your post âsoundsâ like you are mad at me for actually using 3rd party tools to do the job instead of creating my own tool like I always do.
Yes, I created the geometry and lighting with a level-editor, then read that into my own Engine, which was outfitted with physics, and a renderer+reader for the RTW-format over the last three days. Next on to do is to implement an actual Entity-system, and cleaning up code.
And as I said: I made a staircase. (And more things behind the scenes which you canât see)
Thats âWhat I did Todayâ, and have a nice day.
Whoah chill man, I have nothing wrong with that. I realize that came out a little harsher than intended. Donât get me wrong, you did a good job.
I just got the impression that you programmed all the shadows, AO, and other effects yourself, but I might have just been assuming too much.
Nonetheless, youâre doing a good job, and Iâm sure you will continue to do so. Looks like a really nice engine you have going there