Wen hop? The Search for Planet X

[Prizrak]

So you planning on moving beyond 32k? Crap, I'll need to trade my Harmony in for an Encore then. 😥

[+Andrew Davie]

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.

[+Andrew Davie]

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!

 

 

 

WenHop_20230324@19_58_13.bin

[+Andrew Davie]

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.

 

 

WenHop_20230325@15_51_59.bin

[TIX]

Lava effects are looking great !

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 !

.

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..

 

Edited March 25, 2023 by TIX

[+Andrew Davie]

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

 

 

WenHop_20230325@22_00_40.bin

[+Andrew Davie]

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:

 

 

[+Andrew Davie]

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.

 

[+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.

 

 

WenHop_20230326@17_53_44.bin

[TIX]

21 hours ago, Andrew Davie said:

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..

 

I have already arranged the standard 8x30 sprites to a grid (1),

but what about the frames that are wider than 8 pixels ? how do you prefer for them to be arranged ?

Till now I was aligning them to the left (2)..

Is the 3rd option what you need ??

 

 

 

Edited March 26, 2023 by TIX

[+Andrew Davie]

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 three four transitions.

 

 

[+Andrew Davie]

5 minutes ago, TIX said:

 

I have already arranged the standard 8x30 sprites to a grid (1),

but what about the frames that are wider than 8 pixels ? how do you prefer for them to be arranged ?

Till now I was aligning them to the left (2)..

Is the 3rd option what you need ??

 

 

 

 

TY.  Everything aligned to 16x30 would be the best option for me!

 

[Dionoid]

On 3/22/2023 at 11:28 AM, Andrew Davie said:

I have not added a drill. But what happens now is if you are moving into dirt, you move at half speed.

Yes, that indeed results in different dynamics when navigating through the level!

On 3/22/2023 at 11:28 AM, Andrew Davie said:

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.

Excellent change! These simplified physics basically stops me getting reminded of BD. Also, I can now dig away dirt below rocks without the fear of some boulder unexpectedly bouncing off another boulder and crushing me, which will make the game less frustrating for new players that don't have experience with BD.

 

 

[TIX]

Latest sheet (v6), including new 4/way digging,

everything is aligned to 16x30, I have also deleted the "left facing" frames.

1. standing still
2. running up
3. running to the right
4. running down
5. digging to the right
6. digging up
7. digging down
8. idle animation 1 (checking watch)
9. idle animation 2 (jump in place)
10. idle animation 3 (impatient)
11. idle animation 4 (jump and wave)
12. idle animation 5 (stranded crying
13. full rotation
14. crashed

   

 

Edited March 26, 2023 by TIX

[+Propane13]

Hello!

 

I really like the idea of taking the time to play with different concepts and see what sticks.  And, I think there have definitely been successes to this approach as opposed to trying to get a game finalized and over a goal line quickly.  For example, as you said, the crushers are a surprisingly big hit.

 

With the idea of play-testing being the main driving factor, I've been trying to think a bit more of "differentiators" that could take the game-play concept and apply it more towards a space theme instead of just digging / mining.  I was curious if some of these would be possible and/or fun to implement:

• A world with upside-down gravity
• Gravity machines.  If you touch them, the gravity either switches 180 degrees, but I think it could be really fun if they switched by 90 degrees.  This could lead to some interesting rock manipulation game-play behaviors, and lead to interesting dodging and manipulation strategies.
• Setting underground bombs, then running away quickly before they ignite and slowly "nuke" a radius of dirt/gems/crushers/everything
• Lost miners to save, trapped from terraforming projects that failed
• Terraforming stations (above ground) that slowly turn the dirt to greenery, plants, and eventually trees that grow up (might be an interesting way to replenish Oxygen on planets where it is low).  This could also be interesting in anti-gravity worlds.
• Liquids that turn into impassible ice as the temperature drops.

I'm not sure if any of these would be interesting to implement or are potentially already on the roadmap, but I think they could have potential to be a lot of fun while adding some story elements.

[+Andrew Davie]

Here is a prelim version with some of the new frames from @TIX.

In particular, the digging up and digging down are now available actions. Looks great! TY.

VIDEO has a superfluous "facing forward" animation in the middle there -- but fixed in attached binary.

 

 

 

WenHop_20230327@19_05_23.bin

[+Andrew Davie]

@TIX just updated binary to fix animation glitch in video

[TIX]

Looking great Andrew,

 

there seems to be a problem with the "dig down" animation,

he is supposed to jump while digging, but in game he actually goes lower..

.

.

slightly modified digging down animation (v7)

 

[+Andrew Davie]

2 hours ago, TIX said:

Looking great Andrew,

 

there seems to be a problem with the "dig down" animation,

he is supposed to jump while digging, but in game he actually goes lower..

 

 

If we look at the source code for the graphics, like this example...

 

const unsigned char shape_FRAME_MINE_DOWN_1[] = {        // 32

    29,
    3, -5,

    SP( __XXXX__, ________, HMT0,HMT0 ), // 00
    SP( _XXXXXX_, ________, HMT0,HMT0 ), // 01
    SP( _XXXXXX_, ________, HMT0,HMT0 ), // 02
    SP( _XXXXXX_, ________, HMT1,HMT1 ), // 03
    SP( XXXXXXXX, ________, HMT1,HMT1 ), // 04
    SP( XX_X__XX, ________, HMT1,HMT1 ), // 05
    SP( XXX___XX, ________, HMT1,HMT1 ), // 06
    SP( X_X____X, ________, HMT1,HMT2 ), // 07
    SP( X______X, ________, HMT1,HMT2 ), // 08
    SP( X______X, ________, HMT2,HMT2 ), // 09
    SP( _X____X_, ________, HMT2,BDY1 ), // 10
    SP( _X____X_, ________, HMT2,BDY1 ), // 11
    SP( __XXXX__, ________, HMT2,BDY1 ), // 12
    SP( ________, ________, BDY1,BDY1 ), // 13
    SP( _XXXXXX_, ________, BDY0,BDY2 ), // 14
    SP( _XX___X_, ________, BDY1,BDY2 ), // 15
    SP( __XX_XX_, ________, BDY2,BDY2 ), // 16
    SP( __XX_XX_, ________, BDY2,BDY2 ), // 17
    SP( ___X_X__, ________, BDY2,BDY2 ), // 18
    SP( __X_X_X_, ________, BDY2,BDY2 ), // 19
    SP( _XXX_XXX, ________, BDY2,BDY2 ), // 20
    SP( XX_X_X_X, X_______, HMT1,HMT1 ), // 21
    SP( _X_____X, ________, HMT2,HMT2 ), // 22
    SP( ____X___, ________, BONE,BONE ), // 23
    SP( ____X___, ________, BONE,BONE ), // 24
    SP( ____X___, ________, BONE,BONE ), // 25
    SP( ____XX_X, ________, BONE,BONE ), // 26
    SP( ____XXX_, ________, BONE,BONE ), // 27
    SP( ___XX___, ________, BONE,BONE ), // 28
};

 

Those first 3 numbers - (29, 3, -5) - are metadata about the following frame.

 

The first gives the depth in scanlines;  note that this is not 30, for in fact the draw system can (now) draw frames of arbitrary height.  This is partially a space-saving measure, but also an enhancement of capability. Although I ask you to draw frames with a 30-high space... we could actually go to much more (for example, standing with the pick above head).  The 30 is/was the room available in the passageway and was a limitation of the system when you started the graphics design.

 

Every frame is drawn at a "position" on the screen.  When frames are animating, the actual position of the player is usually not changing; it's always at the same onscreen pixel, and the animation happens around it.  You have catered for this by animating within the frames, so the little jump you mention happens that way.  But I try to "pack" frames down to their smallest space, so when you have completely-blank lines at top or bottom of a frame... I have trimmed these away and only show the lines with actual data.  And that's where the next two numbers come into play.  They refer to the location in the frame that is the standardised reference position for that frame. Another way of saying this; the constant point on the ground under the center-of-gravity of the player frame.  In a space game, it would be the center-of-mass of the object about which the object rotates.  In any case, all frames have this.  This allows me to shift the contents of the frame left/right (within the frame) too, so that I can take advantage of the sprite colouring - shifting things so one part (like the pick) is in one of the 2 sprites, and the body/helmet is in the other... and thus they can be independently coloured.  If I shift the frame (any direction) within the graphics data, all I need to do is also shift that (x,y) offset representing that center of gravity/ground point.  The draw system takes account of this and always draws frames so that point is in the same place visually onscreen.

 

So, onwards to the fact that your frame isn't jumping when it should.  I could do this two ways;  I could simply adjust the center point on the frame so instead of being at the base of the feet... it is lower.  And then the frame would shift upwards.  This would mean that every instance/use of that frame would also shift up whenever displayed - which in this single-use-case frame is perfectly valid. But there's also another way... related to animations.

 

When I'm animating the player, he's actually following a very simple little animation program specifically for the action he's taking. Here's an example, being the very animation we're discussing - digging down....

 

const signed char AnimationMineDown[] = {

    ACTION_SFX, SFX_PICKAXE,
    ACTION_DOT, 1,12,
    FRAME_MINE_DOWN_1, 8,
    FRAME_MINE_DOWN_0, 5,
    FRAME_STAND, 5,
    ACTION_LOOP,
};

 

When the player starts mining down, this animation starts. It plays a sound effect (SFX_PICKAXE) and generates a bunch of those moving dot-effects at pixel offset x=1, y=12 relative to that aforementioned onscreen pixel position for the player.  That is, right at the point of the pickaxe relative to the frame itself.  ACTION_DOT generates 3 dots or so at that location of random speed and direction.

 

Then it comes to a frame - referenced as FRAME_MINE_DOWN_1 by name.  This frame is shown for 8 TV frames (at 60Hz, so 8/60tths of a second).  And when that one's done, it displays the other frame FRAME_MINE_DOWN_0 for 5/60ths of a second.  And then it displays the forward-facing stand frame for another 5/60th second.  And finally, this particular animation loops (restarts at the beginning with the SFX again) endlessly.  SO it's started and the digging down happens I don't need to do anything else, until I let the joystick go, at which point the appropriate "stop" animation is triggered.  For example, if you mine upwards, then the same stop animation for walking upwards is triggered... that is, a delayed rotation back to facing forward.

 

As an aside, because the frames are displayed for such a "long" time, it's best not to incorporate the schrapnel/dirt/sparks within frames themselves - it looks a bit odd - and I manually remove these and instead use the dynamic dots system for generating those effects.

 

So, within this animation system is also a movement system that allows me to manually position a frame by offsetting the player position from its current onscreen centerpoint.  It's called ACTION_POSITION and takes an (x,y) offset to temporarily apply to the next frame while it is being displayed.  So I could put the little jump in there with something like ACTION_POSITION 0,-5 and that would also do the job.

 

The whole point being, though, that animation is typically not done in the frame data themselves, because it prevents reuse of that frame for other purposes (generally) and it takes precious graphics data space.  Instead, if I know about the offsets involved in the animation (x, y pixel movement) then I manually add these by either shifting that frame's centerpoint data, or apply the ACTION_POSITION to the animation(s) using that frame.  So, that's what I'll do (the former) and it will be ready for review next release.

 

 

 

[+Andrew Davie]

TY for the interesting ideas.

 

15 hours ago, Propane13 said:

 

• A world with upside-down gravity

 

Yes, it's going to be my mission in life to see what I can do with this one.  Maybe an upside-down world where you actually play the level upside-down too and everything falls upwards.  We shall see just how well the systems and gameplay will cope with the possibilities here.

 

15 hours ago, Propane13 said:

• Gravity machines.  If you touch them, the gravity either switches 180 degrees, but I think it could be really fun if they switched by 90 degrees.  This could lead to some interesting rock manipulation game-play behaviors, and lead to interesting dodging and manipulation strategies.

 

Agreed, although I'm pretty sure existing Boulder Dash games already do something along these lines. But in principle I do like playing with gravity and I'll see what i can do to modify the systems and then we can play with ideas.

 

15 hours ago, Propane13 said:

• Setting underground bombs, then running away quickly before they ignite and slowly "nuke" a radius of dirt/gems/crushers/everything

 

Yep, already something I have planned to include.

 

15 hours ago, Propane13 said:

• Lost miners to save, trapped from terraforming projects that failed

 

A neat idea, but on the other hand I do not currently have (nor plan to have) additional high-res sprites. There's currently ONLY the player.  So this one is unlikely.

 

15 hours ago, Propane13 said:

• Terraforming stations (above ground) that slowly turn the dirt to greenery, plants, and eventually trees that grow up (might be an interesting way to replenish Oxygen on planets where it is low).  This could also be interesting in anti-gravity worlds.

 

OK, remembering we have an extremely limited palette here, and that objects are flat-things you can't go behind. It would look odd having to get past a "tree" to have to move around its outline to get to the other side. In other words, you'd need to move up the trunk around the foilage, over the top, down the other side.  So obviously that wouldn't work so I'd have to start to allow you to go behind things. So I think this one needs a bit of modification/thought to see how the existing systems could be used. not saying no, just saying ... we'll see.

 

 

15 hours ago, Propane13 said:

• Liquids that turn into impassible ice as the temperature drops.

 

Maybe possible. Within the existing palette limitations, we could possible have an "ice" character.  Water and lava are a bit different because they use BG colour, and this does limit where things can be.  But I can see ice behaving a little differently, so let's keep this idea active and see if I can incorporate something along these lines later down the track.

 

 

 

15 hours ago, Propane13 said:

I'm not sure if any of these would be interesting to implement or are potentially already on the roadmap, but I think they could have potential to be a lot of fun while adding some story elements.

 

All great suggestions and thinking, and so thanks it's great to have new input and food for thought. I'll see what I can do.

[+Andrew Davie]

Started to look at the code changes required to implement "falling up" and I changed this...

 

        unsigned char *prev = this - 40;
        unsigned char *next = this + 40;

 

... to this...

 

        int gravity = -1;
        unsigned char *prev = this - 40 * gravity;
        unsigned char *next = this + 40 * gravity;

 

So, basically as I scan the board those two pointers (prev, next) were used in all the processing to point to the object above and object below the current object.  And although I've got some edge-cases to handle and I get lockup sometimes... the above was sufficient to make objects fall up...

 

 

 

In reality it's actually a little more complicated than changing those few lines.  For example, there's a "been processed this frame" flag which is set when things move, and the flag is cleared on the character ABOVE the currently being processed character.  So it's effectively auto-clearing as we go. Well, negative gravity invalidates that, and so things are cleared when they shouldn't be. I should probably process the board bottom-to-top in negative gravity scenarios or change how that flag is cleared.   There are a number of potential boundary issues here, so the above is just a bit of a proof-of-concept experiment to see what it would look like.

Binary included, but be warned it will lock up when you approach the top of screen, and who knows what else.

 

WARNING WARNING WARNING EXPERIMENTAL NEGATIVE GRAVITY TEST BINARY ONLY FULL OF BUGS!

 

 

WenHop_20230327@22_42_11.bin

[+Andrew Davie]

... and in one of those weird synergies the universe seems to throw at me every now and then, I thought I'd checkout a new TV show before retiring for the night. Don't know anything about it, but here's a screenshot from the first few seconds into the show, literally upside-down-world...

 

 

How strange it that!

 

 

 

[+Andrew Davie]

Also flipped the sprites and now it's a really weird feeling playing this "upside-down-world".

Not perfect, and only 10 minutes of work so far -- last for today though -- but this is a pretty cool/simple mod for a very different bit of gameplay.

To be honest, it's pretty bizarre to play and haven't wrapped my head around it yet.  But I kinda love it.  Thanks @Propane13!

 

 

WenHop_20230327@23_31_41.bin

[Prizrak]

Really love the ability to break the rocks in any directions now, feels natural for the game.

[+Propane13]

Thanks for the explanations behind the feasibility of implementing certain ideas.  It's kind of funny-- I am starting to forget that software is running on an actual 2600 and because of that, we still have to worry about things like sprite limitations. The fact that the engine has come this far is astounding.

 

The upside-down demo is brain-breaking, but a lot of fun.  Looks great!