- Welcome to CPCWiki forum.
The ultimate Amstrad CPC community!
News:
Printed Amstrad Addict magazine announced, check it out here!
Recent posts
#11
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?
#12
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).
#13
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).
#14
" 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?
#15
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.
#16
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).
#17
Quote from: djaybee on Today at 13:02Deep inside, I can't stop thinking about a closely related question: what situations would benefit from triple-buffering, i.e. what are the types of graphics where the performance gains of triple-buffering outweigh the memory costs?Fast gameplay 50fps with huge explosions . You need to copy 10kB to screen.
#18
Quote from: Nich on 12:14, 14 April 24Quote from: iXien on 11:23, 14 April 24Hum, interesting. I play this one several times and never shown the problem. But I trust you. And nobody found the problem to poke it ? It would be not too late to fix this versionI've tried, but I couldn't find any way to fix the bug.
I tell you my advances, so you can investigate to at same time if you want.
There is a subrutine in &5b43 That basically have these things:
IX array &51ef-&533f of 2 elements its the source to copy data to the screen zone (&c000/&cfff) of a ldir.
iY array &4ca4-&4dee of 2 elements its the adress destination to copy data en the screen zone of a ldir.
HL=&4f75-&50bf of 2 elements one contains a offset to add to the address of ix/iy , and the other has the BC of the ldir, the lenght data to copy in the ldir.
B=&A5 is the number of the elements of the arrays, i mean he do loops a5 times reading the arrays and write it to the screen with the ldir.
Ok so its the first part to understand the problem.
There is another subrutine in &644c I don't know the function but:
He have an array IX that begins in &4e34 with varius elements,I think 00,+01,+02, is something related with player coordinates in the room, and +3 and +04 are something related to control de array.
He enter there when you put a dinamite, so he basically Walk through the array looking +03 and +04 positions to stop and use the elements of these index.
But every time it stop he modify +03 and +04, so the next time he don't stop in that index it continue searching and repeat.
ok so when you put a dinamite:
1.ix=4f5b stop index 1
2.ix=4f60 stop index 2
3.ix=4f65 stop index 3
4.ix=4f6a stop index 4
5.ix=4f6f stop index 5.
----------------------------
6.ix=5023 index 6
7.ix=5037 index 7
So he basically modify this in dinamite 6&7: HL=&4f75-&50bf of 2 elements one contains a offset to add to the address of ix/iy , and the other has the BC of the ldir, the lenght data to copy in the ldir.
So when &5b43 go to draw the screen, they draw in wrong adresses creating the corruption in the screen.
That That's what I've found out so far.
#19
Deep inside, I can't stop thinking about a closely related question: what situations would benefit from triple-buffering, i.e. what are the types of graphics where the performance gains of triple-buffering outweigh the memory costs?
Typically, triple-buffering results in an unsteady frame rate, which is especially visible at high frame rates, such that it's not necessarily a good idea for situations where the level of complexity is similar from frame to frame (which is the case for anything that's heavy on sprites and background graphics). On the other hand, 3D games, especially those drawn with polygons, might have a slower frame rate and and an inherently unsteady frame rate, such that those might be more appropriate situations for triple-buffering. In good news, those games might rely less on backgrounds and sprites and bitmaps in general, so the memory pressure from having 3 buffers might not be so high.
No, I don't have time to try this (I already have a lot of code on my plate), but, if I did, especially on 6128, I'd be using a 136x160 mode 0 display, with my buffers in banks 2 and 3, core code in bank 0, and banks 1 and 4-7 for situations where code and data can be paged in and out. In such a scheme, I would use memory modes 0 and 4 through 7, but I also note that memory mode 2 could be useful if there's some compressed data that needs to be decompressed on demand (with all the usual caveats about memory mode 2 and interrupts, of course).
Typically, triple-buffering results in an unsteady frame rate, which is especially visible at high frame rates, such that it's not necessarily a good idea for situations where the level of complexity is similar from frame to frame (which is the case for anything that's heavy on sprites and background graphics). On the other hand, 3D games, especially those drawn with polygons, might have a slower frame rate and and an inherently unsteady frame rate, such that those might be more appropriate situations for triple-buffering. In good news, those games might rely less on backgrounds and sprites and bitmaps in general, so the memory pressure from having 3 buffers might not be so high.
No, I don't have time to try this (I already have a lot of code on my plate), but, if I did, especially on 6128, I'd be using a 136x160 mode 0 display, with my buffers in banks 2 and 3, core code in bank 0, and banks 1 and 4-7 for situations where code and data can be paged in and out. In such a scheme, I would use memory modes 0 and 4 through 7, but I also note that memory mode 2 could be useful if there's some compressed data that needs to be decompressed on demand (with all the usual caveats about memory mode 2 and interrupts, of course).
#20
Looking forward to this.
Space Racing on the Spectrum was basically F-Zero before F-Zero was F-Zero
Space Racing on the Spectrum was basically F-Zero before F-Zero was F-Zero