Commander X16

I've got my mouse subroutines working now.  There's going to be a lot of things going on that are triggered by the VSYNC interrupt.  It will do a few things like update the time count from 0 to 59, and at certain points in that sequence events will be triggered. but they won't be triggered within the interrupt itself.  Instead I've set aside a zero page variable called FLAG, and the interrupt routine will be setting or resetting bits in that byte.  The main program will include a case/switch type of statement that reads the bits of that byte and executes code if that bit is set.  That way I can also set some tasks a higher priority than other tasks, making the main program just sort of act like an orchestra conductor reading off the sheet music in that one byte. I may need to set another byte or two aside for these flag purposes, but it seems like a good way to keep everything operating in concert.  Part of the interrupt is also one of my mouse subroutines, which checks to see if a mouse button has been pressed and if so converts the 2byte values for MX and MY into single bytes for the 256x192 screen of this game, then sets bit 6 of FLAG.  There's another subroutine which gets called if bit 6 of FLAG is set, Get_Location.  This converts the x and y values into a single byte representing a "hot spot"; right now the subroutine recognizes the ten hot spots for the nav ball and zoom buttons.

 

Movement!

 

This is the main program (for now), initialization, and the custom IRQ handler.  This is all being written in the META/L editor, so it's easy for me to make changes and test quickly.  The only other tool I've used so far has been Libre Office spreadsheets and a ton of notebooks.

.

 

 

More progress: closeup 3d orthogonal view and scrolling text.

 

So, the map of the asteroid is based on an icosahedron, the 20 sided Platonic solid:



This has been tessellated once; a new vertex created at the midpoint of every edge, with the new vertices extruded out to an equal radius and connected to all their nearest neighbors.  This gives a solid with 80 triangular surfaces:



There are still only 20 equilateral triangles on this object; the other 60 triangles are isosceles but close to equilateral.  Inside each of these triangles we can draw a circle that touches all three sides.  Doing so leaves gaps at the vertices upon which we can center some more circles:



I did that markup in Paint so it's not perfect but you get the idea.  There are 42 vertices and 80 faces, so 122 circles can cover about 78% of the surface. the other 22% is the little gaps between the circles.

The orange circles are on equilateral triangles, the red circles are on isosceles triangles, the blue circles are on vertices with 6 edges and the green circles are on vertices with 5 edges.  When a circle is in the center of the screen, the image looks exactly the same (with rotations) as it would if you were looking at any other circle of that color.  So, as long as each circle has a list of where everything else is relative to itself and some base rotation, the asteroid image centered on any circle can be generated using one of only 4 generic maps.

Each triangle is divided into 81 smaller triangles or "cells". There are 18 of those 81 triangles that are outside the circles, which will always remain terrain.  For the orange, red, and blue circles that leaves 42 cells, and for the 12 green circles there's 35 cells.  This next image shows the 42-cell version in two rotations and the 35 cell version in four rotations:



(I used this image to help generate the closeup orthogonal view, by squashing it to a 192:13 aspect ratio, putting gray grid lines on the result, then putting numbers in a spreadsheet according to colors inside grid lines. The spreadsheet took over from there.)

The buildings that are going into this game have to fit into 42 cells and still look recognizable without the last 7 cells in the pentagonal map.   Here's how I'm indexing these cells for buildings:



There are 128 bytes set aside for each building type.  The first 42 bytes describe the cells' height from 0 to 7 (bits 4,5, and 6; bit 7 is 0) and a color index from 0 to 15 (bits 0-3). 

The next 22 bytes aren't allocated yet.

The 65th byte is a building type byte.

That color nybble in the first 42 bytes does not refer directly to a color on the palette.  Instead, it points to a list of 15 day colors and 15 night colors (color index 0 is considered a terrain color, and for that, color is indexed separately by height). So the 15 bytes following the building type byte are the daytime colors, and refer to the palette index.  These are followed by a building level byte, and then the 15 night colors. 

The next 20 bytes aren't allocated yet.  The last 12 bytes are used for the building name.

For every cell on the map there's a sunset value (0 to 255), and the asteroid has a rotation value (also 0-255), so if sunset minus asteroid rotation is positive the daytime color is shown otherwise the night color is shown.  At startup the program goes through each cell on the map and finds the palette index of the day color and night color for each cell and stores those in lookup tables in banked RAM, so the drawing subroutine only needs to switch bank numbers to find sunset, day color, or night color.

