Recent posts

#1

A

Programming / Re: triple buffering

Last post by andycadley - Yesterday at 23:03

Any kind of screen buffering on the GX is also complicated by the hardware sprites, which will have to have their data buffered as well, or else they'll get ahead of everything. But a sprite game on the GX should rightly be aiming to hit 50fps anyway.

Depends what you're doing, if you were aiming for something 3D like Castle Master you might not have many sprites (or just use it for things like a cursor that just needs positioning). And that's where triple buffering is most likely to be useful. It'd be fascinating to see what a Mode 0 GX Freescape would be like, especially given how much cart space you could dedicate to massive look up tables to speed up the maths...

If you're doing something sprite heavy and scrolling, you'd be more likely to lean on the hardware features and avoid even double buffering entirely (at most keeping a secondary clean background buffer).

#2

A

Programming / Re: triple buffering

Last post by Anthony Flack - Yesterday at 22:39

Any kind of screen buffering on the GX is also complicated by the hardware sprites, which will have to have their data buffered as well, or else they'll get ahead of everything. But a sprite game on the GX should rightly be aiming to hit 50fps anyway.

#3

A

Games / Re: CPC Formula 1 [WIP]

Last post by andycadley - Yesterday at 21:07

Sorry - I think I may have muddled up everything by not explaining well. I meant that you can fit more sprites in mode 1.
For instance - if I were to draw a sprite that is 16*16, I would be able to fit more on the mode 1 sheet.

Well there are half as many pixels across in Mode 0, so you can fit less 16*16 Mode 0 sprites compared to 16*16 Mode 1 sprites. But 16 Mode 0 pixels cover the same physical area as 32 Mode 1 pixels so it's not really a like for like comparison.

Ultimately there is absolutely no advantage to using Mode 1 over Mode 0 in terms of the number of sprites you'll get in a game. The only reasons to choose it are because you need the higher resolution for aesthetic or functional reasons (f.e. you have a lot of text) or because you have art designed for another system with square pixels (typically the Speccy but not necessarily) and don't want to spend time/effort/money reworking it.

#4

Programming / Re: triple buffering

Last post by McArti0 - Yesterday at 21:00

In Jet planes you always have a lot of lag. So it must be Jet simulator games. 

#5

Amstrad CPC hardware / Re: Zilog Z84C0020PEG in my CP...

Last post by McArti0 - Yesterday at 20:34

Hardcore Hardware Patch Z84C - OUT(C),0

Someone tell me if the CMOS output can be shorted with impunity.

#6

L

Technical support - Hardware related / Re: 464 plus to 6128 plus disk...

Last post by lordoftime - Yesterday at 20:32

i have now also fitted the external drive connector and was wondering if i need to do anything to make it the default A drive? i followed the guide with the wire from a pin of the internal drive but it just makes the disc access unreliable.

#7

Programming / Re: triple buffering

Last post by roudoudou - Yesterday at 20:30

in a demo, lag has no meaning

in a game...

that's why emulator authors try to reduce lag...

...sometimes

#8

D

Programming / Re: triple buffering

Last post by djaybee - Yesterday at 19:44

Fast gameplay 50fps with huge explosions . You need to copy 10kB to screen.

Oh, interesting, I hadn't considered that explicitly. Essentially, if most frames take well less than 20ms but some take more than that, having a triple buffer allows to "borrow" time from a short frame into a long latter one.

I think I once did something like that in a demo for the Atari ST: my code took near-constant time, but the music player I used didn't, and I made it so that the average would fit in my 20ms budget (40064 NOPs on the ST). Overall, the delay never added up to more than the size of the bottom + top borders, so my frame boundary never crossed into the visible part of the display.

#9

S

Games / Re: CPC Formula 1 [WIP]

Last post by sigh - Yesterday at 18:35

Was thinking that with the mode 1 graphics, you would have more graphics space for sprites?

It doesn't really work like that, Mode 1 has twice the horizontal resolution and half the colours, so the end result is graphics take the same amount of memory to fill the same physical space

You could save memory by reducing the colour depth of stored graphics and converting them on the fly but that loses speed (and it doesn't really matter what the target Mode is at that point).

Then I have been completely wrong all this time!

I thought a mode 0 sprite sheet that is 160x200 was 8kb and a mode 1 sprite sheet that is 320x200 was also 8kb?

160*200*16 = ~16K
320*200*4 = ~16K

You have to drop in colour depth or resolution to actually save memory.

Sorry - I think I may have muddled up everything by not explaining well. I meant that you can fit more sprites in mode 1.
For instance - if I were to draw a sprite that is 16*16, I would be able to fit more on the mode 1 sheet.

#10

A

Games / Re: CPC Formula 1 [WIP]

Last post by andycadley - Yesterday at 18:27

Was thinking that with the mode 1 graphics, you would have more graphics space for sprites?

It doesn't really work like that, Mode 1 has twice the horizontal resolution and half the colours, so the end result is graphics take the same amount of memory to fill the same physical space

You could save memory by reducing the colour depth of stored graphics and converting them on the fly but that loses speed (and it doesn't really matter what the target Mode is at that point).

Then I have been completely wrong all this time!

I thought a mode 0 sprite sheet that is 160x200 was 8kb and a mode 1 sprite sheet that is 320x200 was also 8kb?

160*200*16 = ~16K
320*200*4 = ~16K

You have to drop in colour depth or resolution to actually save memory.