Almost a month since my last post, and still no progress to report. Real Life - and other less-geeky pursuits - have been taking priority lately and I've been loathe to return to my project(s) before I can be reasonably sure that I'll be able to dedicate time consistently to them again.
It looks like I'm almost certainly US bound again for work at the end of this month for another 2 weeks, so that time may arise sooner than I thought. On my last 2-week trip I managed to implement the core of the Knight Lore port so it's definitely an opportunity to do some significant development.
I will, of course, concentrate on getting Space Invaders finished and, if I do manage to finish that, I'll start looking at optimising Knight Lore, which I'd really like to release sooner rather than later so that I may finally move onto new projects.
I'll also be buying a new laptop for the trip - lugging the old ASUS G73 (at 7kg or 15lbs) back-and-forth across the globe is getting real tired - and I'll need plenty of time beforehand to load up all my development and emulation environments!
Sunday, 19 June 2016
Tuesday, 24 May 2016
Cycles of indecision
Absolutely no progress to report. Work has been taking its toll lately and to be honest, atm when I'm not working and the kids are in bed I'm more inclined to chill out in front of the Giro d'Italia than spend even more time sitting in front of a computer screen.
I do have to admit that I've lost a bit of momentum on the project and still undecided on whether to persist with the on-the-fly rotation or just bite the bullet and finish off my original (pre-rotated graphics) attempt. The latter - although more work - is more likely to be able to handle colour and sound... however I will get this tack working perfectly (even if only for demonstration) before I make up my mind for good.
I do have to admit that I've lost a bit of momentum on the project and still undecided on whether to persist with the on-the-fly rotation or just bite the bullet and finish off my original (pre-rotated graphics) attempt. The latter - although more work - is more likely to be able to handle colour and sound... however I will get this tack working perfectly (even if only for demonstration) before I make up my mind for good.
Friday, 20 May 2016
Still in the red... but much improved
Thanks to jmk, the rotation code is much improved - almost twice as fast in fact! So with some renewed enthusiasm, I added the routine to draw the shields and the game display is complete - except for the scores which I need to relocate to the side of the screen.
Still not a lot of headroom for the VBLANK ISR code which, as you can see above, now encroaches on half the frame, where the mid-screen ISR is scheduled to run. Ordinarily that would show as blue but in the above screen shot, it's happening in the black area above the shields.
There are still some graphical glitches to iron out - my dirty rectangle code needs some tweaking - but the game is certainly playable and it's a reasonably accurate representation of the actual Space Invaders display.
I was originally intending on widening the Coco display from 256 to 320 pixels, but that would actually complicate the calculations for the rotated screen address; right now it's a simple byte-swap and an 8-bit and+neg+add sequence. I'll have to evaluate the implications.
 |
