Hypothetically... The Empire Strikes Back on the Spectrum

[HEXdidnt]

@Lee Bee, funnily enough, I've accounted for that in part of the design document that I hadn't posted here... but I think I'd presumed a straightforward vertical crawl rather than a more authentic angled version.

I'm considering stringing these screenshots together into a slideshow that I can put up on my YouTube channel, along with my SAM Coupé demos, and may attempt to add some form of intro... Had a few ideas, but it's a question of what I can accomplish myself (probably in BASIC on the SAM) and what would require video editing.

BTW, on a related note, I tried sending you a PM earlier today, but my end seems to think it never existed - not in Sent, not in Drafts, nor in Outbox...

[Lee Bee]

Here's a very crude high-speed mock-up of what I meant about the interpolation, using 50Hz flickering dithering. It would be easier to read at normal scrolling speed, but you get the idea…



This interpolation/antialiasing method could be used for all kinds of scrolling text, not just Star Wars and I feel it's something that will one day become far more common in Speccy games.

BTW, on a related note, I tried sending you a PM earlier today, but my end seems to think it never existed - not in Sent, not in Drafts, nor in Outbox...

Curious - I definitely received no message. Please do keep trying!

[HEXdidnt]

@Lee Bee That's fascinating... How did you accomplish that?

Received your PM, reply currently sitting in my Outbox... so fingers crossed.

[Lee Bee]

@Lee Bee That's fascinating... How did you accomplish that?

I'm not a coder, it's purely a graphical mock-up done quickly in Photoshop, though I could just as well have used After Effects. Steps: I tracked down the original acetate slide, changed the text to pure yellow and animated this moving in perspective in a 256x192 screen. I then reduced the number of colours so that there were only two yellow colours, allowing for one shade of antialiasing. Then I set up a batch action to search for this colour on each frame and replace it with the dither pattern, with the dither position alternating each frame. Then exported as animated GIF

[Joefish]

It's a tricky effect to do graphically without revealing obvious glitch lines in the result. You could do it all with vectors, like the Atari arcade machine, but you can't afford to pixel-scale each row graphically, copying from a constant working copy of the text every time.

What I'd try and do it scroll it up pixel-by-pixel, but periodically not scroll a varying upper part of the region. That way the lower region would scroll up and lose a line every so often. Or split the screen and scroll the upper part by one pixel and the lower part by two, but vary the split up and down in a semi-random repeating pattern. That would squeeze the text vertically as it goes up the screen.

Then you want to squeeze it horizontally, losing one pixel off either side every two rows. So, pick a pixel somewhere to the right-of-centre, and remove it by scrolling the rest of the line left one pixel. Then do the same, in from the left, on the next row. The split point would have to move about pseudo-randomly, but always be within the text area as it narrows up the screen. It would be easier if it was always a pixel on the end of a byte; you'd just have to make sure it doesn't repeatedly take out adjoining pixels and set up a noticeable pattern.

Finally you could AND a stipple over the very top, to make the text fade and vanish.

Might look a mess. Who knows?

[Lee Bee]

Well there you have it. If anyone's the expert in scrolling graphics in perspective against a starfield, it's @Joefish:

[HEXdidnt]

Both options very interesting, @Lee Bee and @Joefish, thank you!

The GIF options isn't something I can (easily) transfer to actual hardware, and the scroll'n'squeeze option is far beyond my meagre programming skills... but I have managed to knock up something simple in SAM BASIC, using the custom font I put together for this project. There's a built-in SCROLL command that works in one of four directions, using a specified increment, and it's possibly to fudge a gradient on screen by varying the colour assigned to a particular PALETTE slot from a specified LINE on screen. The text is READ from DATA statements, line by line, printed initially where it's invisible, then scrolled through various levels of visibility before disappearing again toward the top of the screen.

Got it done far quicker than I'd expected*, and the only hitches I had were that the coordinates are assigned from the bottom up, not the top down (I think that's like the Spectrum, but pretty much opposite to everything else!), and that the bottom 2 lines are unavailable by default, so the top of the screen is line 173, not line 191... But then I remembered that I don't even need to specify a line number for the colour that becomes active from the top of the screen...


