New game - tube type thingy

Got a programming project in mind? Tell everyone about it!
User avatar
SarahWalker
Posts: 1108
Joined: Fri Jan 14, 2005 3:56 pm
Contact:

New game - tube type thingy

Post by SarahWalker » Mon Jan 01, 2018 5:36 pm

Back at ABUG in November, just after I finished White Light, I had a play with a basic tube effect :
tubeeffect.gif
Though blocky, it runs reasonably smoothly (12.5 fps) and could have been part of a demo. However, back in 1995 or so, I used to have an old Bullfrog PC coverdisk game called Tube :
tube.gif
Tube used basically the same effect and built a game around it. It's not an amazing game - sort of a hybrid between a racing game and a shooter - but it was reasonably fun. I thought it might be an interesting thing to put on the BBC. Plus I like having a project over Christmas!

The results so far :
toob1.gif
toob2.gif
I thought I'd braindump a bit, in the hopes that someone might find this interesting!
Last edited by SarahWalker on Mon Jan 01, 2018 5:38 pm, edited 1 time in total.

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

Re: New game - tube type thingy

Post by SarahWalker » Mon Jan 01, 2018 5:38 pm

The tube effect is table driven. A 32x32 table is built as :

Code: Select all

dx = 31.5 - x
dy = 31.5 - y

dist[y][x] = (16384.0 / (dx*dx + dy*dy))
ang[y][x] = (atan2(dx, dy) * (128.0 / M_PI)) + 128.0
dist and ang are used as U and V coordinates into a 64x64 texture stored in SW RAM. The game plots a 64x56 render using the following basic code :

Code: Select all

ldx x_1          ;x_1 = byte offset for left column
lda y_dat+$000,x
clc
adc YOFF
and #$fc
tay              ;Y = V coordinate
lda x_dat+$000,x
clc
adc XOFF
lsr
lsr
ora #$80
sta t+5          ;(t+4) = address for top-left texel
eor #$20
sta t+11         ;(t+10) = address for bottom-right texel
lda XOFF
clc
sbc x_dat+$000,x
lsr
lsr
ora #$80
sta t+7          ;(t+6) = address for top-right texel
eor #$20
sta t+9          ;(t+6) = address for bottom-left texel
lda (t+4),y
sta $4000,x
sta $4001,x
sta $4002,x
sta $4003,x
lda (t+8),y
sta $7e04,x
sta $7e05,x
sta $7e06,x
sta $7e07,x
ldx x_2          ;x_2 = byte offset for right column
lda (t+6),y
sta $4100,x
sta $4101,x
sta $4102,x
sta $4103,x
lda (t+10),y
sta $7f04,x
sta $7f05,x
sta $7f06,x
sta $7f07,x
4 pixels get plotted at once, to take advantage of the V coordinate being constant in all four quadrants of the screen. This routine is unrolled to plot an entire column. Unless I'm much mistaken this takes 168 cycles to plot 4 pixels, quadrupling the data to fill a MODE 2 screen. For a 64x64 screen this takes 172,032 cycles per frame. To save a bit of time, I shrink the plotting area to 64x56, and use self-modifying code to blank a chunk of pixels in the middle of the screen, which also avoids having to plot too far towards the horizon. This drops the total plot area to 3376 pixels, taking 141,792 cycles or about 3.5 frames. This leaves about half a frame to plot sprites and anything else, while keeping at 12.5 fps - about the minimum I think I can get away with while keeping the game fairly responsive.

I could probably drop an AND in that routine to save 0.5 cycles per pixel, at the cost of having to quadruple the source data. If anyone else can spot any other obvious optimisations please let me know!

Given that it's mapping a 64x64 source texture to a 64x56 frame everything is a bit blocky! There is room to expand the source to 256x64 or 64x256, and some tweaking to use two sideways RAM banks could expand is to 256x128 or 128x256. However, the low output resolution means that aliasing is already a major problem, so I'm not entirely convinced this is really worthwhile. At the moment any real detail disappears at random in the distance, so I'm considering some kind of MIP-mapping to help this.

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

