News:

Printed Amstrad Addict magazine announced, check it out here!

Main Menu

Recent posts

#1
A
Programming / Re: triple buffering
Last post by Anthony Flack - Today at 05:19
Well, it depends what your priorities are. The GX is a console after all, and 50fps gives you that arcade/console feel. It's a worthy if restrictive ambition even for the stock CPC, and the GX is plenty capable of doing what the Commodore 64 can do, so I'd definitely shoot for that. I did say a sprite game, so something equivalent to what you might see on the NES or Master System. 

I know it cuts your drawing time in half but hopefully you don't need to spend all that time masking and drawing and erasing sprites either, and it's the difference between smooth arcade feel and slightly juddery home computer feel.

The CPC endured such rough FPS back in the day, it always feels really pleasing to see it hitting a clean 50. 

#2
avatar_lmimmfn
Programming / Re: triple buffering
Last post by lmimmfn - Today at 01:54
Very few Amiga games are 50FPS even with all the hardware, games are normally 25FPS so I don't know why GX games should be 50FPS.

You can only move around X amount of screen data at 50FPS, at 25FPS you can double it.
#3
A
Programming / Re: triple buffering
Last post by andycadley - Yesterday at 23:03
Quote from: Anthony Flack on Yesterday at 22:39Any 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).
#4
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.
#5
A
Games / Re: CPC Formula 1 [WIP]
Last post by andycadley - Yesterday at 21:07
Quote from: sigh on Yesterday at 18:35Sorry - 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.
#6
avatar_McArti0
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.  ;D
#7
avatar_McArti0
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.
#8
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.
#9
avatar_roudoudou
Programming / Re: triple buffering
Last post by roudoudou - Yesterday at 20:30
in a demo, lag has no meaning

in a game... ;D

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

...sometimes :P
#10
D
Programming / Re: triple buffering
Last post by djaybee - Yesterday at 19:44
Quote from: McArti0 on Yesterday at 14:18Fast 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.
Powered by SMFPacks Menu Editor Mod