[CSDb] - User Forums - [Req for help] TigerMoth performance

You are not logged in - nap

CSDb User Forums

Forums > C64 Coding > [Req for help] TigerMoth performance

2017-08-02 07:56

pmprog
Account closed

Registered: Nov 2005
Posts: 54

[Req for help] TigerMoth performance

Hi all,

I'm getting to a point in TigerMoth that I'm thinking of dropping it. If you watch the video below, you can see when I start hitting a large number of bullets I get really bad performance.

https://www.youtube.com/watch?v=Lskbol7quDk

It's kind of expected, but this version doesn't even have the raster splits for dealing with the score or player, no collision detection for the TigerMoth or the player, nor any music, so performance is only going to get a lot, lot worse. I really like what I've managed to put together so far, but if it's not going to be playable, then I might as well drop it now.

So I thought I'd pop on here and see if anyone was willing to have a quick look and see if there were any points that look really bad. My code is broken down in to lots of subroutines (this might be a problem regarding performance?) with headers that hopefully explain what it's job is, and I've tried to keep all the related pieces together in aptly named files so it's easy to mooch about.

I've been working in a private git on my local server, but I've uploaded a snapshot of the current code to GitHub. The source code is MIT license, and if the project is finished, the full source will be released with the game.

https://github.com/pmprog/TigerMothC64

Also, for reference, the .spriteproject file can be opened in C64 Studio. Export to data, but change the "!byte" to ".byte"
C64 Studio 4.1

I currently use TASM as my compiler, though I was thinking of trying to move across to the ca65 assembler in the cc65 package. But that doesn't really have any baring on the life of this project.

Oh, and finally, before anyone says, yes, I've got my Sine/Cosine tables all messed up (Sine starts at the positive value, Cosine starts at zero and goes negative before positive), but I'm "okay" with that, I just count my angles anti-clockwise from the "3 o'clock" when dealing with bullets

Thanks in advance

2017-08-02 09:17

oziphantom

Registered: Oct 2014
Posts: 490

Kind of hard or follow the code from those files ;) where is the main loop?

So its a bullet hell? Do you try and update every bullet each frame? if so making it updates the bullets over 4~5 frames would help.

2017-08-02 09:28

Mixer

Registered: Apr 2008
Posts: 452

A faster plot routine seems to be possible with tables. See
http://csdb.dk/release/download.php?id=182655 for instance.

It may be possible to improve trajectory calculation as well. Look at fast line drawing routines.(Bresenham)

You should be able to have 256 plots in 2 to 3 frames easily.

2017-08-02 09:44

pmprog
Account closed

Registered: Nov 2005
Posts: 54

Quote: Kind of hard or follow the code from those files ;) where is the main loop?

So its a bullet hell? Do you try and update every bullet each frame? if so making it updates the bullets over 4~5 frames would help.

Ah, sorry. The main game loop enters here:

https://github.com/pmprog/TigerMothC64/blob/master/screen_game...

Quick ref:
screen_*.inc files are "segments", so eventually there'll be a "screen_gameover.inc" etc.
game_*.inc files are routines and data for the actual game
tools_*.inc files are where I keep general routines not specific to this game

This checks the health of the TM, then goes through the raster checks, then processes the "frame", followed by checking the player is alive.

Each game loop, it processes 8 bullets (this can be tweaked), and only once all 256 bullets have been processed does it do any player/TM movement.

I did it like this so that everything moved together, as on my first write of the game, when bullets moved in seperate frames, it looked a bit odd - especially when you shot a semi-circle all on the same frame, then some bullets moved, and some didn't. But it's something I can try again and see.

Cheers

2017-08-02 09:50

pmprog
Account closed

Registered: Nov 2005
Posts: 54

Quote: A faster plot routine seems to be possible with tables. See
http://csdb.dk/release/download.php?id=182655 for instance.

It may be possible to improve trajectory calculation as well. Look at fast line drawing routines.(Bresenham)

You should be able to have 256 plots in 2 to 3 frames easily.

I did look at this document, and it looked like a lot of repeating data in the tables.
http://codebase64.org/doku.php?id=base:dots_and_plots

I do use tables, but combined with some calculation so I don't have to have such large tables with repeating data.

I will look at using a larger table to reduce some more of the calculations though

Cheers

2017-08-02 10:19

ChristopherJam

Registered: Aug 2004
Posts: 1409

It's pretty ambitious; the Amstrad version looks like it's only doing around 80 enemy bullets (5 waves of 16), and they've got a 4MHz Z80 to play with. (I know, z80 takes more cycles per instruction than 6502, but it's not 4x as many, and their 16 bit registers would probably be handy for plots, too)

