Sporadic

That does look superb, thank you again for the help and information I like the way you defined all the arrays up front and then cycled between them. That gets around the possible problem with how I went about it in the other thread with using the RND on the fly. Can't wait to try all this in the game and see what happens. Even if it doesn't help performance, it still looks much better. Change your VSYNC for an RUPDALL(1) to go into hyperspace......

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

Sounds amazing! I will download in a minute and have a look. I can't wait to see how you went about this. I've just been playing around and have come up with something i'm happy with which i'll post in the other thread. Mine may end up on the rubbish tip by the sounds of things but it taught me a lot just playing around for an hour or two and i'll probably particle all the things now.

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

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.

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

I should make the point, I dont scale the stars at all in code. They are currently 16x16 sprites with the x,y scale perminantly set to 4 in the object list.

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.

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.

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.

It also helps if you have multiple sprites defined for 1 sprite in the object list. Then in code for the following sprite declaration you can do something like NEWSPRITE+16 and so on. Or NEWSPRITE+NUMBEROFBADDIESCONST where NUMBEROFBADDIESCONST=16

Hi all, I've changed the way I declare my sprite constants in my code. Instead of like the examples; ' particle/text layer 0 DIM background% :background=1 DIM water% :water=2 DIM poulpe1% :poulpe1=3 DIM poulpe2% :poulpe2=4 DIM poulpe3% :poulpe3=5 DIM poulpe4% :poulpe4=6 Do this; ' particle/text layer 0 DIM background% :background=1 DIM water% :water=background+1 DIM poulpe1% :poulpe1=water+1 DIM poulpe2% :poulpe2=poulpe1+1 DIM poulpe3% :poulpe3=poulpe2+1 DIM poulpe4% :poulpe4=poulpe3+1 The outcome of doing it the second way, is if you need to add a sprite in the middle of your list, you don't have to adjust all the following variables. You just have to put your sprite declaration in the middle and +1 from the one before it. Then adjust the one after it to +1 from your new variable Once you have lots of sprites, this really helps speed things up. It's also less error prone. Example after inserting a new sprite; ' particle/text layer 0 DIM background% :background=1 DIM water% :water=background+1 DIM poulpe1% :poulpe1=water+1 DIM NEWSPRITE% : NEWSPRITE=poulpe1+1 DIM poulpe2% :poulpe2=NEWSPRITE+1 DIM poulpe3% :poulpe3=poulpe2+1 DIM poulpe4% :poulpe4=poulpe3+1 Hope this helps

This totally works!!! I now have multiple .bas files with subs, functions in them. These then just get included at the bottom of the main .bas file. Eg. $INCLUDE "stars.bas" $INCLUDE "sound.bas" $INCLUDE "scores.bas" $INCLUDE "navigation.bas" $INCLUDE "util.bas" It even looks in the working folder for them so you don't need to hard code a full path

Highscore code MT ship straight to production! Excellent The only thing I had to do was iterate over the raptor_highscores_hex array first to see if the player is in the top 10. This then drives the logic to display the "Enter your name" screen. Then call the hiscore_check(score,name$) function to actually enter it into the table. I'll see how I get on with this and post an example project if I get stuck. Cheers. Awesome, thanks for the offer. Very much appreciated. It's a single scaled bitmap. All the bit of code is doing is updating the starfield (same as in the main game) and scaling a single 32x32 bitmap of a hollow rectangle from 0 to 255. Basically so it looks like it's coming at you. Its X,Y (random) position are worked out before this part of the game starts and stored in an array so there isn't any realtime RND going on. As it scales I have to adjust the x,y position based on the current scale because the origin is in the top left rather than centre of the sprite. This keeps it in the correct position as it scales. There isn't any crazy math here either. I'll play around and see what happens.

I tried the "scores" example and it worked fine for me. I just downloaded the git-master, unzipped to a new folder, jumped into CMD, went into the basic folder and ran "build scores" from there. I didn't try building via notepad++.

Nice find! I was going to look for something like that. I'll definitely give that a try as i'm currently pushing 1357 lines of code. It would be good to organise functions into utility files for example, or player stuff into a player.bas I've delayed releasing the update I mentioned because the navigation mini-game I added is too slow on my actual Jag. I only had chance to try it tonight (anyone need a coaster? I have a few laying around now... ) It's nice and quick in the emulator though. Shame the emulator isn't matching the real speed in this case. Normally it's the emulator that runs slow if anything. But, the highscore table works with and without the memory track inserted. I managed to save my first highscores So thanks again everyone involved in getting that added. Hopefully tomorrow lunch I'll get chance to tweak the mini-game and dig some speed out from somewhere. Just a shame I won't know if its working until I burn another coaster.

Have to do something useful at lunch

Just a little update; I've added a level transition mini-game (every 2 levels) to help you increase your score. Basically 'fly' through the navigation boxes. I might expand this and actually cause a game over if you miss 1 or 2. Still deciding..... Also just finished implementing the highscore system with name input. I'm at work at the moment, so I can't test it on my actual Jag. Once i'm happy then i'll release an updated version.

Excellent. Can't wait to check that out. thanks for sharing

I spoke rubbish there. What i've been doing for my high colour stuff is to save in PSP as 24bit (16 million) but in rapinit.s i told it that the sprite is 16bit ( *2 ) and in the assets.txt i've used gfx_clut16. For whatever reason that works for me. I have a feeling that is the only way I could get anything 16 bit to display. Once I saw it work I just accepted it and moved on to coding. I'll probably revisit at some point and downsize all the assets. I'm just happy it's working.

I think I originally tried out 24 bit and may have also had problems. I can't really remember though. It's true that you rarely need to use 24 bit. 16 bit should be plenty for most cases. Things became much easier for me when I dug out my old copy of Paint Shop Pro 7 because that has nice easy "Convert to xx-bit" options in the "Colour" menu Then just save as .BMP and away you go.....

AWESOME!! I'll try this out as soon as I can. Thanks for creating more work for me Cheers

Haha, a big yes to this. It does seem that I didn't need to know the theory in the end. But I always appreciate that side of things so it's good to know. I have the scaling working now I think. The origin is in the top left so I did have to work out the ratio/percentage of the current scale to 1:1 then adjust the x position by half-width multiplied by that ratio. It looks accurate and fast so hopefully it will be ok. Some of the stuff I have in mind will only need the x-scaling, so it's good to know the performance gains. Thanks! I would be interested to see the source/tutorials from the "Cloudy" demo. I did think that was pretty cool.

These explanations really helped my understanding, so thank you both again. I now have my smooth scaling sprite thanks to RSETOBJ(SPRITENUM,R_sprite_scale_x,scale) where scale is an integer which defaults to 32. Simply increasing/decreasing the scale variable has the effect i'm after. I think before, I was thinking about it too much (or not as it happens) trying to shift the digits or something when passing into the RSETOBJ. Let the scaling commence.....

Thanks guys for the explainations. Yeah, I've not had to deal with fixed point before. What both of you have said makes sense. I'll have a go and see if I can make some progress. cheers.