- Welcome to CPCWiki forum.
The ultimate Amstrad CPC community!
News:
Printed Amstrad Addict magazine announced, check it out here!
Recent posts
#1
Quote from: andycadley on Today at 18:27Sorry - I think I may have muddled up everything by not explaining well. I meant that you can fit more sprites in mode 1.Quote from: sigh on Today at 17:08160*200*16 = ~16KQuote from: andycadley on Today at 16:29Then I have been completely wrong all this time!Quote from: sigh on Today at 15:36Was 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).
I thought a mode 0 sprite sheet that is 160x200 was 8kb and a mode 1 sprite sheet that is 320x200 was also 8kb?
320*200*4 = ~16K
You have to drop in colour depth or resolution to actually save memory.
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.
#2
Quote from: sigh on Today at 17:08160*200*16 = ~16KQuote from: andycadley on Today at 16:29Then I have been completely wrong all this time!Quote from: sigh on Today at 15:36Was 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).
I thought a mode 0 sprite sheet that is 160x200 was 8kb and a mode 1 sprite sheet that is 320x200 was also 8kb?
320*200*4 = ~16K
You have to drop in colour depth or resolution to actually save memory.
#3
Thank you.
#4
Quote from: VincentGR on Today at 09:22Can you also test Relentless? (sound)GamePlay work. Sound noise (Intro and Game).
#5
Quote from: andycadley on Today at 16:29Then I have been completely wrong all this time!Quote from: sigh on Today at 15:36Was 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).
I thought a mode 0 sprite sheet that is 160x200 was 8kb and a mode 1 sprite sheet that is 320x200 was also 8kb?
#6
Quote from: sigh on Today at 15:36Was 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).
#7
Quote from: GUNHED on Today at 15:04Sorry, the GX4000 has only half the RAM compared to the CPC6128. Furthermore the CRTC RAM is 64 KB in both cases. ROM is another thing. The GX4000 itself has none.It doesn't work like that in practice.
When you write cartridge software, you don't typically need much actual RAM for storing stuff (because 99% on code and assets can be in ROM), thus you typically have almost all of the 64K free to dedicate to whatever the CRTC needs. And you can be a lot smarter about arranging things by leaving ROMs paged in and relying on write-through for updates (assuming you don't need masking etc) which gives you an effective usable address space of 96K (and obviously up to 512K of code/data space in total).
On a 128K CPC most of the RAM tends to end up storing code + assets and you have to work with just 64K of effective address space (assuming you're not ROM software).
#8
" Thank you sigh, unfortunately the engine is designed so that the ground is flat. It is drawn horizontally to make it faster. To do what you mention i would have to draw vertically and do more calculations, i guess it couldn't be done that quickly (or at least I don't know how to do it).
The graphics mode doesn't matter too much in memory for this game. "
Was thinking that with the mode 1 graphics, you would have more graphics space for sprites?
The graphics mode doesn't matter too much in memory for this game. "
Was thinking that with the mode 1 graphics, you would have more graphics space for sprites?
#9
Sorry, the GX4000 has only half the RAM compared to the CPC6128. Furthermore the CRTC RAM is 64 KB in both cases. ROM is another thing. The GX4000 itself has none.
#10
Triple buffering doesn't necessarily produce a more variable frame rate, indeed the main reason for doing it is a more consistent frame rate than double buffering in any case where double buffering can stall due to excessive waiting.
Typically it works best when render time for a frame is a little over a frame (or a little over two frames etc). And, of course, you can still rate limit actual frame swaps to make things more consistent.
I don't think it's worth the pain on a standard CPC. As I said it might be more interesting on a GX4000 game as you have a lot more free RAM to play with, a lot more flexibility in terms of screen splitting and you can run much more from ROM to give you a much larger effective address space (assuming your screen buffers can be write only).
Typically it works best when render time for a frame is a little over a frame (or a little over two frames etc). And, of course, you can still rate limit actual frame swaps to make things more consistent.
I don't think it's worth the pain on a standard CPC. As I said it might be more interesting on a GX4000 game as you have a lot more free RAM to play with, a lot more flexibility in terms of screen splitting and you can run much more from ROM to give you a much larger effective address space (assuming your screen buffers can be write only).