256+ plots per frame is doable under demo conditions, but that's without also handling collisions, sprites, other game logic etc.

But yes, those JSRs to sine and cosine in your update routines need to go; inline all that.

Maybe write out a routine that does everything that a bullet needs to do each frame (update position, plot, collision check), inline all the function calls, optimise what you can, then do a cycle count.

Work out how many cycles you want to budget on bullets per frame, divide that by your update time, and that'll tell you how many bullets you can animate. If it's within cooee of the minimum you'd consider tolerable, then continue, otherwise have a rethink.

2017-08-02 10:27

pmprog
Account closed

Registered: Nov 2005
Posts: 54

Quoting ChristopherJam

It's pretty ambitious;

Somebody mentioned that on my YT video, I'm beginning to agree :)

Though I've changed it so it processes 128 bullets per frame, and seems to make quite a nice improvement

Quoting ChristopherJam

Maybe write out a routine that does everything that a bullet needs to do each frame (update position, plot, collision check), inline all the function calls, optimise what you can, then do a cycle count.

That might be an idea. If I can calculate my cycle counts, I guess I could potentially drop my raster checks and know exactly how many bullets to process between each other bit of code.

Cheers

2017-08-02 11:14

oziphantom

Registered: Oct 2014
Posts: 490

Quoting pmprog

I did it like this so that everything moved together, as on my first write of the game, when bullets moved in seperate frames, it looked a bit odd - especially when you shot a semi-circle all on the same frame, then some bullets moved, and some didn't. But it's something I can try again and see.

For something like this, I would make "buckets" and the you update the bucket at once, and then stager the bucket updates. This way a semi circle could be put into 1 bucket so they all get updated.

Also the Amstrad probably ( never dev'd for it ) has a linear bitmap and not the weird as Char system we have on the C64, which helps as well.

With bullets, I imagine they can't move very fast each frame , ie that they won't be able to move say more than 1 char. This means rather than doing a full set of maths to get the point, you can store them as Pointer to Char, x,y then when the x overflows you add 8 to the Pointer, under sub 8, under Y - 320, over y + 320 and keep all of its movements in a delta system rather than convert from X,Y to bitmap.

If you make this for say EF then you have ROM to burn ;) so you can make a bunch of code to handle however many directions you want say you have 16 angles or 32 angles you can support.
so do a diagonal down right so have
Step 0
lda (pointer),y
and #%01111111
sta (pointer),y
iny
lda (pointer),y
ora #%01000000
sta (pointer),y
rts
Step 1
lda (pointer),y
and #%10111111
sta (pointer),y
iny
lda (pointer),y
ora #%00100000
sta (pointer),y
rts
....
Step 7
lda (pointer),y
and #%11111110
sta (pointer),y
jsrAdd321 ( shift down Y and move over 1 char)
lda (pointer),y
ora #%10000000
sta (pointer),y
; set step to 0
....
so this way you jump into a step into an angle and then each update move its pointer, where each step is a custom routine to update the x or y in a relative manner and shift the pixel as needed.

2017-08-02 11:26

pmprog
Account closed

Registered: Nov 2005
Posts: 54

Quoting oziphantom

For something like this, I would make "buckets" and the you update the bucket at once, and then stager the bucket updates. This way a semi circle could be put into 1 bucket so they all get updated.

That's a good suggestion, I'll look into that

Quote:

With bullets, I imagine they can't move very fast each frame

I only move them a maximum of 1 pixel horizontally and 1 pixel vertically. The player's moves 4 pixels vertically, but that's handled differently.

A big thank you to everyone who's posted (and emailed, I hope you get my reply(s), as the mail client was playing up on my end), I've got a few new things to try, and I'll see how I get on; and I'll probably post an update when I've made some progress.

2017-08-02 14:31

JackAsser

Registered: Jun 2002
Posts: 2014

Also lower the resolution of the plots. Check my plot routine in our demo Classics. It kinda looks like bullet hell to me and might be usable for you.

2017-08-02 15:47

ptoing

Registered: Sep 2005
Posts: 271

Gotta agree with Jackasser. A bit of slowdown now and then is OK in a bullet hell shmup, but that video you linked looks unplayable.

I think a screen resolution of 160x100 for the plots would be sufficient.

... 29 posts hidden. Click here to view all posts....

Previous - 1 | 2 | 3 | 4 - Next

Refresh

Subscribe to this thread: