Andrew Davie
-
Posts
5,982 -
Joined
-
Last visited
-
Days Won
8
Content Type
Profiles
Forums
Blogs
Gallery
Events
Store
Posts posted by Andrew Davie
-
-
Here's a bit of an exploration of the idea that the pebbles in the dirt are actually mini geodoges. Or dogeodes, whatever the term is. Every now and then they spontaneously grow into adult geodoges. Furthermore, geodoges occasionally "seed" pebbles in nearby squares. So in pretty short order there are geodoges everywhere. I particularly like in the end of this video how I'm mining, and there's a wave of converstion to dogecoin, but at some point (while that wave is still in action) there's another wave of converting back to geodoge been triggered. It's pretty cool, and I'll try and weave this behaviour into a cohesive story/gameplay..
Press F1 (select) to get to the 2nd screen where there's only pebbles to start off.
-
1
-
-
As a point of interest, here are some of the player frames in source-code format...
const unsigned char shape_FRAME_WALK2[] = { // 14 0x80 | 24, 3, 3, SP2( ___XXX__, HMT0 ), // 00 SP2( _XXXXXX_, HMT0 ), // 01 SP2( _XXXXXX_, HMT0 ), // 02 SP2( XXXX__XX, HMT1 ), // 03 SP2( XXX__X_X, HMT1 ), // 04 SP2( X_X_X__X, HMT1 ), // 05 SP2( X_X_X__X, HMT1 ), // 06 SP2( X_X____X, HMT2 ), // 07 SP2( XXX____X, HMT2 ), // 08 SP2( XXX____X, HMT2 ), // 09 SP2( _XXX__X_, HMT3 ), // 10 SP2( _XXX__X_, HMT3 ), // 11 SP2( X_XXXX__, HMT3 ), // 12 SP2( XX___XX_, BDY1 ), // 13 SP2( XX_XXXX_, BDY0 ), // 14 SP2( XX_XXXX_, BDY1 ), // 15 SP2( XXX_XX__, BDY2 ), // 16 SP2( X_XX____, BDY2 ), // 17 SP2( _X______, BDY2 ), // 18 SP2( _X_XXX_X, HMT1 ), // 19 SP2( XXXX_XXX, HMT2 ), // 20 SP2( XXX__XXX, HMT2 ), // 21 SP2( X_X___X_, HMT2 ), // 22 SP2( ______X_, HMT0 ), // 23 }; const unsigned char shape_FRAME_SKELETON3[] = { // 20 16, 0, 0, SP( _______X,XXX_____, BONE, BONE ), // 00 SP( ______XX,XXXX____, BONE, BONE ), // 01 SP( ______X_,_X__X___, BONE, BONE ), // 02 SP( ______X_,_X__X___, BONE, BONE ), // 03 SP( ______XX,XXXX____, BONE, BONE ), // 04 SP( _______X,_X_X____, BONE, BONE ), // 05 SP( ________,X_X_____, BONE, BONE ), // 06 SP( __X_XXX_,XXX_____, BONE, BONE ), // 07 SP( _X____X_,________, BONE, BONE ), // 08 SP( _X__XXXX,___X____, BONE, BONE ), // 09 SP( ______XX,__XX____, BONE, BONE ), // 10 SP( _X__X_X_,X_______, BONE, BONE ), // 11 SP( _X__X___,X___XX__, BONE, BONE ), // 12 SP( _X__X___,X___X___, BONE, BONE ), // 13 SP( X_______,________, BONE, BONE ), // 14 SP( ___XXX_X,XX______, BONE, BONE ), // 15 };
The first is one-sprite wide, and 24 lines high. The second is 2-sprites wide and 16 high. Each can be an arbitrary height - no real limitations other than memory. In this case the spacesuit walk frame costs 51 bytes and the skeleton costs 48 bytes (the two colour-bytes at the end of each line are combined to 1 byte). Either way, these are quite expensive so lots of animations are ... expensive too.
-
1
-
-
3 hours ago, TIX said:
Lava effects are looking great !
TY. I think the latest one (just posted) might be close to final.
3 hours ago, TIX said:You can add time restrictions, like the suit will dissolve after a period of time so you have to get out of the lava to cool off..
something similar can be done with water/air.. athought he is already in a suit and has air 🙄, but anyway something like that !
Yes, all good ideas and again, gameplay elements to distinguish it from BD. But I think it's actually quite a lot different from BD now.
3 hours ago, TIX said:.
Haven't got time to work on additional animations lately, but I have started thinking about creatures,
I guess the hero is the only high resolution sprite we can have on screen, so can you give me some specs for the rest ?
for example the rocks and the slerg, are 5 pixels wide, but I can't figure out the height..
OK, yes currently only the one high-res sprite, and he uses both players to achieve that. But, having said that... he occupies the entire height of the screen. That is, although his frame is 30 scanlines high, all the other scanlines are blanked out. They can have content but currently do not change x position. So we could drop things on his head, or give him a rope to dangle down from (and climb up/down), or a ladder. But we can't have those things there before he's there. It's all one huge fullscreen sprite, basically, in the one position. We can give him tools (shown in earlier version) like a drill he drills down with.
As to the playfield objects, they are tricky. OK, each "character" is 5 pixels across x 10 pixels deep. But a pixel is 3 scanlines deep. So the characters are really 5 x 30 but you CANNOT DRAW THEM IN THAT RESOLUTION even though they occupy that much space on the screen. They must be drawn as 5 across x 10 deep, and there are only 8 colours (including 0 which is background colour, whatever that happens to be -- use black in drawing stuff). Each "creature" can be formed from a grid of characters... or in the case of slergs, a list of characters at arbitrary positions (these are special-cased for the slergs, but I could possibly do for other creature type/shape/behaviours).
The crushers are also special-cased. Each direction is just two "characters" (as described above). A head, and a body. The head does all the "work" with the movement logic for crushing things, pushing the player, etc. But extremely cheap, just requiring a few characters.
I really do have a "character shortage" - my character set is rather full. I can save a few, and put new things in - but not many. In any case... designing good-looking things in this resolution is very difficult!
SO in summary, "characters" are 5 across x 10 deep with 8 colours (all things on screen use the same 8 colours), so look at the rocks and coins, etc. Enemy can be composed of 1 or more characters, in (I suppose.... might need to support what you come up with) arbitrary arrangements. Slergs are a sort of random orientation of 4 "characters". Crushers are a sort of arbitrary length of 2 characters in any direction (but really only 1 does any "work"). You could have matricies of characters, so something that's a 2x2 for example (so, total size 10 x 20 "pixels"). So, big boss. But this is expensive and chews up characters in the character set - and as I said I have very few spare slots, so unless I change my system (which is unlikely, but possible) we're stuck with that.
Characters can auto-animate at 60Hz (which isn't a great idea because of iCC) or any rate lower than that (20Hz is iCC compatible), but if this animation system is used then every character of a given type (e.g., dogecoin) will animate with exactly the same shape at the same time. Alternatively, we can animate individual characters on the screen independently, but only at the game frame rate (say, 8Hz). Finally, any matrix animation or multiple-character-things animation is also at game frame rate.
One final note -- the reason you may have had difficulty figuring the height is that due to iCC, the 3-scanline-high pixels forming the 10 deep "trixels" (as I call iCC groups-of-three-line pixels) all tend to blend together to your eye, and since they are adjacent to the next trixel, it's really quite hard to see the boundaries. If you put a red trixel next to a green trixel, then you might see yellow between the two. It's quite interesting, and a huge problem for designing good-looking graphics. Just as a for-example, here is the source-code-version of the up-facing head of a slerg...
const unsigned char __CHAR_WYRM_HEAD_U[] = { 0b01110, // 00 < 0b00000, // 01 0b01110, // 02 0b01110, // 03 < 0b01010, // 04 0b01110, // 05 0b11111, // 06 < 0b01010, // 07 0b11111, // 08 0b11111, // 09 < 0b00000, // 10 0b11111, // 11 0b11111, // 12 < 0b00000, // 13 0b11111, // 14 0b11111, // 15 < 0b00000, // 16 0b11111, // 17 0b11111, // 18 < 0b00000, // 19 0b11111, // 20 0b11111, // 21 < 0b00000, // 22 0b11111, // 23 0b01110, // 24 < 0b00000, // 25 0b01110, // 26 0b01110, // 27 0b00000, // 28 0b01110, // 29 };
The format of the data is each 3 lines is a "trixel". The 3 lines give the on/off pixels to be displayed over successive frames -- and the colours are changed over those frames, and the eye blends the on/off pixels and the colours. So each 8-colour-blend-pixel is 3 scanlines high. It's really hard to grasp/explain... and here is the visual...
3 hours ago, TIX said:-
1
-
-
Sparse lava bubbles seem to work best, and I've added a colour pulse for the spacesuit when under the lava. This could be used to indicate status. The whole thing is looking pretty good now, I think. Really time to get those earlier sprites converted and move on to water after that. Haven't done the conversion yet because the sprites aren't grid-aligned and I'm too lazy
-
3
-
-
More work on the lava. I'm close to finished, for now anyway. Some work on the top surface, with bubbles popping up into the air, which looks kinda nice. And the colours and action underground are now more refined. I will work on actual under-lava gameplay at some point later on; these are more or less just the display systems looking pretty good. I might have a go at getting water back in, as the basic things I need to do are the same, and still fresh in my mind.
I can foresee a level where you flip a switch to open up the floodgates to allow the lava to come up, so it undermines an impassable area, the rocks/dirt dissolve as the lava rises, falling down and then you scramble across the top as the lava rises... just in the nick of time you make it to the launchpad.
-
2
-
-
In the video I'm looking at the behaviour of objects under the lava surface. Certain things dissolve - such as the dirt - as soon as they are touched by actual lava (as opposed to being orange because of the lava level) they turn into lava. And there are objects that "melt". The dogeodes for example, and coins. So essentially as things are covered by lava they all turn into lava themselves - at different rates and randomness. Except rocks. You can watch piles of things under lava slowly get smaller and (mostly) disappear. Im not sure how obvious it is that the physics of things under lava is, from the video, but it's there. I envisage being able to move around under lava, if your suit has the right rating.
The lava implementation is still a WIP. I need to graduate/improve the orange colour, and tweak things here and there. It's a start.
Getting there!
-
3
-
-
7 hours ago, Prizrak said:
So you planning on moving beyond 32k? Crap, I'll need to trade my Harmony in for an Encore then. 😥
always on the bleeding edge.
-
Here's the next update for implementation of lava. The dots work perfectly for giving that active feeling. I have put in some basic animation characters for the lava but need to revisit these and make them kind of blend together when side-by-side. There are 4 chars there, randomly swapping between each other. It'll look good when finished. Then I need to sort out a few issues like there should not be blanks in the lava area, and objects under lava will eventually explode. Also, I'm going to allow rocks to roll/fall when under lava, just like earthquakes do. So, a few things to do still. But, very pleased with the dots/effect so far.
PS: as an aside -- the dots here are being drawn from a pool of 8 "dot slots". That is, there are only ever 8 dots on the screen at the same time. When a new one is generated it "kills" one of the existing ones in the 8-slots. Looks way more to me!
PPS: This was really cheap to do, both in terms of ROM space and processing time - because it essentially uses existing systems. The major changes were to define the 4 lava character shapes (120 bytes), modifying the palette code to give the lava colours, and... well that's it.
-
3
-
-
9 hours ago, Propane13 said:
Your "crusher madness" demo had me thinking of an idea that could help differentiate your game a bit more. But, I was curious about a limitation. I know the idea was always to mine 10 planets in the solar system. Is there a potential space concern? The reason I ask is that if you expanded a bit more, it could be fun to have different types of planets and levels with different goals as you go along.
The screen/level you see in the demos I release are a sort of testbed, where I trial new forms of gameplay. All the things you see - crushers, slergs, dogeodes, the physics, lava... these are all elements which I intend to use in various combinations when creating the actual planets. Any space concern will disappear when I move to CDFJ+ -- but for now I have about 4K free (of 32K), so in reality not much because I have lots disabled (e.g., spinning planet interlude, speech, multiple planets to play etc). But it was always the intention here that I had significantly different gameplay on each planet and different goals. So just treat these demos as a hotbed of ideas as to what could go into final planets. For example, the crushers might only appear on certain planets. There might be a "mechanical world" which is pretty much exclusively crushers and you need to find the one/only pathway through. I just don't know yet, exactly what will be on each planet. But adding as many "things" as possible will give me options. The crushers turned out fantastic, and yet I did not think they'd be very useful. Hopefully I can come up with some more. Lava is in progress now; I have a pretty strong feeling lava (and water, later) will be strong gameplay elements. A water planet, for example, where you swim around... and have to come up for regular oxygen refreshment... that might be cool.
9 hours ago, Propane13 said:I'll give an example. Let's say you have 40 planets / levels in total. What if every fourth planet was a "bonus level / asteroid"? That asteroid isn't populated by anything except crushers. And, your main enemy on the level is time, not resource gathering-- and that time is severely shortened. The concept would be that in some locations instead of finding a resource-rich planet, there's nothing there of value. Unfortunately, the ship already left and caused a small cave-in, so you have to get to a flat area to call the ship, which means running through the terraforming crushers. But, the planet isn't terraformed, so there are no oxygen reserves. Can you get through the crushers in 30 seconds? It could be fun to get pushed all over the place and have a different goal than collecting.
Yep. If you press F1 to get to the next level, you'll see I already have preliminary ideas along these lines -- that is, paired crushers you need to go through. As an aside, and for fun, clear the dirt around a pair of crushers and stand in the middle.
9 hours ago, Propane13 said:It would be interesting to see if every few planets had something different from the "collect coin / leave" concept. Some could be "collect the 5 broken terraform machine parts to fix it for the colonists"; some could be "find the missing colonists and rescue them"; some could just be impassible until later due to not having enough pickaxes and needing to stock up over the whole game. I think with different goals, the variety could go way up.
Some good ideas there; I had considered a "tool resource limitation" which does lend itself to having to restock. Unfortunately due to the PF graphics I can't have high-resolution objects lying around so I'd have to find a meaningful way to do the restocking. Maybe an asteroid supply outpost where you stop in between planets to replenish supplies (purchased with dogecoin of course). But the scope is getting bigger and bigger and this would turn it into a years-long project. Along those lines, I've been half-thinking about trying to get a single-planet "planet 0" release out there sooner rather than later, just to have said "at least I released something". I tend to do lots of very big projects/demos and never release. I'd be interested in a small run of "prototype planet 0" carts just to at least have shared the technology and understand the manufacturing costs these days.
-
The red area represents lava. I'd done lava before in my very early WenHop demos. This is a re-implementation. There's lots of work to do yet - bubbling lava characters, exploding rocks, etc. And I can use the "dots" to give surface effects. This is just the very very very preliminary start to the whole thing. Big gameplay element, so I'll be working on this for a few updates. Looking at the video, it's kinda cool (well, hot...) having under-lava creatures. I might think about that.
-
2
-
-
3 hours ago, Bomberman94 said:
Agree with parallels to the BD gameplay…
I remember the (impressive) huge rocket from a „technical demo“ from you, Andrew. Why not leaving a solved level with such a rocket - should fit to the space thematic. Man can hop in and lift up or similar.
That was always the intention. You will arrive at each planet in your rocket, collect enough dogecoin for fuel, and leave for the next planet in your rocket. I think the very first post might cover this, but if not... well, yes, this is a part of the whole concept of visiting 10 planets.
-
3
-
-
18 hours ago, TIX said:
With this engine, a "Mr Driller" clone isn't far off !
Would be relatively easy, I think.
-
Quick proof-of-concept for vertical (up/down) mining - just seeing here how the pickaxe might look. Of course the player frame would need to be adjusted, which might be tricky. But in principiple it might work. Mining up - I'm no so sure about - if you're mining a rock, ok, it turns to dust and you can go through. If you mine a dogeode, it changes to a doge, which then falls on you (or does it?).
I'm still very undecided about this concept/idea.
Technically, those picks could actually be a lasso and you first throw the lasso/rope around the object and then move to the side, pulling the object out of place. Maybe. It's an idea anyway. Not so easy for left/right though because of sprite width limitations. Vertical is unlimited.
-
1
-
-
14 hours ago, Dionoid said:
think the key/solution is to remove (or change) some of the "signature" Boulder Dash features which are still there:
I concur but I did think this would not work in terms of playability. Your overview inspired me to have a go anyway and see what came out of it.
14 hours ago, Dionoid said:- The way you effortlessly 'cut' though the dirt without the need for a drill or blaster. This could be visually solved by giving the player a little drill by default.
I have not added a drill. But what happens now is if you are moving into dirt, you move at half speed. This kinda looks pretty cool, and it now means if you really want to travel somewhere effectively (like, if I add creatures that actively chase you), then digging through dirt is really the last thing you wanna do. You'll be using existing tunnels. Along these lines, and an unexpected consequence -- if you're under a rock and you head downwards, you really do NOT want to be digging through dirt on your way down... because you will get smooshed. It's a completely different mechanic to BD and takes some getting used to. My brain is BD-physics-hardwired, so I kinda expect things to operate a certain way. I do like this new way though.
14 hours ago, Dionoid said:- The distinctive way the boulders fall down. The current physics give me that Boulder Dashy feeling right away. Maybe simplifying the physics and consider the rocks to be squares, so they pile up when they fall on each other instead of rolling off, would make it feel a lot different.
What I've done here is simply disabled the "roll" action of all objects. Now you get vertical columns of things "balanced" atop each other. But I also added a bit of a twist. Remembering that earlier versions of WenHop were demonstrating earthquakes/shake, I re-enabled that code and allow any "balanced" objects to fall to the side (only when an earthquake is happening). It's great. For this version I have simulated earthquake whenever you are holding the fire button. So, play a bit, build a few columns of things, then hold the button down and watch falling rock mayhem everywhere. Fun. This also works as a completely-different-from-BD element, IMHO. Earthquakes need to be a regular element of gameplay.
14 hours ago, Dionoid said:- The 'escape square' which becomes visible after you collected enough diamonds. This could be solved by using a ladder which appears from the top of the screen, to climb out of the underground mine.
That was just a holdover - there will not be an exit door like this in Wen Hop, I think. Will be removed soon. Not so easy right now as there's apparently quite a bit of code around it, all over the place, and my first try failed miserably.
14 hours ago, Dionoid said:Just wondering: is there a reason you can only mine sideways?
Well, yes, sorta... because having animations for up-mining is (was) difficult. But I've rewritten the sprite draw since then, and whereas previously I had to predefine the height of the player sprite, now it's arbitrary. So technically I could add some sort of new animation to show mining-up (and down). But mostly I thought it was kind of cool that you had to plan to attack things from the side. I'll think about this one and see if I can get to an experiment/test on this suggestion sometime soon.
14 hours ago, Dionoid said:I really like how this game is taking shape!
TY! Your feedback and suggestions most valuable to me.
So, here's the result... remember... button press for earthquake, and you go slower through dirt. And the new physics -- so moving up/down nothing will fall, unless you start directly under a fallable object and move down. There may be a few player movement glitches/issues. This was a fairly major change and hasn't had a lot of testing. But overall, I think it's working perfectly and it has, in my view, shifted it significantly away from the BD feel. TY.
-
4
-
I had a thought - I didn't want the crushers to kill the player, but what if they pushed him instead. Would it work? Well, basically.... mayhem! It's a lot of fun. So much going on in the screen here, yet for me at least I still feel "in control" in that I'm following what's going on and am still able to get the player to do what I like. The gameplay around the 40 second mark onwards is pretty funny.
-
2
-
-
Found an interesting double-draw bug in the "dots" which made everything (a) draw twice and (b) move twice as fast. Fixing this led to me being able to draw more dots at the same time (now 20, up from 12) with the result that the screen has more "effects". Total overkill now of course but it's awesome to see all that stuff going on. I added "dots" as an FX when boulders drop and stop, for example. Previously this was handled with special characters at the bottom left/right of a falling boulder, but that was limited to game speed (about 12Hz). The dots can draw/animate at 60hz so it's all much nicer.
-
13 hours ago, TIX said:
Sprite sheet (v4) with added "crashed" animation, it's a work in progress, I have to see it in game..
TY for these; I will convert shortly. It would greatly assist if in future you could put all sprites on a 16-pixel (x) and 30-pixel (y) grid boundary, so that I can use a simple tool to convert them into source code. Otherwise I have to go through and isolate sprites and do manual conversions or extra manipulation. As to the extra frames - - for the same reason that I mirrored the walk, there is not endless space for adding more animations. They are expensive (30 high x 2 wide + colours + centerpoints = about 92 bytes/frame). So I have to cull and only use a subset here. Having said that, if I do move to CDFJ+ and larger ROM size there would be no problem using them all, so don't discard! I'm just working within tight ROM space restrictions at the moment.
-
I have 12 "dots" which are re-used for all sorts of things. Stuff like the crushers impacting things, and the entangled dogecoin radiating. Previously I'd generated "dots" for all these things, and killed the dots when offscreen. This was a slight logic error, as generating dots would kill one of the existing dots if there wasn't a slot available. But this caused offscreen things to kill onscreen things. Now dots are not generated if offscreen, and so the onscreen dots are super-busy. The players' suit colour now "radiates" -- changes colour - when you are close to a fully-entangled dogecoin which is undergoing rapid (pulsed) radiation. It's not a gameplay thing (not yet, anyway). Just a nice visual... but could be gameplay I 'spose!
-
4
-
-
11 minutes ago, TIX said:
This causes some trouble, as the reflection on the visor is not flipped.. I'll take a look.
Nobody will notice.
And those people who do notice, won't care.
And those people who do care, are the artist.
We just can't afford ~87 bytes for reflections in the visor.
It's fine as it is
-
49 minutes ago, TIX said:
Maybe it's an illusion, but when you start to run (from a standing position), it feels "heavier"..
.
.
anyway, moving along here is the latest (v3) sprite sheet,
almost everything have been tweaked/improved, especially the running sequences.
I have also added two more sets:
- the stranded astronaut, just in case (12),
- a full rotation animation (13), so that you can pick and choose the in-between frames
Edit: As I usually forget many of the changes I have done, always consider every sheet as "the latest" !
TY. That last sentence is ambiguous. I will always treat always the last sheet as the latest, right? Not all sheets ever presented as ALL "the latest".
From now on, only facing-right animations are needed. Left-facing animations are auto-flipped version of right-facing (to save memory).
I'll try and get some updates in, in the next few days.
I'm not sure about the rescue-astronaut thing; I can only put one on any line at the moment, although I do have some ideas where I might get 2 if they are only ever 8-pixels wide (that is, no pickaxe).
-
7 hours ago, TIX said:
The new "transitioning" between directions makes a lot of difference for the better !
the downside is it introduces a delay that can prove fatal.
No, it's not a "delay" per-se. It's an animation which happens where none used to happen before. The actual responsiveness of the joystick is the same. If you're moving up, for example, there's no new delay when you move left or right. It's just that the standing animation has an inbuilt transition to make it look nicer. If you're moving around, everything works exactly as before.
-
1
-
-
A short preview of "decorators" - in this case showing a drill, and a numeric overlay. The numeric I might use, for example, when you mine a dogeblock and you have the entangled doge (do-geodes fully surrounded by other do-geodes) -- remember the entangled doge are hard to get and multiply your doge value/count when you mine a block. Not including a binary this time, but jotting down so I don't forget; the doge conversion is now symmetric... when you mine a do-geode and it turns all surrounding (entangled) do-geodes into dogecoins, there's now an automatic/equivalent back-conversion. Any dogecoin which is next to a do-geode will change into a do-geode (this is also a chain-reaction). So, depending on gameplay... you might have a large "block" of dogecoin you're harvesting, but if a do-geode somehow gets next to one of those dogecoin, then a chain reaction starts and you see them all change to do-geodes. This isn't a huge disaster; you can always mine them again... just at the cost of a bit of time. Visually it looks good.
-
A bit of a focus for animations this update. I've worked on the player animation transitions - most noticeable when you walk up (facing away) and when you let go there's a pause and then a rotation back to the default facing-forward frame. All directions end up on that frame, transitioning in different ways. It's made a bit of a difference I think - things feel less "clunky". I've also put just a little vertical motion on the walk. The puff of dust now also appears when you walk into a square that has dirt. Previously it appeared in the square you left (still does), but adding to the new square too is subtle, but works.
As an aside, the slergs don't actually chase dogecoin - even though it seems they're pretty good at it. They are just predominantly trying to move in the same direction with occasional random turns. And rarely they will push through dirt if they can't move ahead. And failing everything they just head/tail switch and reverse. But these together make them a real pain and they are quite effective at grabbing dogecoin that you're mining.
-
3
-
-
13 hours ago, TIX said:
stripe coloring is challenging but you have made some great choices (a grey gradient is missing) !
All colours are available. As noted, they are selected randomly. I simply showed a subset in the earlier image, running the game a dozen times or so and grabbing a screenshot. Grey gradient is there - all of the 16 variants of palette hue are available. Random.
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Wen hop? The Search for Planet X
in Atari 2600
Posted
Slow-motion study (5% speed) of the transition from pebbles to dogeodes. It's pretty smooth, even under such scrutiny. In the video there are
threefour transitions.