C64 Mercenary geometry decoded

Thanks to http://icu64.blogspot.com/ visual editing tools I've figured out the geometry data structure for pickup items in the C64 game of Mercenary. Perhaps this also applies to outdoor structures as well, I haven't check yet. Due to the fact that line segments only use 4 bits to reference verticie indicies, there can only be 16 verticies referenced (0-15.)

pickup object data structure:
1 byte: index of last verticie on the list (max of 0F)
Each verticie is 3 bytes, size of verticie section = (last vert index+1)*3

depth byte, height byte, width byte all from origin (check signed byte number system)

1 byte: index of last line segment on the list (I suppose max of FF)
Each line segment is 1 byte, size of line segment section = last seg index+1.

high nibble is index of 1st verticie, low nibble is index of 2nd verticie

signed byte number system:
FF,00,01, and 80, are all 00 (don't ask me why so many)

FE is -1, 81 is -126  (magnitude = FF - number)
02 is +1, 7F is +126 (magnitude = number - 01)

Example: table in Mercenary Second City that you can fly

Pickup item verticie magnitudes are a very small fraction of the 126 maximum. It reads this data structure every frame, so data compression isn't an option as compression requires compute time which is a very scarce resource on the 1Mhz CPU.

overview: 3e61-3e8e item 06 (Table) 45 bytes

3e61 0b num of last verticie

3e62 f9 vert 00 depth of right-rear leg bottom
3e63 00 vert 00 height of right-rear leg bottom
3e64 f3 vert 00 width of right-rear leg bottom

3e65 07 vert 01 depth of right-front leg bottom
3e66 00 vert 01 height of right-front leg bottom
3e67 f3 vert 01 width of right-front leg bottom

3e68 07 vert 02 depth of left-front leg bottom
3e69 00 vert 02 height of left-front leg bottom
3e6a 0d vert 02 width of left-front leg bottom

3e6b f9 vert 03 depth of left-rear leg bottom
3e6c 00 vert 03 height of left-rear leg bottom
3e6d 0d vert 03 width of left-rear leg bottom

3e6e f9 vert 04 depth of right-rear leg top
3e6f 06 vert 04 height of right-rear leg top
3d70 f3 vert 04 width of right-rear leg top

3e71 07 vert 05 depth of right-front leg top
3e72 06 vert 05 height of right-front leg top
3e73 f3 vert 05 width of right-front leg top

3e74 07 vert 06 depth of left-front leg top
3e75 06 vert 06 height of left-front leg top
3e76 0d vert 06 width of left-front leg top

3e77 f9 vert 07 depth of left-rear leg top
3e78 06 vert 07 height of left-rear leg top
3e79 0d vert 07 width of left-rear leg top

3e7a f6 vert 08 depth of right rear corner
3e7b 06 vert 08 height of right rear corner
3e7c f0 vert 08 width of right rear corner

3e7d 0a vert 09 depth of right front corner
3e7e 06 vert 09 height of right front corner
3e7f f0 vert 09 width of right front corner

3e80 0a vert 0a depth of left front corner
3e81 06 vert 0a height of left front corner
3e82 10 vert 0a width of left front corner

3e83 f6 vert 0b depth of left rear corner
3e84 06 vert 0b height of left rear corner
3d85 10 vert 0b width of left rear corner

3e86 07 num of last line segment

3e87 04 seg 00 right rear leg (right-rear leg bottom to right-rear leg top)
3e88 15 seg 01 right front leg (right-front leg bottom to right-front leg top)
3e89 26 seg 02 left front leg (left-front leg bottom to left-front leg top)
3e8a 37 seg 03 left rear leg (left-rear leg bottom to left-rear leg top)
3e8b 89 seg 04 right side (right-rear to right-front)
3e8c 9a seg 05 front side (right-front to left front)
3e8d ab seg 06 left side (left-front to left-rear)
3e3e b8 seg 07rear side (left-rear to right rear)

Variable Frame Rate videos (request)

I tip my hat at YouTube for finally supporting 60fps! The next best move I believe would be supporting variable frame rate videos. Have fast frame rates for action scenes, and slower frame rates for slow moving scenes that don't need it (to conserve memory) James Cameron is rumored to be considering this for future Avatar movies.

I was thinking about those fast motion / slow motion fight scenes in the movie 300 (2006). Lets say the user wanted to see how fast the action is in real time, after enjoying the artistic slow down / speed up sequences. Perhaps have an optional actual time per frame, while retaining the displayed time for the frame.

Each group of frames declares
-how many REAL_TIME (8 1/3 ms periods) each frame for (this group of frames) represents
-how many (8 1/3 ms periods) to ACTUALLY_DISPLAY each frame for (this group of frames) <- optional, if omitted it's identical to REAL_TIME

8 1/3 ms is not arbitrary, it exactly multiplies to these 5 values: 120hz,60hz,40hz,30hz,24hz
These are very common values, and this should provide sufficient timing refinement.

However more refined values could also be chosen, to include support for hi-speed cameras:
4 1/6  ms exactly multiplies to these 10 values: 240hz,120hz,80hz,60hz,48hz,40hz,~34hz,30hz,~27hz,24hz

2 1/12 ms exactly multiplies to these 20 values: 480hz,240hz,160hz,120hz,96hz,80hz,~69hz,60hz,~53hz,48hz,~44hz,40hz,~37hz,~34hz,32hz,30hz,~28hz,~27hz,~25hz,24hz

If Gsync becomes mainstream, perhaps do multiples of 1 1/24 milli-seconds.
Gsync is basically variable framerate at the hardware interlink between the video card and display.

Audio frames should coincide with video frames.

The common audio sample rates evenly sub-divide into the common video rates

0400 (048khz samples) = 8 1/3 ms
0800 (096khz samples) = 8 1/3 ms
1600 (192khz samples) = 8 1/3 ms

0200 (048khz samples) = 4 1/6 ms
0400 (096khz samples) = 4 1/6 ms
0800 (192khz samples) = 4 1/6 ms

and so on...

(also posted on YouTube product forum)

Why Quake 1 & 2 invoke mouse acceleration

I discovered that both Quake 1 & 2 invoke SystemParametersInfo in IN_ActivateMouse with the third variable being {0,0,1}. The 1 activates mouse acceleration. Quake 3 doesn't invoke SystemParametersInfo in IN_ActivateWin32Mouse, so it uses whatever you have set for mouse accel (what Microsoft calls 'enhanced pointer precision'.) Well you can morph the mouse acceleration curve into a linear response line by editing the registry such as the mouse-acceleration-fix by MarkC. So if an application activates mouse acceleration it will still be linear.

Envisioning various dimensions

2D beings
-we have 1D eyes, hence we can see 1D-sections of 2D, and can only 'envision' how all the 2D sections come-together as a whole
-we can see 1D worlds in their entirety (many 0D pixels stacked onto a 1D line) from the vantage point of another dimension (y axis)

3D beings
-we have 2D eyes, hence we can see 2D-sections of 3D, and can only 'envision' how all the 3D sections come-together as a whole
-we can see a single 2D world in its entirety (many 1D lines stacked onto a 2D plane) from the vantage point of another dimension (z axis)

4D beings
Difficult to envision as we are 3D beings. And I don't mean the 4D in the Back to the future since where the 4th dimension is time!