Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
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-18 03:51
ChristopherJam

Registered: Aug 2004
Posts: 1359
It looks like you've just toggled the high bit from the absolute value to get your negative numbers, rather than flipping all the bits and adding one (or alternately just subtracting from 256).

-5 isn't %10000101 ($85), it's %11111011 ($fb)
2017-08-19 20:27
pmprog
Account closed

Registered: Nov 2005
Posts: 54
I think you're right, but at the same time, I wrote a subtract_fraction routine, so it shouldn't be a problem, as it'll be subtracting the fraction amount, rather than adding the negative version.

I think I might start a new project that is just my math code and see if I can fix all the problems there, then bring it back into my game project. Should help speed up debugging
2017-08-20 19:09
pmprog
Account closed

Registered: Nov 2005
Posts: 54
I bizarrely have 3 angles which don't work properly, and there seems to be a couple of gaps, but otherwise, I think it's looking much better

https://youtu.be/dOPoIq3K8c8
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: 541
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: 5007
"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: 1987
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: 541
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.
Previous - 1 | 2 | 3 | 4 | 5 - Next
RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Advanced
Users Online
csabanw
Yado/Hokuto Force
Moloch/TRIAD
hedning/G★P
Mibri/ATL^MSL^PRX
Murphy/Exceed
Knut Clausen/SHAPE/F..
Guests online: 302
Top Demos
1 Next Level  (9.8)
2 Mojo  (9.7)
3 Coma Light 13  (9.7)
4 Edge of Disgrace  (9.6)
5 No Bounds  (9.6)
6 Comaland 100%  (9.6)
7 Uncensored  (9.6)
8 The Ghost  (9.6)
9 Wonderland XIV  (9.6)
10 Bromance  (9.6)
Top onefile Demos
1 Party Elk 2  (9.7)
2 Cubic Dream  (9.6)
3 Copper Booze  (9.5)
4 Rainbow Connection  (9.5)
5 TRSAC, Gabber & Pebe..  (9.5)
6 Onscreen 5k  (9.5)
7 Dawnfall V1.1  (9.5)
8 Quadrants  (9.5)
9 Daah, Those Acid Pil..  (9.5)
10 Birth of a Flower  (9.5)
Top Groups
1 Booze Design  (9.3)
2 Nostalgia  (9.3)
3 Oxyron  (9.3)
4 Censor Design  (9.3)
5 Crest  (9.3)
Top Crackers
1 Mr. Z  (9.9)
2 S!R  (9.9)
3 Mr Zero Page  (9.8)
4 Antitrack  (9.8)
5 OTD  (9.8)

Home - Disclaimer
Copyright © No Name 2001-2024
Page generated in: 0.051 sec.