Hi all,

I'd like to ask for opinions on the best way to proceed with the Electron version of Treasure Island...

The main problem is the amount of memory taken up by the graphics data, which is now visibly spilling over into screen memory.

On the Beeb version I've got around this by manipulating the CRTC registers to change the dimensions of the screen so it's only just big enough to display the game area. This freed up 8K of screen memory for use as storage. Unfortunately, on the Elk we don't have that luxury. The screen size is fixed.

My question is, how would Electron owners prefer to see the game progress:

1. Use mode 5 instead of mode 2 - I'm not particularly keen on this because the game would lose a lot of its charm without the colourful graphics but it would have the added benefit of speeding things up

2. Have the game data visible around the edges of the play area (like Exile) - I would, of course, get rid of all the flashing colours so it's not 'in yer face'

3. Reduce the number of tiles and sprite frames so the game fits in the memory before the screen. It wouldn't look quite as good as the Beeb version but at least the screen wouldn't be contaminated with 'junk'.

4. Do a raster split and change the palette entries to black to hide the on-screen data from view. Is this even possible on the Electron?

Any comments or alternative suggestions would be most welcome.

Cheers,
Paul.

You can do this to an extent. There's an interrupt that happens at exactly line 100, you could idle for however many lines you want and then blank the palette. This does eat CPU time though.

CPU time is a bugger in general, the Electron in mode 2 runs at about 600khz (as opposed to 2mhz on the beeb). If that's enough then I'd leave it in mode 2 with junk on the screen, otherwise mode 5 is the only answer.

Let me go and hunt down some Elk users and I'll point them at this thread!

I think Tom Walker has more or less hit the nail on the head — the real-time clock interrupt at line 100 means you can hide either the top 100 lines of the screen or the bottom 156 with almost no processing cost (even better, set palette to black and switch to a 40-column mode during the area that you are blanking to grab a bunch of extra processing cycles). At the less extreme end, you can post some data to the tape at end-of-display, set the palette and then set it back to whatever you really want when the tape hardware comes back to you with the tape data entry interrupt, giving something like 74 lines of blankness at the top of the display, leaving only a shade fewer than the total available on e.g. the Spectrum. That's what the Hewson train-driving games do, the only major disadvantage is that you can use the sound output only when you're not using the tape stuff, but you could do that for the entire pixel area and if you're only using sound effects it wouldn't be too much of a problem, I reckon.

Manic Miner on the Spectrum does a similar thing with only being able to play a note for part of a frame, then having no sound output for the rest of the frame, and doesn't do too badly. It's even playing music, albeit in a slightly stilted manner.

I would say go with the Raster Split as others have said.

Though if you are working in Mode 2, it may be more the processor speed rather than memory that is your main enemy. I'm not sure how many sprites your planning on pushing around the screen so might be ok, but in Mode 2 you can roughly halve the speed compared to a Beeb (tis a little less than half I think in reality).

So if you're at the limit of a Beeb now than an Elk version is going to struggle. Which would mean looking at Mode 5 or just scaling everything down. Reducing sprites by 25% would mean they'd plot nearly twice as quick, but of course they may look crap then !

If you are using a lot of sprites what about reducing the number of colours per sprite with a custom data encrypter/decryption routine, i.e. store data as 1 or 2 bits per pixel and expand them to 4 bits per pixel in Mode 2. I've used this technique with some success (e.g. PLIG) but it depends on the speed of the game. There IS an overhead of course (the code for unpacking) BUT you could get up to four times as many sprites in / reduce the sprite data to a quarter of its size.

Thanks to everyone for the replies.

@TomW/ThomasHarte:
The game area takes 192 lines which only leaves 64 lines at the top of the screen to play with. This rules out using the interrupt at line 100 but using the tape interrupt sounds interesting. I'll have a look into that.

@SteveO:
I agree, the processor speed is a big problem and was something I wasn't aware of when I first agreeed to do an Elk version of the game. In mode 2 it's almost 4 times slower than the beeb. Luckily, the maximum number of sprites active at any one time can be limited to 4, so plotting speed isn't too much of an issue.
Your suggestion of reducing the size of the graphics may be the way to go. Not only would this free up some memory, it would also allow the use of the line 100 interrupt. Definitely worth considering even though it would involve the most effort.

@ChristopherD:
I'm already using this technique along with data compression to squeeze down the tile graphics. I did try it on the sprite data but it only saves around 1/3 of the memory and slows down plotting considerably. I can live with the slower redraws when moving between screens but not for the sprites. The technique I ended up using for sprites is to eliminate redundant images. For example the main character sprites facing left and right are mirror images of each other. By just having one sprite and flipping it around when the character turns I can save 1/2 the memory with almost no speed penalty.

Yeah, I'd support the more colourful Mode 2 w/ smaller graphics (over Mode 5 w/ larger, 4-colour graphics).

Anyway, glad to see this is back on track!