News:

Printed Amstrad Addict magazine announced, check it out here!

Main Menu

Game loop - help

Started by shaymanjohn, 21:06, 07 April 20

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

shaymanjohn

Hi folks,


After discovering the assembler in retro virtual machine, I've been busy trying to learn about coding games for the CPC.


I've managed to hack a few tools together to pull the tileset and first sprite into asm format from the new blues brothers images that NiNxPe put together (they're excellent btw!) (I've no plans - or indeed the ability - to make the full game, just getting my head around how things work).


So here's where I am - btw the code is an extension of the excellent tilemap tutorial on here by arnoldemu (again excellent, thanks so much).

       
  • Got the first screen showing
  • Got a font and string routine working
  • Got Elwood sprite showing (correctly masked, holding my gfx as mask / pixel / mask / pixel / etc)


The game loop I'm using is very simple (see tilemap.asm):

       
  • Wait for frame
  • Erase Elwood
  • Check for movement
  • Draw Elwood
  • Loop


But even with one sprite, as I move Elwood towards the top of the screen he disappears (fine at the bottom). I've attached the code and a disk image - i understand it's not going to be the best code in terms of optimisations, but I'm surprised I can't even draw one masked sprite in the v-blank.


In the sprite routine I basically save the background into a buffer as I'm drawing the sprite. To erase I just put the background back.


To build the code in RetroVirtual machine just launch the console in there, cd to where you've put it, and type 'a tilemap.asm'. Then in the main emulator window 'call &1000'
Or if you don't want to build, insert the disk and run"blues


I'm not sure if the assembly format used here will work with other assemblers...(it might do, but not tried it).


(cursor keys to move Elwood).


I've played loads of Amstrad games which happily show sprites at the top of the screen - is there something wrong with my approach here. Should I be double buffering or something? (but does every game do that?)


Thanks in advance for any advice/help on this.








Axelay


As far as expectations of code speed go, something I usually do is time a core routine even before I've written it in an assembler.  Then you have a fair idea how long it's going to take even before you've written a thing.


So if you do not want to double buffer, you should consider instead starting your game loop with the first interrupt after your play area, or maybe the one before with a delay if it's just above the bottom of the play area.


If you have too many sprites, or they're too large to avoid writing to screen while the screen is refreshed, you could use a small buffer where you draw the background behind a sprite, then mask the sprite on to that, then copy that to the visible screen.  The difficulty with that approach is when sprites overlap, things get complicated.


Another approach that can be used is 'dirty tiles', so you don't save the background, just restore it from background tiles marked as 'dirty'.


I think the sprites you are using here might be so big that you probably would have to double buffer.  Personally I have always used a hardware double buffer in my projects to date.  There is the possibility of using a software 'double buffer', like a spectrum ported game, but only do that if you want a terrible frame rate or a small screen...

shaymanjohn

Thanks Axelay.


On the distinction between a software double buffer and a hardware one - my understanding is:

       
  • A software double buffer is an area of memory where you can make updates, and when done that space is copied to the physical screen as quickly as possible (hence the need to possibly use a smaller screen size)
  • A hardware double buffer is where you alternate the physical address of the screen, and do all work on the screen memory thats not currently visible.


Does that sound right? Seems in both cases memory is going to be very tight (and probably more so if using a hardware buffer?)


Axelay


Yes, that sounds right.


A hardware double buffer doesn't necessarily consume more memory than a software double buffer though.  Using simple CRTC manipulation, you can shrink the screen to use less memory, and use the unused memory for other purposes.  At least one game comes to mind (Astro Marine Corp) that took that to the extent of having two screens of just 8k side by side in the same 16kb bank with a hardware double buffer.  If you consider more complex CRTC manipulation and use a screen split, then you can double buffer just the play area and not the score panel, which would result in using no more memory than an equivalent sized software double buffer.

Sykobee (Briggsy)

Another thing to note is that you won't be targeting 50fps with your game most likely.


Even with 25fps you can split sprite rendering between the two frames (e.g., frame 1 - player and bullets, frame 2 - enemies).
But without a double buffer this will still limit the total amount of sprites you can render in that time, and also there may be sprite overlap issues.


So this is why so many people using double buffering - it makes things easier - no timing issues, no sprite flickering issues, if you do take to long to render a frame you get game slowdown but no rendering issues (e.g., dropping from 17fps to 12). Stick anything that needs to run every frame (music player) in an interrupt routine. Make use of 128KB if you want lots of varied graphics.


Other games used plain backgrounds where sprites could be (quicker to write 0s to erase a sprite than copy+restore background). Okay in early CPC platformers and space shooters, but not if you want something graphically interesting.


It does sound like you've made great strides however! Excellent work.

GUNHED

Quote from: Sykobee (Briggsy) on 11:07, 08 April 20
But without a double buffer this will still limit the total amount of sprites you can render ...
Why? Look at Cyber Chicken, it displays dozens of sprites and runs with (up to) 50 fps. All you need is effective code.
http://futureos.de --> Get the revolutionary FutureOS (Update: 2023.11.30)
http://futureos.cpc-live.com/files/LambdaSpeak_RSX_by_TFM.zip --> Get the RSX-ROM for LambdaSpeak :-) (Updated: 2021.12.26)

Sykobee (Briggsy)

Quote from: GUNHED on 13:04, 08 April 20
Why? Look at Cyber Chicken, it displays dozens of sprites and runs with (up to) 50 fps. All you need is effective code.
It does indeed and it's excellent coding, however it is one of those games with a plain background (and indeed you can just overwrite the chickens directly with no erase step - I forgot to mention this option - software sprites may be slower than hardware, but you get so much more flexibility!) so you save a lot of effort blending background and foreground graphics.

GUNHED

Well, the background is limited, but need to get restoring. About flexibility you got a very good point. Other systems with hardware sprite often have limited colors in them for example.
http://futureos.de --> Get the revolutionary FutureOS (Update: 2023.11.30)
http://futureos.cpc-live.com/files/LambdaSpeak_RSX_by_TFM.zip --> Get the RSX-ROM for LambdaSpeak :-) (Updated: 2021.12.26)

Powered by SMFPacks Menu Editor Mod