I upgraded my tile graphics again for a more solid feeling. Started documenting plans for the finer details of how the game will work.
And setup an awful website describing the project: http://www.cosmicmenace.com
Tried to learn drawing again, but with pixel art this time. It was fairly easy, drew this in just 5 minutes.
But I personally don’t like pixelated graphics, so I tried to trace it with InkScape, and here is the result.
This is fine enough for my small games, but I’ll really try to improve my drawing skills.
I suffer from the same issues. Really need to practice.
That looks like some of the upscaling methods. hqx,scalex,sai, etc.
i bought a digital piano. not too fancy 
https://www.casio.com/products/Digital_Pianos_%26_Keyboards/CELVIANO_Digital_Pianos/AP-260/
Ahh what pieces do you play? Personally I enjoy chopin and romatic period music.
sweet … i like classic - but i’m home at the aeolian scale, which is common in film scores. … also good to make others fall asleep
The problem in these pictures is the shading. Think of where the light would be and draw the darker areas accordingly. In your image the left tentacle certainly does not agree with the right tentacle on where the light is. And your specular highlights in the blue head area seem completely random.
Both are lit from the right side…what’s the problem with that?
On the more high def picture, imagine how it should look when light is hitting it directly from the right. The tentacles would be lighter on the right side, maybe a bit of a highlight if the tentacles are slimy. And unless these tentacles have strange and unnatural bulges, the darker areas should conform to the shape of the tentacle’s outline.
Here, I’ve outlined the areas where you could put highlights and shadows. I’m just using my mouse and did it in like 30 seconds so take it with a grain of salt. Little details make a huge difference.
Spent some time figuring out just how much I hate optimization. So rewarding but endlessly painful. So much so that even the smallest of mistakes just leads to hours and hours of agonizingly looking over perfectly working code to always gloss over that one line that’s breaking everything.
And then after all of that pain to find out the performance boost was… minimal at best. Hooraaaayyy…
Maybe try guiding your efforts with a profiler? Then at least you know what to target to get the highest gains.
Also always go for algorithmic improvements / data representation first, then everything else.
Learning faster ways of solving a Rubiks Cube. Today I got my time consistently under a minute!
Started work on the DropdownListBox widget for SPGL2/Battledroid. A surprisingly fiddly widget but when you need one, you need one.
Cas
I feel your pain, I also hate coding dynamic right click menu. So many little finicky variables involved.
I think I can get away with a lot of common code for context menus… they are after all basically listboxes without scrollpanes. Might get a bit more hairy if I do sub-menus but maybe I won’t bother with sub-menus. Don’t think I need them for a game GUI.
Cas
I learnt that calling
System.currentTimeMillis();
or
System.nanoTime();
or
GLFW.glfwGetTime();
In an FPS calculator all lead to a steady increase in java.nio.DirectByteBuffer objects being created on the heap. Does anyone have any idea on how to stop this happening?
This may sound blunt: but that’s impossible. Your FPS calculator itself is most likely to blame. This is good news, as the problem is in your code, so you can fix it.
You are probably right (I hope you are), but just adding this line
currentTime = System.currentTimeMillis();
(currentTime is a private class variable and is a double (doesn’t matter if its a long))
To my FPS calculator class increments the loaded class count for DirectByteBuffer
And replacing that line with
currentTime = 1.56;
(ie hard coded)
Stops the loaded class count going up. I’m sure there is something else going on here but it is looking odd at the moment