Why am I showing all of this?  I think I'm going to need some help designing buildings.  

For visualization purposes, each cell is a triangular tower, and each step increase in height is roughly 1/4 of the length of an edge. A max height 7 tower would be almost twice as tall as it is wide.  Height 0 is fine; it just means the cell height is the default height of the building area but colored differently than the terrain.

The 15 day colors and 15 night colors can be any of the 4096 available colors.  Each cell can use only one of those pairs of colors; if it's using #13 for day then it's also using #13 for night.

As a fun complication, I'm not going to have just one palette.  There will probably be 16 of them, cycling in once every 1/3 of a second.  Most of the colors will stay the same from palette to palette, but I'm going to set aside 32 or 64 of them to change from palette to palette.  This could lead to some interesting and computationally cheap animation effects.

For instance, suppose 4 palette entries are a daytime color, say an amber color most of the time.  And another 4 palette entries are a night colors, say a darker brownish color.  Suppose that color 1 (both day and night) is gray instead in palettes 0-3, and then amber/brown in palettes 4-F; and that color 2 is amber/brown in palettes 0-3 and 8-F but gray in palettes 4-7; color 3 is gray in palettes 8-B, and color 4 is gray in palettes C-F.  Then using those four pairs of cycling colors on cells that are close together could make the illusion of something gray being moved across an amber/brown surface. 

Or more simply, imagine that a color is gray in most of the palettes but red in palettes 7 and F.  Then it would be a blinking red light every couple of seconds.

That sort of quick animation would take place simultaneously all over the image, and in the closeup image, all just by loading 512 bytes into VERA every 20 VSYNCH interrupts.  It'll make it look like there's a lot more going on than there actually is.

So, if anyone wants to take a crack at designing a building, just come up with 42 bytes to describe the height & color index, and a listing of the RGB values for each of the 15 day/night colors, and if any of them are color cycling list the RGB values for that color index for each of 16 palettes.  That and 12 Petscii characters for the name.  If anyone submits a building I'll probably use it for something in the game.

I'm working on a Headquarters building first, as that will always be the first building placed on the map.  After that buildings will have to be placed next to existing buildings.  The other buildings I have in mind are:

- power plant

- habitat (probably several examples of this: level 1, level 2 etc)

- greenhouse (ditto)

- mines of various types

- smelter

- refinery

- foundry

- 3D printer (enormous)

- storage tanks (various)

- warehouses

- factory (various types)

- maintenance shop

- hospital

- armory

- wretched hive of scum and villainy, with live band

- shipyard

- launchpad

I might write a tool to make it easier to design buildings.  If I do, I'll probably share it here.

Wow, that is a lot of thoughts gone into the graphics! Good job!

 

So, did I understand correctly, that in case a building is rendered on a "pentagonal" site, 1/6th of the hexagonal "cake" is automatically left away?

 

Also I am not sure if I got the thing with colors already. Each element contains 4 BPP, and I get that you are going to swap out the palette for day and night. For each building type, those 32 colors are stored in the building info. But how do you plan to do this animation thing? Clearly, the 32 (or rather 30) slots in the building info are not enough memory for that. So would those 8-bit numbers, that would normally refer to one of 256 colors from the palette now instead refer to an entire color-cycling palette?



If I understood this correctly, I would encourage to make several of the color cycling palettes identical except for phase offsets. This way, you can have wave-like animations (e.g. waving flags or water or glowing stuff going through transparent pipes)

Edit: Oh wait, there's actually not enough graphical resolution to have waving flags ore pipes ?

Yes, for a pentagonal one cells 35-41 are left out.

The 15 day and 15 night colors will be the only colors on the building,  but for the simple animation the palette itself will be changing. Not all the colors, but a few of them can change depending on which of the 16 palettes is loaded. There isn't enough resolution for small stuff at this scale, although I might have vehicles roaming about in the closeup view.

I'll probably have to place a few buildings on the map to show how the animation will work. 

edited to add: the building cells will be pointing to the same colors on the palette, but those colors themselves may change from palette to palette.  Nothing actually changes in the data for the display itself, except a few colors will look different as they change when the palette switches.