Re: New game - tube type thingy

Post by SarahWalker » Mon Jan 01, 2018 5:42 pm

For sprites, the requirement to handle scaling & rotating sprites means that a more flexible sprite system is required than the one used by White Light, which used an unrolled plot routine with fixed size sprites. Obviously this is going to use a _lot_ of sprites, so there needs to be some kind of management system in place.

Tube used realtime texture mapping for all objects incidentally, which is probably why it ran in slow motion on my old 486/25. Not brave enough to attempt this on a Beeb.

Currently the only fully implemented object (diamonds) uses 4 frames for animation, with 4 levels of scaling, and 8 levels of rotation. This takes a mere 128 sprites, which in total takes about 7.5 kB. Each sprite has a header :

Code: Select all

u16 base
u8 x_size (in bytes)
u8 y_size (in lines)
u8 x_offset
u8 y_offset
u16 filler
The offsets mean that the coordinates passed to the sprite plotter can point to any position in the sprite, rather than the top left - this means the main code can just pass the world location to the sprite plotter, and the plotter can adjust for rotation/scaling correctly.

To make life easier for the main game code, there's a routine that will take object number, animation frame, and rotation & distance coordinates, and compute the correct sprite. There's another table with per-object data to help with this, but I won't document it as it's a bit placeholder at the moment. Sprite coordinates are calculated by passing an angle through sine/cosine tables, then multiplying that through a factor derived from distance from camera.

The sprite plotter is column-major, with sprite masks being inferred from colour data via a lookup table. There are variants for X and Y flipping - this helps minimise the number of rotation frames that need to be stored. This does have the quirk that sprites rotated 90 or 270 degrees will appear to be left-right inverted. This hasn't been an enormous issue - yet!

Currently all sprites are pre-rendered. Modelling is done in Blender (which is complete overkill for models this simple!), all required animation & rotation frames are rendered out and fed into a converter, which scales the sprites appropriately, packs them onto a single 160x256 bitmap which is fed into BBC Micro Image Converter, and generates headers which are fed into another converter which packs everything into data to fit into sideways RAM. That all turns frames that look like this :
diamond.gif
diamond.gif (2.16 KiB) Viewed 1142 times
into this :
diamonds.gif
Obviously some manual tweaking is needed at some point!

Currently I'm using 4 distance levels + 32 rotations (8 rotation frames + mirroring). There's some noticeable popping between frames, but I think it's acceptable. I did originally use twice as many frames for rotation, but it currently uses too much memory. I'm toying with using some kind of compression, probably storing all sprites at 2 BPP, which might let me tweak this a bit.

I concluded quickly that having some kind of shadow makes sprites fit in to the world more convincingly. I've done this manually for the main player sprite, as there are only a few of those. I intend to automate this for other objects, due to the sheer number of sprites, but I haven't done this yet.

I should add incidentally that memory usage means there's no way this will run on less than a Master!

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

Re: New game - tube type thingy

Post by daveejhitchins » Mon Jan 01, 2018 5:55 pm

SarahWalker wrote:I should add incidentally that memory usage means there's no way this will run on less than a Master!
:shock: What . . . Not even on an Electron - With Turbo :-

Lookin good, though . . . =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
tricky
Posts: 2768
Joined: Tue Jun 21, 2011 8:25 am
Contact:

Re: New game - tube type thingy

Post by tricky » Mon Jan 01, 2018 10:14 pm

Crazy but I like 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 » Tue Jan 02, 2018 3:39 pm

Neat! I remember Tube ...

Could you post some video of it running? (the Master version that is!)
For a "Complete BBC Games Archive" visit www.bbcmicro.co.uk

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

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

Re: New game - tube type thingy

Post by crj » Tue Jan 02, 2018 5:41 pm

