Sporadic

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.

Is there any way to see if its doing anything during the freeze? As I suggested, poke the bg colour in the loop. Assign a different button to the call to save? Put a small delay before the save?

How about copying your project folder to a new rb+ install? Could you be using a test version of rb+ for example? But then, if the scores project works then that probably isn't it. Is the 6 minutes relevant to anything in your code? Eg. 6x60x50 vbls. Does that equal some magic timer/counter you've made up? This is major straw clutching though! Edit: How about poking the background colour in your main loop and see if it keeps changing during the freeze?

Very strange! Are you sure the MT actually works? My one was dodgy and stopped games loading. Turns out it had a random blob of solder joining 2 of the contacts! I just picked it off.

hmm bummer Luckily i've not had my CD drive very long, so don't have any major MT saves yet. You say it's creating the save initially, but not writing until after the high score? That sounds different to what i've done above.

Looking at my snippets there though, couldn't I have used the hiscore_check function before they enter their name? Rather than my own iteration through? Lol who knows.

Nope, afraid not. It pretty much just worked out the box! I'll give you some snippets (with unrelated stuff removed). If not use then i'll just post the whole SUBs. FYI, all contained tidily in my score.bas First, before the main loop it does this; if raptor_mt_present<0 then 'no MT? for i=0 to 9 raptor_highscores_hex[i]=(9-i)*100 next i endif Then at game over detect if the score is actually in the highscore table (without writing to it); for i=0 to 9 IF score > raptor_highscores_hex[i] THEN inscoreboard=1 ENDIF next i Then, if inscoreboard=1 then player enters their name. After that, call this; if hiscore_check(score,name$)>0 then call RAPTOR_resort_score_table endif if raptor_mt_present<0 then 'no MT? else call RAPTOR_mt_save endif I'm sure that was it. Unless of course i've not noticed the same bug yet

I can safely say i'm not anywhere near that (unless particles count perhaps lmao)

The .abs is 1049k. So plenty there. I've not have time today (pub lunch was more appealing) so I will have a mess around as soon as I can and report back. Thanks

I need to stop speaking too soon I just thought I would apply the tip for the variable in the loops to another area of code. I made that change and the problem has reappeared. I changed this; LIFECHECK=0 FOR currentmob = 0 TO mobsloop IF mobLife[currentmob] > 0 THEN LIFECHECK++ mobX[currentmob] = RGETOBJ(startmob+currentmob,R_sprite_x) mobY[currentmob] = RGETOBJ(startmob+currentmob,R_sprite_y) IF mobX[currentmob] < (minxx)<<16 THEN mobX[currentmob] = maxxx RSETOBJ(startmob+currentmob,R_sprite_x,(mobX[currentmob]<<16)) ELSEIF mobX[currentmob] > (maxxx)<<16 THEN mobX[currentmob] = minxx RSETOBJ(startmob+currentmob,R_sprite_x,(mobX[currentmob]<<16)) ENDIF IF mobY[currentmob] < (minyy)<<16 THEN mobY[currentmob] = maxyy RSETOBJ(startmob+currentmob,R_sprite_y,(mobY[currentmob]<<16)) ELSEIF mobY[currentmob] > (maxyy)<<16 THEN mobY[currentmob] = minyy RSETOBJ(startmob+currentmob,R_sprite_y,(mobY[currentmob]<<16)) ENDIF ENDIF NEXT To this; LIFECHECK=0 mobtmpcnt = startmob FOR currentmob = 0 TO mobsloop IF mobLife[currentmob] > 0 THEN LIFECHECK++ mobX[currentmob] = RGETOBJ(mobtmpcnt,R_sprite_x) mobY[currentmob] = RGETOBJ(mobtmpcnt,R_sprite_y) IF mobX[currentmob] < (minxx)<<16 THEN mobX[currentmob] = maxxx RSETOBJ(mobtmpcnt,R_sprite_x,(mobX[currentmob]<<16)) ELSEIF mobX[currentmob] > (maxxx)<<16 THEN mobX[currentmob] = minxx RSETOBJ(mobtmpcnt,R_sprite_x,(mobX[currentmob]<<16)) ENDIF IF mobY[currentmob] < (minyy)<<16 THEN mobY[currentmob] = maxyy RSETOBJ(mobtmpcnt,R_sprite_y,(mobY[currentmob]<<16)) ELSEIF mobY[currentmob] > (maxyy)<<16 THEN mobY[currentmob] = minyy RSETOBJ(mobtmpcnt,R_sprite_y,(mobY[currentmob]<<16)) ENDIF ENDIF mobtmpcnt++ NEXT At the top of the main program I also DIM'ed the new variable mobtmpcnt . Is there any chance I am near some kind of limit for sprite count, sprite memory, code memory?

Thank you for the in-depth explanation. I have just had the chance to try again at home (on a different machine) and it's currently working. I forgot to copy my latest version of code so had the non-working version from yesterday - I changed the SUB to the code below and it just worked.... SUB SHOWPOINTS(num%) scoretmpcnt = scoresprites FOR scorei = 0 TO 4 IF RGETOBJ(scoretmpcnt,R_sprite_active) = R_is_inactive THEN IF num% = 100 THEN RSETOBJ(scoretmpcnt,R_sprite_gfxbase,score100gfx) ELSEIF num% = 200 THEN RSETOBJ(scoretmpcnt,R_sprite_gfxbase,score200gfx) ELSEIF num% = 500 THEN RSETOBJ(scoretmpcnt,R_sprite_gfxbase,score500gfx) ENDIF RSETOBJ(scoretmpcnt,R_sprite_active,R_is_active) RSETOBJ(scoretmpcnt,R_sprite_x,tx<<16) RSETOBJ(scoretmpcnt,R_sprite_y,ty<<16) RSETOBJ(scoretmpcnt,R_sprite_scale_x,50) RSETOBJ(scoretmpcnt,R_sprite_scale_y,50) EXIT FOR ENDIF scoretmpcnt++ NEXT END SUB As you can see, I have taken your advice regarding the variable and incrementing it at the end. I will try this code again tomorrow and see how it goes (if the problem reappears). If this works on my other machine then I will try swapping out code to try and break it again, then play spot the difference. It would be nice to know the cause, not just for my sanity but also in case it helps others. Thanks all again for the help and suggestions.

Unfortunately neither worked. I don't know if it's relevant but the "line" appeared in a different location for -Os