News:

Printed Amstrad Addict magazine announced, check it out here!

Main Menu
avatar_zhulien

Games Rendering Question: such as Alcon

Started by zhulien, 16:05, 13 October 21

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

zhulien

Hi Everyone,


For most part I can program the bits of a scrolling game with overlapping sprites, in fact it is really easy on the right hardware (modern day PC)... The questions below are I am hoping someone can clarify or guide me in doing so on a CPC because the Alcon demo especially the 25fps one is f***ing AMAZING!!! I can't stress it more because it is on a CPC.


Obviously it shows that the CPC's potential was never met and likely still has more to get out of it.  Alcon, R-Type Remake, Pinball Fantasy, Donkey Kong, Moon Cresta, Scramble, Frogger almost all perfect ports.  Probably I missed some too.


Back to the questions I have.  What are the best approaches in the following examples in relation to scrolling with backdrops & overlapping sprites:


1. Backgrouds rendered direct to screen only with no virtual representation


Backdrop is initially fully rendered, sprites are XORd in an ugly way to display and remove them without damage to the background, carefully coordinated with a hardware scroll of background where the background is only ever drawn by software on the edges by whatever the scroll amount is (character, half character for example). 


To me this is efficient, in 1 directional scrolling game (eg: right to left), we only need to render 200 scan lines of the right-most pixel (or tile) periodically, only bytes to render.


2. Backgrounds rendered in a buffer, with all objects, enemies etc rendered there... & transferred to the gfx memory


This is what I'd do on a powerful PC, how many fps + processing time can we get out of a CPC if doing full 16kb screen copies?  4? 5? 


3. similar to 2, but we always have 2 screen memories with fully rendered backdrops and the renders of software sprites are the only thing that needs to really take place between alternating the CRTC between the 2 screens.  Something like that.  I suspect this could be an option?


4. as per option 1, but... not XORing sprites, but rather repainting the original backdrop between sprite movements - i am thinking this could be optimised depending on the game so the sprite actually includes part of the backdrop and displaying a moved sprite basically covers it's trail.


Any better suggestions?  I am sure i am way off.  My plan already includes tiles stored that only are going to be used for the current level, sprite lists for the animation frames of each sprite (even non-moving sprites will be constantly repainted)...


I really don't want the XOR method, and I need to cater for a non-destructive backdrop - like Alcon has.

abalore

Hello,
Alcon uses three video buffers. Two of them to make the classical double buffer rendering, and the third to keep a full intact copy of the background.
So, when a sprite is erased the background is copied from the third buffer to one of the other two. As you said, not all the sprite surface is copied, but only what is not already repainted by the sprite itself.
This three buffer method is meant for cartridge games, where you don't need much RAM, (you will have only 16KB free for all the other stuff on a 464). But is also usable on 128KB machines.
Of course these are the basics, there are a lot of stuff to take into account to sucessfuly implement it, but I'm sure you will solve them all!


zhulien

#2
Thanks, that makes a lot of sense.  The historical method would be to instead of having a complete other background to take a copy of where the sprite was before rendering it so it can be put back later - but that doubles the time taken for every sprite.  Something for me to think about for sure.


How do you scroll the 3rd background copy or is it a fully rendered entire level background (not just a screen)?

reidrac

#3
If you don't have that much memory, you can rebuild the background from tiles when you erase the sprites (the independent tiles + a tilemap uses way less memory, specially if there are repeated tiles). That's what I have done in all my games. It works fine, although you may erase more than the exact amount of pixels overwritten by the sprite, because the sprite won't always be tile-aligned. But in general, that's OK.

You can see what I mean on this video:

https://twitter.com/reidrac/status/952689606255939584

(the red shows what is actually erased, which is more than the actual "dirty" area; that was a not very optimised version of the engine, can be better!)

Personally I prefer drawing the sprites with a mask, I have never used XOR sprites on the CPC.

I recommend you reading this: https://cpctech.cpcwiki.de/docs/sprites.html
Released The Return of Traxtor, Golden Tail, Magica, The Dawn of Kernel, Kitsune`s Curse, Brick Rick and Hyperdrive for the CPC.

If you like my games and want to show some appreciation, you can always buy me a coffee.

zhulien

Yes, I will be using tiles, I guess the tile rebuild method would be still faster than preserving the previous content, but not quite as fast as a fully pre-rendered backdrop to copy.

zhulien

I bought Dawn of Kernel, excellent game!

abalore

Quote from: zhulien on 16:48, 13 October 21
How do you scroll the 3rd background copy or is it a fully rendered entire level background (not just a screen)?
In Alcon, background is done from 4x8 pixel tiles, in each frame I draw 1/8 of the tile map width and then I scroll the full character row. In the meantime I use the vertical adjust register of the CRTC to achieve the 1 pixel scroll.

zhulien

Quote from: reidrac on 16:53, 13 October 21
I recommend you reading this: https://cpctech.cpcwiki.de/docs/sprites.html


Great, i will need to re-read it later, but the different methods so far make sense.

Powered by SMFPacks Menu Editor Mod