- Welcome to CPCWiki forum.
The ultimate Amstrad CPC community!
News:
Printed Amstrad Addict magazine announced, check it out here!
Recent posts
#1
Quote from: McArti0 on Today 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.
#2
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.
#3
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.
#4
Thank you.
#5
Quote from: VincentGR on Today at 09:22Can you also test Relentless? (sound)GamePlay work. Sound noise (Intro and Game).
#6
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?
#7
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).
#8
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).
#9
" 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?
#10
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.