Astro-Storm - My new RB+ Game

[Sporadic]

 

Going to attempt to pick your brains here... did you have any issues implementing this at all?

 

I gave it a go as I got high score handling working in my game, but everything freezes when I attempt to perform the write.

 

If I check the MT the save is there, so it is created when it first loads... but after that nope.

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

Edited August 12, 2015 by Sporadic

[Sporadic]

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.

[sh3-rg]

Pretty much what I'm doing... it's creating the save initially but hangs on writing after a new high score... and it has now managed to wipe the whole MT lol. Only thing I have different here is I'm using zerosquare's sample replay.

[Sporadic]

Pretty much what I'm doing... it's creating the save initially but hangs on writing after a new high score... and it has now managed to wipe the whole MT lol. Only thing I have different here is I'm using zerosquare's sample replay.

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.

[sh3-rg]

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.

 

Oh I mean raptor/rb+ creates the save the first time the game is run and no save is present, it's automatic.

 

I also found out the hang isn't the end of it... the game springs back to life after around 6 minutes!

 

WTF?!

 

Trying a few things anyway, at least if I encounter these nasty things nobody else should later :0)

Edited August 12, 2015 by sh3-rg

[Sporadic]

 

Oh I mean raptor/rb+ creates the save the first time the game is run and no save is present, it's automatic.

 

I also found out the hang isn't the end of it... the game springs back to life after around 6 minutes!

 

WTF?!

 

Trying a few things anyway, at least if I encounter these nasty things nobody else should later :0)

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.

[sh3-rg]

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.

 

It does, it had all kinds of junk on it from testing over the years. The MT scores project also works fine.

 

I've ruled out a number of things, the fact the stall ends after 6 minutes and the game goes on is really odd.

 

Maybe I should give up on the code side and throw random blobs of solder at my MT until it works... yep, it's getting that desperate now!

 

Not sure what to do now, I cut and pasted every last piece of GGN's example and only zapped the PRINTs and changed "432" for my score variable, moved the write code to right after the VBL, it still hangs... sorry for the derail and thanks for the infos.

Edited August 12, 2015 by sh3-rg

[Sporadic]

 

It does, it had all kinds of junk on it from testing over the years. The MT scores project also works fine.

 

I've ruled out a number of things, the fact the stall ends after 6 minutes and the game goes on is really odd.

 

Maybe I should give up on the code side and throw random blobs of solder at my MT until it works... yep, it's getting that desperate now!

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?

Edited August 12, 2015 by Sporadic

[Sporadic]

 

It does, it had all kinds of junk on it from testing over the years. The MT scores project also works fine.

 

I've ruled out a number of things, the fact the stall ends after 6 minutes and the game goes on is really odd.

 

Maybe I should give up on the code side and throw random blobs of solder at my MT until it works... yep, it's getting that desperate now!

 

Not sure what to do now, I cut and pasted every last piece of GGN's example and only zapped the PRINTs and changed "432" for my score variable, moved the write code to right after the VBL, it still hangs... sorry for the derail and thanks for the infos.

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?

[sh3-rg]

The whole game is 60frames locked all the time, it never drops a frame...if it did, stuff would begin falling over and the timers would soon crap out.

 

Even the auto-update raptor objects are frozen (clouds in background and logo on title). The only thing that hints of life is the audio that keeps keeping on... maybe I'll add zero's player to the scores project and burn that, just to rule that one out.

 

I wanted to check what actually gets created on the MT as well, but Matthias' site doesn't have a link to the MT manager remix tool and I can't find my copy of Impulse X that includes it.

Edited August 12, 2015 by sh3-rg

[Sporadic]

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.

Edited August 13, 2015 by Sporadic

[sh3-rg]

Haven't got a lot of time to check through the above, will do in a bit.

 

I know a bug that generates a line of junk on the particle layer and it does involve PRINT. Basically PRINT is a bit of a minefiled and it's amazing GGN got it to do anything. When you, say, PRINT score, what will actually end up on screen is the space character or a minus sign followed by the numerical value of your variable followed by... "something". I know what this "something" is, but quite why it appears is a mystery, and not one GGN currently wishes to explore (zero blame given).

 

I mention this because, "something" using the default fonts provided with rB+ adds up to "nothing much" unless you're using the 2nd variant of the fonts. Even then, it probably won;t show. But when it will show, and it does appear as a single character width row of random junk pixels, is when you use the 16x16 font and the second one - it essentially displays a random 16 pixels worth of whatever is in memory after the font.

 

If this sounds like it might be the cause, a very quick "fix" (botch) past it, is to edit your font file, make it 1 row taller at the bottom than existing and save over it. Make this row the background colour and the random junk won't show.

 

Of course, yours might be a completely unrelated random row of pixeljunk! :0)

 

I'll write up the PRINT bug issues in the bug thread and as a note on the site, just so it's there to refer to in future either if GGN fancies tackling it (noooooo!) or someone else encounters it (you never know with the bustling rB+ dev community!).

[Sporadic]

Haven't got a lot of time to check through the above, will do in a bit.

 

I know a bug that generates a line of junk on the particle layer and it does involve PRINT. Basically PRINT is a bit of a minefiled and it's amazing GGN got it to do anything. When you, say, PRINT score, what will actually end up on screen is the space character or a minus sign followed by the numerical value of your variable followed by... "something". I know what this "something" is, but quite why it appears is a mystery, and not one GGN currently wishes to explore (zero blame given).

.....

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.

[Sporadic]

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.

Edited August 13, 2015 by Sporadic

[sh3-rg]

I'm almost certain this is a text to particle buffer issue of some sort. Screen 2's corruption is exactly 192 pixels, 24 8-pixel characters, apart from screen 1's, and seems consistent with the PRINT side effects thing I mentioned earlier.

 

Some things I could ask you to check and try:

 

The font BMPs in ASSETS/FONTS - add an extra row of pixels to each, so they'd be 960x17 instead of 960,16; 960x33 and 1920x33. See if the dots disappear when you re-build.

 

In RAPAPP.S, what does the section that by default would display the initial rB+ text look like? Around line 140, this stuff:

jmp __Z9basicmainv
 
; "0123456789012345678901234567890123456789"
init_txt: dc.b "       RAPTOR BASIC+ v0.1 - REBOOT      ",raptor_t_lf
dc.b raptor_t_font_siz,0
dc.b "        Derived from BCX BASIC v6       "
dc.b raptor_t_quit
.even
 
; Loop around!

Higher up the same file, what do you have here for this part?

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 50 ; 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)

CLS is bugged, basically don't use it right now. It wouldn't result in what you're seeing, but side effects could be much worse! It doesn't use the above settings, it just assumes them. So make a small particle buffer and use CLS and you end up filling memory with 00s past the particle buffer :0)

Bit tired so can't think of much else now. One thing I will mention after looking at your screen shots and getting feedback from someone playing my WIP game on a jaguar/TV, is that at 60Hz, I'm afraid the top of your screen where the scores are will be off-screen :/ If you want to send me a test build, I'll remove the scaler I'm using and use SCART directly with a US Jaguar to test and take some photos for feedback. Doesn't ahve to be a working build if you don't want, just something that displays the screen.

Edited August 13, 2015 by sh3-rg

[Sporadic]

 

I'm almost certain this is a text to particle buffer issue of some sort. Screen 2's corruption is exactly 192 pixels, 24 8-pixel characters, apart from screen 1's, and seems consistent with the PRINT side effects thing I mentioned earlier.

 

Some things I could ask you to check and try:

 

The font BMPs in ASSETS/FONTS - add an extra row of pixels to each, so they'd be 960x17 instead of 960,16; 960x33 and 1920x33. See if the dots disappear when you re-build.

 

In RAPAPP.S, what does the section that by default would display the initial rB+ text look like? Around line 140, this stuff:

jmp __Z9basicmainv
 
; "0123456789012345678901234567890123456789"
init_txt: dc.b "       RAPTOR BASIC+ v0.1 - REBOOT      ",raptor_t_lf
dc.b raptor_t_font_siz,0
dc.b "        Derived from BCX BASIC v6       "
dc.b raptor_t_quit
.even
 
; Loop around!

Higher up the same file, what do you have here for this part?

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 50 ; 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)

CLS is bugged, basically don't use it right now. It wouldn't result in what you're seeing, but side effects could be much worse! It doesn't use the above settings, it just assumes them. So make a small particle buffer and use CLS and you end up filling memory with 00s past the particle buffer :0)

Bit tired so can't think of much else now. One thing I will mention after looking at your screen shots and getting feedback from someone playing my WIP game on a jaguar/TV, is that at 60Hz, I'm afraid the top of your screen where the scores are will be off-screen :/ If you want to send me a test build, I'll remove the scaler I'm using and use SCART directly with a US Jaguar to test and take some photos for feedback. Doesn't ahve to be a working build if you don't want, just something that displays the screen.

 

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

[sh3-rg]

VJ gives you everything (well almost, I can make my xRGB mini show quite a bit more), I think it's more down to how TV standards work as to what you actually see on a CRT or more modern TV acting like one as best it can.

 

I went to grab my CRT TV and when it wasn't there remembered I'd given it away... oops! So maybe GGN can try this for you?

 

Anyway, here's what I see on my panel TV via SCART, PAL60 and PAL50:

 

 

Expect to see less (possibly much less) on a CRT TV thanks to all kinds of reasons. The top area is most susceptible to being hidden away.

[Sporadic]

VJ gives you everything (well almost, I can make my xRGB mini show quite a bit more), I think it's more down to how TV standards work as to what you actually see on a CRT or more modern TV acting like one as best it can.

 

I went to grab my CRT TV and when it wasn't there remembered I'd given it away... oops! So maybe GGN can try this for you?

 

Anyway, here's what I see on my panel TV via SCART, PAL60 and PAL50:

 

..

 

Expect to see less (possibly much less) on a CRT TV thanks to all kinds of reasons. The top area is most susceptible to being hidden away.

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

[Sporadic]

 

I'm almost certain this is a text to particle buffer issue of some sort. Screen 2's corruption is exactly 192 pixels, 24 8-pixel characters, apart from screen 1's, and seems consistent with the PRINT side effects thing I mentioned earlier.

 

Some things I could ask you to check and try:

 

The font BMPs in ASSETS/FONTS - add an extra row of pixels to each, so they'd be 960x17 instead of 960,16; 960x33 and 1920x33. See if the dots disappear when you re-build.

 

In RAPAPP.S, what does the section that by default would display the initial rB+ text look like? Around line 140, this stuff:

jmp __Z9basicmainv
 
; "0123456789012345678901234567890123456789"
init_txt: dc.b "       RAPTOR BASIC+ v0.1 - REBOOT      ",raptor_t_lf
dc.b raptor_t_font_siz,0
dc.b "        Derived from BCX BASIC v6       "
dc.b raptor_t_quit
.even
 
; Loop around!

Higher up the same file, what do you have here for this part?

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 50 ; 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)

CLS is bugged, basically don't use it right now. It wouldn't result in what you're seeing, but side effects could be much worse! It doesn't use the above settings, it just assumes them. So make a small particle buffer and use CLS and you end up filling memory with 00s past the particle buffer :0)

Bit tired so can't think of much else now. One thing I will mention after looking at your screen shots and getting feedback from someone playing my WIP game on a jaguar/TV, is that at 60Hz, I'm afraid the top of your screen where the scores are will be off-screen :/ If you want to send me a test build, I'll remove the scaler I'm using and use SCART directly with a US Jaguar to test and take some photos for feedback. Doesn't ahve to be a working build if you don't want, just something that displays the screen.

 

 

 

 

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).

Edited August 14, 2015 by Sporadic

[sh3-rg]

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;

 

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).

OK, then I'm out of ideas :/

 

You're safe to use CLS with that particle buffer setup and if you're using CLS to clear the screen and not printing blank spaces over anything then the mystery pixels will have to remain a mystery... my only guess at them appearing was as a side effect of using PRINT with the alternate fonts. Somehow, something it shoving junk into the particle buffer... hmmm... maybe check your particle tables for uninitialised entries or... but you say it's there before you do anything...

Edited August 14, 2015 by sh3-rg

[Sporadic]

OK, then I'm out of ideas :/

 

You're safe to use CLS with that particle buffer setup and if you're using CLS to clear the screen and not printing blank spaces over anything then the mystery pixels will have to remain a mystery... my only guess at them appearing was as a side effect of using PRINT with the alternate fonts. Somehow, something it shoving junk into the particle buffer... hmmm... maybe check your particle tables for uninitialised entries or... but you say it's there before you do anything...

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.

[Sporadic]

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

[sh3-rg]

what size is your binary at the moment?

[Sporadic]

what size is your binary at the moment?

1050kb when I looked earlier.

[Sporadic]

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

Edited August 18, 2015 by Sporadic