Scrolling Maze Demo

[Scrolling Maze Demo]

The old website is still on the wayback machine:

 

http://web.archive.org/web/20040202131229/...vg-network.com/.

 

The files are not stored, but googling for pcaesrc.zip gives the following website:

 

http://patpend.net/ftp/emulators/a2600/

 

Unfortunately it appears to be written in a combination of Pascal and 386 assembler ...

 

Chris

[Scrolling Maze Demo]

Hi Folks,

 

I have now created a new version of the maze demo, based on the comments posted here. The old version calculated the entire screen on every frame, which was clearly sub-optimal. The new version shifts the existing screen data, and only calculates the new data at the edges. This change required a big rewrite of the core code, but that is life! The result is an amazing improvement in speed, and the scrolling routine now fits comfortably within the vertical blank region, without the need for double-buffering.

 

I am quite pleased with some of the tricks employed in the new code. For example, the screen is represented as a circular-buffer, so we don't have to shift the data when scrolling vertically. However, there is still plenty of room for improvement, and I will welcome any suggestions. The scrolling doesn't quite work in the diagonal direction, but I don't think this is particularly useful in any case. I will probably remove this possibility from the code unless I can find the source of the problem. It is probably just a stray carry, which seems to happen to me all the time!

 

On that note, does anyone have any debugging tips for 2600 code? Since there is no printf, I usually write the data into PF1 to see what is going on, but this gets to be a real pain. Something like a memory monitor would help enormously!

 

Anyway, feel free to copy this code and modify it for your own purposes.

 

Chris

maze03.zip

[Scrolling Maze Demo]

Cool demo.

 

Probably something like Cyclotron from last years Minigame Compo would be pretty doable by using this. It was one of my absolute favourites.

 

Thanks for the suggestion - it took me a while to get the Oric emulator running,

but it seems like a rather addictive game to me. I was originally planning some

kind of adventure game (collect the objects, avoid the baddies), but this looks

like it would make for a better game. Also, the maze could be generated by a

pseudo-random sequence to save on ROM space. The only thing that worries

me at present is that it would be necessary to store the "trail" of the player as

they move through the maze. In theory, you could loop back and forward several

times through the corridors, leaving a rather complex trail. It might be rather a

push to fit this in the RAM?

 

Chris

[Scrolling Maze Demo]

Are you shifting the whole maze from scratch each frame?

 

If yes, then you could save a lot of time, by:

A: only shift the visible parts  

B: shift the maze relative to the last frame

 

Aha, that makes a lot of sense. At the moment I am redrawing the

screen from scratch every time, but it should be possible to reuse the

existing data with something like the routine by batari posted above.

Of course, this is going to require a fairly major redesign of my scroll

engine, but I am rapidly learning that it is necessary to rewrite all my

code several times on the 2600! I will keep this group posted on my

progress.

 

Many thanks,

Chris.

[Scrolling Maze Demo]

Hi there!

 

Weird. The scrolling looks better on the horizontal axis than on the vertical. I'd have thought it should be the other way round...

 

Greetings,

Manuel

 

The vertical axis scrolls by 9 lines in each step. It should be possible to make it smoother by adding more scroll steps.

 

Chris

[Scrolling Maze Demo]

Hi Folks,

 

Thanks for all the positive feedback! I now realise that I need to

calculate the length of the overscan properly. For some reason I was

assuming that the vertical blank would automatically be triggered at

the correct time. Unfortunately, this means that the code uses about

twice as many scanlines as it should in the overscan region

 

I have now coded up a modified version which calculates the screen in

2 passes. The calculations are now performed entirely in the Vertical

Blank region (37 cycles), which leaves the Overscan region free. The

calculations could probably be done in a single pass by using both of

these regions, but I hope to make a game out of this demo, so I need

to leave some space for the rest of the game. Because I am calculating

in 2 passes, the screen is double-buffered, as only half of the screen

would be displayed in the first pass otherwise. The scrolling is now half the speed, but I think it is still fast enough for a decent game.

 

I have attached the new version of the code to this message. Note: I didn't include the .h files again as there is a note in these

files that states that they shouldn't be redistributed. However, as

pointed out above, they are available from the

DASM site.

 

Unfortunately there are two problems with modified version, and I

would be grateful for any suggestions:

 

1) The code overflows the vertical blank region when there are too

many blocks displayed on the screen. I think the code would be stable

with only 2-3 more scanlines. As the screen only uses 189 of the 192

available scanlines, I think this problem could be fixed by extending

the vertical blank to 40 cycles, and shrinking the screen to 189

scanlines. Is there any problem with this, or will it fail to work on

real Atari hardware? Alternatively, I think some work could be done

during the three vertical sync scanlines? However, most of the sample

code on the web avoids this region. Is there any reason for this, or

is it possible to do work here?

 

2) The code is now using too much RAM (60 bytes for the screen). I

would like to reduce this significantly as it doesn't leave much spare

space. Only 4 bits of each byte are actually being used, so

theoretically we could fit both screens into 30 bytes by using the

unused 4 bits. However, there are not enough spare cycles in the

kernel to do the required masking and shifting. Are there any tricks

that I can use to make use of these wasted bits?

 

Many thanks,

Chris

maze02.zip

[Scrolling Maze Demo]

Hi Folks,

 

The "Retro Gamer" magazine in the UK had a feature on the Atari 2600

last month (issue 12). This feature covered both the gaming side, and

the programming side, including a pitch for the Atari Age website.

After reading about how difficult it was to program the machine, I got

motivated to have a shot myself. My main programming these days is

done in Java, so it was a bit of a paradigm shift to start programming

the 6502. Actually, this is the first time I have ever touched real

assembly language.

 

Anyway, cutting to the chase, I have now read through the various

tutorials on the web, including the excellent material on this forum.

I decided to get started with playfield graphics, rather than tackling

the sprite hardware straight away. To get to grips with asymmetric

playfields, I have coded-up a small scrolling maze demo to test my

understanding of the principles. The demo and source code should be

attached to this message. The code is GPL licenced, so anyone is free

to take it and modify it should they wish.

 

My maze demo displays a 6x5 window which can be scrolled around a

32x32 maze using the joystick. The maze wraps at the edges, so you

can scroll indefinitely in any direction. It also uses the full

screen, except for 3 scanlines. I think this demo will make a good

basis for a number of different maze-type games which I hope to write

soon. I still have plenty of spare cycles in the vertical bank

region, and spare RAM to play with. I would be grateful for any

suggestions on how I can improve the code, and any flaws in my

programming technique. The scrolling appears to be stable in both

Stella and Z26, but the line count in Z26 fluctuates between 270 and

290 scanlines? Any pointers on what I am doing wrong would be most

appreciated.

 

Cheers,

Chris

maze.zip