Great start there Simonh!

How are you calculating the ball angles /velocity ?

Thanks!


I have x-velocity and y-velocity variables which are simply added to the x and y positions, when a collision occurs and a change of direction is required I simply subtract from 255 to get the new velocity.

eg xvel = 1
xpos =xpos + xvel
on collision: xvel = 255 - 1 = 254.
Adding 254 to a byte will have the same effect as subtracting 1.
Next collision: 255 - 254 = 1
No need to calculate angles.



Btw the previous download has poor collision detection and I've changed it a bit but not tested it much. Here is the updated ssd.

Collision detection seems fine to me ... have just one long go for a couple of minutes and can't see any issues.

Good luck with the project - I'll be checking back regularly to download and test all the alpha/beta versions!

Cheers Dave!

Another update.
I have the wall up and collision detection is working except I don't remove the brick on collision - I ran out of time as I have an early start tomorrow. That's a job for next week as I'm busy at work from now until Monday or maybe even Wednesday.

Nice to see the game starting to take shape ... keep the updates coming thick n' fast!

Neither WinRAR or WinZip are able to do anything with the file you uploaded, and I go through enough archive formats to know that the problem ain't at my end. Can you re-upload?

I think he said to rename it, not extract it.

You may have done your own timer code by now, I didn't check.

Here is the code for my colour change timers, I have moved it from SysVia to UsrVia as I hadn't checked if you still had the OS running.

The important bit to making it steady is starting T1 at vsync and then using the free running latches so as not to introduce any more errors. You could just set T1 free running and just reset the count at vsync for an even steadier result, but you would have to run non-interlaced.

To move the who lot up, subtract from VSyncToTop, or add to move down. ScanLineUs (64) is one virtical pixel, so you can roughly judge moving sideways.
You can move the transition area off the side of the screen, but as you have a blank pixel between rows, I would do it there so that you have the maximum variation without seeing anything.

I would use Pal4Col0 to get the timing right, and then swap to the brick colour.

I wouldn't recommend using it like (don't know what you might have using T1) this, but as an example in an emulator it should be OK, possibly disable HW if it doesn't look correct.

As I said, I use SysViaT1 and no OS, so this is just an example. RichTW is far better on configuring the timers than I am.

20 REM Sample colour timer code
30 *K.10O.|MREN.|ML.07|ML.|M
40 MODE 1

You could use mode 5, or for breakout, even mode 4 would be OK, but the palette code is slightly different.

timer related stuff

50 Reload = 2
60 ScanLineUs = 64
70 RowPeriod = 8 * ScanLineUs - Reload
80 VSyncToTop = 4 * 8 * ScanLineUs - Reload

various useful addresses and values

90 IRQV1 = &204
100 UsrViaT1CL = &FE64
110 UsrViaT1CH = &FE65
120 UsrViaT1LL = &FE66
130 UsrViaT1LH = &FE67
140 SysIntVSync = &02
150 UsrIntT1 = &40
160 SysViaIFR = &FE4D
170 UsrViaACR = &FE6B
180 UsrViaPCR = &FE6C
190 UsrViaIFR = &FE6D
200 UsrViaIER = &FE6E
210 VideoULAPalette = &FE21
220 Pal4Col0 = &00
230 Pal4Col1 = &20
240 Pal4Col2 = &80
250 Pal4Col3 = &A0
260 PaletteWhite = &00
270 PaletteCyan = &01
280 PaletteMagenta = &02
290 PaletteBlue = &03
300 PaletteYellow = &04
310 PaletteGreen = &05
320 PaletteRed = &06
330 PaletteBlack = &07
340 :

somewhere to put the code

