New game - tube type thingy

Got a programming project in mind? Tell everyone about it!
hexwab
Posts: 32
Joined: Wed Jul 08, 2015 8:27 pm
Contact:

Re: New game - tube type thingy

Post by hexwab » Mon Jan 22, 2018 1:43 am

How about checking to see if the 4 pixels you're about to write are the same as what's already there? Currently you have constant 20 cycles for 4*STA abs,X. Doing

Code: Select all

CMP abs,X ; 4/5
BEQ skip ; 2/3
4*STA abs,X ; 20
.skip
and assuming you're crossing a page boundary half the time works out to 26.5 cycles if different and 7.5 if the same. That's a net win if only 35% of your pixels are the same. Cursory inspection of the video makes me think it's more than that. You'd need to do extra work to force plotting over sprites, of course.

I suspect this would be particularly effective over the Tube, if the parasite is indeed the bottleneck. You'd need a Tube-side copy of the current frame for reference, and hopefully you can arrange it such that you can use zero or bit 7 as a "no need to plot" sentinel:

Code: Select all

LDA $fee1
BMI skip
4*STA abs,X
.skip
Other ideas include a Thrust-style scanlines effect by plotting only alternate lines.

Keep up the good work!

User avatar
1024MAK
Posts: 8033
Joined: Mon Apr 18, 2011 4:46 pm
Location: Looking forward to summer in Somerset, UK...
Contact:

Re: New game - tube type thingy

Post by 1024MAK » Mon Jan 22, 2018 10:07 am

Wow! =D> If this does become a playable game, I'm gonna have to be careful that I don't get motion sickness!

Mark

User avatar
SarahWalker
Posts: 1115
Joined: Fri Jan 14, 2005 3:56 pm
Contact:

Re: New game - tube type thingy

Post by SarahWalker » Mon Jan 22, 2018 9:52 pm

hexwab wrote:How about checking to see if the 4 pixels you're about to write are the same as what's already there?
Ooh, good catch! Just implemented this on the single processor version. While it doesn't quite fit into 3 frames with sprites onscreen, it does keep a nice stable 4 frames now. Overplotting the sprites wasn't too difficult - I'm now setting bit 7 in every byte the sprites touch, which will be seen as 'changed' by the tube plotter. It does need to do some cleanup when the top of a sprite isn't aligned with a tube pixel, but that's not too difficult.

Not sure how much use this will be over the Tube - I think you meant to say 'if the _host_ is indeed the bottleneck'? If the parasite is the bottleneck then this will surely just make it worse! I still need to play with it a bit.

hexwab
Posts: 32
Joined: Wed Jul 08, 2015 8:27 pm
Contact:

Re: New game - tube type thingy

Post by hexwab » Mon Jan 22, 2018 11:42 pm

SarahWalker wrote:
hexwab wrote:How about checking to see if the 4 pixels you're about to write are the same as what's already there?
Not sure how much use this will be over the Tube - I think you meant to say 'if the _host_ is indeed the bottleneck'? If the parasite is the bottleneck then this will surely just make it worse! I still need to play with it a bit.
You are correct, I did. (Isn't the official terminology "coprocessor" or "application processor" and "I/O processor"? Anyway, I misread.) I think I was assuming that because the parasite is ~always faster than the host, and it has less to do (it's relieved of plotting duties), that the host would always be the bottleneck.

User avatar
SarahWalker
Posts: 1115
Joined: Fri Jan 14, 2005 3:56 pm
Contact:

Re: New game - tube type thingy

Post by SarahWalker » Tue Jan 23, 2018 9:06 pm

hexwab wrote:
SarahWalker wrote:
hexwab wrote:How about checking to see if the 4 pixels you're about to write are the same as what's already there?
Not sure how much use this will be over the Tube - I think you meant to say 'if the _host_ is indeed the bottleneck'? If the parasite is the bottleneck then this will surely just make it worse! I still need to play with it a bit.
You are correct, I did. (Isn't the official terminology "coprocessor" or "application processor" and "I/O processor"? Anyway, I misread.) I think I was assuming that because the parasite is ~always faster than the host, and it has less to do (it's relieved of plotting duties), that the host would always be the bottleneck.
It depends on the copro - from my testing, at 3 MHz the copro is the bottleneck, at 4 MHz the host is. I've implemented the comparison check on the host side now, and the speedup isn't subtle - it can now hit 25 fps much of the time! Obviously having sprites on screen will slow that down, but a solid 3 frames seems good.

I've had a look at implementing it on the copro side, and it looks complex - not least because I need to account for double buffering! I'll probably come back to it later.

crj
Posts: 834
Joined: Thu May 02, 2013 4:58 pm
Contact:

Re: New game - tube type thingy

Post by crj » Wed Jan 24, 2018 3:06 am

hexwab wrote:(Isn't the official terminology "coprocessor" or "application processor" and "I/O processor"? Anyway, I misread.)
I thought Acorn used "host" and "parasite"?

User avatar
daveejhitchins
Posts: 4470
Joined: Wed Jun 13, 2012 5:23 pm
Location: Newton Aycliffe, County Durham
Contact:

Re: New game - tube type thingy

Post by daveejhitchins » Wed Jan 24, 2018 8:14 am

@SarahWalker . . . . Love the new avatar =D>

Dave H :D
Parts: UM6502CE, GAL22V10D, GAL16V8D, AS6C62256A, TC514400AZ, WD1772, R6522, TMS27C512, AT28C256
Products: ARA II, ARA III, ABR, ATI, AP6, MGC, AP5 . . .
For a price list, contact me at: Retro Hardware AT dave ej hitchins DOT plus DOT com

User avatar
SarahWalker
Posts: 1115
Joined: Fri Jan 14, 2005 3:56 pm
Contact:

Re: New game - tube type thingy

Post by SarahWalker » Wed Feb 21, 2018 9:15 pm

Haven't posted an update for a bit! I've put the optimisation stuff aside, and started trying to make an actual game out of this. I put together a level editor - after the headache of writing the While Light editor in Win32, I wrote this one in C#, and made as much progress in a couple of hours as I had for WL in a couple of days.
toob_editor.png
Designing 4x4 tiles is pretty rubbish so I've doubled up to 4x8. Which looks slightly better, particularly when running in high res mode.
toob_ingame.png
I've also changed the player physics. Previously there was just a hack where moving left/right simply shifted the tube left/right. Now left/right now actually rotates the player, and the velocity is then applied via sin/cos tables. Braking drops the velocity, friction drops it less. I need to add an acceleration curve, and possibly also some momentum. Lots of trial and error here!

User avatar
Arcadian
Site Admin
Posts: 2941
Joined: Fri Nov 24, 2000 12:16 pm
Contact:

Re: New game - tube type thingy

Post by Arcadian » Thu Feb 22, 2018 7:59 am

Ah cool glad to see another update! Would love to see a new vid (preferably with a screen chock full of those 4x8 designs, which I suspect will look breathtaking!!).
For a "Complete BBC Games Archive" visit www.bbcmicro.co.uk

Image
ABug SOUTH (Hampshire) (1-3 June 2018)

User avatar
SarahWalker
Posts: 1115
Joined: Fri Jan 14, 2005 3:56 pm
Contact:

Re: New game - tube type thingy

Post by SarahWalker » Sun Feb 25, 2018 3:58 pm

Oh go on then - https://www.youtube.com/watch?v=3miRyea ... e=youtu.be.

A couple of other changes I didn't mention - I added a fog effect, as otherwise I found it a little difficult to differentiate between the limited draw distance and the track running out. Also I moved to a fixed game speed, using the basic technique of incrementing a counter on interrupt, then in the main loop plotting when the counter is zero, otherwise run the game logic and decrement the counter.

User avatar
leenew
Posts: 3695
Joined: Wed Jul 04, 2012 3:27 pm
Location: Doncaster, Yorkshire
Contact:

Re: New game - tube type thingy

Post by leenew » Sun Feb 25, 2018 4:08 pm

Very, very clever =D>

Lee.

Mekon
Posts: 14
Joined: Mon Jun 21, 2010 12:33 pm
Contact:

Re: New game - tube type thingy

Post by Mekon » Thu Mar 01, 2018 4:27 pm

Wow! This is looking amazing. I'm starting to regret getting rid of my Master :(

User avatar
danielj
Posts: 6658
Joined: Thu Oct 02, 2008 4:51 pm
Location: Manchester
Contact:

Re: New game - tube type thingy

Post by danielj » Thu Mar 01, 2018 5:28 pm

Holy cow, Sarah!

minwah
Posts: 40
Joined: Tue Jul 21, 2015 12:12 pm
Contact:

Re: New game - tube type thingy

Post by minwah » Fri Mar 02, 2018 11:33 am

Looks brilliant! I'm not familiar with the original Tube game, but it reminds me of Yoomp! on the Atari 8 bits:

http://yoomp.atari.pl/
BBC Master | IFEL Switchable MOS | Sundby PiTubeDirect (Pi 3) | RetroClinic DataCentre | Deltronics Control It

User avatar
Arcadian
Site Admin
Posts: 2941
Joined: Fri Nov 24, 2000 12:16 pm
Contact:

Re: New game - tube type thingy

Post by Arcadian » Fri Mar 02, 2018 10:32 pm

Wow, thanks for posting the new clip Sarah, it's staggeringly impressive! Fog effect seems to work really well also!!
For a "Complete BBC Games Archive" visit www.bbcmicro.co.uk

Image
ABug SOUTH (Hampshire) (1-3 June 2018)

tom_seddon
Posts: 220
Joined: Mon Aug 29, 2005 11:42 pm
Contact:

Re: New game - tube type thingy

Post by tom_seddon » Sat Mar 03, 2018 2:17 am

minwah wrote:Looks brilliant! I'm not familiar with the original Tube game, but it reminds me of Yoomp! on the Atari 8 bits:

http://yoomp.atari.pl/
https://www.youtube.com/watch?v=0uzSt4TOtA0 :)

From memory, Tube had a lookup table that mapped each pixel of a flat 320x200 (or whatever) bitmap to a tubeified position on the 320x200 mode 13h VGA screen. Watch the video and you'll be able to see this sort of thing in action: it's just ordinary 2D stuff drawn as if wrapped round a tube.

--Tom

P.S. when I say "just", what I mean is that because of the way the 486 works - assuming my 25 year old memories are valid? - the main bottleneck ends up being graphics memory write speed. Getting this working on the BBC is a different matter! Let alone making it run at a playable speed ;)

User avatar
SarahWalker
Posts: 1115
Joined: Fri Jan 14, 2005 3:56 pm
Contact:

Re: New game - tube type thingy

Post by SarahWalker » Sun Jun 10, 2018 8:17 pm

I'm not entirely sure this is working as a game. I don't think limiting everything to a tube makes for particularly good handling. I really need to get some outside opinion on this though; the only person who's tested this other than me was Arcadian at the most recent ABUG, and the fact that he struggled with the controls isn't filling me with optimism. Maybe I need to step back from it for a bit?

In any case though, I made some changes pre-ABUG. Namely computer-controlled opponents :
toob_withai.png
Getting multi-coloured opponents on screen involved some sprite code changes. There isn't enough RAM to have multiple sets of vehicle sprites, so everything is now plotted via colour translation tables. In addition, I've dropped sprites to 2 bits per pixel, with the colour translation expanding back up to 4. This obviously complicates the sprite code a bit; the inner plotting loop now looks like this :

Code: Select all

spr_mod_start:
        ldy #8
        lda (spraddr),y
        tax
        ldy #16
        lda (scraddr),y
        and masktable_exp1,x
spr_plot_exp1_mod1:
        ora ortable_exp1,x        
        sta (scraddr),y
        ldy #24
        lda (scraddr),y
        and masktable_exp2,x
spr_plot_exp2_mod1:
        ora ortable_exp2,x        
        sta (scraddr),y  ;2+5+2+2+5+4+4+6+2+5+4+4+6 = 51 cycles, 30 bytes   
The addresses to the ortables are modified at the start of a plot, based on the sprite colour set.

AI is implemented through the old fashioned method of sticking lots of arrows on the map :
toob_arrows.png
The direction determines what angle the vehicle should be accelerating in, and there's code to slow down if the current direction is completely wrong. There are also directions for braking, and just continuing regardless of the current heading.

This is far from perfect, but the opponents currently do a reasonable job of moving round the track.

Video : https://www.youtube.com/watch?v=VjYKYvaWgVg

User avatar
tricky
Posts: 2857
Joined: Tue Jun 21, 2011 8:25 am
Contact:

Re: New game - tube type thingy

Post by tricky » Mon Jun 11, 2018 6:41 am

Looking very good.
Are you heading for a straight race like sprint, or more like simple Mario cart?
The tube certainly gives it a unique look.
Is two player simultaneous an option? I guess that would make controlling the ship even harder.
Or even linking two beebs?
Would it be more playable if you bounced off the edges, probably with a slow down?

User avatar
Kecske Bak
Posts: 692
Joined: Wed Jul 13, 2005 7:03 am
Location: Treddle's Wharf, Chigley
Contact:

Re: New game - tube type thingy

Post by Kecske Bak » Mon Jun 11, 2018 6:46 am

Wouter Scholten has a very solid understanding of how to make arcade games really playable - it might be worth asking what he thinks.

User avatar
Elminster
Posts: 3140
Joined: Wed Jun 20, 2012 8:09 am
Location: Essex, UK
Contact:

Re: New game - tube type thingy

Post by Elminster » Mon Jun 11, 2018 8:43 am

Obviously I can't comment on how it plays (unless we all crowd round at Cambridge ABug for a go) but it is looking good. Another one of those games/demo's etc that would have been mind blowing in the mid 80's (and still looking good in what ever year we are up to now).

User avatar
kieranhj
Posts: 729
Joined: Sat Sep 19, 2015 10:11 pm
Location: Farnham, Surrey, UK
Contact:

Re: New game - tube type thingy

Post by kieranhj » Fri Aug 24, 2018 9:59 am

SarahWalker wrote:
Sun Jan 07, 2018 5:23 pm
For performance reasons I ditched the normal Tube protocol and rolled my own. Commands are sent to the parasite via port 4, data is sent back via port 1 (the one with the big FIFO). Data is sent back in 8 byte packets, with port 2 used on both sides to track progress. The parasite can get 2 packets (16 bytes) ahead, which should help avoid as much waiting on the host side as possible.
Hi Sarah - I definitely want to pick your brains on this at Cambs ABUG but thought I'd ask a couple of questions now to see how far I can get before then.

How are you preventing the normal Tube handlers from running for your own protocol? On the parasite side is it a case of installing a new interupt handler to stop the Tube ROM responding when bytes appear in the Tube? On the host side I'm guessing it's just a case of not returning from your host-side code so the Tube spin loop never gets chance to run? If so, how do you bootstrap both executables?

(I'm currently running a host executable that just installs new handlers for events / oswrch / etc. then returns, then executing the parasite code from the command line which sends data over the Tube using the pre-existing protocols to wake up the host exe as appropriate, so there is no "main loop" on the host side, as it were.)

Would you be willing to share any code snippets for your protocol, so how synchronisation is achieved? I'm in the process of implementing something rudimentary just using a byte R3 to synchronise between host & parasite once per frame (in the vsync event actually) then sending a stream of data (of a known size ~480 bytes) over R3 rather than using the 256 byte read protocol, but it's very flaky. It's very hard to debug in my current version of b-em, I should probably check if the newer builds have better copro debugging support.
Bitshifters Collective | Retro Code & Demos for BBC Micro & Acorn computers | https://bitshifters.github.io/

User avatar
SarahWalker
Posts: 1115
Joined: Fri Jan 14, 2005 3:56 pm
Contact:

Re: New game - tube type thingy

Post by SarahWalker » Fri Aug 24, 2018 5:30 pm

I won't post the code here right now - mainly because it's a mess :) - though I don't mind letting you have a look at ABUG. This seems to be what I did though :

*RUN the parasite side loader, which then :
- *LOADs the host side loader
- Poke the run address of the host side loader into &20e via OSWORD 6
- Call OSWRCH with a dummy value, which will cause the host side to enter the loader
- Disable interrupts (which are never re-enabled)
- Clear out all the tube ULA parasite input ports (probably unnecessary)
- Write a sync value (&a5) to output port 4
- Enter the main loop, polling for host commands on input port 4

The host side loader is entered following OSWRCH, and then :
- Disables all Tube interrupts by writing $0f to $ffe0
- Polls input port $ffe7 for the sync byte
- Then does all the actual loading

In-game, all communication uses polling - the host sends commands through port 4, reads & writes data to and from port 1, and synchronises with the parasite through port 2. Within a command, port 2 is initialised to 0 on both sides at the beginning, then incremented on the parasite side for every packet sent and on the host side for every packet sent. Port 1 parasite->host has a 24 byte FIFO, I've split this into 8 byte packets so the parasite is allowed to get 2 packets ahead of the host before it has to wait.

You could probably handle interrupts via IRQ1V, which would prevent the Tube ROM from interfering, but I didn't try this. If you do though, don't forget that port 3 actually triggers NMIs!

cmorley
Posts: 677
Joined: Sat Jul 30, 2016 7:11 pm
Location: Oxford
Contact:

Re: New game - tube type thingy

Post by cmorley » Fri Aug 24, 2018 6:06 pm

SarahWalker wrote:
Fri Aug 24, 2018 5:30 pm
You could probably handle interrupts via IRQ1V, which would prevent the Tube ROM from interfering, but I didn't try this. If you do though, don't forget that port 3 actually triggers NMIs!
Do you mean on the parasite? During the boot sequence the 2nd P boot code copies the ROM to RAM. It then issues an access to one of the Tube registers which pages out the ROM for evermore. So you can overwrite the client ROM. You can also overwrite the 6502 NMI and IRQ (and reset) vectors on the parasite.

User avatar
kieranhj
Posts: 729
Joined: Sat Sep 19, 2015 10:11 pm
Location: Farnham, Surrey, UK
Contact:

Re: New game - tube type thingy

Post by kieranhj » Sun Aug 26, 2018 9:04 am

SarahWalker wrote:
Fri Aug 24, 2018 5:30 pm
I won't post the code here right now - mainly because it's a mess :) - though I don't mind letting you have a look at ABUG. This seems to be what I did though :
<snip>

Thanks for all the technical details Sarah. I’m on holiday this week, which ironically means less/no coding time as I’m not on the train every day, but I’ll take a look through and likely borrow your approach to get my demo working properly.

I will definitely take up your offer for a look at the code and a chat through all things Tube related at ABUG. :)
Bitshifters Collective | Retro Code & Demos for BBC Micro & Acorn computers | https://bitshifters.github.io/

Post Reply