Jump to content
IGNORED

Astro-Storm - My new RB+ Game


Recommended Posts

Just had an idea that might be cheaper in terms of performance.....

 

Ditch the scaling and just create a 128x128 sprite and animate it to make it look like its getting larger/closer.

 

Then I can just dump it at the correct x,y and run the animation..... rinse and repeat.....

 

Could probably make it look a bit nicer too then.

 

That's the same advice we gave to someone a while back with regards to some Jaguar feature or other, just because the Jaguar can do something it doesn't mean it's the best way to achieve it or the simplest or easiest :0) Burn a bit more memory, but save tons of performance with the added benefit of being able to make it look more than just a bit nicer as you have full control of every pixel of every frame.

 

Maybe it's an easier decision to make if you're targeting a ROM rather than a BJL-style single-loader, but either way it's more down to the overall scale of your project and what you want to allow for yourself.

 

If you want to send something over for testing or if you want any ideas on how to reduce the performance requirements for the original implementation, you could always fire over a binary and some code, it'd be interesting to see how the Jaguar handles what you were asking of it (I've done a few experiments with various rmw scaled objects and things, I think there were 11 or 12 of them on screen at once but it required some careful positioning with respect to overlaps and objects per scanline).

Link to comment
Share on other sites

I imagine it's the starfield thats killing it. There are some floats in there etc. Its fine in the main game loop but the majority of the other things happening there are handled directly by Raptor.

 

Perhaps if I can change that to fixed point or something then that might help.

 

Hopefully I'll get some time this weekend to play around.

 

If i have no success then I will set up an example project. I'm sure you guys would just look at it and see the answer ;) I would rather have a go first though.

Link to comment
Share on other sites

I imagine it's the starfield thats killing it.

 

Does it use the particle system or are you tracking pixels/objects for the stars? I can't remember how it looks right now off the top of my head, I want to say they looked like tiny sprites...

Link to comment
Share on other sites

 

Does it use the particle system or are you tracking pixels/objects for the stars? I can't remember how it looks right now off the top of my head, I want to say they looked like tiny sprites...

Yes, there are 16 sprites. I think they are all 16x16 though as I couldnt get them smaller. Then they are scaled down to 4 on x and y in the object list. Perhaps I should try get them smaller, that could be a win? I seem to remember CJ saying the x has to be a multiple of 8 but not the y.

 

The start positions are worked out at the beginning and stored. Then the math happens to move them. Once they are past the screen they just reset to their start position.

 

I did just think I might be able to pre-compute all their locations though, from start to end. I need to look into that. Not sure how much storage that would need.

 

I did wonder if the particle engine could do a starfield as that would probably be really quick.

Link to comment
Share on other sites

So you have 16 16x16s displaying scaled down from their usual size for the stars? That's probably asking a lot of the OP already (if I understood what you're doing), all scaling adds to the work of the OP.

 

If you just use the first 3x3 or 4x4 pixels of your 16x16 and display at native size (unscaled) it'll be less work for the OP. You should reduce their height to whatever the max number of pixels you use, 3 or 4 or whatever to save memory (tiny bit) and again reduce work for OP (less objects on each scanline). If you only use 2 or 3 colours reducing the bit depth could help as well if you haven't already.

 

Sorry if I misunderstood what you meant by "scaling to 4 in the object list", I took that as meaning you had them set to 00000100 scale factor.

 

I should make the point, I dont scale the stars at all in code.

 

Changing the scale factor itself doesn't really take up that much resources, it's having scaling itself and more so the number of scanlines the object then appears on that gives the OP more work to do.

Edited by sh3-rg
Link to comment
Share on other sites

I'm not sure if what you want to achieve is doable with the particle system but I think you should definitely take a look at it. The reason? It can handle tons of pixels floating about without serious slowdowns.Have a look at "particles" and "spiral" projects to see how you can set those up. They might seem a bit quirky at first but (as usual with rb+) once you find the magic incantations you can write proper stuff :).

  • Like 3
Link to comment
Share on other sites

I'm not sure if what you want to achieve is doable with the particle system but I think you should definitely take a look at it. The reason? It can handle tons of pixels floating about without serious slowdowns.Have a look at "particles" and "spiral" projects to see how you can set those up. They might seem a bit quirky at first but (as usual with rb+) once you find the magic incantations you can write proper stuff :).

You were spot on with what im doing. I'll try as you say and make them smaller etc. It's definately a logical place to start.

 

I have had a look at the particle examples before but not played around with them yet. I think it could get pretty close.

 

Really hope I get some time this weekend.

 

I'm starting to get the "midway game development itch" .

Where I'm itching to get going on a new project :) Must finish this first

  • Like 1
Link to comment
Share on other sites

If you attempt a starfield with particles, remember you can adjust the size of the particle buffer itself fairly easily so you could reduce it to just you game window size. You can also use multiple copies of it set to different CLUT regions for the palette or flip a copy of it to get a 'free' doubling of star cout, at the expense of it looking symmetrical.

 

