| |
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 |
|
... 29 posts hidden. Click here to view all posts....
|
| |
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. |
| |
soci
Registered: Sep 2003
Posts: 480 |
I took a trace at the time when it's slow. Got this:
http://singularcrew.hu/temp/96f7bbe1a270a5667b6f91878f504a18.png
Inlining maths_sine and maths_cosine is not worth it at this point. Go for bitmap_plotpixel and bullets_check first.
Btw. nice structured code. |
| |
pmprog
Account closed
Registered: Nov 2005
Posts: 54 |
Quoting ptoingI think a screen resolution of 160x100 for the plots would be sufficient.
I would like to make the bullets bigger (and thus easier to see), but the way I was looking at it meant that you needed to plot 6 extra pixels per bullet (instead of one "clear" and one "draw", you'd be doing four "clear" and four "draw")
That said, I guess if I switched into multicolour mode, then I could reduce that to drawing two pixels per bullet to get a nice square block; and it would let me draw the player bullets in a different colour to the TigerMoths
Quoting soci
I took a trace at the time when it's slow. Got this:
http://singularcrew.hu/temp/96f7bbe1a270a5667b6f91878f504a18.png
Wow, amazing. What tool did you use to produce that?
Inlining maths_sine and maths_cosine is not worth it at this point. Go for bitmap_plotpixel and bullets_check first.
Quoting soci
Btw. nice structured code.
Thanks for the compliment |
| |
ptoing
Registered: Sep 2005
Posts: 271 |
Quote:That said, I guess if I switched into multicolour mode, then I could reduce that to drawing two pixels per bullet to get a nice square block; and it would let me draw the player bullets in a different colour to the TigerMoths
Yeah, that is what I would suggest. Make the bullets Mcol, and update gfx only every other line, so every 2nd line can use the same data as the odd line before it. The different colour thing is also a nice bonus. |
| |
soci
Registered: Sep 2003
Posts: 480 |
First half was deleted as I was too slow ;)
What I wanted to add beyond that is that bigger pixels won't be faster to draw but a smaller amount is needed to "cover" the same area.
The tool is QCacheGrind with this trace and the github sources mentioned above:
http://singularcrew.hu/temp/callgrind.out.16726 |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
Quote: 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
thats the way it works, you trade memory for speed :) also compared to 64k a few 256 byte tables to speed up plotting is not much. |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: First half was deleted as I was too slow ;)
What I wanted to add beyond that is that bigger pixels won't be faster to draw but a smaller amount is needed to "cover" the same area.
The tool is QCacheGrind with this trace and the github sources mentioned above:
http://singularcrew.hu/temp/callgrind.out.16726
Bigger pixels are faster to draw indeed. For example with 2x2 resolution you can fit both x position in a byte instead of a word. Also you mask and or the same byte on both lines with a byte difference. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
Nice work on the profiling, Soci.
Interesting idea about doing less work within a char, oziphantom.
I was already thinking there may be merit in using a few charsets instead of a bitmap. Combining the two could work quite well; eg if every 32x64 pixel region of the screen was one page of a charset, then for some bullets it could be as long as 70 frames before a page crossing.
If each bullet computed at spawn time (and again at every subsequent page crossing) a lower bound on the number of frames until the next crossing, most of the overflow checks could be skipped altogether. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
Assuming an event table is used to handle shunting bullets from unrolled speedcode to edge-detecting code (so they don't need to check their own timers), it's looking like eorplot/update position/eorplot would take around 76 cycles per bullet per frame.
That's just for a single hires or MCM pixel per bullet, too; add 26 cycles per bullet per frame for a second row of pixels. |
| |
Martin Piper
Registered: Nov 2007
Posts: 722 |
Nice idea for a bullet hell game :) |
| Previous - 1 | 2 | 3 | 4 - Next |
