A miracle when it works first time!
A miracle when it works first time!
Following on from the "An impressive way to crash the Speccy?" thread (viewtopic.php?f=6&t=918), I was working on a sprite clipping m/c routine and when it came to test my first attempt, while not exactly crashing, I watched it spectacularly fail as the sprite "exited" the top of the screen
It occurred to me that not only do assembly routines often fail the first time you run them, they often fail in quite dramatic fashion!
There are those rare (but memorable) occasions when it does work first time but anyone else captured any amusing pseudo-crashes when it doesn't?
BTW, I got it going the next day, though the result seemed a bit boring and pedestrian in comparison
It occurred to me that not only do assembly routines often fail the first time you run them, they often fail in quite dramatic fashion!
There are those rare (but memorable) occasions when it does work first time but anyone else captured any amusing pseudo-crashes when it doesn't?
BTW, I got it going the next day, though the result seemed a bit boring and pedestrian in comparison
Cosmium
https://cosmium.itch.io/
https://cosmium.itch.io/
Re: A miracle when it works first time!
Heh nice. I've had a few firework displays like that. I'll see if I can find them later. It is usually for the same reason - sometimes I even see the sprite data walking around the attributes, and can safely walk it back up to the display file.
It's not quite the same, but something I keep doing when starting my code is hurriedly typing RANDOMIZE USR 3268 (I think) instead of 32768. I get a flashing dashed line at the screen bottom - I must have done it hundreds of times!
It's not quite the same, but something I keep doing when starting my code is hurriedly typing RANDOMIZE USR 3268 (I think) instead of 32768. I get a flashing dashed line at the screen bottom - I must have done it hundreds of times!
Re: A miracle when it works first time!
Do you mean by "sprite clipping" a situation where a sprite emerges from a side of a screen so you draw only visible part of it?
If so then it's a troublesome job. If you put clipping into your sprite drawing routine then unfortunately it'll become slower and more complicated.
In many cases you may consider the effect is not worth the cost and just draw full sprites when they appear at the screen edge.
If you use a screen buffer in memory then a common trick is to make the buffer a bit wider than the visible screen. So you never clip sprites when you draw them into the buffer but when you copy buffer to the visible screen then you do it without the edges and the sprites will look like clipped.
If so then it's a troublesome job. If you put clipping into your sprite drawing routine then unfortunately it'll become slower and more complicated.
In many cases you may consider the effect is not worth the cost and just draw full sprites when they appear at the screen edge.
If you use a screen buffer in memory then a common trick is to make the buffer a bit wider than the visible screen. So you never clip sprites when you draw them into the buffer but when you copy buffer to the visible screen then you do it without the edges and the sprites will look like clipped.
Re: A miracle when it works first time!
A third trick is to put part of the edge of the screen as black paper and black ink, so that drawing sprites can "leak" over the edges (as long as you also reserve some memory after the display) and the effect won't be visible on screen. How well that works does depend on the size of your sprites too (or at least the granularity with which you can draw them)
Re: A miracle when it works first time!
My favourite one is working in all-ram mode. Normally we’re used to bugs doing a reset after eventually jumping to some part of the ROM.
In all-ram mode it’s ALL your code, and it has an annoying habit or restarting your program at a random point rather than crashing. Makes debugging it hard sometimes.
In all-ram mode it’s ALL your code, and it has an annoying habit or restarting your program at a random point rather than crashing. Makes debugging it hard sometimes.
Robin Verhagen-Guest
SevenFFF / Threetwosevensixseven / colonel32
NXtel • NXTP • ESP Update • ESP Reset • CSpect Plugins
SevenFFF / Threetwosevensixseven / colonel32
NXtel • NXTP • ESP Update • ESP Reset • CSpect Plugins
Re: A miracle when it works first time!
Yeah!
Very true, but I thought I'd update my existing "non-clipped" sprite routine to first test for sprites partially off screen (via their coordinates) and add a branch to the new clipping code which adjusts some draw values before returning to the (mainly) unchanged main draw loop. That way there wouldn't be as much impact on the original code's performance.Ralf wrote: ↑Thu Aug 29, 2019 5:28 pm If so then it's a troublesome job. If you put clipping into your sprite drawing routine then unfortunately it'll become slower and more complicated.
In many cases you may consider the effect is not worth the cost and just draw full sprites when they appear at the screen edge.
Cosmium
https://cosmium.itch.io/
https://cosmium.itch.io/
Re: A miracle when it works first time!
Thanks for these tips. This black attribute trick was actually my plan for sprites entering/leaving the left/right sides of the screen. It's better than suddenly fully appearing at the screen's edge yet barely requires any code changes to the render loopAndyC wrote: ↑Thu Aug 29, 2019 6:12 pm A third trick is to put part of the edge of the screen as black paper and black ink, so that drawing sprites can "leak" over the edges (as long as you also reserve some memory after the display) and the effect won't be visible on screen. How well that works does depend on the size of your sprites too (or at least the granularity with which you can draw them)
And the sprite clipping at the screen top/bottom only required changes to the sprite's source address and number of lines to draw, which was relatively easy to change and hasn't had much impact on performance.
Cosmium
https://cosmium.itch.io/
https://cosmium.itch.io/
- Turtle_Quality
- Manic Miner
- Posts: 506
- Joined: Fri Dec 07, 2018 10:19 pm
Re: A miracle when it works first time!
For vertical clipping , if you use a lookup table to get the address of each row, you point rows 192-255 to somewhere harmless, ROM for instance. That way there is no loss of speed. I assume you hold the y address in a single byte so -1 would be 255.
Definition of loop : see loop
- Ast A. Moore
- Rick Dangerous
- Posts: 2641
- Joined: Mon Nov 13, 2017 3:16 pm
Re: A miracle when it works first time!
Yup, even the release version of Exolon has a similar bug.
Every man should plant a tree, build a house, and write a ZX Spectrum game.
Author of A Yankee in Iraq, a 50 fps shoot-’em-up—the first game to utilize the floating bus on the +2A/+3,
and zasm Z80 Assembler syntax highlighter.
Author of A Yankee in Iraq, a 50 fps shoot-’em-up—the first game to utilize the floating bus on the +2A/+3,
and zasm Z80 Assembler syntax highlighter.
Re: A miracle when it works first time!
Yeah, USR 3268 does it. Reminds me of some old ZX81 BASIC laser effect!
Cosmium
https://cosmium.itch.io/
https://cosmium.itch.io/
Re: A miracle when it works first time!
Hey, that's an elegant solution!Turtle_Quality wrote: ↑Thu Aug 29, 2019 9:06 pm For vertical clipping , if you use a lookup table to get the address of each row, you point rows 192-255 to somewhere harmless, ROM for instance. That way there is no loss of speed. I assume you hold the y address in a single byte so -1 would be 255.
Though I think it's handy to calculate ahead of time how many lines of the clipped sprite to draw. That way you can avoid drawing more than necessary as you would if you "blindly" wrote data into ROM over the course of the full sprite height.
Cosmium
https://cosmium.itch.io/
https://cosmium.itch.io/
Re: A miracle when it works first time!
So I finished writing the part where the sprite should gracefully exit the bottom of the screen. Gave it a test and sure enough there were no "it works first time" miracles on display here either. Just an encore fireworks display!
Luckily it was an easy fix and a silly mistake (aren't they always?!). I'd incorrectly assumed a register had a certain value in it after copying and pasting code. Ugh
I wonder what percentage of programming bugs are due to unfounded assumptions..
Luckily it was an easy fix and a silly mistake (aren't they always?!). I'd incorrectly assumed a register had a certain value in it after copying and pasting code. Ugh
I wonder what percentage of programming bugs are due to unfounded assumptions..
Cosmium
https://cosmium.itch.io/
https://cosmium.itch.io/
Re: A miracle when it works first time!
And so does Rallybug, or at least the paid-for version does. There's very few opportunities to actually reach the outer limits, but it's happen to me.Ast A. Moore wrote: ↑Thu Aug 29, 2019 10:20 pm Yup, even the release version of Exolon has a similar bug.
- Ast A. Moore
- Rick Dangerous
- Posts: 2641
- Joined: Mon Nov 13, 2017 3:16 pm
Re: A miracle when it works first time!
What’s that, you say? A bug in Rallybug? Figures.R-Tape wrote: ↑Sat Aug 31, 2019 6:58 amAnd so does Rallybug, or at least the paid-for version does. There's very few opportunities to actually reach the outer limits, but it's happen to me.Ast A. Moore wrote: ↑Thu Aug 29, 2019 10:20 pm Yup, even the release version of Exolon has a similar bug.
Every man should plant a tree, build a house, and write a ZX Spectrum game.
Author of A Yankee in Iraq, a 50 fps shoot-’em-up—the first game to utilize the floating bus on the +2A/+3,
and zasm Z80 Assembler syntax highlighter.
Author of A Yankee in Iraq, a 50 fps shoot-’em-up—the first game to utilize the floating bus on the +2A/+3,
and zasm Z80 Assembler syntax highlighter.
Re: A miracle when it works first time!
Capture of the latest amusing bug while optimising my sprite routine. Think it needs a bit more of work.
Funny how tiny and seemingly innocuous changes in the code can lead to such graphic disaster!
Funny how tiny and seemingly innocuous changes in the code can lead to such graphic disaster!
Cosmium
https://cosmium.itch.io/
https://cosmium.itch.io/
Re: A miracle when it works first time!
Don't think I've seen this quirky one before
Check out the copyright year right after this latest programming crash:
Check out the copyright year right after this latest programming crash:
Cosmium
https://cosmium.itch.io/
https://cosmium.itch.io/
Re: A miracle when it works first time!
Is that 1882?! Clive hadn't even started going bald back then.
How is that even possible? Is 'overwrite ROM' enabled in you emulator?
How is that even possible? Is 'overwrite ROM' enabled in you emulator?
Re: A miracle when it works first time!
I had a look at Spin's settings: "Allow ROM editing" and "Allow assembly to ROM" are disabled, and I've since fixed the bug, so I'm not even sure how it happened..How is that even possible? Is 'overwrite ROM' enabled in you emulator?
Actually it showed "(c) 1B82...". Wasn't even a number. Weird!
Cosmium
https://cosmium.itch.io/
https://cosmium.itch.io/
Re: A miracle when it works first time!
Hex. Good to know that Sinclair research will outlive the common era!
Re: A miracle when it works first time!
A few days ago, while programming some fixed-point maths routines, I was suddenly rewarded with this festive-themed crash. Just before the (c) message it kinda looks like a full screens-worth of gaudy xmas wrapping paper, if you squint hard enough!
Cosmium
https://cosmium.itch.io/
https://cosmium.itch.io/
Re: A miracle when it works first time!
The wrapping paper is a classic runaway stack. Rogue bytes get executed as code, and it goes into a loop pushing pairs of bytes all the way down memory from the head of the stack to the bottom of memory, passing through the attributes and then the pixels as it goes
Robin Verhagen-Guest
SevenFFF / Threetwosevensixseven / colonel32
NXtel • NXTP • ESP Update • ESP Reset • CSpect Plugins
SevenFFF / Threetwosevensixseven / colonel32
NXtel • NXTP • ESP Update • ESP Reset • CSpect Plugins
Re: A miracle when it works first time!
I bet you're right! I fixed the bug a while ago, but I do remember there was a lot of tricky stack handling going on in a loop, and I ended up simplifying by storing to memory locations instead. But I must say the 'wrapping paper' crash did feel like a timely festive treat when it happenedSeven.FFF wrote: ↑Fri Dec 06, 2019 4:02 pm The wrapping paper is a classic runaway stack. Rogue bytes get executed as code, and it goes into a loop pushing pairs of bytes all the way down memory from the head of the stack to the bottom of memory, passing through the attributes and then the pixels as it goes
Cosmium
https://cosmium.itch.io/
https://cosmium.itch.io/
Re: A miracle when it works first time!
Sure it is. It's 7042 in decimal
Website: Tardis Remakes / Mostly remakes of Arcade and ZX Spectrum games.
My games for the Spectrum: Dingo, The Speccies, The Speccies 2, Vallation & Sqij.
Twitter: Sokurah
My games for the Spectrum: Dingo, The Speccies, The Speccies 2, Vallation & Sqij.
Twitter: Sokurah
Re: A miracle when it works first time!
I had a nightmare of a bug, that I solved last night. A compressed screen was decompressing into a right mess, and it wasn't always the same screen, or the same way. It turned out that I'd pasted a bit of code and forgot that it loaded a zero into an absolute memory address high in memory. So as the code built up, I got different effects in different places each time. Even though it was kind of fun to track it down, I should never have made that mistake in the first place. Argh!
- Ast A. Moore
- Rick Dangerous
- Posts: 2641
- Joined: Mon Nov 13, 2017 3:16 pm
Re: A miracle when it works first time!
Oh, I just realized that Quadron didn’t run on the +2A/+3, so I developed a bugfix for it. I only tested the demo version, so [mention]Cosmium[/mention], if you’re interested, PM me for details. I believe my fix should make it compatible with all Spectrums in all modes (48 and 128K).
Every man should plant a tree, build a house, and write a ZX Spectrum game.
Author of A Yankee in Iraq, a 50 fps shoot-’em-up—the first game to utilize the floating bus on the +2A/+3,
and zasm Z80 Assembler syntax highlighter.
Author of A Yankee in Iraq, a 50 fps shoot-’em-up—the first game to utilize the floating bus on the +2A/+3,
and zasm Z80 Assembler syntax highlighter.