Quote from: BSC on Today at 10:03Retro Virtual Machine (2) has this feature and I am pretty sure that WinApe has it.I didn't find it in RVM but now I saw it. Thanks.
Quote from: BSC on Today at 10:03Retro Virtual Machine (2) has this feature and I am pretty sure that WinApe has it.You can't do that with WinAPE.
Quote from: lmimmfn on Today at 04:07That's what I understood from Gunheds post: When you scroll the screen by one character, the CPU has to update that part of the screen, that is shifted out of one border and into the opposite border. Otherwise your screen would not scroll, but roll. With a character height of 8 lines, you have to update 8x 80bytes and with a character height of 2 lines, you have to update only 2x 80bytes.Quote from: GUNHED on Today at 02:54It only matters what the Z80 does. The less you shift the screen, the less RAM the Z80 needs to change. The CRTC does it's work independent, like all other chips too.That's my point really, Z80 has to update the screen and outside of the Z80 processing time the screen is updated via the CRTC.
Which brings me to the point that 2 pixel character screen setup has no advantage over 8 pixel characters Smooth vertical 1 pixel scrolling is completely independent of vertical char size or 1 byte horizontal scrolling.
Quote from: GUNHED on Today at 02:58Eventually you can use the LEDs of the LambdaSpeak.I don't have that. I used the printer port idea as it's easy to build.
Quote from: GUNHED on Today at 02:54That's my point really, Z80 has to update the screen and outside of the Z80 processing time the screen is updated via the CRTC.Quote from: lmimmfn on 01:53, 15 August 22It only matters what the Z80 does. The less you shift the screen, the less RAM the Z80 needs to change. The CRTC does it's work independent, like all other chips too.Quote from: GUNHED on 20:29, 14 August 22But why is that different, its the same amount of screen update from the CPU and the CRTC is updating a full screen, where is the saving coming from? Not trying to be argumentative, I just don't understand.Quote from: andycadley on 21:37, 13 August 22No, just use more character lines. 25 * 8 = 200 scanlines. 100 * 2 = 200 scanlines too.Quote from: GUNHED on 21:23, 12 August 22Wouldn't that also make the screen 1/4 height? Or am I missing something?Quote from: lmimmfn on 03:18, 11 August 22The regular character line height is 8 scan lines. So you need to transfer data for 8 scanlines every frame in case you want to scroll up or down.Quote from: GUNHED on 17:37, 10 August 22Excuse my ignorance but onQuote from: Axel on 14:28, 08 August 22What tricks could you try to enlarge the game window with the same or better framerate?- Use screen 64 byte in width (32 x 32 characters in MODE 1, but here MODE 0 would probably look more nice)
- Use CRTC characters only 4 scanlines high, or even better only 2 (instead of 8 like usually), this will make the scrolling more smooth, also gives extra time, because less V-RAM needs to be moved.
- instead of having sprites as data, use something like CoData (I use that for Filmemacher). Basically a program which draws the sprite or graphic element on screen. That's more quick compared to copy data.
- Use more RAM, this enables to unroll routines which contain loops. Also a speed up.
And finally: Do a complete rewrite instead of patching / enhancing / bettenering / etc. of an existing program. Alcon 2020 may serve as a well example for that ;-)
"Use CRTC characters only 4 scanlines high, or even better only 2 (instead of 8 like usually), this will make the scrolling more smooth, also gives extra time, because less V-RAM needs to be moved."
How does that make scrolling smooth? The CRTC has a fixed number of cycles to read the ram separately to the Z80, so how does reducing the character scanlines improve performance if its still a full screen(32x32)?
The CRTC is still working outside of the Z80 for screen refresh so I don't understand the comment.
In case you use only 2 scanlines, then you only need to transfer 1/4 of the data. In addition scrolling is more smooth and slower.
Page created in 0.045 seconds with 29 queries.