| The red colour indicates time spent in the VBLANK ISR |
Still not a lot of headroom for the VBLANK ISR code which, as you can see above, now encroaches on half the frame, where the mid-screen ISR is scheduled to run. Ordinarily that would show as blue but in the above screen shot, it's happening in the black area above the shields.
There are still some graphical glitches to iron out - my dirty rectangle code needs some tweaking - but the game is certainly playable and it's a reasonably accurate representation of the actual Space Invaders display.
I was originally intending on widening the Coco display from 256 to 320 pixels, but that would actually complicate the calculations for the rotated screen address; right now it's a simple byte-swap and an 8-bit and+neg+add sequence. I'll have to evaluate the implications.
Thursday, 19 May 2016
Mostly working.
Usual story, busy with work blah blah.
I have managed to get it mostly working though - except for the shields. The rotation code is brain-dead brute-force, and given that the VBLANK ISR now takes most of the frame to execute, there's going to have to be a lot of optimisation if it's going to be playable, let-alone add colour and sound. But I still think it can be done.
I should note that I do appreciate the coding/optimisation suggestions tendered in the comments, and will certainly be visiting those again when the time comes.
But the important part is that I've now wrapped my head around what needs to be done. Tonight, for example, I racked my brains trying to find which routine wiped the invaders as they moved - in particular when they hit the edge of the screen and move down. Finally it dawned on me that they don't get erased, but in fact get redrawn by the shifted sprite routine - with a shift value of 0. This has the effect of wiping the 8 pixels above the invader (each and every time).
There's still a chance that I'll get all this done and then need to return to the original plan though...
I have managed to get it mostly working though - except for the shields. The rotation code is brain-dead brute-force, and given that the VBLANK ISR now takes most of the frame to execute, there's going to have to be a lot of optimisation if it's going to be playable, let-alone add colour and sound. But I still think it can be done.
I should note that I do appreciate the coding/optimisation suggestions tendered in the comments, and will certainly be visiting those again when the time comes.
But the important part is that I've now wrapped my head around what needs to be done. Tonight, for example, I racked my brains trying to find which routine wiped the invaders as they moved - in particular when they hit the edge of the screen and move down. Finally it dawned on me that they don't get erased, but in fact get redrawn by the shifted sprite routine - with a shift value of 0. This has the effect of wiping the 8 pixels above the invader (each and every time).
There's still a chance that I'll get all this done and then need to return to the original plan though...
Tuesday, 17 May 2016
Monday, 16 May 2016
Seeing double
Next-to-no time to work on Space Invaders lately, but managed to find 10 minutes here and there a few times since the last post, and tonight I finished another intermediate task.
The idea was to duplicate the screen, to achieve a few goals. One was to identify each of the routines in the code that will require extending to render the rotated screen. FTR there are 11 such routines. In each case, I simply added code to the end of the routine to (also) re-render the video to the Coco3 display. This code will ultimately rotate the graphics on-the-fly. It should be obvious that during the process, I had to take note to preserve and restore any registers that were assumed to be a certain value on return from the rendering routine.
Another goal was to gauge how much processor time was still available during the interrupts. The good news is that, whilst the VBLANK interrupt now encroaches on the visible display (as it no doubt does on arcade hardware) there still seems to be plenty of headroom for further complexities.
Next step is to add the rotation. Looking at my old Space Invaders TRS-80 Bootleg Project code, it was all done brute-force using a few assembler macros. No harm in at least giving that a go; it should mean there's not a lot of code required to achieve all of the rotations!
UPDATE: A little more progress. Three (3) of the eleven routines are complete; the two clear routines and the routine to draw the line along the bottom. None of these required any graphics rotations and were more-or-less simple rewrites.
As for the remaining eight (8) routines, they've all been modified to draw the graphics at the correct screen location. One of them, the routine that draws the shields, will have to be modified in the caller as well as it sets the video address of each individual shield.
Right now it's crashing, but that's not totally unexpected.
The idea was to duplicate the screen, to achieve a few goals. One was to identify each of the routines in the code that will require extending to render the rotated screen. FTR there are 11 such routines. In each case, I simply added code to the end of the routine to (also) re-render the video to the Coco3 display. This code will ultimately rotate the graphics on-the-fly. It should be obvious that during the process, I had to take note to preserve and restore any registers that were assumed to be a certain value on return from the rendering routine.
Another goal was to gauge how much processor time was still available during the interrupts. The good news is that, whilst the VBLANK interrupt now encroaches on the visible display (as it no doubt does on arcade hardware) there still seems to be plenty of headroom for further complexities.
Next step is to add the rotation. Looking at my old Space Invaders TRS-80 Bootleg Project code, it was all done brute-force using a few assembler macros. No harm in at least giving that a go; it should mean there's not a lot of code required to achieve all of the rotations!
UPDATE: A little more progress. Three (3) of the eleven routines are complete; the two clear routines and the routine to draw the line along the bottom. None of these required any graphics rotations and were more-or-less simple rewrites.
As for the remaining eight (8) routines, they've all been modified to draw the graphics at the correct screen location. One of them, the routine that draws the shields, will have to be modified in the caller as well as it sets the video address of each individual shield.
 |
| The Coco3 screen in its correct orientation |
Right now it's crashing, but that's not totally unexpected.
Friday, 13 May 2016
Changing tack
I've been overwhelmed with work the last few days - and still am - but whilst watching Quartus do its thing (it's about as exciting as watching paint dry) and pondering Space Invaders, I'm seriously considering changing tack altogether.
To some extent, the original game was optimised for the rotated display; the player, the invaders and the saucer all move left/right and thus don't require the shifted rendering routine. Even worse, the shields are each offset 45 pixels from the one to the left, which means they too will require shifting.
Way back in 2003 (gosh!) I worked on what I called the Space Invaders TRS-80 'Bootleg' Project, in which I patched the arcade ROMs to run on the TRS-80 Model 4 with the aftermarket uLabs Grafyx Solution high resolution graphics board. It was only partly successful for reasons you can read about on the link if you're interested.
The strategy I took in that project was to retain all of the original rendering, but rather than render to video memory, it was rendered to an off-sceen buffer. The patches then modified each rendering routine to update the Grafyx Solution video memory, rotating each 'dirty rectangle' on-the-fly. It was much, much simpler to implement and, with a 4MHz Z80, there was enough head room for the rotation calculations. It's a pity the Grafyx Solution video bandwidth was the show-stopper.
I think it's worth at least giving it a go on the Coco3. Once the playfield has been drawn at the start of each player's turn, there's really very little rendering per frame. I'm pretty sure the 1.79MHz 6809 is up to the task, especially given the results of the profiling I did recently.
Time to dig out that Z80 code from 2003...
UPDATE: During lunch today I've just backed out the rotation changes and in preparation for the new scheme, moved the Space Invaders video memory (buffer) from $0000 to $2000. I had to fix a couple of latent bugs that weren't apparent when the video memory was based at $0000.
I've also had an idea; now that I'm re-rendering from the original video RAM to the Coco3 display, it should be relatively simple to change to 2BPP and add colour at the same time - effectively killing two birds with one stone!
To some extent, the original game was optimised for the rotated display; the player, the invaders and the saucer all move left/right and thus don't require the shifted rendering routine. Even worse, the shields are each offset 45 pixels from the one to the left, which means they too will require shifting.
Way back in 2003 (gosh!) I worked on what I called the Space Invaders TRS-80 'Bootleg' Project, in which I patched the arcade ROMs to run on the TRS-80 Model 4 with the aftermarket uLabs Grafyx Solution high resolution graphics board. It was only partly successful for reasons you can read about on the link if you're interested.
The strategy I took in that project was to retain all of the original rendering, but rather than render to video memory, it was rendered to an off-sceen buffer. The patches then modified each rendering routine to update the Grafyx Solution video memory, rotating each 'dirty rectangle' on-the-fly. It was much, much simpler to implement and, with a 4MHz Z80, there was enough head room for the rotation calculations. It's a pity the Grafyx Solution video bandwidth was the show-stopper.
I think it's worth at least giving it a go on the Coco3. Once the playfield has been drawn at the start of each player's turn, there's really very little rendering per frame. I'm pretty sure the 1.79MHz 6809 is up to the task, especially given the results of the profiling I did recently.
Time to dig out that Z80 code from 2003...
UPDATE: During lunch today I've just backed out the rotation changes and in preparation for the new scheme, moved the Space Invaders video memory (buffer) from $0000 to $2000. I had to fix a couple of latent bugs that weren't apparent when the video memory was based at $0000.
I've also had an idea; now that I'm re-rendering from the original video RAM to the Coco3 display, it should be relatively simple to change to 2BPP and add colour at the same time - effectively killing two birds with one stone!
Subscribe to:
Posts (Atom)