Wen hop? The Search for Planet X

[Bomberman94]

Wow very impressive on a real Atari 2600 - even if colors are a bit  „off“ with a PAL machine ?

[+Andrew Davie]

26 minutes ago, Bomberman94 said:

Wow very impressive on a real Atari 2600 - even if colors are a bit  „off“ with a PAL machine ?

You still living in PAL land?  About time you moved to an NTSC country, for your chroma contentment

[+Andrew Davie]

31 minutes ago, Bomberman94 said:

Wow very impressive on a real Atari 2600 - even if colors are a bit  „off“ with a PAL machine ?

No idea how this will go, but give it a whiz and see...

 

 

spinningGlobes20220212PAL.bin

[Bomberman94]

6 hours ago, Andrew Davie said:

You still living in PAL land?  About time you moved to an NTSC country, for your chroma contentment

Yes, I’m working on it and try to convince my family ?

[Bomberman94]

On 2/11/2022 at 5:32 PM, Andrew Davie said:

No idea how this will go, but give it a whiz and see...

 

 

spinningGlobes20220212PAL.bin 32 kB · 9 downloads

Thx - works great on PAL machine ?

[+Andrew Davie]

I've started the tool to convert actual planet textures.  

 

 

That's a "standard format" texture of Io, a moon of Jupiter.  These projections are interesting, and a bit different to how I do things in the code. In the above example, what we see is as if we'd taken a photo of a horizontal cylinder.  Yes, we get a flat image, but in reality the texture at the top and bottom are curved around that cylinder, so we have distortion there, and you can just sort of make out some circular features at the bottom which have been "flattened". Maybe it's a bit easier to see with the moon...

 

 

So, in the current system, this cylindrical projection (that is, wrapping a "square" texture onto a cylinder, giving the curvature in one axis) is done on-the-fly as the planet is drawn. In code.  On the other hand, these textures have that wrapping "embedded" in the texture itself.  So it's a step you don't need to do, so to speak, when mapping onto the sphere.  Normally you'd go "oh, one less step, that's great".  But since my code is already doing that, we can't exactly use the textures as-is, as we'd get a double wrapping and it would look all wrong.

 

One option is to disable the horizontal-wrapping part in the code (I explained all this in an earlier post).  That would work, but it would mean that I could no longer draw things (in real time) on the texture and have them appear correctly onscreen.  That's a huge advantage of doing things on-the-fly.  I can't, for example, draw undistorted things onto the above textures and have them come out looking as if they're wrapped on a sphere.  Anything you add to the above textures must have that "wrapped around a horizontal cylinder" distortion applied.  Difficult.

 

So, I'm thinking that I'm going to convert these standard-form textures into an "unwrapped" form first, so that the draw system will then (in real time) apply the distortion back again.  Or maybe I'll just abandon the real-time component for that axis only, in which case I'd be able to use these textures directly.

 

So that's where my thinking is at.  Many of the available textures don't really have a lot of large features or contrasting details, and I'm a bit concerned that using them will end up just having fairly bland single-colour planets.  I guess sometimes you just gotta suck it and see, so that's what I'll do.  I've started writing the utility - python - which gives easy-to-use image processing code through the Pillow library.

I'll do that on and off over the next week or two. Meanwhile I've been doing even more optimisations with the super-cool Gopher2600 profiler of my code. I've saved absolutely heaps of processing time in many of my CDFJ programs. It's quite astounding what bits of the code actually are using up processing time.

 

 

 

 

 

 

 

[+SpiceWare]

42 minutes ago, Andrew Davie said:

That's a "standard format" texture of Io, a moon of Jupiter. 

 

Yep, known as equirectangular projection.

 

I work in the space industry and last week I committed a change set that included updated planet textures. For performance reasons the end user gets to set the max resolution they wish to use: 1K, 2K, 4K, and now 8K. 1K = 1024x512

 

Previously all the textures were available in 1K, with about half in 2K and a few in 4K.

 

Now all are available in 1K and 2K, most in 4K, and half of them in 8K.

 

Here's the textures I used for the update:

https://www.solarsystemscope.com/textures/

 

 

 

[+Andrew Davie]

On a different project I've been working on, I realised that true "iCC" (Interleaved ChronoColour) -- a display technique I use to interlace colours on a scanline and give (effectively) multi-colour playfields... didn't actually (as I originally thought) require triple the graphics data. I found an elegant way to just use the single shape definition.  Previously, the spinning globe demo used just plain-old ChronoColour, which used triplets of scanlines, each coloured successively red/green/blue (replace those three colours with anything, but the triplet is repeated down the sreen).  So. something that is "blue" would have an on pixel every 3 scanlines, wherever that pixel was horizontallly.  That all worked nicely, but the graphics had a sparse look.  Sort of, hard to describe.

But with iCC, instead of line triplets. now every single scanline has the red/green/blue multiplexed. so objects are much more solid -- at the cost (there's always a cost) of some artefacting in horizontal motion, and a bit of "shimmer" which will affect some more than others.  On a CRT it's usually fine.  Play with the phosphor setting on your emulator if it is a bit flickery for you.

 

Anyway, I do like iCC so here's the spinning globe demo using that display technique...  
F1 to go to next planet.  Use up/down/left/right to change planet zooming and spinning..

 

Here's a screenshot of the old ChronoColour version...

 

And here's the new iCC version...

 

 

 

 

spinningGlobes20221019.bin

[mika]

impressive!

 

Wen game?

[+Andrew Davie]

Here's a bugfix which shows the colours much more nicely.

I'm still trying to figure out that jagginess on the edges of vertical moving lines. In theory it shouldn't happen.

 

 

 

 

spinningGlobes20221022.bin

[+Propane13]

With the new algorithm / setup, is there room for players / missile graphics on those scanlines?

 

It could be really interesting to see a spaceship flying away from the globe as an animation.

[Keatah]

Liberator!

[+Andrew Davie]

8 hours ago, Propane13 said:

With the new algorithm / setup, is there room for players / missile graphics on those scanlines?

 

It could be really interesting to see a spaceship flying away from the globe as an animation.

I can display two independent sprites.

[+Andrew Davie]

Just a quick "colour bar" demo to show the available colours on the Earth, given the palette used.  8 colours total (including black), made up of three selectable colours and the remainder being a blend of those three.  The video essentially demonstrates all colours on each scanline, dynamically changing. My screen recording doesn't quite do this justice; looks a bit better to the naked eye.  And clearly the "sub-sampling" onto such a low-res destination (i.e., 40 pixels wide, max) looks terribly clunky when in slow movement. There's a threshold, though, where if the rotation speed is sufficient... it actually looks pretty good.

 

 

[+Andrew Davie]

OK, so back to this one. My code has diverged somewhat - although I tried to keep the wenhop stuff (lava, water) and the circle swipe etc., it appears that my conditional compiles were not enough to keep everyting working as I wanted, and essentially I'm going to have to spend much time "porting" from the original wenhop codebase into the BD codebase, removing all BD stuff and reimplementing WenHop stuff.  So that's gonna take some time. I want to do this because the BD systems are super-optimised and include mid-view, iCC, etc.  Also, the spinning planet stuff was diverged even from that - and thats something I definitely want to put in the game.  So I'm going to try and rewrite the planet spinner to work with an asymmetric mirrored playfield, which will allow it to work with the menu screen system.  Why do I wanna do that?  Well, because that will allow me to have a 6 -sprite routine over the top of the spinning globes. In glorious iCC.  That will allow me to have (for example), the planet spinning with a text overlay (in sprites) describing the planet characteristics.  e.g., PLUTO/size/distance/etc.

My vision is to have 10 stages in the game, each visiting one of the planets (Pluto being a planet) and the final one of course "Planet X".  At the start of each stage the spinning planet zooms in, the text overlay pops over the top describing it, then you press button, the text overlay fades/disappears and the panet zooms in to fill the screen, and you siwtch to the landing sequence where you land on the planet.  Mellon hops out, off goes the spaceship, you play the "planet", spaceship comes down, Mellon gets on board, repeat for the next planet.

 

So I need to combine the BD engine just shown, in all its glory, remove all BD stuff, add in all the previous WenHop stuff (from demos/videos shown here), add in the spinning globe stuff (rewritten to be menu system compatible), and at that point I'll have a functional system into which I can start working on gameplay.  That will take some time. Meanwhile, here's the last binary I think I had before I moved on to BD...

 

PS: the earlier demos/videos of spinning globes are rather low resolution. I'm pretty sure I can super-res those up to much higher resolution versions which will have no blockiness in the shape of the continents.  Essentially the current textures are formed at a resolution of roughly 40 x 20 pixels.  I expect to be able to increase this by an order of magnitude.  Just need to write a few conversion tools. So, that's gonna be interesting.

 

 

WenHop20230201.bin

[Bomberman94]

… so Wen Hop is a „side project“ that now benefits from the technical magic you achieved in (let’s call it) Boulder Dash 2? 🤔

Edited February 1, 2023 by Bomberman94

[+Andrew Davie]

13 hours ago, Bomberman94 said:

… so Wen Hop is a „side project“ that now benefits from the technical magic you achieved in (let’s call it) Boulder Dash 2? 🤔

Bit of both. That is, there are demos (e.g., spinning planets) which were side projects to wen hop but which will be incorporated into the "BD2" codebase and upgraded in capability. WenHop v2, so to speak, will benefit from all the BD2 "magic" as you call it... plus more from those side projects.  I think I'm going to focus on the spinning planets first, because I have some clear ideas how to make it look 10x better

[+Andrew Davie]

So today I had a go at integrating the spinning planet demo into the existing "BD2" engine code.  bit of a mish-mash at the moment, and I have yet to get the colours and correct textures going. But this work-in-progress shows that I will have the time/room to have the status screen (as discussed above) with a full spinning/zooming planet and text over the top of that.  Colours are random here, text is random here, planet is only a shell - no real form. But it's clear that it's going to work. I though I'd share the basic mockup stage I go through as I'm developing/testing concepts.
Also being tested here, the basic layout of a menu/title screen. It's really really really rough - but it says WEN HOP / PLANET / X.  The large X I think I can get an atari rainbow going along that, without affecting the other colours. So that would be pretty cool.
 

So, essentially -- when you get to a new planet, you see the status screen with the planet zooming in from the background, and then we have text over the top of that, "typing out" as if by a futuristic computer (i.e., '70s style with dorky fonts and typewriter sounds as each character is put on the screen - you know, the FUTURE) telling us about the planet name, and of course what the "mission" is on that planet.  Might give stuff like gravity, number of dogecoin required... anything star-trekky - space-exxy.

 

 

Sad news in our household today. My mother-in-law Gerry died last night. She was a science teacher and a real fighter - a role model for strong independent women. I had known her for 37 years or so; I will miss her greatly.

[+Andrew Davie]

One of the major engine differences in WenHop is the processing of the board.  In BD, the board is processed left to right, top to bottom.  At each grid position in the board we have an object and decide what to do based on the surrounding grid positions. For example, if there's a gap below, a boulder can fall.  In WenHop's engine, the board is processed left to right, bottom to top. have a think about the difference in mechanics/visuals - particularly if we have a large column of boulders. What happens visually if we clear a space under (say) a 4-high column of boulders?  Well, the answer is they will appear to fall as a single group - rather than individual boulders with gaps between them. This is a deliberate change; I want to be thinking of conglomerations of boulders as a super-large boulder rather than individual boulders which happen to be next to each other. Earlier demos showed some of this by changing the graphics when boulders were adjacent, so they looked like a larger block/rock.  The board scan direction emphasises this, and the manipulation of large blocks will be part of the gameplay.

On another note, I intend to make the board "wrap-around" horizontally.  That is, there will be no edges on the left/right side - you just keep going as if the surface you are playing on is actually a planet.  A very small 40-character-wide planet, to be sure - but a planet nonetheless.  So this will also change the gameplay significantly.  I'm hoping this will not be a difficult change to make. 

[+Andrew Davie]

Here's an interesting what-if experiment.  The spinning planet with a title screen with the 6-sprite routine. I haven't put in palette management here, so it's really whatever it happened to be at the time. It's a super-busy screen.... not going to use this, but preserving a video of it for posterity .  Towards the end of the video things went tits up.
 

 

[+Andrew Davie]

A little more work on this - I've increased the playfield size a bit by reclaiming the score area and instead overlaying the score. It's sometimes hard to see, but I can always put a black surround on the digits. But I'm thinking at this point perhaps having no score at all (unless really needed) on the screen, and devote the entire to the playing area.  Anyway, we can see what it looks like in this video.

 

The major change here is the "auto-config" of the falling rocks.  The game will have more of a moving/digging through underground chambers with large solid blocks of rock, and perhaps mechanics where the rock sections behave as a single unit, rather than individual characters. Anyway, this is a first step towards that, and as you see, the individual characters can still fall - a bit like in BD, when they settle, there's a bit of a readjustment going on there and the characters coalesce into a more solid-feeling wall/passageway type of thing. I quite like it.  Eventually you will have to use tools to break through these sections of rock.

 

 

[+Andrew Davie]

When migrating this project from BD, I was looking at my "ROMs" directory. When I do a build, the Makefile automatically puts a time-stamped copy of the binary in that directory. I set this up around 8/8/2022.  For those of you in the USA, who do dates different to the rest of us, that's 8/8/2022. Anyway, that was 194 days ago - and the directory has just over 10,500 binaries in it.  So that makes just over 50 builds a day, every single day since then. That's a lot!

[+Andrew Davie]

Here's the first binary of the "rewrite" version.  It's just a single planet/screen with the "auto-merge" rocks working.  Essentially all you can do is move around and dig away dirt under the rocks, watch them fall and merge.  Single-click to switch to mid-view.  Double-click to switch to overview.  When you're dead, hold down the button to restart.  There's a tune, of sorts, running in the background. @Pat Brady helped me with the transcription; TY.  I hacked the 2nd channel to be a sort of random-distortion backing track; I know it's horrible!

One thing I'm working on in the display is left/right wraparound.  So, the playing area is 40 "characters" wide, and you scroll over that as you move... but I'm going to have "infinite" movement left/right - you just kind of wrap around the left/right edge of that 40-wide area.  It will be interesting, and possibly add to the game mechanics.

The iCC display is enabled by default - but I'm undecided about that. To toggle on/off, switch the left difficulty (F5 on emulators).  Sometimes I love it, sometimes it really annoys me.


 

WenHop_20230219@20_18_52.bin

[+Gemintronic]

The formation directly below the player looks.. girthy.. substantial?  rock hard?  *cough*

 

[+Andrew Davie]

16 minutes ago, Gemintronic said:

The formation directly below the player looks.. girthy.. substantial?  rock hard?  *cough*

 

 

 

I'm wondering if you watched the ZPH show a year or two back where wen hop was shown?  In particular the dogeship with the animating dogeballs?