[Coco] Coco game engine demo

[Arthur Flexser]

The frame rate seems like it would only equal 16.683 milliseconds per
frame (at 60 frames per second) if you were using those jumbo seconds
that are made up of 1001 milliseconds each, no?

Nitpickingly yours,

Art

On Sat, Feb 2, 2013 at 6:26 PM, Richard Goedeken
<Richard at fascinationsoftware.com> wrote:
> Hello all,
>
> I recently got the idea and motivation to start working on a Coco 3 game.  I
> really want to do something in the side-scrolling / platforming genre,
> inspired by some of my favorite vintage action/adventure games: downland,
> cave walker, jumpman junior, montezuma's revenge, super mario brothers, etc.
> I started by writing a background scrolling engine, and I have a demo to
> show you.  You can download a zip file of a .dsk image here:
>
> http://www.filedropper.com/rg-scroller
>
> It requires a 512k coco 3.  My goal with this background scroller was to
> write something flexible, high quality, and high performance to use as a
> basis for this (and perhaps other) games.  To run the demo, just 'loadm' the
> 'DEMO6809.BIN' program and 'exec' it.  Use a joystick plugged into port 0
> (the right port) to control the direction of the scrolling.  Depending on
> how far the joystick is from the center, it will scroll by 1-4 rows or bytes
> per frame in each direction. Some of the relevant features of the scrolling
> engine are:
>
>  - full-screen 320x200 16-color scrolling background
>  - double buffered, vertical sync page flipping
>  - horizontal scrolling by 1-4 bytes per frame (2-8 pixels)
>  - vertical scrolling by 1-4 lines per frame
>  - up to 256 background tiles (16x16 pixels each)
>  - up to 64k of tilemap data
>  - maximum tilemap width of 4095 blocks (204 screens)
>  - maximum tilemap height of about 75 blocks (6 screens)
>
> The demo runs at 60fps.  The field duration at this frequency is 16.683
> milliseconds, so all of the drawing must be done in less than this time.  I
> ran some tests to determine the amount of time necessary to run the engine
> for various horizontal and vertical movement speeds, and here are the
> results:
>
> Time (milliseconds)
> Movement amount:   0     1     2     3     4
> -----------------------------------------------
> Horizontal       1.2   4.3   7.4  10.2  13.0
> Vertical         1.2   6.8   9.1  10.8  13.0
> -----------------------------------------------
>
> These are the worst-case times.  As you can see, you can go in any one
> direction at full speed, but you will drop frames if you try to go at full
> speed in both directions.  The overhead for the engine is currently 1.2
> milliseconds, which covers the vertical retrace IRQ, reading the joystick (2
> axes, 6 bits), and the logic of the engine.  Since sprites and sound will
> also take up a big chunk of time, I plan to run my game at 30fps.
>
> You can see that I only have 4 different tiles in this demo, and the tilemap
> is just a random mapping of these 4 tiles into a playfield which is 1000
> blocks wide and 63 blocks high.  The demo starts up with the position at the
> center of the playfield.  This software is not in any way optimized for the
> fact that there are only 4 different tiles.  Even if I were using all 256
> different tiles the speed would be about the same.  You can see it stutter a
> little bit when you move to the vertical edges of the playfield.  This is
> because I implemented a virtual memory system which allows the scrolling
> graphics memory aperature to move anywhere within the physical 512k memory
> space.  When you get to the edge, it drops a few frames as it move an 8k
> block out of the way of the screen graphics aperature.  This frame dropping
> will be greatly reduced with a 6309.
>
> I think this engine could be useful for a lot of other great games as well.
> In particular:
>
> - side scrolling shooter game like R-type or super cobra
> - side scrolling beat-em-up
> - top-down action game (ikari warriors) or RPG-style adventure
> - top-down racing game (micro machines)
>
> The limitation on the vertical tilemap height makes this engine unsuitable
> for a top-scroller type of shooter game.  I thought of a different
> architecture which would work to give you a very large vertical scroll size,
> but the memory layout and update algorithms would be totally different than
> what I've written here.
>
> If anyone is seriously interested in using my engine for your own game,
> please let me know.  I may release the source code under the GPL at some
> point in the future, and I'm willing to work out a licensing deal if someone
> wants to make a closed-source game to sell.
>
> My next plans are to add sprite capability and 6309 optimizations.  When
> this is done then I'll have a pretty solid idea of the kind of performance
> which will be possible with this engine.  It might even be possible to do a
> 60fps micro machines racer if the number of sprites is kept low and
> scrolling is limited to 1-2 pixels per frame.
>
> Please let me know what you think of the demo.
>
> Regards,
> Richard
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco