[CSDb] - User Forums - Release id #199070 : S.P.R.E.R.O. V1.1

Welcome to our latest new user maak ! (Registered 2024-04-18)

You are not logged in - nap

CSDb User Forums

Forums > CSDb Entries > Release id #199070 : S.P.R.E.R.O. V1.1

2021-01-21 05:59

oziphantom

Registered: Oct 2014
Posts: 478

Release id #199070 : S.P.R.E.R.O. V1.1

Quote:

Submitted by St0rmfr0nt [PM] on 20 January 2021
Unfortunately the game crashes when finish level 6 on real hw as well as on Vice.

I did a full play though before uploading. I just tested again and got to level 7 with no issues.

Which route do you follow in level 6, what are you doing on the final screen?

2021-01-21 13:01

Danzig

Registered: Jun 2002
Posts: 428

Quote: Quote:
Submitted by St0rmfr0nt [PM] on 20 January 2021
Unfortunately the game crashes when finish level 6 on real hw as well as on Vice.

I did a full play though before uploading. I just tested again and got to level 7 with no issues.

Which route do you follow in level 6, what are you doing on the final screen?

Comes to mind: "Disable Cardridge" ;-)

2021-01-21 17:00

Krill

Registered: Apr 2002
Posts: 2825

Quoting Danzig

Comes to mind: "Disable Cardridge" ;-)

I think cartridge interference usually pops up pretty quickly when there is a problem with that.
Stuff like the cartridge not banking itself out properly upon autostart/run and such.

Crashes that late while a program runs are probably caused by other things. ;-)

2021-01-21 20:06

Count Zero

Registered: Jan 2003
Posts: 1820

Must be the used reset pattern! :)

2021-01-22 11:47

chatGPZ

Registered: Dec 2001
Posts: 11100

That is not a bad guess in such cases :)

2021-01-22 17:43

oziphantom

Registered: Oct 2014
Posts: 478

At the moment, I've not been able to replicate it. It works fine in the version of WinVICE 3.2 I use, although it apparently crashes in other versions of WinVICE 3.2. Seems it works in GTK 3.5, but crashes in Denise and HOXS.

Basically the game is very on the edge. So if the "update loop" crosses into the start of the stable raster at the top, instant DEATH. The game update must end before the frame starts to draw.
Y movement is expensive, I have to work out the line the sprite will move to, and the one it will leave. Then adjust the sprites on that line and then work out which timing I need and update the timing functions on those 2 lines. This is about 24 bytes to be copied.

Bats also move up and down, so their update can take time.

X Monsters can move up to 3 lines on the Y, so they are very expensive to have, I removed a lot of them on the final day.

Adding and removing a sprite is really expensive as you have to modify 21 lines and then another 21 lines. This is why explosions take 2 frames. 1 frame removes, 1 then puts the sprite back as the laser. You can't use the laser while a TNT is done, because they share the sprite. Dropping the TNT is free as it has to be dropped where the player is and the laser sprite moves with the player at all times. X movement is "free".

So if there is a case it just so happens you move 2 up while enough other things move on the Y. BOOM instant death.

Or its something that just so happens to be wrong and it just so happens that the value mostly holds a safe enough value on it.

That being said the last screen of 6 is the most pedestrian screen. The water doesn't even animate.

2021-01-22 17:50

Raistlin

Registered: Mar 2007
Posts: 549

If you have timing problems due to too much happening in IRQs, often the best solution is to move some stuff to be outside of IRQs. If the game thread then pushes you to 1.05% of a “frame”, nobody’s going to really notice - and, even if there is a momentary glitch, that’s much much better than a crash.

My 2c. But maybe I’m misunderstanding what’s happening here.

2021-01-23 02:08

chatGPZ

Registered: Dec 2001
Posts: 11100

yep, only display things in irq, game logic in main. should be a general rule for games :=)

2021-01-23 04:08

Adam

Registered: Jul 2009
Posts: 321

It crashed for me in level 6 using x64sc v3.5 "JAM AT $100C". The route I took was to the right, flying over the lava. As I start climbing upward I collided with a snake coming out of the wall, then VICE stopped running it.

2021-01-23 07:15

oziphantom

Registered: Oct 2014
Posts: 478

if this was a normal game, and the background was chars or a bitmap. sure 100% what you say.

The background is not chars, and its not bitmap. its 3FFF. Clock stable perfect with arbitrary sprites over it 3FFF.

So from the first line of the "display" to the top of the HUD sprites, there is not a single free clock, its all used on the display.

And when you move a sprite, you have to update the display so the clocks match for example.

ldy #%11111111
; delay for no sprites
cmp ($00,x) ; 6
cmp ($00,x) ; 6
cmp ($00,x) ; 6
nop			; 2
jmp +			; 3
00 00
+
sty kVicIdle       ; 6
ldy #%00000000
sty kVicIdle       ; 6
ldy #%01000100
sty kVicIdle       ; 6
ldy #%00010001
sty kVicIdle       ; 6 
ldy #%10010010
sty kVicIdle       ; 6
ldy #%10101010
sty kVicIdle       ; 6
stx kVicIdle       ; 4
; next line

now we move 3 sprites on to the line ( i.e the 2 for the player + the laser ) we have to adjust the timing because the sprites steal clocks so now the line becomes

ldy #%11111111
; delay for no sprites
cmp ($00,x) ; 6
bit $1000
bit $02 ; 6
jmp +
00 00			; 3
+
sty kVicIdle       ; 6
ldy #%00000000
sty kVicIdle       ; 6
ldy #%01000100
sty kVicIdle       ; 6
ldy #%00010001
sty kVicIdle       ; 6 
ldy #%10010010
sty kVicIdle       ; 6
ldy #%10101010
sty kVicIdle       ; 6
stx kVicIdle       ; 4
; next line