350 DIM code 500
360 FOR pass = 0 TO 2 STEP 2
370 P%=code
380 [OPT pass

redirect IRQ1V to our handler and then chain the original vector to exit

390 sei
400 lda IRQV1 : sta prev_irq1
410 lda IRQV1+1 : sta prev_irq1+1
420 lda #handler MOD 256 : sta IRQV1
430 lda #handler DIV 256 : sta IRQV1+1

clear any pending T1 interrupt (not really needed)

440 lda #&00 OR UsrIntT1
450 sta UsrViaIER : sta UsrViaIFR

configure T1 in freerunning mode (best check with RichTW)

460 lda #4 : sta UsrViaPCR
470 lda #64 : sta UsrViaACR
480 cli
490 rts
500 :

our inserted interrupt handler

510 .handler
520 lda SysViaIFR
530 and #SysIntVSync
540 beq not_vsync

it was a vsync, set up first timer to bottom of first line and then latch a value for every 8 pixels down (this will keep firing every char row).

550 lda #VSyncToTop MOD 256 : STA UsrViaT1CL
560 lda #VSyncToTop DIV 256 : STA UsrViaT1CH
570 lda #RowPeriod MOD 256 : STA UsrViaT1LL
580 lda #RowPeriod DIV 256 : STA UsrViaT1LH
590 lda #0 : sta counter

enable T1 interrupts

600 lda #&80 OR UsrIntT1
610 sta UsrViaIER
620 .done
630 jmp (prev_irq1)
640 :
650 .not_vsync
660 lda UsrViaIFR
670 and #UsrIntT1
680 beq done
690 :

clear the T1 interrupt

700 sta UsrViaIFR

change palette to next colour and if not last, done

710 tya : pha
720 ldy counter
730 lda colours,Y
740 jsr set_palette_colour
750 iny : sty counter
760 cpy #colours_end-colours
770 pla : tay
780 bcc done
790 :

last colour change, disable T1 until vsync (but I think stuff uses T1 if OS enabled)

800 lda #&00 OR UsrIntT1
810 sta UsrViaIER
820 jmp (prev_irq1)
830 :

change this routine if you aren't going to use a four colour mode.

840 .set_palette_colour
850 sta VideoULAPalette : eor #&10
860 sta VideoULAPalette : eor #&40
870 sta VideoULAPalette : eor #&10
880 sta VideoULAPalette
890 rts
900 :

few bits of storage

910 .prev_irq1
920 EQUW 0
930 .counter
940 EQUB 0
950 .colours
960 EQUB Pal4Col0 OR PaletteWhite
970 EQUB Pal4Col0 OR PaletteCyan
980 EQUB Pal4Col0 OR PaletteMagenta
990 EQUB Pal4Col0 OR PaletteBlue
1000 EQUB Pal4Col0 OR PaletteYellow
1010 EQUB Pal4Col0 OR PaletteGreen
1020 EQUB Pal4Col0 OR PaletteRed
1030 EQUB Pal4Col0 OR PaletteBlack
1040 .colours_end
1050 .y_save
1060 EQUB 0
1070 ]
1080 NEXT pass
1090 PRINT~code
1100 PRINT P%-code
1110 CALL code

after starting the routine, it will just carry on, changing the background.

Always back up your work.
I go on and on at my wife when she accidentally deletes something and the one time I do something I really value I break my own rule.
Bugger!
On the positive side it means I will be starting again but with a lot more knowledge than I had last time.
I'm going to follow Tricky's advice and have a 256 pixel wide screen to make things easier. I'm going to look at other sprite code but write my own rather than just rip one from a book.
I have redesigned the entire program - first time round I had a basic idea of what to do and coded a bit then moved the code around until it worked and was understandable. This time I know how to do it, have planned it out in detail and will begin by typing up a detailed set of comments which I can then pad out with code so everything is more readable.
I know where to look for information - which books and websites have what I need.
I'm annoyed that this has set me back but the process has done what it was meant to do - helped me to learn how to program in assembly language. I'm still a beginner but I'm much more knowledgeable and confident that I was just a few weeks ago.
I feel confident that I'll be back to where I was in no time at all and hope to have a basic playable version ready for the meetup in November.
Thanks for the code Tricky, I'll probably have a good read of that once I get back to where I was when I lost everything.
I'm off to have a little cry now.

I have learnt that lesson many times, and now use the free version of Perforce. I know open source people don't really like it, but my code isn't, so I use the most reliable program that works the way my brain does
Any source control system will do, but I highly recommend using one as it is invaluable for finding what you broke some versions ago, but can't remember when, or why or how.

We used Perforce p4 in my last job but it started to hold back development in a similar way to Subversion in my current job. I use Mercurial for most personal projects, and Mercurial repositories can be hosted here at Retro Software.

Simonh, you're welcome to look at my source code for biplane game. I have routines for a 128pixel wide (easily amended) mode 5 type screen based on Tricky's advice. I also have routines which clear the screen and set initial colours in the custom screen mode.

Coupled with this is a sprite routine I wrote that plots in column major order. It uses sprites drawn in RTW's BeebSpriter (in Dev Tools page of this site).

These might be useful to you. ..? [Code = beebasm. Routines to look for are .PlotSprite, .WipeSprite and .SetupGameScreen]

Edit: for an excellent explanation of sprite plotting in column order, as well as the Beeb's screen layout, I found this document in the SWIFT tool pages on this site. It talks about the SWIFT tool but the explanation is applicable to any sprite work done on the Beeb.

http://www.retrosoftware.co.uk/wiki/images/7/70/Sprite_Data_Formats.zip