OK. Hands up everyone who thought, based on the subject line, that this was going to be a game that took advantage of a second processor? (-8

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

Re: New game - tube type thingy

Post by tricky » Tue Jan 02, 2018 8:02 pm

Me, Me, Me sir!
but I like this too :)

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

Re: New game - tube type thingy

Post by SarahWalker » Tue Jan 02, 2018 10:09 pm

Arcadian wrote:Neat! I remember Tube ...

Could you post some video of it running? (the Master version that is!)
Here you go!

https://www.youtube.com/watch?v=fmJezG66038

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 » Wed Jan 03, 2018 7:48 am

SarahWalker wrote:
Arcadian wrote:Neat! I remember Tube ...

Could you post some video of it running? (the Master version that is!)
Here you go!

https://www.youtube.com/watch?v=fmJezG66038
Crikey, would never have expected it to run quite as well as that!

It doesn't look like anything seen before on a BBC ever! :shock:

It's Mode 2 right so is there the possibility of adding the extra three colours? What about all 16 with a NuLA? ;)
For a "Complete BBC Games Archive" visit www.bbcmicro.co.uk

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

User avatar
sbadger
Posts: 342
Joined: Mon Mar 25, 2013 1:12 pm
Location: Farnham, Surrey
Contact:

Re: New game - tube type thingy

Post by sbadger » Wed Jan 03, 2018 1:36 pm

This looks really nice, good work!
it really reminded me of Stunrunner. Sarah, you just need to add some bends in the tube now :wink:
So many projects, so little time...

User avatar
jbnbeeb
Posts: 424
Joined: Sat Apr 03, 2010 8:16 pm
Contact:

Re: New game - tube type thingy

Post by jbnbeeb » Thu Jan 04, 2018 12:59 am

=D> =D> =D>

Nicely done Sarah! This looks fantastic and I agree with Arcadian -not seen anything look quite like this on the Beeb!
I'm going to ..
ABUG Cambridge Sept 7th-9th Sept 2018
Image

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

Re: New game - tube type thingy

Post by cmorley » Thu Jan 04, 2018 11:00 am

Can you use palette swapping to double the frame rate of the tube with sacrificing colours?

A four colour tube + swap would eat all 16 colours (same 4 colour sprites :( ) but you could draw a 3 colour tube with 9 palette entries and leave 7 colours for sprites perhaps. Changing what 3 colours they are as you descend the tube would give the illusion of a full colour tube (with only 3 on screen at once). Or indeed a two colour 3 frame tube draw with 8 palette entries... tripple frame rate.

User avatar
Rich Talbot-Watkins
Posts: 1352
Joined: Thu Jan 13, 2005 5:20 pm
Location: Palma, Mallorca
Contact:

Re: New game - tube type thingy

Post by Rich Talbot-Watkins » Thu Jan 04, 2018 11:59 am

Wow, what a fantastic idea - totally original, and the only thing which vaguely compares are those palette switching 'through the tunnel' demos, like Orlando's 3D Wars. This is of course far better, and I think it's fair to say that it's the first time I've seen perspective correct texturing on the Beeb before :D The effect of rotating around the tube is just beautiful.

I'm sure Sarah will correct me if I'm wrong, but it looks like she's using a bitplanes type scheme like Firetrack, so two bits per pixel for the tube, and the other two bits for moving sprites - which unfortunately would rule out extra NuLA colours, or using the palette for intermediate animation frames.

Really looking forward to seeing what comes of this!

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

Re: New game - tube type thingy

Post by kieranhj » Thu Jan 04, 2018 6:54 pm

Finally got chance to take a look at the video - this is amazing! =D> I don't think I fully appreciated what you were trying to show me untextured at ABUG, sorry about that!! My 2p is, sod the game, this is demo material - tube scroller anyone? :D
Bitshifters Collective | Retro Code & Demos for BBC Micro & Acorn computers | https://bitshifters.github.io/

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

Re: New game - tube type thingy

Post by SarahWalker » Sun Jan 07, 2018 11:08 am

cmorley wrote:Can you use palette swapping to double the frame rate of the tube with sacrificing colours?

A four colour tube + swap would eat all 16 colours (same 4 colour sprites :( ) but you could draw a 3 colour tube with 9 palette entries and leave 7 colours for sprites perhaps. Changing what 3 colours they are as you descend the tube would give the illusion of a full colour tube (with only 3 on screen at once). Or indeed a two colour 3 frame tube draw with 8 palette entries... tripple frame rate.
Not entirely sure how this would work? Wouldn't this basically just double the length of the tube rendering, giving roughly the same frame rate at before?

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

Re: New game - tube type thingy

Post by SarahWalker » Sun Jan 07, 2018 11:09 am

Rich Talbot-Watkins wrote:I'm sure Sarah will correct me if I'm wrong, but it looks like she's using a bitplanes type scheme like Firetrack, so two bits per pixel for the tube, and the other two bits for moving sprites - which unfortunately would rule out extra NuLA colours, or using the palette for intermediate animation frames.
Nope - full 4 bits for everything. If you look closely the sprites are already using 4 colours, rendering this scheme impractical.

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

Re: New game - tube type thingy

Post by SarahWalker » Sun Jan 07, 2018 11:23 am

SarahWalker wrote:The sprite plotter is column-major
Don't know why I originally did this, row-major turned out to be faster!

The column-major inner loop looked like this, unrolled 4 times :

Code: Select all

        lda (spraddr)
        tax
        lda (scraddr), y
        and masktable,x
        ora ortable,x        
        sta (scraddr), y

        inc spraddr
*       iny
        bne +        
        inc scraddr+1
        inc scraddr+1
        ldy #$f8
It stores the low 3 bits of the screen address in Y, and the sprite converter ensures that a sprite column will never cross a page boundary, which saves a few cycles. Best case scenario with loop overhead accounted for is 38.25 cycles per byte, but there's also a bit more code to handle when sprite height isn't a multiple of 4 lines, so it's a bit more expensive.

The row-major loop looks like this, unrolled to 17 bytes (currently the width of the largest sprite) :

Code: Select all

        lda (spraddr)
        tax
        lda (scraddr)
        and masktable,x
        ora ortable,x        
        sta (scraddr)

spr_mod_start:
        ldy #8
        lda (spraddr),y
        tax
        lda (scraddr),y
        and masktable,x
        ora ortable,x        
        sta (scraddr),y

        ldy #16
        lda (spraddr),y
        tax
        lda (scraddr),y
        and masktable,x
        ora ortable,x        
        sta (scraddr),y
        
        etc etc
Sprites are stored in sort-of screen format (with lowest three address bits being the lowest three line number) to save an LDY per iteration. Self modifying code is used to skip over unneeded columns. Overall speed is (28 * number of columns) + 30 cycles per row.

This is enough of a speedup to get to 12.5 fps with a couple of sprites on screen, though it will slow down with any more than that. I'm working around this by taking advantage of the Master's ability to swap buffers without waiting for vsync - this prevents dropping straight down to 10 fps, and any tearing doesn't seem too obvious to me so far...

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

Re: New game - tube type thingy

Post by cmorley » Sun Jan 07, 2018 12:35 pm

SarahWalker wrote:
cmorley wrote:Can you use palette swapping to double the frame rate of the tube with sacrificing colours?
Not entirely sure how this would work? Wouldn't this basically just double the length of the tube rendering, giving roughly the same frame rate at before?
It depends entirely on the ratio of time spent doing (a) the LUT+texture to the time pushing the large pixels to (b) the screen memory.

If tb >> ta then you would get a decent speedup. If tb > 2*ta then you might get a few % or 10% (not worth the complexity). If lookup+texture is the bottleneck then it would be slower.

4 frames would be: L-lookup. P-plot. S-switch palette
LP.LP.LP.LP
LLP.S.LLP.S

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

Re: New game - tube type thingy

Post by SarahWalker » Sun Jan 07, 2018 5:07 pm

62 cycles for LUT stuff, 20 cycles total for texture load, 83 cycles for store. So this would (in theory!) be 62*2 = 124 cycles for LUT, 20*2 = 40 cycles for texture load, plus some cycles to swap SWRAM banks between texture colour and texture colour*3 (12 at minimum), then 83 cycles for store. So 260-odd cycles for 4 texels for 2 frames, or 32.5 cycles per texel. An improvement over the current 42 cycles per texel, but this would add a fair chunk of complexity, plus I think would also mean sprites running at half frame rate? So probably good for a demo effect, but I don't think it would really work here. I could be overlooking something though!

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

Re: New game - tube type thingy

Post by SarahWalker » Sun Jan 07, 2018 5:23 pm

crj wrote:OK. Hands up everyone who thought, based on the subject line, that this was going to be a game that took advantage of a second processor? (-8
Just implemented this, actually!

The game still mostly runs on the host CPU, but the parasite is used to assist with the tube rendering. The parasite runs the texture lookup :

Code: Select all

        ldx x_1
        lda y_dat+$004,x
        clc
        adc YOFF
        tay
        lda x_dat+$004,x
        clc
        adc XOFF
        lsr
        lsr
        ora #$80
        sta t+5
        eor #$20
        sta t+11       
        lda XOFF
        clc
        sbc x_dat+$004,x
        lsr
        lsr
        ora #$80
        sta t+7
        eor #$20                
        sta t+9
        lda (t+4),y        
        sta $fef9
        lda (t+8),y        
        sta $fef9
        lda (t+6),y
        sta $fef9        
        lda (t+10),y
        sta $fef9        
while the host plots to screen memory :

Code: Select all

        lda $fee1
        sta $4400,x
        sta $4401,x        
        sta $4402,x
        sta $4403,x        
        lda $fee1        
        sta $7a04,x
        sta $7a05,x        
        sta $7a06,x
        sta $7a07,x        
        lda $fee1        
        sta $4500,y
        sta $4501,y        
        sta $4502,y
        sta $4503,y        
        lda $fee1        
        sta $7b04,y
        sta $7b05,y        
        sta $7b06,y
        sta $7b07,y        
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.

Ideally this should give 25 cycles per texel at peak, which should give 23.7 fps, assuming no other bottlenecks. In practice, on my Master with 3 MHz external copro varies between about 2.5 frames and 3.5 frames - between about 14 and 20 fps. This compares to ~12.5 fps on the single processor version. Emulation suggests that the parasite is probably the bottleneck here, the 4 MHz internal copro should be a bit quicker. I don't think there's much of a gain above 4 MHz.

Some footage here : https://www.youtube.com/watch?v=QTwrO2SD734.

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

Re: New game - tube type thingy

Post by cmorley » Sun Jan 07, 2018 6:23 pm

SarahWalker wrote:62 cycles for LUT stuff, 20 cycles total for texture load, 83 cycles for store. So this would (in theory!) be 62*2 = 124 cycles for LUT, 20*2 = 40 cycles for texture load, plus some cycles to swap SWRAM banks between texture colour and texture colour*3 (12 at minimum), then 83 cycles for store. So 260-odd cycles for 4 texels for 2 frames, or 32.5 cycles per texel. An improvement over the current 42 cycles per texel, but this would add a fair chunk of complexity, plus I think would also mean sprites running at half frame rate? So probably good for a demo effect, but I don't think it would really work here. I could be overlooking something though!
20% ish... not a win then. Plotting sprites in the palette swap frames would require a background store which would consume cycles & memory :( Sprites on the draw frames only would (just less than) halve the sprite frame rate - #-o - with the tube animation increasing by ~20%...

Sorry, not much help with 3:4... it might have been a different story @ say 1:9

edit: ooh... the copro could do the texel lookup as per your above post... then you would win

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

Re: New game - tube type thingy

Post by crj » Sun Jan 07, 2018 9:12 pm

cmorley wrote:20% ish... not a win then.
That depends.

Even 0% is a win if the extra 64K of RAM is useful. And with PiTubeDirect out there, it could be that there are more people with BBC B, sideways RAM, 6502 second processor (=112K) than a BBC Master (=128K).

Incidentally, a PiTubeDirect would be the easy way to see if the parasite was the bottleneck, by running in effect infinitely quickly. (-8

dp11
Posts: 834
Joined: Sun Aug 12, 2012 8:47 pm
Contact:

Re: New game - tube type thingy

Post by dp11 » Sun Jan 07, 2018 11:27 pm

On the master can you use a number of swr bank so that you have 70k of loads and writes to the screen buffer so no x or y indexes are used?

On the 6502 pitubedirect the is also banked ram available giving you 2MBytes

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

Re: New game - tube type thingy

Post by SarahWalker » Mon Jan 08, 2018 5:46 pm

crj wrote:
cmorley wrote:20% ish... not a win then.
That depends.

Even 0% is a win if the extra 64K of RAM is useful. And with PiTubeDirect out there, it could be that there are more people with BBC B, sideways RAM, 6502 second processor (=112K) than a BBC Master (=128K).
I think you might be confused here? The 20% was for increasing framerate through palette animation, nothing to do with second processors, and wouldn't gain any more RAM.

I seriously doubt that more people have BBC B + SWRAM + 6502 copro than Master 128. In any case the model B can't double buffer MODE 2 so it's a non starter.

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

Re: New game - tube type thingy

Post by SarahWalker » Mon Jan 08, 2018 5:50 pm

dp11 wrote:On the master can you use a number of swr bank so that you have 70k of loads and writes to the screen buffer so no x or y indexes are used?
The Master hasn't got 70k of SWRAM...

In any case I'm currently using 1 bank for the source bitmap for the tunnel, and sprites currently spill to 2 banks and will probably use 3 in the end. Add to that the 32kb used for the screen and however much is used for code, and there really isn't enough left for massively unrolled & precalculated plotting code.

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

Re: New game - tube type thingy

Post by SarahWalker » Sat Jan 13, 2018 1:27 pm

Bit of a philosophical question now - I've had a play with increasing the tube resolution on the copro version, from 64x56 to 64x112. This works, but drops performance slightly, from 16.7 fps back down to 12.5. Which do people prefer?

64x56, 16.7 fps - https://www.youtube.com/watch?v=QTwrO2SD734

64x112, 12.5 fps - https://www.youtube.com/watch?v=QzEHAZ9KoZI

User avatar
sbadger
Posts: 342
Joined: Mon Mar 25, 2013 1:12 pm
Location: Farnham, Surrey
Contact:

Re: New game - tube type thingy

Post by sbadger » Sat Jan 13, 2018 1:52 pm

Hi Sarah, I personally think the fps is more important than the res.
So many projects, so little time...

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 » Sat Jan 13, 2018 1:57 pm

Comparing the two vids, I'd say FPS too :)
For a "Complete BBC Games Archive" visit www.bbcmicro.co.uk

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

Kevin Edwards
Posts: 97
Joined: Tue Mar 14, 2006 9:16 pm
Contact:

Re: New game - tube type thingy

Post by Kevin Edwards » Sun Jan 21, 2018 9:27 pm

Hi Sarah.

I'd say faster frame rate would be best. Most gamers care more about FPS than resolution / detail, but not everyone!

How easy would it be to allow the user to select their preference, either in the front end menu, or ideally, 'on-the-fly''?

Also, if it is possible to change 'on-the-fly' you could defualt the game at maximum resolution and switch to lower resolution ( faster update ) when the performance is likely top drop eg. when effects trigger or more objects need rendering. Then switch back to higher resolution when things calm down.

Cheers and good luck,
Kevin.

Post Reply