General Category > Programming

3D-Maze (written using ccz80 and machine code)

(1/5) > >>

ervin:
Hi all.

I've finally fulfilled a 24-year dream of writing a machine code program for the Amstrad.
I've converted Nigel Sharp's 1985 3D-Maze type-in game (Amstrad Computer User, October 1985).

I initially wrote it using the fantastic ccz80 compiler, by converting the BASIC program line-by-line.
But the aim was to then change as much of it as possible to machine code.

It has been an excellent experience (although no one seems to understand why on earth I would want to write a program in machine code for a long-dead platform ;D), and I'm pretty chuffed with the results.

For more info, please have a look here:
http://ccz80.foroactivo.com/ccz80-f1/3d-maze-game-for-amstrad-cpc-t28.htm#67

The dsk file (containing both the original as well as my re-write) can be downloaded from here:
http://www.cpcwiki.eu/imgs/f/f1/3d-maze.zip

Now I can finally get back to the ACU Type-ins project!

redbox:
Hey, that's really cool!

I had a play in WinApe and it really is fast.  I had some graphical glitches over the right panel whilst playing though (not tried it on a real CPC yet though)...?

And how did you write the code for the display to be double-buffered?

fano:
Very nice work , it is now very pleasant to play  :D

ervin:
Thanks guys.
I really enjoyed writing it, and I've got some more ideas I'd like to put in when I get some time.

redbox - what sort of graphical glitches are you getting?
Are you running winape in cpc6128 mode or cpc464 mode?
The program was written using the cpc6128 library for ccz80.

Can you upload a screenshot of the sort of thing you are seeing?

The double-buffering was very tricky, as this is my first machine code game, so I kind of stumbled around and tried lots of things by trial and error.

Here's a rough summary of how it works:

- I use the IYL register (IY low byte) as a flag, so that the program always knows which "screen" is being printed and drawn to.

- the clear screen routine (using the famous stack push method for fast memory filling) checks IYL.
if IYL is 0, &8000 is subtracted from the normal screen address, and then that new location is cleared.
Otherwise the normal screen location is cleared.
ie. I am using &4000 and &c000 as the screen memory locations.

- once all plotting/drawing has been completed, IYL is checked to see which screen buffer is being drawn to.
I then switch the location of the screen memory from &4000 to &c000 (or vice versa) to display the buffered screen data, using SCR SET BASE.
Then I switch the screen-buffer-to-draw-to using SCR SET POSITION.
So if the buffer being displayed is &c000, SCR SET POSITION points to &4000, and vice versa.

I hope that made sense!

I'm sure there are several improvements that could be made to the logic I've used (and I'd love to learn as much as I can to improve it), but for a first effort I'm pretty pleased.  :)

redbox:

--- Quote from: ervin on 01:05, 14 December 09 ---redbox - what sort of graphical glitches are you getting?

--- End quote ---

I just tried to replicate it to take a screenshot and couldn't...  I think probably the problem was the PC I was using at the time (my crappy work one) and not your program / WinApe - sorry to worry you!  :)


--- Quote from: ervin on 01:05, 14 December 09 ---The double-buffering was very tricky, as this is my first machine code game, so I kind of stumbled around and tried lots of things by trial and error.
Here's a rough summary of how it works:

--- End quote ---

That's a good technique and explanation, thank you.  I will try and incorporate it into my program.

We were discussing the stack push method for drawing to the screen RAM in the programming thread, so it's good to see someone else recommending it!

Navigation

[0] Message Index

[#] Next page

Go to full version
Powered by SMFPacks Reactions Mod
Powered by SMFPacks Alerts Pro Mod
Powered by SMFPacks Mentions Pro Mod