OpenTTD is interesting because it can have multiple "cameras" following objects on the screen. e.g. a viewport can be opened to follow a bus or train, zoomed in, while the main viewport is zoomed out.
Or, if you want to loose a few months of your life, instead of looking at the code, just play the game. After 5 years, I am still improving the urban rail system of my metropolis.
> OpenTTD is interesting because it can have multiple "cameras" following objects on the screen. e.g. a viewport can be opened to follow a bus or train, zoomed in, while the main viewport is zoomed out.
I have used OpenTTD, so I don’t know the specifics, but from how you describe it, RollerCoaster Tycoon has/had this too. The main viewport would show what you’re zoomed in/out on, while you could have a screen open following a roller coaster train.
It’s an achievement, for sure. Maybe it’s just me, but there’s not really anything special about assembly. It does require a different way of thinking than higher level languages, but if you’re used to it, why not continue using what you’re good at?
I love pixel art in general but the Zeus one, in particular, is amazing. I think it's only on that one that I realized just how much these change in response to movement.
Don't know much about it but this surely takes a lot of work? Does every instance of movement have to be accounted for separately or would this reuse some variations?
I'm not sure whats going on here but I'm just seeing a picture of 3 nude elderly people fighting over a loaf of bread. It doesnt really seem responsive beyond stretching to fill the screen.
Maybe try one or two of the other half dozen examples. And spend an extra second or two looking at how the images stretch to fill the screen, think about what it would take to make the image stretch the way it does.
BTW, “responsive image” referring to having the image respond to resize, with anything other than uniform stretch, is absolutely standard terminology in web development.
On Firefox mobile the site navigation doesn't appear so the link literally leads to a single picture of three old naked men fighting over bread and that's it.
Maybe try giving people the benefit of the doubt. And spend an extra second or two considering valid reasons why someone might post something.
The image depicts the Graeae, three sisters who held the secret of where the Gorgons (e.g., Medusa) lived. I'm not sure what the "bread" is in the picture. Presumably only one could eat at one time?
In Firefox, on Windows 10, moving the mouse pointer over the resizes the image.
For the "Zeus" image (selectable from a list on the side of the screen) you get a lot of changes - Zeus goes from young to old, changes into animals, etc.
Probably not quite, because the order in which you carve seams matters for every variant that I'm aware of (forward of backward energy seam carving). That is, if you reduce a 200x200 image to 100x100, you get a different result if you do that in order 200x200 -> 100x200 -> 100x100 than if you do that in order 200x200 -> 200x100 -> 100x100.
But if you constrain it so that any reduced resolution is carved by stepping through the path that represents a straight line from the original image, and pre-generate all images, you might end up with something that looks smooth.
That's more or less what I was trying to convey: for any size reduction, take the route that follows the path with the shortest Euclidian distance[1] (as opposed to Manhattan distance[1]) from the original resolution.
If you do that, then the transitions should look quite smooth. You better memoize the intermediate results if you want decent performance though ;)
So yes, I think your line of thought is on the right track!
Cool idea. I don't see why you couldn't do this. First, run seam carving at a few sample aspect ratios but modify the algorithm to keep track of what regions are carved. Create a kind of heatmap that records the "disposibility" of each pixel (probably in two dimensions, x and y) interpolated from the sample seam carved images. Use that to remove or add pixels as the user resizes the image.
I think most people have patience for different things they enjoy.
Someone recently told me they were amazed of my patience, because one of my programs for computer-generated art took 20 seconds to render (meaning it takes 20 seconds, plus a bit of coding, to iterate on a previous output). Their workflow involved a few (powerful) pieces of software, with instant preview for certain tweaks. I'm going to assume most people here write a lot of code, and that you do too. Haven't we all at some time done a debugging or iterating session that took 20+ seconds just to test? (To clarify, usually my programs don't nearly take as long, but sometimes they grow increasingly more complex as I iterate, and when you also increase the resolution ...)
I'm sometimes amazed by the patience people have doing running sessions longer than 30 minutes. Or soldering many equivalent pieces on a PCB. Or reverse engineering software. Or hardware. Doing big DIY stuff to your house.
Surely there are cool things that you have patience for, that many other people would envy. Probably more than one, I have patience for cooking projects, pen and ink drawing, much more actually. I don't have time for all of it though :)
I used to have patience for rather huge (but tiny in size) projects that took half a year of coding in my free time, to write non-interactive real-time procedural graphics and audio applications called 4k demos (4096 bytes of x86 machine code). But I don't have the patience for machine code any more, and that is fine too :)
I instantly thought of rust when you mentioned long times, lol.
You are right, though. People have different amount of patience for things but some go beyond it. I have seen projects posted here which people worked on for a decade consistently. That is some hard work and dedication. I can't imagine doing the same and perhaps, it's better I don't. There are many different things to learn and dip into, maybe some day I will have the same patience for things I take up and throw (ADHD).
https://www.openttd.org/
Specifically, Viewports, Blitter and Resize handling:
Viewport: https://github.com/OpenTTD/OpenTTD/blob/1.9.3/src/viewport.c...
Window resizing: https://github.com/OpenTTD/OpenTTD/blob/1.9.3/src/video/sdl_...
Zoom: https://github.com/OpenTTD/OpenTTD/blob/1.9.3/src/main_gui.c...
OpenTTD is interesting because it can have multiple "cameras" following objects on the screen. e.g. a viewport can be opened to follow a bus or train, zoomed in, while the main viewport is zoomed out.
Also I'd like to recommend aseprite (https://www.aseprite.org/), which has even cleaner code with zoom / panning / etc. The GUI itself is also pixel art: https://github.com/aseprite/aseprite/blob/v1.2.16.3/src/rend..., https://github.com/aseprite/aseprite/blob/v1.2.16.3/src/app/..., https://github.com/aseprite/aseprite/blob/v1.2.16.3/src/ui/v...