Andrew Davie
-
Posts
5,982 -
Joined
-
Last visited
-
Days Won
8
Content Type
Profiles
Forums
Blogs
Gallery
Events
Store
Posts posted by Andrew Davie
-
-
I haven't posted many videos of the normal chronocolour display - my preference being the interleaved (iCC) version. Here's a video update of how things are looking using normal chronocolour. It's not too bad, actually. I put a slerg in, and made a minor change to the grinders; now there's a bit of a chance of a grinder knocking something that's sitting on top of it off to the side.
-
3
-
-
Does anyone wonder how all of this is done?
Let's look at the grinders. There are two "characters in the grinder, each being 5 pixels wide and 30 scanlines deep. Those scanlines being grouped into "trixels" 3 scanlines high of the iCC triplet-colour format. But how, if the game frame rate is about 10Hz... do the things on screen animate at 60Hz? Well, there's an inbuilt "auto-animate" capability. Each character has an innate "type". For example, the two grinder characters are "TYPE_GRINDER". This type is retrieved by a lookup in a table called "CharToType[...]". So, every single one (of the 120 different) characters in the character set is associated with a type. There are currently 38 different types. But, back to the grinders as an example...
So every frame the code calls an "animate" subroutine. This subroutine runs a tiny little "program" for each of the types. There's a table called "animate" which (for each type) points to a little animation program, or contains 0. If 0, then nothing's done. But if the entry points to an animation program, then the animate function "executes" the program. Here's a sample "program" for one of the types...static const char AnimateGrinder[] = { CH_GRINDER_0, 12, CH_GRINDER_1, 12, ANIM_LOOP, };
So, what's happening here? Well, the first line is saying "display the character called CH_GRINDER_0 for 12 frames". And the next line is similar for the character called CH_GRINDER_1. And the ANIM_LOOP is a command to restart this little animation program from the beginning. Pretty simple. So let's get to the screen draw, which happens every frame.... When the draw grabs a character number to draw (e.g., a CH_GRINDER_0) from the board (the 40 x 22 grid of what's what that you move around), it doesn't actually draw the character CH_GRINDER_0. What it does is look up the type of the character (which is TYPE_GRINDER), and then it looks at the animation program (if non-zero) for that type, and retrieves the character to draw from the current animation pointer. So what will happen is that anything in the board containing CH_GRINDER_0 (or, for that matter, any character which resolves to TYPE_GRINDER) will go through that animation program and ***every single character on the screen of that type will display the same character from the animation program for that type***. This is a limitation but also a blessing. It means you can't individually animate characters which are the same type, but it also means we have essentially free animation for everything of that type, at a frame rate of 60Hz. Another way of looking at this is that these simple automatic animations are inbuilt into the 60Hz draw system and cost almost zero processing time to do.
There are independent systems running at 10Hz which allow you to animate things independently (that is, individual cells in the 40x22 board can make their own "decisions" if the everything-of-the-same-type-all-at-once system is not useful). An example of those other systems is the lava, the water, boulders, all the typical gameplay stuff. Things that use the automatic system are obvious in the animation table, shown below...const char *const AnimateBase[TYPE_MAX] = { // indexed by object TYPE (def: ObjectType in attribute.h) // =0 if object does not auto-animate // Note that the type number is an ID, not ordinal. That's because the continuity may // be compromised by the conditional compilation. Beware. 0, // 00 TYPE_SPACE, 0, // 01 TYPE_DIRT, 0, // 02 TYPE_BRICKWALL, 0, // 03 TYPE_OUTBOX_PRE, AnimFlashOut, // 04 TYPE_OUTBOX, 0, // 05 TYPE_STEELWALL, 0, // 06 TYPE_BOULDER, AnimPulseDoge, // 07 TYPE_DOGE, 0, // 08 TYPE_HUSK_PRE, AnimRockford, // 09 TYPE_HUSK, 0, // 10 TYPE_PEBBLE1, 0, // 11 TYPE_PEBBLE2, AnimGrab, // 12 TYPE_GRAB, 0, // 13 TYPE_DUST_0, 0, // 14 TYPE_DOGE_FALLING, 0, // 15 TYPE_BOULDER_FALLING, 0, // 16 TYPE_DUST_ROCK, 0, // 17 TYPE_DOGE_CONVERT, AnimSwitch, // 18 TYPE_SWITCH, 0, // 19 TYPE_PUSHER, 0, // 20 TYPE_PUSHER_VERT, 0, // 21 TYPE_WYRM, 0, // 22 TYPE_BOULDER_DOGE, 0, // 23 TYPE_BOULDER_DOGE_FALLING, AnimConglomerateMid, // 24 TYPE_BOULDER_DOGE_CRITICAL, 0, // 25 TYPE_LAVA, 0, // 26 TYPE_PEBBLE_BOULDER, AnimateGravity, // 27 TYPE_FLIP_GRAVITY, 0, // 28 TYPE_BLOCK 0, // 29 TYPE_PACMAN_DOT AnimateGrinder, // 30 TYPE_GRINDER 0, // 31 TYPE_HUB 0, // 32 TYPE_WATER AnimateWaterFlow, // 33 TYPE_WATERFLOW 0, // 34 TYPE_TAP 0, // 35 TYPE_OUTLET AnimateGrinder1, // 36 TYPE_GRINDER1 };
In summary, every time I add a new "thing" that does different stuff, I add a new TYPE to the system and I also add new characters to the character set.
Another really interesting thing is that each TYPE of object has a bunch of attribute flags. The attributes describe how objects behave -- do they participate in explosions, are they treated as blank space, do they have the awesome "rounded corners" of the dirt (and I should explain how that's done sometime - remind me), etc., etc. Here's the rather large and impressive attribute table...
const int Attribute[TYPE_MAX] = { // see attribute.h "ObjectType" #define _ 0 // LAV = Object immediately turns into lava bubbles when below lava line // QUI = Quiet object. No noise genrate when things fall onto it // HRD = Hard. Boulders create dust when falling onto // ACT = Active object that must be processed every frame // BNG Explodes in lava // CNR = surrounding space fills in corner // PAD = do the corner padding for this creature type // SHV = the pushers can push this object if next square blank // MLT = melts when in lava -> CH_LAVA_00 // PUL = object pulled by lassoo // // PH1 every nth frame processes... // PH2 // PH4 // GND object can be "grinded" // 21 // 22 // 31 30 29 28 27 26 25 24 23 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 // CNR PAD SHV BOU DGE MLT DIS PUL PH* MIN DRP RKF LAV QUI XIT HRD SQB BNG GRB DRT SPC PER XPD ROL // ---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ _ |PAD| _ | _ | _ | _ |DIS| _ | _ | _ | _ | _ | _ | _ | _ |RKF|LAV|QUI| _ | _ | _ | _ | _ | _ | _ |SPC|PER|XPD| _ | _ , // 00 TYPE_SPACE, CNR| _ | _ | _ | _ | _ |DIS| _ | _ | _ | _ | _ | _ | _ |DRP| _ |LAV| _ | _ | _ | _ | _ | _ | _ |DRT| _ |PER|XPD| _ | _ , // 01 TYPE_DIRT, _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ |DRP| _ | _ | _ | _ |HRD| _ | _ |BNG| _ | _ | _ | _ |XPD| _ |ROL , // 02 TYPE_BRICKWALL, _ | _ | _ | _ | _ | _ | _ | _ |PH1| _ | _ | _ | _ | _ | _ | _ | _ | _ | _ |HRD| _ | _ | _ | _ | _ | _ | _ | _ | _ | _ , // 03 TYPE_OUTBOX_PRE, _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ |XIT| _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ , // 04 TYPE_OUTBOX, CNR| _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ |DRP| _ | _ | _ | _ |HRD| _ | _ | _ | _ | _ | _ | _ | _ | _ | _ , // 05 TYPE_STEELWALL, _ |PAD|SHV|BOU| _ | _ | _ |PUL|PH2| _ |GND| _ | _ |MIN| _ | _ | _ | _ | _ |HRD| _ | _ |BNG| _ | _ | _ | _ |XPD| _ |ROL , // 06 TYPE_BOULDER, _ |PAD|SHV| _ | _ |MLT| _ |PUL|PH2| _ |GND| _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ |BNG|GRB| _ | _ | _ |XPD| _ |ROL , // 07 TYPE_DOGE, _ | _ | _ | _ | _ | _ | _ | _ |PH1| _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ , // 08 TYPE_HUSK_PRE, _ |PAD| _ | _ | _ | _ | _ | _ |PH1| _ | _ | _ | _ | _ | _ |RKF| _ |QUI| _ | _ |SQB| _ | _ | _ | _ | _ | _ |XPD| _ | _ , // 09 TYPE_HUSK, CNR| _ | _ | _ | _ | _ |DIS| _ |PH4| _ | _ | _ | _ | _ |DRP| _ |LAV| _ | _ | _ | _ | _ | _ | _ |DRT| _ |PER|XPD| _ | _ , // 10 TYPE_PEBBLE1, CNR| _ | _ | _ | _ | _ |DIS| _ |PH4| _ | _ | _ | _ | _ |DRP| _ |LAV| _ | _ | _ | _ | _ | _ | _ |DRT| _ |PER|XPD| _ | _ , // 11 TYPE_PEBBLE2, _ |PAD|SHV| _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ |RKF|LAV|QUI| _ | _ | _ | _ | _ | _ | _ |SPC|PER|XPD| _ | _ , // 12 TYPE_GRAB, _ |PAD| _ | _ | _ | _ | _ | _ |PH2| _ | _ | _ | _ | _ | _ |RKF| _ |QUI| _ | _ | _ | _ | _ | _ | _ |SPC|PER|XPD| _ | _ , // 13 TYPE_DUST_0, _ |PAD| _ | _ | _ | _ | _ | _ |PH2| _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ |BNG| _ | _ | _ | _ |XPD| _ |ROL , // 14 TYPE_DOGE_FALLING, _ |PAD| _ | _ | _ | _ | _ | _ |PH2| _ | _ | _ | _ | _ | _ | _ | _ | _ | _ |HRD| _ | _ |BNG| _ | _ | _ | _ |XPD| _ | _ , // 15 TYPE_BOULDER_FALLING, _ |PAD| _ | _ | _ |MLT| _ | _ |PH2| _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ |BNG| _ | _ | _ | _ |XPD| _ | _ , // 16 TYPE_DUST_ROCK, _ |PAD| _ | _ | _ |MLT| _ | _ |PH2| _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ |BNG| _ | _ | _ | _ |XPD| _ |ROL , // 17 TYPE_DOGE_CONVERT, _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ |GRB| _ | _ | _ | _ | _ | _ , // 18 TYPE_SWITCH, _ | _ | _ | _ | _ | _ | _ | _ |PH1|PIP| _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ |ROL , // 19 TYPE_PUSHER, _ | _ | _ | _ | _ | _ | _ | _ |PH1|PIP| _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ , // 20 TYPE_PUSHER_VERT, _ |PAD| _ | _ | _ | _ | _ | _ |PH1| _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ , // 21 TYPE_WYRM, _ |PAD|SHV|BOU|DGE|MLT| _ |PUL|PH2| _ |GND| _ | _ |MIN| _ | _ | _ | _ | _ |HRD| _ | _ |BNG| _ | _ | _ | _ |XPD| _ |ROL , // 22 TYPE_BOULDER_DOGE, _ |PAD| _ | _ | _ | _ | _ | _ |PH2| _ | _ | _ | _ | _ | _ | _ | _ | _ | _ |HRD| _ | _ |BNG| _ | _ | _ | _ |XPD| _ | _ , // 23 TYPE_BOULDER_DOGE_FALLING, _ |PAD|SHV|BOU|DGE| _ | _ | _ |PH2| _ | _ | _ | _ |MIN| _ | _ | _ | _ | _ |HRD| _ | _ |BNG| _ | _ | _ | _ |XPD| _ |ROL , // 24 TYPE_BOULDER_DOGE_CRITICAL, _ | _ | _ | _ | _ | _ | _ | _ |PH1| _ | _ | _ | _ | _ | _ |RKF| _ | _ | _ | _ | _ | _ | _ | _ | _ |SPC| _ | _ | _ | _ , // 25 TYPE_LAVA, _ |PAD| _ | _ | _ | _ |DIS| _ |PH4| _ | _ | _ | _ | _ | _ |RKF| _ | _ | _ | _ | _ | _ |BNG| _ | _ | _ |PER|XPD| _ | _ , // 26 TYPE_PEBBLE_BOULDER, _ | _ | _ | _ | _ | _ | _ | _ |PH1| _ | _ | _ | _ | _ | _ |RKF| _ | _ | _ | _ | _ | _ |BNG| _ |DRT| _ |PER|XPD| _ | _ , // 27 TYPE_FLIP_GRAVITY _ | _ | _ | _ | _ | _ | _ | _ |PH1| _ | _ | _ | _ | _ | _ | _ | _ | _ | _ |HRD| _ | _ | _ | _ | _ | _ | _ | _ | _ | _ , // 29 TYPE_BLOCK _ | _ | _ | _ | _ | _ | _ | _ |PH1| _ | _ | _ | _ | _ | _ | _ | _ | _ | _ |HRD| _ | _ | _ | _ | _ | _ | _ | _ | _ | _ , // 30 TYPE_BLOCK _ |PAD| _ | _ | _ | _ | _ | _ |PH4| _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ |ROL , // 31 TYPE_GRINDER _ | _ | _ | _ | _ | _ | _ | _ |PH4|PIP| _ | _ | _ | _ |DRP| _ | _ | _ | _ |HRD| _ | _ | _ | _ | _ | _ | _ | _ | _ | _ , // 32 TYPE_HUB _ | _ | _ | _ | _ | _ | _ | _ |PH1| _ | _ | _ | _ | _ | _ |RKF| _ | _ | _ | _ | _ | _ | _ | _ | _ |SPC| _ |XPD| _ | _ , // 33 TYPE_WATER _ | _ | _ | _ | _ | _ |DIS| _ |PH1| _ | _ | _ | _ | _ | _ |RKF| _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ |XPD| _ | _ , // 34 TYPE_WATERFLOW _ |PAD| _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ , // 35 TYPE_TAP _ | _ | _ | _ | _ | _ | _ | _ |PH4|PIP| _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ , // 36 TYPE_OUTLET _ |PAD| _ | _ | _ | _ | _ | _ |PH4| _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ |ROL , // 37 TYPE_GRINDER1 // ---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ };
So, in the main processing loop... I can quickly determine what things an object needs to do without a whole bunch of conditional code. I simply load the character from the board, convert it to a type, and look up the attribute I'm interested for that type... for example, this code is used by the grinder to determine if the character above the grinder should be destroyed...
if (Attribute[CharToType[up]] & ATT_GRIND) {
... we don't need lots of conditionals (is it a boulder, is it dogecoin, dogeode, or any other of the 120 characters)... just a single lookup for everything.
That's it for now.-
5
-
-
Things were running slow. Mainly because of inefficiencies in processing lava. I've cleaned all that up, and addressed the speed issues. Also a few gameplay fixes here and there. It's all super-busy here; I'm just pushing the systems at load to make sure all is running properly. Seems OK.
-
4
-
-
It's like one of those image-ident / captcha things I SO HATE. "please select all the squares with Wen Hop"
Put all together like that -- pretty cool for a '2600 game.
-
1
-
-
At the end of watching a YouTube video, the algorithm feeds to me a grid of potential other videos I might like to watch, in the form of thumbnails. The one it presented to me today was pretty interesting - a grid almost entirely Wen Hop screens. I do like the effect of seeing these all together!
-
1
-
3
-
-
Prelim grinding action drop dogeodes on 'em -- and also when you bump into 'em.
-
2
-
-
First appearance of the grinder. Graphics by @TIX.
Doesn't do anything yet - just checking out the visuals/animation.-
4
-
-
I'll take this recent comment, left on one of my YouTube Wen Hop videos, as an unintended compliment...
-
3
-
6
-
-
11 hours ago, TIX said:
Is something like this to your liking ?
I kept it simple with 1 frame only, but I think it's working.
I reproduced the faucet by eye so it might be off.. I've also done an alternative faucet design to alleviate the top distance..
look to the right for another element you can add to your collection..
it's
the crusher(ok the crusher is already taken), rotating cogs that smash to powder everything that falls through them, including our hero 😲
Very nice; TY. I will put these in soon.
Let's call the one on the right "the grinder". Looks great.
-
1
-
-
Just now, TIX said:
for me, this is a stress free hobby,
it not necessarily have to lead to a finished game, so I may do some more animations or not, it's all for fun 😄
Your animations have given a whole new life/look-feel to it.
Things that I could use - a "reaching-over a long way" kind of frame/animation for turning on/off the tap.
I still have to think of a way to "turn on the tap below you", too. At the moment it's horrible because the player is a very long way from the tap when he's above it. I could extend the tap upwards but it wouldn't look the greatest.
-
1
-
-
3 hours ago, TIX said:
love the progress,
TY. I live for feedback. Good and bad.
3 hours ago, TIX said:as I see it, you have more than enough material to span several games 😀
Yes, maybe. I want to have a vast pool of things to choose from when I have to whittle things down.
3 hours ago, TIX said:The latest binary (22_52_52) crashes Stella for me..
TY for the report. Interesting one. I think I may have found/fixed this. See attached binary. If it's fixed, I know kinda what was happening but not exactly why. It's to do with the drawing of the tool "menu" going off the screen boundary. Shouldn't have happened; I've not looked too closely. Will investigate, but as noted I think the attached will be OK.
3 hours ago, TIX said:I really love the water effects,
the new faucets and running water work great (how about an object that floats ?)
Objects other than the player are restricted to " character" boundaries -- that is, they can only move in chunks of 5 pixels horizontally and 30 pixels vertically. Pretty clunky, which is not going to work for "floating" objects. I'd have to, instead, use an overlay draw system -- like the butterflies on the title screen of BoulderDash#2... which I don't really have processing time for. Possible, but not going to happen here. The other major issue with this is freeform movement comes with additional complexity of handling collision detection with things in the background - a whole different kettle of fish, so to speak. So, not likely to happen.
3 hours ago, TIX said:I'm currently recovering from covid, but I'm thinking some swimming animation will compliment it further, if there is space !?
I hope you are feeling better soon. Space is tight - about 1K left and I have all sorts of things that I want in the game currently disabled. So in reality it's oversize for 32K which means at some point I have to convert to CDFJ+. and at that point space won't be an issue at all - I can keep evertyhing, add a gazillion frames of animation.... sky's the limit. The only real limitation would be my ability to ever finish such a game. Finishing stuff isn't my strong suite.
-
Perhaps my updates are too frequent. It seems like a lot of work for only a few views. On the one had I like keeping things rolling and doing lots of small little things that I can share (even though some of them are actually quite major)... on the other hand it seems like I'm working with an audience of just one or two. Thing have been really zooming along recently, trying out all sorts of ideas and now it's a long long way from Boulder Dash. At least I think so. And more to come.
I was thinking about how to work thxe controls - at the moment you just walk in the direction you want, and if you hit a mine-able object then out comes the old pickaxe and away you go. No thinking required, really... and for me it seems to be working really well. That leaves the button - and in this version you're "laying pipe" whenever you press the button. It's a bit buggy, but essentially just hold button down and move, and there will be pipe left wherever you go. There are complexities regarding where to join up pipe, etc -- solvable but what's there is just a what-if so I'm happy enough with it.
Well, let's say that's what the button does - lay pipe. So that doesn't leave much of any room for any other actions. Many can be inferred by context, depending on what you're pressing against, for example. But I have plans for more "actions"... and so I've introduced a "tool menu". The idea here is that you'll have a bunch of "tools" and you first double-click to bring up the visual menu/icon lower right -- and then you choose which tool you want, click the button, and the tool you have selected is on the joystick button. In this binary (and the video), it's a mockup and doesn't actually change anything - but the icon represents a plumber's pipe wrench... hence laying pipe.
Additional tools could include a bomb, the lasso, a gun, a call button to call your ship down from orbit, etc.
So, that's the update for today. Remember -- button + move lays pipe, and double-click brings up your tool "menu".
-
5
-
-
What else would you expect from Wen Hop, than "laying pipe" being one of the things you have to do.
Careful, or I'll put chickens in that you have to catch with the lasso, and thus you'll also have to be "pulling chicks"
Anyhow, here's a bit of an experiment to see if "laying pipe" would work. I think it does. I could build this into game mechanics.
-
2
-
-
Another study in pipe/water animation. This one is OK - surprisingly it doesn't seem to matter much that the water isn't blue... it's more the animation and impression of movement that matters. This one is OK.
Last for the day.
-
2
-
-
An experiment/study in alternate water animation...
-
Last for today...
The piping now has a functional tap, and you can turn it on and off to start/stop the flow of water. In this video I just muck around a bit, looking at the various visuals and playing with the tap. I have the initial stream falling in slow motion just for checking out the operation here - it will be much faster in actual play. This all leads to the idea of a network of pipes with on/off junctions, and you need to feed the water to a preset place. Completely new gameplay opening up. Hmmmh.
The controls aren't debounced, so very touchy. Very early days for this, but you can play with turning the tap on and off. The water below will not start rising until you turn on the tap for the first time. It keeps going after that, even if you turn the tap off -- will fix later. Still deciding if this is "good" - but at least it's totally different. A few things of note; the "hub" beneath the tap now shows the on/off status of that hub. I envisage a network of piping and hubs and you need to run around and turn on/off taps to get the pathway for water to a particular place. Might not work, as you can't cross pipes. But we shall see. The tap also shows the on/off state, of course.
-
1
-
-
So, based on the observations above... I wanted a feeder pipe and flowing water.
First appearance of a feeder pipe, pumping water into the mine. I can't change the colours from what the mine colours are, but it doesn't look too terrible. Kinda. This was just a prelim "what if" -- I can change the visuals of the falling water to be a bit less awful. Perhaps put some spray, etc. The idea here is that we'll have a switch/tap on top of the pipe junction, or maybe on the pipe... where you can turn on the water flow. You might have to solve puzzles to get to it. For now, I'm re-using components so when the water level gets above the pipe exit, the pipe suddenly thinks it's a crusher! Easy to fix; this was just a quick 'n dirty.
-
1
-
-
A note on the observed differences between gameplay under lava, vs. under water. Both lava and water dissolve blocks of dirt, causing anything above the dirt to fall downwards into the water. However lava also *melts* some objects, such as dogecoin and dogeodes. This melting process is slower and random, so eventually under lava most objects will just disappear. In water, the objects remain, allowing you to build vast hoards of dogecoin to collect. This will balance of course by some sort of oxygen limit. My point, though, is that they are both *significantly* different in feel/gameplay.
Because water "concentrates" dogecoin at the bottom of the screen - you effectively get access to all the coin on the planet just by going back and forth at the very bottom, underwater... water planets are a huge bonus for collecting doge. So it's going to be useful having some sort of valve or piping where water can be introduced to a planet to help you mine.
-
More work on the underwater stuff. Note the bubbles and breathing
Came out pretty good. Not sure about the wavy-type lines, though. Edit: I dumped 'em.
-
1
-
-
14 hours ago, 32shot said:
That's right, i saw your post, along with the bus stuffing experiments as i was looking for some info... really interesting stuff!
Clearly we're talking about hardware and tech that is close to half a century old, yet i can't help wondering is this normal behaviour for a stock, unmodded VCS and no hairdryer involved?
Thanks a lot for your input!
Well, it's analogue hardware being pushed to the very limits of exact timing. There are analog components involved which are going to be affected in "performance" by variations in manufacture/materials and temperature. I'm very much not surprised a hairdryer could trigger something that was "right on the edge" in the first place. Happy to have found/demonstrated it. So yes, it's normal behaviour. But mostly software doesn't push things right to the edge so it's never seen. That's my view on what's up.
-
The beginnings of underwater stuff.
-
6
-
-
I assume you refer to the experiments I did with one machine which showed sprite glitching based on TIA temperatures? If not, I will dig up the post for you.
-
OK, so straight up front - this binary will crash occasionally. The crash is in the draw loop when it's doing an illegal access -- so basically I have put an illegal character on the screen, and it accesses wrong memory trying to draw it. Not sure why yet, but I do often do several passes of optimisations and I've borked something in there. Not a big issue. So it will crash. Known problem.
The new scheduler is now working smoothly. It operates by running the board scan at a minimum of 4 frames/scan and the objects can choose to run every frame, every 2nd frame, or every 4th. This allows the player to be responsive by initating a move every frame, but moving over 2 frame timing. Complex to describe, but essentially variable speeds for the objects to help with responsiveness and relative timing. This video looks pretty "tight". Note the crushers have new graphics and are going super-quick.
It's actually pretty slick; I'm quite happy with how responsive things feel and how the whole thing feels busy but not clunky.
Note the new details in the crusher graphics; pads on the end of the crushers and a neat center-part which works well.
-
3
-
-
Part of the internals of Wen Hop is the 'scheduler' which essentially processes everything that does stuff. The old version was kind of limited to having everything process at the same rate - let's say 10fps. But the new one I'm showing here is a bit more sophisticated, and allows objects on the screen to schedule at different rates. The details are a bit limiting, but it does for example allow the crushers to be fast, and the player relatively slow. Work in progress, so this looks horrid at the moment (at least in terms of jerky player movement).... but it shows promise with the extra speed of everything.
So there's this process that "scans" the board -- all 40 x 22 objects. This scanning simply sweeps through the 'squares' and looks at what object is in that square, and processes the appropriate code (e.g., falling rock). That's how things have worked for yonks. This video although rough, shows a slightly different method. In the old version I processed everything on the board and then WAITED until a certain time had passed - in order to establish a constant frame rate.
This prelim new scheduler does things a bit differently. It constantly sweeps through the board and does NOT wait for constant rate when it's done. It instead immediately starts a new sweep. So everything is running fast at the moment -- look for example at the crushers. They are demonstrating "top speed". But I have now based all of this around a "6-cycle" idea -- where some objects process every cycle of the sweep (so they're fast), some every 2 cycles, so half as fast, some every 3 cycles (so um... slower still) and some every 6 cycles. I chose 6 because it can be divided into even segments of 1, 2, 3 and 6 - giving me effectively 4 different 'speeds' for objects to be processed on the board. So the player - I can have him operating at "2" which means every two sweeps he does his stuff. When I get this working properly you won't notice he's only processing every 2, because everything is running faster so he'll actually appear to be the same speed. But but but.... he's no longer running the same speed as the other things around him. The other things are proceesing speed "1" at the moment, so they are twice as quick. Effectively, say, rocks fall a lot faster than you walk - and you may argue this is a bad thing. Could be. Maybe. maybe not. But I can tailor this now. So objects that don't do much can run only every 6 sweeps - and thus they cost 1/6 of the processing time, overall -- so the system has more ability to run faster. No need to process pebbles, for example, every single game loop. 1/6 is fine. Likewise, things which are fairly static and only do minor checks/changes... probably don't need to move fast.
I'm still testing this out - asynchronous movement of objects. Its slightly different (for example when you move out of a square, a rock can fall onto it 1/2 of your movement faster than it would). But that actually looks pretty good to my eye.
So, I might continue refining this and see where it leads. It does have one possible disadvantage - it kind of does suffer from the possibility of the ACTUAL physical time required to sweep the board (in terms of TV frames) being inconsistent - maybe 2 frames one time, and then 1 the next. and 3 the next. That's what the original "wait" was fixing and making it all constant-speed. Maybe I'll reintroduce a lower "wait" inside of the new 1-2-3-6 scheduler. All part of the fun in making systems work.Have to say, though., in the middle part of that video things are awesomly complex/hectic.
-
3
-
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
Sorry for the delay. Thanks for the suggestions/ideas.
Thought about that. Because of the animation in this, it's actually quite expensive to define a whole block of duplicate characters to get that effect. There are 3 characters in the animation, each 30 bytes + table pointers (3 ints) + new char type entries (3 bytes) so maybe 120 bytes given everything I'd need to do for this. It's still a possibility, but maybe down the track.
The impassable wall is workable. As it stands the water is already impassable. I could have a secret entrance in one of the impassable waterfalls, for example... like a cave you need to get into but can't. I'll have a think. In the latest version I hope it looks more water-like. It's not easy to get good looking animations in 5 pixels wide
Yes. Bombs are a definite candiate for a tool you could have/use. If we had a huge block of rock, for example (kind of like the conglomerate of dogeoids slot together to form one mass. well perhaps we could have a mass of boulder which is essentially un-mineable. Or it takes forever. I could make the rock take 10 digs to break (one of them) whereas the dogeodes take 3 and you "mine" the whole lot of them in one go. Breaking through a rock barrier could be extremely tedious. So you use a bomb. I already have screen shake which would look good with that. Thanks for the ideas on the bomb. I'll remember this and come back to it.
I'm a one-button fan and basically too lazy to learn other interface/hardware. It's going to be one-button and I have no plans/intent to do anything new there.
That's a pretty neat idea. I'll get around to doing that sometime, for sure.