At this point you could then experiment with scaling the copies, having them darker and higher up the list to produce trails, but then you might be disappearing into a resource-hogging scenario and no better off than where you are now :o)

 

A starfiled would be a good particle example, it's probably worth doing.

Edited by sh3-rg
  • Like 1
Link to comment
Share on other sites

If you attempt a starfield with particles, remember you can adjust the size of the particle buffer itself fairly easily so you could reduce it to just you game window size. You can also use multiple copies of it set to different CLUT regions for the palette or flip a copy of it to get a 'free' doubling of star cout, at the expense of it looking symmetrical.

 

At this point you could then experiment with scaling the copies, having them darker and higher up the list to produce trails, but then you might be disappearing into a resource-hogging scenario and no better off than where you are now :o)

 

A starfiled would be a good particle example, it's probably worth doing.

That all sounds very interesting. It's driven me more to look at it.

 

Of course, I dont know how to do half the things you mention. Is it easy to make a copy and flip it, for example? I wouldn't know where to begin. I could copy the array but I have a feeling thats not what you mean.

 

One possible issue is in a starfield the stars typically all start from different locations. I think from what I've seen the particles all start from the same origin. This might look ok especially if they start as a dark colour, I'll have to check it out.

Link to comment
Share on other sites

Yep, you can set your palette to begin with dark colours or even black, then the stars would appear to melt in from the blackness and go up to shite/bright/whatever you fancy.

 

By "making a copy" (sorry, my bad wording) I meant just make a second object/sprite based on the particle buffer and set the h-flip.

 

I'll try to make an example starfield using a reduced-sized particle buffer (that's done in rapapp.s) with multiple copies and maybe some scaling.

Link to comment
Share on other sites

Yep, you can set your palette to begin with dark colours or even black, then the stars would appear to melt in from the blackness and go up to shite/bright/whatever you fancy.

 

By "making a copy" (sorry, my bad wording) I meant just make a second object/sprite based on the particle buffer and set the h-flip.

 

I'll try to make an example starfield using a reduced-sized particle buffer (that's done in rapapp.s) with multiple copies and maybe some scaling.

That would be awesome but I am more than happy to have a go and see what I come up with first if you like.

 

I see what you mean about the copy now, I hadn't realised that could be done :) My mind has just exploded with possibilities lol

Edited by Sporadic
  • Like 1
Link to comment
Share on other sites

That would be awesome but I am more than happy to have a go and see what I come up with first if you like.

No doubt you will come up with something decent for your game, just think it's something that might help as a mini tutorial thingy as it could also cover resizing the particle buffer and particle count.

I see what you mean about the copy now, I hadn't realised that could be done :) My mind has just exploded with possibilities lol

 

I know that feeling well! What I never did that you might want to look at as well is using gwidth to make use of sections of it... could get messy, but might be worth it!

Link to comment
Share on other sites

Check out the attached. In just under an hour I had something running that looked ok.

 

I didn't like that you could see a pattern in the particles though, so I added a counter for each particle to tell when it expires, then picked a new angle.

 

I also wanted to remove the delay and put in an RUPDALL(1) so it mimicked the game. I was then presented with what looks like extra copies of some stars so some of them kind of have trails. I assume that's something to do with how the screen updates?

 

I quite like the result and will be more than happy for this in my game so I will try plugging it in later and see if any better for performance. Having the RND in the loop to pick the new angle is concerning because I don't know how much of a performance hit that causes so we'll see.

 

Anyway, here is the project file so anyone else can have a look and play.

 

starfield.zip

  • Like 1
Link to comment
Share on other sites

RND is a bit of a POWA-leech, going to check this out now!

 

EDIT:

 

I got a few black screens at random, IIRC CJ's firework particle demo did the same thing (worked in VJ fine, black screened on hardware). I think he was requesting too many particles too often or using something out of range, I did fix it for rB+ (it was fine in original rB) but can't remember exactly what it was. I'll take a look later if you've not found it by then.

 

RNDRANGE is new to me, not seen that in the BCX help before - interesting.

Edited by sh3-rg
Link to comment
Share on other sites

RND is a bit of a POWA-leech, going to check this out now!

 

EDIT:

 

I got a few black screens at random, IIRC CJ's firework particle demo did the same thing (worked in VJ fine, black screened on hardware). I think he was requesting too many particles too often or using something out of range, I did fix it for rB+ (it was fine in original rB) but can't remember exactly what it was. I'll take a look later if you've not found it by then.

 

RNDRANGE is new to me, not seen that in the BCX help before - interesting.

 

Strange, i've just noticed a difference between mine and yours...

 

Could it blow up where I used RND * 512 for the angle?

You used RND * 511

 

Just a thought.

 

Also, perhaps the raptor_particle_pixels variable isn't large enough? I changed it to 16 and it blew up. Maybe it should be larger.

 

Yes, that RNDRANGE is quite handy. Spotted it when looking up RND in the help file.

Edited by Sporadic
Link to comment
Share on other sites

I think the particles were getting called too often, that's why they looked like they had trails (I exploited that for one of the particle demonstrations I did by overloading the requests for more particles and changing timing intervals every tick).

 

I think the best way to think about particles is that they're fire and forget. Once you pass the array to RPARTI, your job is done and you can go do other stuff for a while.

 

I changed the inner loop to the below and it no longer black screens:

 

DO
  counter++
  VSYNC
  IF counter=20 THEN
    FOR i=1 TO parts%
      particles[i,0]=RND * 512 ' angle
    NEXT i
    RPARTI(strptr(particles))
    counter=0
  ENDIF
LOOP
The refresh of the angles is done every 20 frames, you don't need to check that the previous particle described by that array has finished, as the particle engine manages that stuff itself - when you request more particles it simply checks to see if there's any free and uses as many as it needs. So alter the amount of time between calls to that and you'll get a more or less dense starfield.

 

If you want to add your trails back in, you could request the same particles again a few frames later. Likely before there were many particles stacked up on top of each other that you couldn't initially see until they moved further from their origin.

 

Something like this:

DO
  counter++
  VSYNC
  IF counter=3 OR counter=7 THEN
    RPARTI(strptr(particles))
  ENDIF
  IF counter=20 THEN
    FOR i=1 TO parts%
      particles[i,0]=RND * 512 ' angle
    NEXT i
    RPARTI(strptr(particles))
    counter=0
  ENDIF
LOOP
That shows the initial particles, then 3 frames later fires the same set, and then again another 4 frames later. Edited by sh3-rg
  • Like 1
Link to comment
Share on other sites

I think the particles were getting called too often, that's why they looked like they had trails (I exploited that for one of the particle demonstrations I did by overloading the requests for more particles and changing timing intervals every tick).

 

I think the best way to think about particles is that they're fire and forget. Once you pass the array to RPARTI, your job is done and you can go do other stuff for a while.

 

I changed the inner loop to the below and it no longer black screens:

 

DO
  counter++
  VSYNC
  IF counter=20 THEN
    FOR i=1 TO parts%
      particles[i,0]=RND * 512 ' angle
    NEXT i
    RPARTI(strptr(particles))
    counter=0
  ENDIF
LOOP
The refresh of the angles is done every 20 frames, you don't need to check that the previous particle described by that array has finished, as the particle engine manages that stuff itself - when you request more particles it simply checks to see if there's any free and uses as many as it needs. So alter the amount of time between calls to that and you'll get a more or less dense starfield.

 

If you want to add your trails back in, you could request the same particles again a few frames later. Likely before there were many particles stacked up on top of each other that you couldn't initially see until they moved further from their origin.

 

Something like this:

DO
  counter++
  VSYNC
  IF counter=3 OR counter=7 THEN
    RPARTI(strptr(particles))
  ENDIF
  IF counter=20 THEN
    FOR i=1 TO parts%
      particles[i,0]=RND * 512 ' angle
    NEXT i
    RPARTI(strptr(particles))
    counter=0
  ENDIF
LOOP
That shows the initial particles, then 3 frames later fires the same set, and then again another 4 frames later.

 

 

Ok right, I understand now. That sounds great. I'll have a look at the changes you've made.

 

Thanks so much for the help. I will be looking at adding more particles if possible :P :twisted: :thumbsup:

  • Like 1
Link to comment
Share on other sites

Ok right, I understand now. That sounds great. I'll have a look at the changes you've made.

 

Thanks so much for the help. I will be looking at adding more particles if possible :P :twisted: :thumbsup:

I think with something like what I posted above added to what your starfield (kind of taken away really, it's calling less particles :0) ) it should look great in your game and not be too much of a resource hog at all. I left it running here, it looks decent, the stretchy stars as they pull away and truly random look are win.

  • Like 1
Link to comment
Share on other sites

I think with something like what I posted above added to what your starfield (kind of taken away really, it's calling less particles :0) ) it should look great in your game and not be too much of a resource hog at all. I left it running here, it looks decent, the stretchy stars as they pull away and truly random look are win.

Cheers, can't wait to try it

Link to comment
Share on other sites

I think with something like what I posted above added to what your starfield (kind of taken away really, it's calling less particles :0) ) it should look great in your game and not be too much of a resource hog at all. I left it running here, it looks decent, the stretchy stars as they pull away and truly random look are win.

So erm, yeah.....

 

I just swapped out the old star code for the new particle code (made easier by using an 'include' for the .bas files) and OMG.

 

I can barely even complete the first level now because the shield runs out too fast as the main loop is so much faster. So i'm going to have to slow that down now :)

 

Then, I got to the navigation mini-game and they shot past so fast it was over in a few seconds.... I barely had time to react lmao

 

This is all in VJ, not tried actual Jag yet but I would say that's a bloody good sign.

 

Will post update later hopefully and maybe even new binaries....

  • Like 2
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...