Not the same method, but as I recall the developer of the game A Short Hike did a similar procedure - mostly to allow him to quickly draft 3D models and hide the low-poly models, artifacts, and "glitches" behind the pixel shader.
I wonder if there's a way to keep the pixels on the diagonal of the crystal that's moving up and down consistent, i.e. move them all up and down 1 at a time, rather than blend it as the shape moves in fractions of a pixel. It'd help it look more pixel art.
This is one of the more challenging parts of turning 3D scenes into pixel art in real time — making them pixel perfect. There are definitely ways of doing it, but it honestly rarely gets closer to looking like pixel art that’s created pixel perfect to begin with.
Or even where you play through the first 99 levels thinking it's purely isometric pixel art, then on the final level, for the fight against the boss with perception-warping powers, it unexpectedly changes to a first-person shooter.
I'm currently working on an isometric city builder game. It took me awhile to figure out how to depth sort all assets properly and quickly. I have walls that sit on the edge of a tile, i.e. they take up almost no floor space. Since my game will display the interior of buildings, this means the typical approach of sorting everything by the screen.y position (so long as every asset is a cube (or stack of cubes), or broken up into cubes) fails, because the bottom of the wall texture can be a whole tile-size away from the bottom of the asset.
I had to implement "snap to grid" calculations in the background for moving units inside buildings, meaning for the depth sorting algorithm, I pretend they are on a different tile (when needed). Unfortunately I dont have a video of this yet.
As for efficiency, I implemented static quads (for non moving items) and only draw items within the quads on screen. And for units/vehicles, I do a rectangle collision check (unit rectangle compare to screen space rectangle). It's very fast!
> the typical approach of sorting everything by the screen.y position
Shouldn't that be sorting by the world.y position? Ie, northness, rather than northness + altitude = world.y + world.z = screen.y.
I'm not sure about how much it matters for your game particularly (you don't seem to have world.z coordinates), but in general screen-space operations are a recipe for that sort of bugs, and should be avoided whenever practical.
Caveat: I dont have any experience with 3D games, so we may not be speaking the same dialect.
My game is an "old fashioned" isometric game, meaning it is a 2D game through and through. All assets are square (for top down) or rectangle (for isometric) sprites. Of course, since it's pretending to be a 3D game, you have to draw/place the isometric tiles oddly so the inner rhombus (or hexagon, which is what an isometric cube is without shading) are drawn flush, since the graphics engine is working with rectangles. Thus the sprite's rectangles overlap like this: https://i.imgur.com/NTNHvbL.png
In order to simulate a camera looking into a 3D world, I need to draw everything from the top of the screen to the bottom, in that order, so assets with height are drawn over everything behind it (in world space)
For simulating world height (e.g. something flying one tile off the ground), you just need to move the sprite's screen.y position up the sprite's height (i.e. the height of the rectangle) per tile of height.
I have yet to implement terrain height into my game, but I think there are a couple ways to accomplish this.
1.) I can store the part of the asset touching the ground for all assets stacking upwards (like a multistory building). Thus I can keep the depth sorting algorithm I have.
2.) Or I can add the asset's world height multiplied by asset's (rectangle) height to the screen.y position (again, just for the depth sorting part)
For both cases, I may need to add micro adjustments if I need a specific order within the tile stack itself (seems unlikely). edit: this wont be needed unless I have overlap in the stacking, and I wanted to e.g. have something lower down on the stack be drawn over something above the stack, like an antenna or w/e.
Lastly, this only works if all assets are the same size (thus larger ones are a combination of smaller sprites).
To be fair, I was pilfering loanwords like "screen-space"(adj) from the 3D dialect.
> In order to simulate a camera looking into a 3D world, I need to draw everything from the top of the screen to the bottom
Right, the point I was trying to make was that, technically, you need to draw things from the north edge of the world to the south. If you have a asset with height, you need to draw it at a higher screen position, but also a later time, than a low/short asset that's at norther world position but lower screen position. (Presumably you know that already; I was mostly asking/objecting about confusing the screen position versus the world position.)
> I can add the asset's world height multiplied by asset's (rectangle) height to the screen.y position (again, just for the depth sorting part)
My point was that you'd add[0] the world height plus the world.y position, in order to get the screen.y, but depth sort based only on world.y, independently of height or screen position. That way things that are vertically on top of each other have the same world x and y coordinates (differing only in z), even though they're draw at different screen.y coordinates to provide isometric simulation of height.
0: give or take factors of -1 depending on which way the various coordinate axes go
Most 2d engines use shader system underneath, it easier to write a shader to solved all the z-sorting problems. Only minimal 3d maths and billboarding(tile) are all you need.
I'll have to look around and see if I can find that old site.
I do remember DA had some really great tutorials, and Pixeljoint was full of neat stuff to look at. Twitter was also a good place to check sometimes.
In a bit less mature vein, here's a 2D pixel sketch I made a while back that came to mind. I was trying to recreate the enthusiasm I had when drawing combat pictures as a kid.
When I taught art at the local college, I would sometimes give extra credit to students who tried pixel art, and I usually spent some time demonstrating how photoshopping could be done effectively and even quickly at the pixel level.
If you can work effectively with pixels (and maybe beziers in the vector world, not just the manipulation technique but the minimal-node style), you can pick up just about any graphics tool faster. I would even include 3D design tools in that.
Eboy were the definite leader of the early-oughties isometric pixel art fashion. At first I liked it a lot, but after a while, it went everywhere and became a bit tiresome.
I found it interesting around that time that user interfaces finally got to have less visible pixels due to higher resolutions and full color antialiasing, as well as proper 3D graphics, and yet the retro pixelated pseudo-3D style was trending so much.
I hadn't seen this, thanks! It's quite polished and not very pixelly, but still a great example! Somehow reminds me of the classic "Itsu" video by Plaid (Caution: NSFW!)
Early at my last job (~10 employees) they got eboy to do a pixel art portrait of the early crew. I'm pretty sure they paid with shares and that company is doing fairly well these days, I wonder how much they ended up being worth
I can remember playing this in the 80s as well. They had some classic names back then, all Zs and Xs. Got on a freighter ship in China as a teenager in 1991, and the lone arcade machine was Xevious.
Good memories. Head Over Heels (C64 here) was one I used to just stare at, waiting for the next animation, musical cue, or room reveal...it was very well put together.
(Oh, and the title always made me wonder if it was a Tears for Fears collab, which seemed like such a rad idea at the time)
As others pointed out Zaxxon and Marble Madness came first, but neither allowed the same sort of interaction with the environment (changing depth and moving other blocks around).
Nice guide, but one thing that seems slightly off: All the cubes don't look exactly cube shaped, they need to be slightly taller to look perfectly cube. If for instance a cube is 2x16 px wide, then the height at the side should be approximately 18 px.
One reason is, at least, that because pixel art "isometric" is actually 2:1 dimetric, the vertical axis is slightly less foreshortened than the two horizontal axes.
Let's look at top surface. To have it 2 times wider horizontally than vertically in projection camera angle must be 30 deg down from horizon.
Ratio between the foreshortened diagonal of top surface and foreshortened height of the cube would be sin(30)/cos(30) if they were same length in 3d.
Since they don't have the same length in 3d (diagonal is sqrt(2) times longer than cube height) the final ratio in projection between cube height and diagonal comes out to be cos(30)/(sin(30)*sqrt(2)) so more than 19px and less than 20px (a little bit closer to 20px) for the foreshortened diagonal of 16px.
Blender3d>Modifier>Remesh has a "blocks" modifier, it looks pretty nice, and you can set the camera to "isometric-ish"[1] . However. I hope your model topology is straightened out.
I've stumbled across so many SketchUp imported meshes that are just . . hmm . . I don't know the scientific word for it. "Unconventional" is a nice one. Remesh is going to do some weird stuff there.
[1] Camera>Orthographic Camera Rotation> X:54.7, Y:0.000004, Z:45
Somewhat related, there is a Twitter thread about (not quite isometric) hex-grid pixel-art [1].
In a previous thread [2], Oskar Stålberg, creator of the games Bad North, Townscaper, is talking about his use of grids and their dual for procedural tile placement.
Franekk, an amazing pixel artist, is reacting to this that hex-grids are difficult for pixel-art, and later figures out that Oskars trick does indeed work for pixel-art too [3].
Does anybody reading this thread have suggestions for open source engines/environments to interact/display isometric pixel art? I've looked at a few game engines and haven't found anything well suited for my purpose.
I'd like to be able to generate 3d diagrams of infrastructure maps using the python based mingrammar "Diagrams as Code" approach: https://diagrams.mingrammer.com/docs/guides/diagram presently this can only do 2d SVG.
I'm trying out midjourney for making game assets for my first game. It gets you
90% of the way there. Cut out, adjust colors in photoshop, scale and animate in Aspite. I don't have art experience, but this gets you good enough results for a hobby project, and better what I could draw.
I was reading this old thread on factorio about the projection that is used there oblique/axonometric. Isometric art and equivalents can speed things up, but I wonder how often you run into walls eventually, like factorios trains?
Happy to see slynyrd featured here. Not only is his art great, but he is a nice person and gives quality personal critiques of your pixel art via his patreon on request, of which I'm a member.