(* I'm actually not too bad with SAM BASIC, when I put my mind to it...)

[Joefish]

Try this...

https://cluster3.secure-staging.uk/rail ... roller.zip

Bit crude and makes bits of the text unreadable not far up the screen, but it does the job, ish, and can be run from BASIC.
It starts by doubling the size of any text printed in the top corner of the screen, then pixel shifting rows left and right at various points to eliminate pixels. All while copying lines up the screen, and occasionally skipping lines, to squeeze the text vertically.

[HEXdidnt]

Bit crude and makes bits of the text unreadable not far up the screen, but it does the job, ish, and can be run from BASIC.

Honestly, that looks fantastic - great work, and thank you!

...Now if I can figure out how to get that working on a SAM Coupé, I may be able to integrate it into my slideshow demo...

[Lee Bee]

Amazing, Jason!

I feel that a heavier font may solve the legibility problem. The original Star Wars crawl font was News Gothic bold (image). Just to give an example, I roughly rasterised a few characters at 8x8: In retrospect, I probably should have enlarged the lower cases so there's less gaps when presented as monotype.

[HEXdidnt]

While I'm (probably) not going to go back in and 'correct' this, it's occurred to me today that the way I've presented the Dagobah 'assault course' stages may have been misjudged... The more I've thought about it, the more I think it should be more like the Cloud City level, in that it's not so much a straightforward platformer with trees and vines to climb, as an exploration of the swamp, similar to the first level of Platoon.

That way, rather than two or three separate courses, there could be a single map for the swamp, but Luke needs to take a different route through it to reach specific locations for each of his Force exercises, and the last one is the spooky hollow where he meets the phantom Vader...

I think the main thing that's been bothering me since putting that mockup together is that it's the only level that essentially has colourful sprites and scenery on a black background, which I consciously avoided on every other level bar those set in outer space... I'd rationalised it by thinking that those scenes were pretty dark and dank, not much sunlight, etc. but it almost looks like an entirely different game.

[flatduckrecords]

...Now if I can figure out how to get that working on a SAM Coupé, I may be able to integrate it into my slideshow demo...

I've modified @Joefish's code to work on SAM, hopefully it's helpful!

samscroll.mgt
modified source code

I'm sure Hex knows but if anyone else is interested: the main difference on SAM is that you need to page-in the screen when you want to update it, and it needn't necessarily be at 16384. On SAM that's where the system heap, variables and stack normally are; so it's probably easier not to page that around if you don't have to. Instead I've tweaked the routine to page-in the current screen to upper memory (so it's accessed at 32768) and then put everything back when it's done. The routine itself has been reassembled at 16384 so it easily fits in the heap space below the system variables. (That can be changed if you've got other routines that clash with it in your slideshow @HEXdidnt).

The disk also contains a BASIC demo and I've included the AUTOCHARS font (as featured in Outlet). It's a double-width font so it seems to work well with the scaling.

[Joefish]

Nice. If your font is a full 8 pixels high, you could try calling the routine a couple of extra times before printing the next line. I think that should scroll it up some more thus leaving extra blank lines between rows of text. (Actually no, you'll probably have to print a blank line, then do a couple of scrolls, then print the next line of text. The last pixel row of the text will probably be repeated otherwise).

I think the thing I need to do is to define a character that's alternating vertical lines, then watch how they go up the screen and which pixels get eaten where, then adjust the squeezing factors so it only ideally takes out the doubled-up pixels first, squeezing them down to single pixels again. But that could take a while to figure out!

[HEXdidnt]

I've modified @Joefish's code to work on SAM, hopefully it's helpful!

That's awesome - thank you!

I'll start looking into patching it into the demo today. I've currently got the text crawl running in MODE 3 with some palette changes to handle the fade. Curious to see how it looks using my current font (not great, I suspect) but I was pretty much ready to set up a bolder font.

[Lee Bee]

Very impressive, @flatduckrecords. The justified text is a nice detail.

[flatduckrecords]

Thanks @Lee Bee. Yeah as @Joefish alluded to, the SAM font is fully 8px high (normally SAM inserts a blank line for each row in its default “8x9” mode) so I was padding-out each line of text with spaces anyway to avoid "trails" appearing below characters with descenders. I thought I might as well justify it while I was adding extra spaces anyway - it's a wee bit clunky with the monospaced font and only 16 chars but it adds to the authenticity, I reckon.

I've sent @HEXdidnt a demo of some custom/proportional text that might work a bit better.

[Quazar]

I've modified @Joefish's code to work on SAM, hopefully it's helpful!

Cool to see!

A potential tweak would be to adapt it to MODE 2. It'll be the same number of bytes to shift around, with the screen being mapped linearly rather than the ZX Spectrum way in MODE 1. The benefit would be a bit of a speedup with the Z80 running at an effective speed of ~4.8MHz rather than the extra contended ~3.8MHz of MODE 1. (The effective speed figures are based on the 6MHz Z80 and the WAIT states for RAM access and additional MODE 1 slowdown)

[flatduckrecords]

Thanks @Quazar!

We were wondering about MODE 3 for extra horizontal resolution as that would help with the text legibility (and/or line-length), but of course that's 4x the number of bytes to move. (Plus extra shifting operations for the scaling routine to the handle 2-bits-per-pixel instead of MODE 1's 1bpp). MODE 3 should also benefit from the speedup though? (If that's not nerf'd by the extra gruntwork!)

[Quazar]

MODE 3 should also benefit from the speedup though? (If that's not nerf'd by the extra gruntwork!)

Yes. With MODEs 2, 3 and 4 you have the full speed. But you are right in that you will then be moving four times the bytes so it will end up being slower

[ionut76]

If this project will ever become a game I want it soooo bad !

[HEXdidnt]

If this project will ever become a game I want it soooo bad !

While it might never be a Star Wars game in name, having written the design document and put together a handful of screenshots, I'm honestly curious to see how well it would work on actual hardware, and whether it would actually present an enjoyable playing experience.

I'd need to spend a lot more time finishing sprites, backgrounds, etc., creating maps, setting objectives, etc. before that could happen... but, at this point in time, and without a coder on-board to set some practical limits on sprite size, animation frames, etc., I'm not inclined to do that.