- Welcome to CPCWiki forum.
The ultimate Amstrad CPC community!
News:
Printed Amstrad Addict magazine announced, check it out here!
Recent posts
#1
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).
#2
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.
#3
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.
#4
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).
#5
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
#6
Ok, i will take note, i will check what signs usually appear on F1 tracks and try to replicate them.
Thanks for the feedback.
Thanks for the feedback.
#7
Quote from: luckpro on Today at 11:43ground seems big enough to me, you can improve readability with some columns or traffic signs maybe? Keep the speed!Quote from: cwpab on Yesterday at 09:57As a feedback, I'd say that it looks like you can't see s**t with the current camera and speed. Maybe the camera could be moved up a little or the speed reduced?Like you, several people have told me that there is little ground to be seen.
EDIT: I think it's the peculiar format of the video with margins. I suspect the movement would look normal in a normal video.
I'll try to improve that part.
The video is recorded using the RVM emulator although the quality is not very good (twitter limits...).
Thank you for feedback.
#8
#9
Quote from: cwpab on Yesterday at 09:57As a feedback, I'd say that it looks like you can't see s**t with the current camera and speed. Maybe the camera could be moved up a little or the speed reduced?Like you, several people have told me that there is little ground to be seen.
EDIT: I think it's the peculiar format of the video with margins. I suspect the movement would look normal in a normal video.
I'll try to improve that part.
The video is recorded using the RVM emulator although the quality is not very good (twitter limits...).
Thank you for feedback.
#10