[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

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

2017-08-21 13:16

pmprog
Account closed

Registered: Nov 2005
Posts: 54

Okay, so the 1st problem was that I had angle 180, where my range is 0-179. Then I also had some issues with sine/cosine of -1.0

Anyway, looks good, but slow
https://youtu.be/qWvrhBZiWlk

2017-08-21 13:26

Bago Zonde

Registered: Dec 2010
Posts: 29

Well, the real bullet hell :D. In terms of gameplay, do you think you're going to avoid all that bullets during the gameplay? I would try to remove half of the bullets, and try to play with the speed. I'm thinking about the game itself here, as from tech perspective, would be great to have thousands of bullets moving around.

www.commocore.com

2017-08-21 19:37

TWW

Registered: Jul 2009
Posts: 545

Two quick thoughts I had;

#1: How is the plotter set up, not using a shitload of jsr and stuff I hope. Also as it's <256 pixels, you should get away with a:

    lda Y_Table_Hi,y
    sta $fc
    lda Y_Table_lo,y
    sta $fb

    ldy X_Table,x
    lda BitMask,x
    ora ($fb),y
    sta ($fb),y

where X and Y contains the plott coordinates.

Second, the bullets seem to follow the path of an expanding circle. Could this be handled by a adapted Bresenham's circle algorithm (only drawing in two lower quadrants and limiting the number of pixels to match what you have on your youtube video)?

2017-08-22 09:31

pmprog
Account closed

Registered: Nov 2005
Posts: 54

I've put a new snapshot of the code up on GitHub. I've not converted it to use 64tass yet, but that will be done, then I can abuse macros to have "subroutines" written in seperated files, but drop the need for all the jsr/rts.
https://github.com/pmprog/TigerMothC64

Quoting Bago Zonde

In terms of gameplay, do you think you're going to avoid all that bullets during the gameplay? I would try to remove half of the bullets, and try to play with the speed.

I did think about cutting the number of bullets, but it really makes the play area sparse, meaning it's pretty easy to avoid everything.
I am thinking of making a strip down the left hand side to match the right hand side, so you play in a narrower corridor. This will also mean some bullets drop quicker, whilst still giving a bullet hell feel.

I think part of my problem will be making the game fun. I'm torn between trying to make the game fun, then seeing if I can fix performance, or seeing if I can get the performance before working on the "game". The problem is, if either of these aren't up to scratch, it's practically all wasted.

Quoting TWW

#1: How is the plotter set up, not using a shitload of jsr and stuff I hope. Also as it's <256 pixels, you should get away with a:

lda Y_Table_Hi,y sta $fc lda Y_Table_lo,y sta $fb ldy X_Table,x lda BitMask,x ora ($fb),y sta ($fb),y

https://github.com/pmprog/TigerMothC64/blob/master/tools_bitmap..
My code is different in the sense that it both sets and clears, however I am completely unaware of the whole $fc and $fb thing. Looks handy, considering I rewrite two portions of code with the address I'm editing.
How does the $fb:$fc thing work? What's special about it?

Quoting TWW

Second, the bullets seem to follow the path of an expanding circle. Could this be handled by a adapted Bresenham's circle algorithm (only drawing in two lower quadrants and limiting the number of pixels to match what you have on your youtube video)?

Not all bullets will be in an expanding circle, that's just one firing pattern. There will be others.

Cheers

2017-08-22 11:05

Oswald

Registered: Apr 2002
Posts: 5094

"How does the $fb:$fc thing work? What's special about it?"

it works by first setting the DST adress to the leftmost of the screen at the right 'height', then you use the Y register to offset the adress "horizontally" to the final desired one.

pro tip, you can save that adress in an unrolled loop for clearing.

(ldy # sta .. ldy # sta .. ldy # sta .. <- selfmod here the adress you write to, then just call all the sta's for clr)

if the bullet doesnt move vertically the whole zp pointer setup can be skipped.

anyhow max 256-512 dots can be moved like that per frame under demo conditions. so realistically in a game thats like 128 max imho.

2017-08-22 11:26

JackAsser

Registered: Jun 2002
Posts: 2014

Quote: "How does the $fb:$fc thing work? What's special about it?"

it works by first setting the DST adress to the leftmost of the screen at the right 'height', then you use the Y register to offset the adress "horizontally" to the final desired one.

pro tip, you can save that adress in an unrolled loop for clearing.

(ldy # sta .. ldy # sta .. ldy # sta .. <- selfmod here the adress you write to, then just call all the sta's for clr)

if the bullet doesnt move vertically the whole zp pointer setup can be skipped.

anyhow max 256-512 dots can be moved like that per frame under demo conditions. so realistically in a game thats like 128 max imho.

Assuming 50fps which is at all not needed in a game. 25fps would do just fine.

2017-08-22 16:07

TWW

Registered: Jul 2009
Posts: 545

Description about the plotting routine:

http://codebase64.org/doku.php?id=base:dots_and_plots&s[]=plott

EDIT: And yes, what Oswald say as clearing the entire bitmap screen (32 x 8 x 25 = 6400 bytes) vs. clearing only the plotts you have on the screen.

2017-08-23 19:17

pmprog
Account closed

Registered: Nov 2005
Posts: 54

Thanks for the info on zero page. I've also had an email from BiGFooT with some more stuff.

I apologise for turning this into a kind of developer log. Feel free to tell me to shut up until it's ready. Though I'm finding it quite helpful getting feedback as I'm working through it.

Here's a new video of the current version (The music is not playing from the game BTW, just on my audio player), plus a download of the PRG file, if you want to try it yourself. If you do, please could you provide feedback on whether you think it's responsive enough to make a playable game. Obviously there's still work to be done on optimising, and actual game play, but it's nice to get an idea of it's feel.

https://youtu.be/HHrJiZr4l1A
http://www.pmprog.co.uk/download/tigermoth.zip

2017-08-25 14:41

TWW

Registered: Jul 2009
Posts: 545

As you say, still needs some more spunk.

I'd get rid of that "clearbitmapmemory" routine first of all if I were you and replace it with something like:


plott:
    lda Lobyte
    sta $fb
    sta wiperoutine1+1
    lda Hibyte
    sta $fc
    sta wiperoutine1+2
    //plottit
    rts

wiperoutine:
    lda #$00
wiperoutine1:
    sta $2000
wiperoutine2:
    sta $2000
    //....

    rts

And no worries, wish more people would share their projects on something else than that damn facebook so here is good with me.

2017-08-26 20:48

pmprog
Account closed

Registered: Nov 2005
Posts: 54

Bah, it didn't save my reply. So I've got to rewrite it.

bitmap_clear is only called once at the start of a new game, so I'm not worried about that proc for now. Only things directly related to gameplay.

I really need to get the player firing bullets again, and actually implement bullet collisions, which I think is going to be the hardest part.

I was originally going to raster split two sprites multiple times down the right hand side for the score (that you can see in one of my older videos), but I'm considering just writing some 8x1 and 8x8 blit routines and use a mini "character set" to drop that dara in, as well as a health bar. That way I can save cycles reconfiguring sprites, and just update the bitmap memory when the score or health changes.

Previous - 1 | 2 | 3 | 4 - Next

Refresh

Subscribe to this thread: