I did the first Project Euler problem. Since the goal for an easy one like this was more about getting tool chain issues sorted out I went ahead and did it the brute force O(n) way. I had planned on working out the more efficient solution which should be O(1), but they actually discuss it in the explanation you get after reading it, so now I don’t know if I will or not.
Doing it the more efficient way would still let me play around with pointing a profiler at it or something to actually measure the difference, so maybe I still will. I definitely will for some problems, I just don’t know if I’ll bother with one this simple.
EDIT: Decided to go ahead and do the smarter version. Also found a bug in the brute force version while doing so and fixed it.
EDIT2: Removed link to github (and made repo private) because it is against the rules to reveal solutions.
Today is apparently National squirrel Appreciation Day. I trust we are all celebrating it appropriately and responsibly.
As discussed previously, I’m going to attempt to use SVG based tiles for my map output. Which means I’ll need a library Java library. Enter Apache Batik. https://xmlgraphics.apache.org/batik/
I may need to switch to something else later, but this seems like a pretty reasonable starting point.
Just a note to myself to look into https://projecteuler.net/about a bit more.
EDIT: Signed up.
One of the never ending issues with roguelikes is tiles vs characters (ASCII for example, but many use more extended character sets.
Currently I’m exploring the feasibility of making a graphical tile based interface where the default tiles are SVG defined character graphics. For local play, this should give most of the benefits of both. For online play, there are different issues (ans some additional benefits if I go with a browser based interface), but I’m focusing on local play at this point.
I hope this approach will give me:
- A system where pretty graphical tiles are possible but where I can quickly define character based ones. For me, character based is preferred, but an SVG tile is an SVG tile whatever it’s contents, so if someone with the desire and talent wished to do so, icons would be inherently supported
- Scaling. This should allow the “graphical” part of the game to scale more gracefully across a range of screen/windows sizes and resolutions.
- Templating. I’m just learning to work with SVG, but I hope that I can template-ify the icons so that variations (tin things like color) can be done more easily. This is the equivalent of color coding your orcs (‘o’) in a character based system.
For now, I’m going to work towards using the SVG data directly, but I suspect that for performance reasons some sort of tile generator/smarter caching/whatever will be required.
Since I know next to nothing about working with SVGs, I picked up a few books. No review/recommendation on these as I have not read them yet.
As I think some more about this, I want the alarm clock portion to be near the bed, but not the light portion. This means some sort of communication (presumably wireless) between them.
I’m also not sure just how much light I’ll need to pull this off and/or how to diffuse it effectively. Also, colors?
With this in mind, I think step one is going to be to kludge together an LED setup to get a feel for brightness controls. I’m concerned by how dim I can usefully go using PWM so may need to look into a more involved current source rather than just using the PWM off of a micro to trigger a transistor (I’m assuming I’ll need more current than the micro pin can source/sink)
With that in mind:
Step One: Figure how much light I’ll need, if I want colors (possibly starting more red), and how to diffuse the light.
Step Two: Get the fading process worked out, but just triggered by a local button.
Step Three: Clock Stuff
Step Four: Wireless communication. I may go with something that includes wireless from the start (I’ve already been kicking around the idea of an MQTT hub for the house, could just use actual wifi and tie into it, but I’d also like to learn to do some more direct radio comms)