which is fine because they have the same number of bytes, conveniently.
But lets imagine that copy routine got interrupted, i.e the start of the frame IRQ happened before the "main loop" was able to complete.

ldy #%11111111
; delay for no sprites
cmp ($00,x) ; 6
cmp ($00,x) ; 6
cmp ($00,x) ; 6
nop			; 2
jmp +			; 3
00 00
+
sty kVicIdle       ; 6
ldy #%00000000
sty kVicIdle       ; 6
ldy #%01000100
sty kVicIdle       ; 6
ldy #%00010001
sty kVicIdle       ; 6 
ldy #%10010010
sty kVicIdle       ; 6
ldy #%10101010
sty kVicIdle       ; 6
stx kVicIdle       ; 4
; next line

now we move 3 sprites on to the line ( i.e the 2 for the player + the laser ) we have to adjust the timing because the sprites steal clocks so now the line becomes

ldy #%11111111
; delay for no sprites
cmp ($00,x) ; 6
bit $1000
00 ea 4c <+ >+ 00 00
+
sty kVicIdle       ; 6
ldy #%00000000
sty kVicIdle       ; 6
ldy #%01000100
sty kVicIdle       ; 6
ldy #%00010001
sty kVicIdle       ; 6 
ldy #%10010010
sty kVicIdle       ; 6
ldy #%10101010
sty kVicIdle       ; 6
stx kVicIdle       ; 4
; next line

so now your display hits a brk mid render, so it starts drawing again because the BRK will trigger the IRQ again. Now your IRQ overflows by either a little or a lot. The IRQ chain is broken, the stack is corrupted. You're dead.

The main game loop has to modify the IRQ, they are depended upon each other, and if the updates don't complete then your sprites and the timing code don't match. Thus the game loop must finish before the screen starts to draw.

You could slightly mitigate this by double buffering the whole "display" IRQ. Then only flip once you know that all the updates are done. However you then need to double buffer you sprite display lists, and make sure updates are applied to both with doubles the amount of time it takes to do them.

Now that is the worse case. What other cases are there.

Well if the "set up the sprites" code gets interrupted then you don't see the player sprites because they are still the hud, or you seem some sprites not all depending upon where it was interrupted.
The timings above require that they start on cycle 56, because they count out read/write clocks to sync to the clock. If the sprite isn't there, then the timings change and now the how thing is shifted to the left not so bad, it looks horrible, but being under time is not so bad. But the HUD is expanded sprites, so if some sprites did make it, they are now twice as high, which means the timings on those lines is over, so its shifts the display to the right. If this overflows, your draw raster goes on too long and you miss the next raster and your raster chain collapses. Luckily the Hyperscreen enable is no longer on the IRQ chain, otherwise instant black screen that is never coming back. But you are still going to get the case where things don't get set as the need to, timings are out, stability is lost and one way or another you are going to mostly going to crash.

maybe the partial update of the delay, doesn't hit a brk, maybe it just jmps to no mans land, maybe an address held a 9d and now you write a random value to somewhere in the zero page, maybe it was a state variable for the entity system that gets looked up in a table and written to. maybe it was $01.

This is why the player moved slowly ;) to reduce the timings as much as possible.

There is no "little" glitch, a sprite cut in half or the sprite holds the same position for a frame. It might just shunt over where the glitch happens and then part of the hud will disappear, or it will just scramble the whole screen.

Thinking of what could be different:
model C vs breadbing. This will cause the timers to be 1 clocks off, however the only thing on timers is the hyperscreen and the timings on it are such that a clock is neither here nor there. I though maybe I might modify a "temp" variable in them which if it happened 1 clock earlier ( My Vice is set to C and I have 128 ) - so no

the whole game use to run in IRQ, where main was - JMP - because it had to complete so why split it. To get more clocks back I pulled things into the "Main" so I could do the HUD as a bunch of splits, to get me more clocks. Now the screen being so padestrain could mean that things are happening earlier and I've missed an
ZPTemp -> ZPTempNoIRQ update and something gets trashed.

Where does it crash, on the screen, when you collide with the "miner", during the countdown, after the countdown?
It could be the first screen of 7 that is killing it.

2021-01-23 07:51

oziphantom

Registered: Oct 2014
Posts: 478

.C:093b   .StartLevel:
.C:093b  EA          NOP
.C:093c  4C 38 24    JMP $2438
.C:093f  C1 00       CMP (.HLWord_lo,X)
.C:0941  C1 00       CMP (.HLWord_lo,X)
.C:0943  A6 A2       LDX $A2
.C:0945  00          BRK
.C:0946  86 E0       STX .BaseMapNumForLevel
.C:0948  86 2C       STX .MainGameBaseD015Value
.C:094a  86 2E       STX .PlayerMoveUpNF
.C:094c  86 4F       STX .PlayerRotarFrame
.C:094e  86 50       STX $50
.C:0950  86 CE       STX .Restore6SpriteToPlayerNF
.C:0952  86 CF       STX .DoGameUpdateNF
.C:0954  86 78       STX .Player_dead
.C:0956  86 E4       STX .RestartLevelNF
.C:0958  86 68       STX .Player_facingLeft0_1
.C:095a  86 E7       STX .WaterAnimStartFrame
.C:095c  86 E6       STX .WaterAnimCounter
.C:095e  86 E5       STX .WaterAnimEnableNF
.C:0960  86 E8       STX .LevelComplete
.C:0962  CA          DEX
.C:0963  86 77       STX .Player_hoverModeNF

yeah that is not correct, my guess at the moment is, you need to have had a "bounce" when you leave the top of the screen for it to happen. Because I had 1, and now the end of level 6 crashes 100%.

Refresh

Subscribe to this thread: