Tempest is possible

Use this forum to share and discuss Uzebox games and demos.
Post Reply
CunningFellow
Posts: 1174
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Tempest is possible

Post by CunningFellow » Sat Jun 22, 2013 3:47 am

Although I said I could not do it, I now am pretty certain I can pull Tempest off.

Whats even better is that I can now do it in the same 256 pixel wide nice aspect ratio that I used for Asteroids.

256 x 208 x 5 colours (Blue, Black and 3 user selectable colours per scan line)
Self erasing screen.
enough ramTiles for a fairly busy game (128 x 8x8)
Bootloader compatible

Only 2 downsides

Line drawing between 1/2 and 1/4 the speed of Asteroids.
Rendering and line drawing code will take up over 32K of flash.

User avatar
uze6666
Site Admin
Posts: 4448
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Tempest is possible

Post by uze6666 » Sat Jun 22, 2013 4:48 pm

Cool ! So what the trick? 8-)

CunningFellow
Posts: 1174
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Re: Tempest is possible

Post by CunningFellow » Sat Jun 22, 2013 10:40 pm

Well - you obv. realise I am making a 2x256 entry long code table for the 4 colour foreground. And that is why I am using up so much flash.

But still 5 clocks per pixel would never be enough to work out the address for the next IJMP if I had to use MUL/MOVW/ADD/ADC

I have worked out some logic and layout that means I can kind of MUL x30 and leave the result in Z with 2 or 3 less clocks taken. It has been a bit tricky working out how to do this without trashing the boot loader but I have managed it I think.

Also the reason the background can only be blue is the way I am getting that down in clocks. It worked out quite well that you chose BBGGGRRR as the colour map. If you shift a bit INTO the register being used for colour then it is either BLUE or BLACK. It is very fortunate that the WEBs in tempest are blue.

Right at the moment though my health has taken a bit of a turn for the worst, so I am going to take a bit of a break.

When I come back I am going to need some help learning how to use the SD card on the UzeBox as I am going to have to store the WEB bitmaps on SD.

greenpower
Posts: 62
Joined: Mon Jun 13, 2011 7:48 pm
Location: Benidorm, Spain

Re: Tempest is possible

Post by greenpower » Sun Jun 23, 2013 1:29 am

Lets all rejoice and thank the great CunningFellow for his great milestone in Uzebox history.
Now, seriously, thank you so much. :D :D
I know i'm too young, but it doesn't matters. Maybe i'm a newbie, but i can learn very fastly

CunningFellow
Posts: 1174
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Re: Tempest is possible

Post by CunningFellow » Sun Jun 23, 2013 4:41 am

OK - Have worked out how to have background WHITE or BLUE. Has to be set at compile time though. Can't change it on the fly.

WHITE Mostly it is Uzes trick used in Mode-6 as shown here

Code: Select all

ROL   r19        ; Move Pixel/Bit into CARRY
SBC   r2,r2      ; subrtact R2 from R2 with carry
                 ; (will be 0xFF if carry set     or 
                 ;          0x00 if carry clear)
OUT   PortX,r2   ; Put out pixel
But I have to change the endian-ness of the bit-orders so I can use ASR

Code: Select all

ASR   r19        ; Move Pixel/Bit into CARRY
                 ; and duplicate b7 back into b7
SBC   r2,r2      ; subrtact R2 from R2 with carry
                 ; (will be 0xFF if carry set     or 
                 ;          0x00 if carry clear)
OUT   PortX,r2   ; Put out pixel

; This gets repeated 7 times
; but on the 8th time we only need to

NOP              ; LOOK WE HAVE 2 free clocks here
NOP              ; because r19 already has 0b77777777
OUT   PortX,r19  ; YAY
Only a slight difference but that 2 extra free clocks is very important. (I need at least ONE free clock from the background shift to do the fake MUL x31)

CunningFellow
Posts: 1174
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Re: Tempest is possible

Post by CunningFellow » Sun Jun 23, 2013 5:10 am

OH and before anyone asks here is the original way I got 8 BLUE pixels with one free clock

Code: Select all

; Way up front before the render loop

ldi   r17, 0x80  ; Value to multiply that is effectivly ROR>>1



; Then in the render loop after r19 has the pixel-byte

MUL   r19, r17   ; Shift R19 right by 1 leaving 16 bit result in R0:1
OUT   PortX, R0  ; output the BLUE pixel

MUL   r17, r1    ; Shift r1 right by 1 leaving 16 bit result in R0:1
OUT   PortX, R0  ; output the BLUE pixel

; Do the MUL r17,r1 bit 5 more times
; Then for the last pixel you still have the original
; unaltered value in r19 so you just

ANDI  r19, 0x80  ; clear out the lower 7 bits
NOP              ; AND YAY another free clock :)
OUT   PortX, R19

CunningFellow
Posts: 1174
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Re: Tempest is possible

Post by CunningFellow » Sun Jun 23, 2013 5:24 am

OH - and yes - it is possible to make the background ANY single bit colour at compile time.

Code: Select all

B0000000  Bright-ish Blue
0B000000  Dark Blue
00G00000  Bright-ish Green
000G0000  Medium Green
0000G000  Dark Green
00000R00  Bright-ish Red
000000R0  Medium Red
0000000R  Dark Red
By changing the way the bit map is stored and using BLD/BST/OUT for 7 pixels and then ANDI/NOP/OUT for the 8th pixel.

For example if you wanted the background to be bright green (good old green CRT colour) then you would store the bitmap in the order

Code: Select all

76054321
Then you would do the following in the byte render code

Code: Select all

BST   r19, 7     ; Store the first pixel into T
BLD   r2, 5      ; Load the first pixel from T into the output REG
OUT   PortX, r2  ; Output the first green pixel

BST   r19, 6     ; Same for the next 6 pixels but note
BLD   r2, 5      ; the order/skip of BIT 5
OUT   PortX, r2

BST   r19, 4
BLD   r2, 5
OUT   PortX, r2

BST   r19, 3
BLD   r2, 5
OUT   PortX, r2

BST   r19, 2
BLD   r2, 5
OUT   PortX, r2

BST   r19, 1
BLD   r2, 5
OUT   PortX, r2

BST   r19, 0
BLD   r2, 5
OUT   PortX, r2

ANDI  r19, 0x20  ; Because down here we only have to ANDI to get BIT 5
NOP              ; Free Clock WOOOO HOOOO
OUT   PortX, R19

CunningFellow
Posts: 1174
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Re: Tempest is possible

Post by CunningFellow » Sun Jun 23, 2013 5:49 am

And - the above BLD/BST bit also kind of means you COULD have the BACK-BACK-Ground any colour you wanted as long as the FORE-BACK-Ground is only one pixel different

YELLOW vs WHITE
AQA vs BRIGHT GREEN
PURPLE vs RED
OLIVE vs BRIGHT BLUE

Or about 100 more gaudy horrible combinations instead of boring old BLUE-BLACK or WHITE-BLACK

CunningFellow
Posts: 1174
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Re: Tempest is possible

Post by CunningFellow » Sun Jun 23, 2013 5:57 am

aoeuidrtns, greenpower,

sorry - I probably won't be doing a Tempest 2000 soundtrack on it as per your previous request.

In all likely hood I may not do sound at all. I'll leave sound up to someone else if they want too. Sound doesn't work for me all a lot of the time.

I promise to make it fluid, fast and frantic graphics though.

CunningFellow
Posts: 1174
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Re: Tempest is possible

Post by CunningFellow » Sun Jun 23, 2013 6:17 am

Point out here though.

BLUE is the preferred colour for the background.

Using Blue I can get the code table down to 24603 bytes with an 8179 byte space in the middle to put the line drawing code.

With the White/Any-Colour version of the code the code-table takes full 32792 bytes.

BTW - I just applied some of the silly logic tricks to the 480x224(448) pixel 2 colour mode I did and I can do it now without trashing the bootloader as well so eventually I may do a higher res asteroids. It will be asteroids only though as I will need to pre-cook the objects rather than the full 2d geometry engine I currently have.

Really starting to vague out a bit here so if I make any more posts today they may be making less and less sense.

EDIT:

As I said yesterday - I may not be making sense all the time.

I remember now the reason I gave up on the 480x448 mode. The only way I could store the screen was as RLE of the VRAM and it ended up too slow. At least the way I was trying was too slow. I may revisit it later but Tempest is the lead project now.
Last edited by CunningFellow on Mon Jun 24, 2013 10:00 am, edited 1 time in total.

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest