Sporadic

That sounds [email protected]#king awesome! I would definately be interested to check that out. As I've said, this is just a mess around at the moment, so no rush or anything. But having said that, I think a POWARSET command would be an excellent addition anyway!

I had thought about doing half the resolution (chunkier scanlines) but was going to fall back on that if too slow. I was also thinking that animating the road could be a way to do it but clut switching might be easier. (I'm no artist) . Depends if it adds much slow down. The benefit of animating the road would be that it could look textured and the stripy lines could be removed. But I do like the Outrun look

Amazing update! Loads of new toys to play with Bin2asc is going to allow me to cut out a chunk of nasty code I used to work out highscore digits. Ntsc detection will be handy too for sure. Thanks

Was thinking about switching the CLUT for each scanline to similate movement. Kind of colour cycle it.

Haha excellent Nice coincidence there! I know the page you mention. Ive had something like this running on Android before but I could not think how to go about it in rb+. It's not as quick on the real Jag as the emulator but im sure optimisations can be made. No clever tricks here. It's a static image, full road with perspective (what you see when you start it up). There are then 150 1px high sprites which each point to sequentual lines in the image. These simulate scanlines. Before the "game" starts it works out the speed of each line in x and y. The further away it is, the faster it moves. Then in the main loop when you move, it just iterates the 150 sprites and sets the xadd and yadd to that lines speed. Next frame the speed is zeroed again. There might be more efficient ways but I dont know them lol.

Just had a go. I found it really enjoyable, the only times I shouted at the screen were when my brain confused the fly button and dpad and I ended up in a wall. This was my own fault and not the game, which is how it should be It's got a great "just one more go" feeling when you die so great replayability value too. Still loving the parallax effect too, especially on the walls. The only possible suggestion i could think of would be to perhaps also add on a wall counter so I know how far I've got. But that's scraping the barrel really as the score also ultimately shows your progress. Pic attached of current high score. Yes, I have some catching up to do

Hi all, Thought i'd share a little progress on a separate prototype i've been playing around with. Only spent a few hours messing around so far, just needed a break from AstroStorm. You can guess from the screenshot what it is. There is no "forward" movement yet, that's probably next. Just use Dpad to move the road direction around to see the road curve and uphill/downhill (this would be automated in a game by the track layout - you would move your car). road.abs

This is awesome. I wish I had the knowledge to do this.

Excellent work. I will definately have a go as soon as I can.

Many, many prototypes, nothing really published. I have always tended to mess around more than get anything finished lol I released an Invaders clone for Android. See here; http://www.sporadicapps.co.uk

Awesome feedback thank you! I haven't done a long play through since adjusting the scoring, so I need to look at that and balance it. I could add another digit I guess The score tracking is just an int var. I carve this up into thousands/hundreds/tens/units to then work out which score sprite digit to display. I use the font code from the scoller tutorial for that. I also thought the same thing about the directional indicators, just couldn't be arsed lol. Your suggestion for swapping the gfx is a winner though so i'll do that. All waves in the main game and the nav game are randomly generated (from a set seed) so there might be some unfair levels. If people can generally scrape by then i'm happy with that. I did think about letting people do their own seed too but that would have to not interfere with the main high score list. I'll look into the slowdown - there certainly isn't anything major going on while you're not firing. The main thing would be where it has to check the position of each rock to know if it has to be reset to the other side of the play area. I can't let raptor handle this at the screen edges because you might never see some rocks. I do need to run through everything still to see what can be optimised though. Spamming the fire button reduces the overall score for that level. It works out your hit ratio as a % and makes adjustments on that. Perhaps as your score was alternating to 00000 it just didn't work it out. I like the overheating idea, I did wonder about doing something like this. We won't talk about the collision detection....... lets just say I didn't even "bail in" to using RHIT, let alone bail out with the rest of it lol. I'm just doing manual box collision detection (only when you hold fire). This is something I should probably change but I didn't bother as it seemed to work ok. You win. Don't need to play any more now you've maxed the score The twitchyness might be the 50/60hz difference as I balanced it to 50 for the input. Thank you ever so much for the detailed feedback. Most welcome as always. I'm having a little break from this game at the moment as I wanted to prototype another idea (still in rb+). That shouldn't take too long though, then i'll revisit this and try to finish it off.

No, it's worded well, though perhaps an example of the above code to show how to apply a fractional value to the RSETOBJ. I feel slightly more empowered now that I know how to do it

Ok that looks like it works, thank you. However, for completeness in case anyone else wants to know, I had to add some brackets. So this is the working version; RSETOBJ(startline+i,R_sprite_xadd,(INTPART<<16)+FRACPART) Otherwise it added the FRACPART to the 16 and did a comedy bit shift. cheers.

lol no way. Is that for real? That's probably the only thing I haven't tried. Thank you

Hi, In the tutorial it states; If you want to pass a fractional part, remember it is always a positive value, whereas the whole part can obviously be negative. So if you need to describe say a negative drift of half a pixel, you have to first set the fractional part to a half, (65535/2= 32768), then set the whole part to -1, (-1<<16), with the net effect of -1 + 1/2 giving -1/2. Once you get this into your head it becomes second nature, it can just seem a little awkward at first. So how would I specify the fractional part first and then the whole part? For example, I tried calling RSETOBJ in succession but I think "last one wins" here so the fractional part isn't set. RSETOBJ(startline+i,R_sprite_xadd,FRACPART) RSETOBJ(startline+i,R_sprite_xadd,INTPART<<16) Where FRACPART is the fractional part ranging from 0-65535 and INTPART is the integer portion. The other thought was that it should be passed as a fixed point binary value, which isn't so bad if i'm just setting when coding, but i'm not sure how to work that out at runtime on the fly. Sorry if i've completely misunderstood what's intended and thank you in advance for any feedback.

New release - V1.2 Here is the latest build, changes; - Shield is regenerated by flying through navigation points now, not after each level. - Better timing in navigation section to allow user time to respond. - Rocks in navigation section you have to dodge. - In navigation mode, HUD arrows show you the direction the next nav rectangle or rock is coming from. It's a surprise which one it is - Tweaks to the way scores are worked out. - Score sprites. - Other stuff i've probably forgotten about. Please note: I have not managed to get rid of the particle line issue, but I have managed to balance my plates in such a way that it's outside the play area window. Out of sight, out of mind for now. I've not had chance to test this version on an actual Jaguar yet, so burn to coasters etc at own risk. I imagine the next part i'll be working on is the NTSC issue with things getting cut off the top/bottom. I'll look at the best way to rework the layout etc. Thanks for reading and playing AstroStormV12.abs AstroStormV12.rom

1050kb when I looked earlier.

ok, so just adding in the sprite in the object list and the assets.txt the line reappeared. I have reverted all code back to the full thing (as it was the other day with the line appearing when shooting something). Then I removed a completely different sprite (tried it with a couple of different ones) and the lines do not appear. One sprite I removed was 176x176 @ 15KB and the other was 208x176 @ 107KB. In the next installment of "Riks Debugging Shenanigans" I will try reducing the size of stuff to see if I can get it all in (should be easy). Removing/shinking sounds isn't worth it as suggested before, as my sound RAW files in windows add up to a total of 68KB - so not much to save there lol cheers

Yes it's there before starting the game. I just tried all my old builds and none of them have the issue. So I opened the current version and deleted everything to do with the score sprites completely from the project as that was the last thing I added. Then, no line appeared. So I assume there is either something wrong with that deleted stuff, or that deleted stuff is cause particle wierdness perhaps due to something overflowing etc. Next, I will gradually add bits in to try and see where the line appears.

So the first section you mention, i don't have! The only part of that section I can find is the JMP command. Here is all the text surrounding that command; ;; get something on the screen jsr RAPTOR_start_video ; start video processing move.l #LIST_display,d0 ; set RAPTOR to display initial RAPTOR list jsr RAPTOR_setlist ; tell RAPTOR which list to process jsr RAPTOR_UPDATE_ALL ; and update the object list with initial values jmp __Z9basicmainv ;; ;; RAPTOR user VBI vector ;; RAPTOR_user_vbi: tst.l RUPDALL_FLAG beq.s .uvbi_out movem.l d0-d7/a0-a6,-(a7) jsr RAPTOR_UPDATE_ALL movem.l (a7)+,d0-d7/a0-a6 .uvbi_out: rts RUPDALL_FLAG: dc.l 0 Here is the second section; raptor_particle_buffer_width equ 320 ; tell RAPTOR the Particle / Text Buffer is 368 pixels wide raptor_particle_buffer_height equ 240 ; tell RAPTOR the Particle / Text Buffer is 240 pixels high raptor_particle_pixels equ 128 ; tell RAPTOR the maximum number of particles raptor_particle_drift_x equ 0 ; tell RAPTOR the Particle Drift Factor (x) raptor_particle_drift_y equ 0 ; tell RAPTOR the Particle Drift Factor (y) I'm almost 100% sure i'm using the GIT master download from the build after the MT stuff was added. EDIT: I have tried changing the fonts as described and removing the CLS commands. I also tried removing the CLS commands with the original fonts. Neither of which made any difference, i'm afraid. All I use CLS for is to clear the highscore table text off the screen so it's not there in the starfield when you play. I have been backing up my builds as I go, I might try an old one to see if the issue is there. It might help narrow down when it appeared (maybe).

Excellent thank you. Interesting stuff to know. I guess i'm going to have to rethink my layout slightly Many thanks for grabbing those for me. I'm just running my Jag through an s-video -> RGB converter to show on my computer monitor. I have got another Jag (non-working) that I hope to fix up and then add the 50/60 hz switch mod too. So that will help

Awesome. That sounds kind of promising. I'll hopefully be able to look at this tomorrow. I have used CLS in a couple of places ... Not in gameplay but before the game starts. Shame about the 60hz thing. I thought VJ would emulate that kind of thing I would really appreciate the test and photos you mention. You should be good to use one of the builds I already posted here as the scores have always been there. Cheers

Hi all, First screen is the line as it appears when shooting something. Ignore the "35", thats just the debug message I added. However, the second screen is when I take out all the score stuff - It shows the line is outside the playfield when first starting the game!! Before even playing! So, I assume this means it has always been there, just hidden behind the main large graphic. Then depending on what I do, it changes its location to somewhere that's visible. The location does only seem to change horizontally though, not vertically. So now i'm going to play with some more stuff and check over everything. Will post back results.

Thanks for the info. I would say it looks bigger than the font (maybe). I guess I should grab a screenshot later. That might help. Also, I dont think im using the print command normally during the game. I only used it here to debug the values being passed to SETOBJ . Then noticed the wierdness of adding the duplicate commands stopping the problem. The only other time I print is for the highscore table. The other fonts are custom. I'll grab a screen later. Let me do some more debugging I mentioned earlier too. I certainly don't want anyone looking at fixing other known bugs on the off chance they might be related.

So it's hilarious update time. I wonder if this will mean anything to anyone... I have a SUB that draws the scores every tick; I have added a print in the middle to check the var is correct. SUB UPDATESCOREUI scoretmpcnt = scoresprites FOR scorei=0 TO 4 IF RGETOBJ(scoretmpcnt,R_sprite_active) = R_is_active THEN scoresizetmp = RGETOBJ(scoretmpcnt,R_sprite_scale_x) IF scoresizetmp > 0 THEN scoresizetmp-=1 ENDIF RLOCATE 150,150 print scoresizetmp RSETOBJ(scoretmpcnt,R_sprite_scale_x,scoresizetmp) RSETOBJ(scoretmpcnt,R_sprite_scale_y,scoresizetmp) IF scoresizetmp = 0 THEN RSETOBJ(scoretmpcnt,R_sprite_active,R_is_inactive) ENDIF ENDIF scoretmpcnt++ NEXT END SUB If I change to this it stops showing the error (the horizontal grey particle line cannot be seen.) SUB UPDATESCOREUI scoretmpcnt = scoresprites FOR scorei=0 TO 4 IF RGETOBJ(scoretmpcnt,R_sprite_active) = R_is_active THEN scoresizetmp = RGETOBJ(scoretmpcnt,R_sprite_scale_x) IF scoresizetmp > 0 THEN scoresizetmp-=1 ENDIF RLOCATE 150,150 print scoresizetmp RLOCATE 150,150 print scoresizetmp RSETOBJ(scoretmpcnt,R_sprite_scale_x,scoresizetmp) RSETOBJ(scoretmpcnt,R_sprite_scale_y,scoresizetmp) IF scoresizetmp = 0 THEN RSETOBJ(scoretmpcnt,R_sprite_active,R_is_inactive) ENDIF ENDIF scoretmpcnt++ NEXT END SUB All i've done is duplicate the rlocate and print commands. The error also didn't manifest if I took out all the prints and rlocates from that SUB and Remmed out the RSETOBJ(scoretmpcnt,R_sprite_scale_x,scoresizetmp) and RSETOBJ(scoretmpcnt,R_sprite_scale_y,scoresizetmp). The strangeness continues. I should also mention, the score sprites are rendering correctly. Everything is. It's just this grey particle line is showing. I have a horrible feeling this problem has been here for longer than this. But, the particle layer used to be behind everything (because I didn't use it) so I wouldn't have seen it happen. I think it's time to comb through every single line, object definition and sprite. EDIT: another thought I just had, perhaps it's always been there, but the line is located behind the main "Screen" graphic so I cannot see it. Because if I change certain things, the "line" appears in a different location. I will try hiding the main big graphic and see if it's actually still there, just outside the play area.