- Welcome to CPCWiki forum.
The ultimate Amstrad CPC community!
News:
Printed Amstrad Addict magazine announced, check it out here!
Recent posts
#1
I would still do it line by line.
Start from the hsync singnal and scan to the next hsync, then output it twice to the target monitor with double pixel frequency.
That would catch everything the CPC will do, regardless of video modes or anything else.
If you just do that this needs only one line of memory and is never wrong, whatever the demo might do and it is also very fast (no additional delay) in the output. So even any mode switch will be done immediately without any adaption time.
Start from the hsync singnal and scan to the next hsync, then output it twice to the target monitor with double pixel frequency.
That would catch everything the CPC will do, regardless of video modes or anything else.
If you just do that this needs only one line of memory and is never wrong, whatever the demo might do and it is also very fast (no additional delay) in the output. So even any mode switch will be done immediately without any adaption time.
#2
Hello guys!
During the last few days there has been an influx of new users, above the normal levels. Some of the accounts created were definitely spammer accounts, for others I have my doubts. Just wanted to ask you to report any suspicious behavior you see and it'll be taken care of.
Thanks!
During the last few days there has been an influx of new users, above the normal levels. Some of the accounts created were definitely spammer accounts, for others I have my doubts. Just wanted to ask you to report any suspicious behavior you see and it'll be taken care of.
Thanks!
#3
it's always possible (like Prehistorik II or Super Cauldron) to have some parts @50Hz and some animations @5Hz 
and it's also possible to have a dedicated engine to manage any framerate for any animation in the screen (some @50Hz, some @25Hz, ...)
even better, an automatic distribution, with priorities for main character and lower priority for background, as you must know time consumption for each element
and it's also possible to have a dedicated engine to manage any framerate for any animation in the screen (some @50Hz, some @25Hz, ...)
even better, an automatic distribution, with priorities for main character and lower priority for background, as you must know time consumption for each element
#4
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.
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.
#5
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.
You can only move around X amount of screen data at 50FPS, at 25FPS you can double it.
#6
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).
#7
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.
#8
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.
#9
In Jet planes you always have a lot of lag. So it must be Jet simulator games.
#10
Hardcore Hardware Patch Z84C - OUT(C),0
Someone tell me if the CMOS output can be shorted with impunity.
Someone tell me if the CMOS output can be shorted with impunity.