| |
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....
|
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
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: 1378 |
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: 1378 |
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: 634 |
Nice idea for a bullet hell game :) |
| |
Style
Registered: Jun 2004
Posts: 498 |
Im wondering if, based on the moth movement and the bullet frequency, you couldnt generate a sprite with multiple bullets in it that hold the same pattern down the screen together..... if that makes sense. |
| |
pmprog
Account closed
Registered: Nov 2005
Posts: 54 |
Things have gone a little wrong
Quoting Martin PiperNice idea for a bullet hell game :)
Thanks, but what really inspired me was Dragon Attack on the Amstrad
Quoting StyleIm wondering if, based on the moth movement and the bullet frequency, you couldnt generate a sprite with multiple bullets in it that hold the same pattern down the screen together..... if that makes sense.
Possibly, but the sprites are (will be) all already in use multiple times once I've got all the multiplexing in |
| |
pmprog
Account closed
Registered: Nov 2005
Posts: 54 |
https://youtu.be/6n2zQIuYe1Y
So many bugs!!
Not quite sure why some lines move slower than others, and if I add the code that removes the bullet before redrawing, it'll only ever draw right down the centre of the screen! |
| |
rexbeng
Registered: Aug 2012
Posts: 30 |
Quoting ChristopherJam[...] the Amstrad version looks like it's only doing around 80 enemy bullets [...]
80 bullets? You should try a bit harder and get to the further levels :) |
| |
pmprog
Account closed
Registered: Nov 2005
Posts: 54 |
I'm kind of getting angles now, but my maths code is still pretty poor. These videos are supposed to show an exploding circle.
https://youtu.be/hp8XVp5yeLc
The code before this looks pretty nice, it made a "star" explosion... still all wrong though.
I really can't wrap my head around why it's doing this, partly because I'm tired. Feel so close to just ditching this project and working on a simpler one... one that preferably doesn't need 8bit trigometry... |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
That my friend is you not having proper 2 complements math. First of all, is your sinus table signed at all?! |
| Previous - 1 | 2 | 3 | 4 | 5 - Next |
