MK MMXXI Parsec

[oddemann]

MK MMXXI Parsec

Story!

Joe No Good - YOU! (Parsec as First Person Shooter!)
Have been given a shoot at fortune and fame! IF, you can get to Texas. You live in Hammerfest and has won the lottery and got yourself the latest MK MMXXI Star shooter! "The higher ups!" has seen a possibility to exploit Joe No Good! And if he is up to the task they will use him as a messenger for the latest universal "world" war! They are sending out the last and final war plan to kill the ReyZen. ReyZen is the latest danger that has been discovered in the universe! "The higher ups!" are scrambling to upgrade there computers to fight of the ReyZen invasion! Joe No Good is promised 1.000.000 Bitcoins!

The only problem, is to get to Texas! IF Joe No Good can get to Texas he can possibility make 1.000.000 Bitcoins!

(If this "fly's off" then there is a possibility for Part 2 and more?)

 

The Idea!
I have a idea to make a Parsec in First Person Shooter mode! I have made a main screen (combat), and I want to grow the game from that point and out. I am trying to make the game be as simple as possible on the graphics, so that I can make the graphics as good as possible. (Inspired by Raycaster)

Short explanation: of game play! Use the same set up as in Parsec. Same "monsters". The only difference is that your sitting inside the "MK MMXXI Star shooter" and seeing it all as a First Person Shooter!

How to make it run... Just use a smaller part of the screen for "live action", so that the power can be focused on a smaller part.

And then I run right into the first problem... I am not a skilled programmer, I am more the mad artist. Lots of dreams! Having read up and is more and more in tune with the limitations of the TI. I have been looking for a game, where I can make a game that is as modern as possible and in with in the TI frame. I am a Basic and EX Basic programmer, so MY first idea is to use EX B. But, maybe it will not work. BUT, I see that the possibility to maybe compile it and in that way make it more powerful.

I think I got the perfect game idea! MK MMXXI Parsec FPS - Parsec, a tribute to the first game I came to love and get really good at. And First Person Shooter to take Parsec to a new level. MK MMXXI - the year this model is completed!

I would like to be a part of it! My main "super power" is the graphics! I love to tinker and make stuff look great. So I am hoping to recrute some people to make this game, and in worst case I am leaving the game up for anyone to make it. I will try to brainstorm it as much as possible and try to keep it within the TI frame.

Tools in the game!
USTF - Ultra Sonic Target Focus (Tribute to my Canon camera and its USF!) This is a "computer" in the MK MMXXI Parsec FPS that aid the pilot to shoot the bady!

3DS - 3 Dimension Scanner - This has the same look as Elite, another tribute! Pluss there are tre color lights to indicate when your lined up with the bady. Horizontally and vertically. This can be scrapped or made very simple!

LG - Life Gage - This shows the temp of your laser, the Armor and Fule lvl. (Life is Good, as long as you have stuff here)
Main Computer - Where main info is displayed!
Target Computer - Displays distance to next section(end), Numbers of enemy, Distance to Texas! When fueling, it will change and show fueling info.

Missile bay Computer - 1 EMP (save my ass), 3 Self seeking destroyer!

Fueling!

Here you can refuel, refill missile, re-armor the Star shooter!  

 

Making money on the run!

Metal scoops! MK MMXXI Star shooter is equipped with a on the run metal scoop. With the metal scoop you make money to pay for your upgrades. That is a part of the fighting to get to Texas! This way you can also fill you wallet with cash to do bigger upgrade every "next lvl"
- Better fuel efficiency!
- Better Armor!
- Better Laser!
- Better Missiles and more of them!
- ???

 

Armor!

3 Center hits - dead!

5 Partial hits (66%) hits - dead!

10 Barely hits (33%) hits - dead!

 

Every 5 second 15 % upgrade!

Screen!
Light Gray box: Target Computer - Displays distance to next section(end), Numbers of enemy, Distance to Texas!

Dark Gray box: This is where the action is happening, trying to limit all the hard graphics here. Also the USTF is in the middle in it! 

Radar box: Trying to make it simple and another way to show info about targets.

Blue box: Missile bay Computer

Red box: Main Computer - Where main info is displayed!

Pink box: LG - Life Gage - This shows the temp of your laser, the Armor and Fule lvl.

Important to make all the "other screens" as simple as possibility to take as little power from the TI. So that the "Dark Gray box" has all the power possibly!

 

This is just a starting point!

So... are YOU interested?

Edited October 15, 2020 by oddemann

[WhataKowinkydink]

Cool idea ?

 

[Elia Spallanzani fdt]

https://atariage.com/forums/topic/305987-raycaster/?tab=comments#comment-4521620

[+FarmerPotato]

Hi! I think there should be a Parsec sequel.  I have a lot of ideas of my own for a 2D scroller intended for the F18A. But..

Also inspired by Raycaster, and on the 4A, regular bitmap mode:

I have worked out the math for a "Death Star" trench run. It is much less general than Rasmus' raycaster. The view is in a trench, with texture-mapped sides and fixed stars. You see your ship and others as hardware sprites.  It uses pre-calculated raycast tables for every X, Y position of your starfighter. The shifting point of view will be dramatic.

 

I think it could fill across the middle third of the screen, in fat-pixel mode (1x4, just like Rasmus' Raycaster) and achieve an acceptable frame rate, pushing up to 2K/frame to VDP.

 

If the frame rate is not acceptable, figure out optimizations, or make the view narrower.

 

Ships would be regular sprites, not textures (I guess.) 

 

The 32K memory expansion is allocated as: 12.5K data, 8K texture, 2K for sprites, the rest for program. If it were a paged 64K cartridge, 32K for texture, more sprites.

 

[+FarmerPotato]

Trench Run Technical Details (boring)

Spoiler

Technical detail:

 

For each of 128 player X positions, and each of 64 fat pixel columns, there are indexes Z into the textures of the left and right walls. The foreshortening height Y is a pre-calculated function of 1/Z. For every player Y position (Y is up) there are pre-calculated top and bottom screen rows. For each column height, there are interpolating index to sample the texture. 

 

I pre-calculated the tables already, in a C program.  Walls are painted by a big texture, 256 pixels long by 32 high, with up to 2x magnification closest to you.

 

Optimizations

 

Double the texture memory. Pre-shift the texture by 4 bits (>F0 and >0F)

 

Not re-drawing transparent pixels.

 

2/3 of the screen is probably excessive and really messes up the pointer math.

 

Use double buffering. Works on bottom only.  pattern table fixed, doubles as color table in top third

 

VDP Memory map, by 2K:

0000 F0 pattern table 2
0800 --
1000 color page 1
1800 --
2000 F0 pattern table 1 (is one enough?)
2800 --
3000 color page 2
3800--

 

If some chars are trimmed from bottom third edges, these can be reused in top two thirds.

 

CPU memory map:

 

2000 Code (Is it irrelevant to EA5 loader?)
6000 paged area
A000 Sprites. (3K) YTABLE (0.5K)
B000 YTABLE. 4K
C000 ZTABLE. 8K
E000 TEXTUR. 8K

 

If 6000 is paged, it would be 32K TEXTUR data. Each column runs through all 4 pages, causes >8000 bit on increment, use JLT.

Hey, what if digitized sound were interleaved.

 

Graphics mode:

 

The middle third of bitmap mode has pattern table filled with >F0. The screen image table is arranged with >00 to >07 down the first column, and so on. This makes 2 fat pixels columns continuous in video memory, so the column drawing loop sets the address once, then writes 64 bytes of texture data, then another 64... The address is already aligned to write the next column. So the frame rate is determined by the time to do many indexed loopups, OR two texture columns, while writing 64x32 or 2K bytes to VDP. 

 

There's not a lot of scope to unroll loops. Inner loop is reading index tables.

 

* texture layout:
* row-major, 256 x 32 bytes, each byte holding a 4 bit color in low nybble => 8K

* Z table is 1024 word values, giving a foreshortening factor, which points to an STABLE (there are 64 with scaling 2x down to 0x)

from precalculated X table for player X=64 (center position): 33 35 37 40 44 48 53 59...37 35 33 (64 entries)
from indexing precalculated Z table: 0 1 2 4 5 11 17 23...23 17 11 5 0 0 0 0 (64 columns)

 

 

[oddemann]

4 minutes ago, FarmerPotato said:

Hi! I think there should be a Parsec sequel.  I have a lot of ideas of my own for a 2D scroller intended for the F18A. But..

Also inspired by Raycaster, and on the 4A, regular bitmap mode:

I have worked out the math for a "Death Star" trench run. It is much less general than Rasmus' raycaster. The view is in a trench, with texture-mapped sides and fixed stars. You see your ship and others as hardware sprites.  It uses pre-calculated raycast tables for every X, Y position of your starfighter. The shifting point of view will be dramatic.

 

I think it could fill across the middle third of the screen, in fat-pixel mode (1x4, just like Rasmus' Raycaster) and achieve an acceptable frame rate, pushing up to 2K/frame to VDP.

 

If the frame rate is not acceptable, figure out optimizations, or make the view narrower.

 

Ships would be regular sprites, not textures (I guess.) 

 

The 32K memory expansion is allocated as: 12.5K data, 8K texture, 2K for sprites, the rest for program. If it were a paged 64K cartridge, 32K for texture, more sprites.

 

I was thinking the same... but more like a "night rider"!

Using the original pics from Parsec as ground. Like they are moving closer under you. And make "shadow" trees. Some stars moving slowly. So a kinda invisible "Death Star" trench, but open. Mostly dark, so that the only stuff that steals power is the enemy getting closer.

[+FarmerPotato]

Trench Run inner loop (Code) (boring!)

 

Spoiler

* ZTABLE  64 rays through screen X strike wall at distances Z. Precalculated for every player X[0..127]. 128*64 = 8K. 
*         Z is capped at 255, infinity. Usually 25% of view shows infinity.
* YTABLE  For a given Z, the foreshortening factor Y. Y=0 corresponds to 2x, Y=63 corresponds to 0x. 256 words.
* STABLE  sampling indexes for a given Y. 64x64 = 4K.
* TEXTUR  row-major, 256x32. 8K. If paged memory allows, could be expanded as far as 2048x32, 32K.
*
* Total data: 20.5K. Might add 24K more texture if paged.
*
* sprite data
* per 16x16 ship with 16 scale factors: 1K


* R7 is distance travelled so far. Increments by speed. Texture wraps every 256 ticks, to create the effect of movement.


* Sampling table STABLE
* if texture were stored row-major and there were 256 columns, then adding >0100 would advance by one pixel => 16K.
* if texture were stored column-major, then adding >0001 would advance by one pixel

* A height value is 0-63. It indexes
* 4K STABLE is 64 tables of 32 entries. Each table's values sum to 32, for sampling a column of the texture. Produces foreshortening.
* STABLE looks like: 
* 1 0 1 0 1 0 1 0 1 0 1...1 0 1 0  (64 entries  scaling factor 2.00) (last entry doesn't matter)
* ...
* (16 zeros) (32 ones) (16 zeros)  (64 entries  scaling factor 1.00, filling middle half of the column)
* ...
* (17 zeroes) (26 ones and 3 twos) ...(18 zeroes)  (64 entries  scaling factor 0.90) (leading and trailing zeroes indicate reduction)
* ...
* note: Z height in pixels is the number of non-zero entries in STABLE column
* last or first byte could store this value.

* draw the screen:
 MOV @PLAYRX,R8    
 SLA  R8,6
 AI   R8,ZTABLE    * R8 = ZTABLE+x*64, a precalculated table of Z for each player x. table is distances at which 64 rays struck the side

 LI   R10,32       * # loops on screen column

 LI   R0,>6800
 BL   @SETVA       * Set vdp address to >2800 color table
 
* loop per screen column.  one screen column consumes two *R8+: drawing the even and odd fat pixels.

LOOP
* evens
 CLR   R3
 MOVB *R8+,R3       * R3 distance at which the ray struck the side
 SWPB  R3
 MOV   R3,R4

 A     R7,R3        * add distance travelled down trench
 ANDI  R3,>1FC0     * repeat texture each 8K, or 256 columns
 AI    R3,TEXTUR    * R3 pointer into texture column to sample

 A     R4,R4
 MOV  @YTABLE(R4),R4    * YTABLE (words) is height as a function of 1/distance, premultiplied by 64
 AI    R4,STABLE    * R4 pointer into sampling table for this Z
* TBD: shift up or down, including more or less of the transparent pixels, function of player Y position and z height

* odds: merely change R3,R4 to R5,R6 in the above code
 CLR   R5
 MOVB *R8+,R5       * R5 distance at which the ray struck the side
 SWPB  R5
 MOV   R5,R6

 A     R7,R5        * add distance travelled down trench
 ANDI  R5,>1FC0     * repeat texture each 8K, or 256 columns
 AI    R5,TEXTUR    * R5 pointer into texture column to sample

 A     R6,R6
 MOV  @YTABLE(R6),R6    * YTABLE (words) is height as a function of 1/distance, premultiplied by 64
 AI    R6,STABLE    * R6 pointer into sampling table for this Z
* TBD: shift up or down, including more or less of the transparent pixels, function of player Y position and z height

 BL   @PAINT
 DEC  R10
 JNE  LOOP
 


* fill 64 rows of 1 screen column, sampling and combining 2 columns of texture
PAINT
 CLR   R1
 LI    R2,64
PAINT1
 MOVB *R3+,R1      * even color
 SLA   R1,4
 SOCB *R5+,R1      * odd color
 MOVB  R1,@VDPWD

 AB   *R4+,R3      * 0100 advances by 256 bytes or 1 texture row (texture is stored column-major) 
 AB   *R6+,R5

 DEC   R2
 JNE   PAINT1     * repeat 32 times 
 RT

 

 

[oddemann]

Just now, FarmerPotato said:

Trench Run inner loop (Code) (boring!)

 

  Reveal hidden contents

* ZTABLE  64 rays through screen X strike wall at distances Z. Precalculated for every player X[0..127]. 128*64 = 8K. 
*         Z is capped at 255, infinity. Usually 25% of view shows infinity.
* YTABLE  For a given Z, the foreshortening factor Y. Y=0 corresponds to 2x, Y=63 corresponds to 0x. 256 words.
* STABLE  sampling indexes for a given Y. 64x64 = 4K.
* TEXTUR  row-major, 256x32. 8K. If paged memory allows, could be expanded as far as 2048x32, 32K.
*
* Total data: 20.5K. Might add 24K more texture if paged.
*
* sprite data
* per 16x16 ship with 16 scale factors: 1K


* R7 is distance travelled so far. Increments by speed. Texture wraps every 256 ticks, to create the effect of movement.


* Sampling table STABLE
* if texture were stored row-major and there were 256 columns, then adding >0100 would advance by one pixel => 16K.
* if texture were stored column-major, then adding >0001 would advance by one pixel

* A height value is 0-63. It indexes
* 4K STABLE is 64 tables of 32 entries. Each table's values sum to 32, for sampling a column of the texture. Produces foreshortening.
* STABLE looks like: 
* 1 0 1 0 1 0 1 0 1 0 1...1 0 1 0  (64 entries  scaling factor 2.00) (last entry doesn't matter)
* ...
* (16 zeros) (32 ones) (16 zeros)  (64 entries  scaling factor 1.00, filling middle half of the column)
* ...
* (17 zeroes) (26 ones and 3 twos) ...(18 zeroes)  (64 entries  scaling factor 0.90) (leading and trailing zeroes indicate reduction)
* ...
* note: Z height in pixels is the number of non-zero entries in STABLE column
* last or first byte could store this value.

* draw the screen:
 MOV @PLAYRX,R8    
 SLA  R8,6
 AI   R8,ZTABLE    * R8 = ZTABLE+x*64, a precalculated table of Z for each player x. table is distances at which 64 rays struck the side

 LI   R10,32       * # loops on screen column

 LI   R0,>6800
 BL   @SETVA       * Set vdp address to >2800 color table
 
* loop per screen column.  one screen column consumes two *R8+: drawing the even and odd fat pixels.

LOOP
* evens
 CLR   R3
 MOVB *R8+,R3       * R3 distance at which the ray struck the side
 SWPB  R3
 MOV   R3,R4

 A     R7,R3        * add distance travelled down trench
 ANDI  R3,>1FC0     * repeat texture each 8K, or 256 columns
 AI    R3,TEXTUR    * R3 pointer into texture column to sample

 A     R4,R4
 MOV  @YTABLE(R4),R4    * YTABLE (words) is height as a function of 1/distance, premultiplied by 64
 AI    R4,STABLE    * R4 pointer into sampling table for this Z
* TBD: shift up or down, including more or less of the transparent pixels, function of player Y position and z height

* odds: merely change R3,R4 to R5,R6 in the above code
 CLR   R5
 MOVB *R8+,R5       * R5 distance at which the ray struck the side
 SWPB  R5
 MOV   R5,R6

 A     R7,R5        * add distance travelled down trench
 ANDI  R5,>1FC0     * repeat texture each 8K, or 256 columns
 AI    R5,TEXTUR    * R5 pointer into texture column to sample

 A     R6,R6
 MOV  @YTABLE(R6),R6    * YTABLE (words) is height as a function of 1/distance, premultiplied by 64
 AI    R6,STABLE    * R6 pointer into sampling table for this Z
* TBD: shift up or down, including more or less of the transparent pixels, function of player Y position and z height

 BL   @PAINT
 DEC  R10
 JNE  LOOP
 


* fill 64 rows of 1 screen column, sampling and combining 2 columns of texture
PAINT
 CLR   R1
 LI    R2,64
PAINT1
 MOVB *R3+,R1      * even color
 SLA   R1,4
 SOCB *R5+,R1      * odd color
 MOVB  R1,@VDPWD

 AB   *R4+,R3      * 0100 advances by 256 bytes or 1 texture row (texture is stored column-major) 
 AB   *R6+,R5

 DEC   R2
 JNE   PAINT1     * repeat 32 times 
 RT

 

 

I trust you, if you say it is boring :p I can see the code, I understand that this dos SOMETHING :p lol but I am clueless!

BUT... It sounds like you would like to make something like this?

I can not help you out with the code. Can I help with the graphic in any way if you would like to try to make it? I can make a story book for every section on first lvl and so on. I have ideas about how to make stuff small but visually interesting and looking like speed.

[oddemann]

Dos anyone know where I can find the original pics of objects in Parsec? Want to use true pic of the original stuff in the old Parsec, in the new. Along with new stuff.

Working on making new stuff.

But I need to make pictures of the old stuff on the ground, from fare to near. To get a feel of speed.

PS! Testing... smaller...

Edited October 16, 2020 by oddemann

[+FarmerPotato]

I have just used Classic99 and taken a screenshot. Or magnify and draw pixel by pixel in Magellan. Really Magellan format is very convenient to include in a program. 
 

 

[oddemann]

32 minutes ago, FarmerPotato said:

I have just used Classic99 and taken a screenshot. Or magnify and draw pixel by pixel in Magellan. Really Magellan format is very convenient to include in a program. 
 

 

I use it myself, very good to make pics and get the code out.

New update on the flight console...

[+Ksarul]

The patterns for the original graphics are in the source code for Parsec. You can find that in the resources thread. Paul Urbanus and I took a somewhat passable copy of the source code and turned it into a complete, modern file a few years back.

[Asmusr]

18 hours ago, FarmerPotato said:

Hi! I think there should be a Parsec sequel.  I have a lot of ideas of my own for a 2D scroller intended for the F18A. But..

Also inspired by Raycaster, and on the 4A, regular bitmap mode:

I have worked out the math for a "Death Star" trench run. It is much less general than Rasmus' raycaster. The view is in a trench, with texture-mapped sides and fixed stars. You see your ship and others as hardware sprites.  It uses pre-calculated raycast tables for every X, Y position of your starfighter. The shifting point of view will be dramatic.

 

I think it could fill across the middle third of the screen, in fat-pixel mode (1x4, just like Rasmus' Raycaster) and achieve an acceptable frame rate, pushing up to 2K/frame to VDP.

 

If the frame rate is not acceptable, figure out optimizations, or make the view narrower.

 

Ships would be regular sprites, not textures (I guess.) 

 

The 32K memory expansion is allocated as: 12.5K data, 8K texture, 2K for sprites, the rest for program. If it were a paged 64K cartridge, 32K for texture, more sprites.

 

That sounds interesting. I'm looking forward to see some visuals.

[oddemann]

I have split the "Action screen" in 4.

#1 Ground... Where art from the old Parsec will move under and back.

#2 and 3 Side... Shadow of trees, towers and mountain, that also moves from front to back. But art will only partly show, "moon light" shadow will barely show them. This will save CPU power, i think.

#4 This is all screen on top of all that is made to project speed!

[oddemann]

112*80 is the screen size where the main action will show.

I will make a "test pic" of how it can look like with the environment in moon light.

Thinking about it... I don't think you need to make a full picture of everything. Just a outline from top and side. Like the moon lighting up just so you see the silhouette. It should give the CPU more power to run it. Maybe then the 112*80 screen can be made bigger. I think that do it in the night is the way to go. Just give the mind so much data that it fills the "holes" it self. Testing... Low resolution is "hell" to make looking good :p But mayeb with speed it will look some what OK...

I also guess that if the silhouettes are made mathematically simple, it makes it faster to draw out stuff. Trees can be made as a line or/and maybe use RND to make branches.

So @Asmusr dos it take more power to make "boxes" that is not symmetrical. Or is it just pure number crunching that matters?

Edited October 16, 2020 by oddemann

[oddemann]

Bady front profile!

Animation test

Small 16*16
Big 64*64 (just to show it better) 

 Dramite Urbite Bynite

Edited October 16, 2020 by oddemann

[oddemann]

More badys...

Thinking... If this is on earth, then asteroids will not fit. Maybe I will change it to "Air mines".

But here are some of the pics so fare... constructive critics?

 Satellite

 LTFs

 Saucers

 Swooper

 Ast

 Ast

 Ast

 Ast

 Ast

 Ast

 Ast

 Ast

 Air mine

Edited October 16, 2020 by oddemann

[oddemann]

Saucers anim, normal and big
 

  16*16

 64*64

Edited October 17, 2020 by oddemann

[Asmusr]

21 hours ago, oddemann said:

So @Asmusr dos it take more power to make "boxes" that is not symmetrical. Or is it just pure number crunching that matters?

If you're talking about a raycaster it cannot draw anything with holes or anything with variable heights.