Hey, you know if Eugene Jarvis was to pop up on the thread and chat about what he remembers of creating Defender, that'd be fascinating.
OK, here's the first primitive release. It's just the player's ship which can be controlled. But it's got acceleration horizontally and vertically that I think is about right.
Controls are
UP/DOWN.
LEFT/RIGHT to reverse.
B for thrust.
The window position isn't attached to the ship yet, so the ship will fly off one side of the screen, go around the world and come back on the other side.
Looks good. Also they released Defender on SNES and Genesis as Williams arcade hits or something. You might want to look at those to see how they do the rendering since both of those are sprite/tile systems. There was also Defender 2 on NES and that might be worth checking out too.
I thought it was about time I did an update on what I've been doing.
I've added the scrolling terrain. Initially this was really slow, as the graphics renderer is working on one scan line at a time, and has to read through 292 bytes of a terrain array and compare each terrain height with the Y coordinate or the current scan line, and either plot a colour or black. Obviously because of throughput with the hub, and because the cog works exclusively in longs, it's a case of doing 4 at a time. But 3 times out of 4 the terrain long word is out of alignment with the scan line buffer, so it's complicated and slow to do. Initially it was taking 5 cogs just to draw the terrain. But a bit of loop unrolling, and optimisation has meant that can now be done in 4 cogs with a sprite.
I've also been changing the way I draw sprites. The problem is this: When aliens are shot, they split into little 2x2 blocks and fly apart. And they do the same in reverse when they appear. See the GIF below for the step nearest to a complete alien. So either I create 16 tiny sprites for each alien in these cases, or I use a sprite drawing routine that copes with it. I'll go for the latter.
For a bitmapped screen, such a sprite routine is easy. A sprite draw routine can draw it's pixels anywhere on the screen - they don't have to be together. But I'm drawing a scan line at a time, so I need to work out for each scanline whether each sprite crosses that line. Which gets a lot more complicated when the sprite is split up into lots of widely spread parts.
Anyway, I'm only partially through changing the sprite routine, so appearing and exploding sprites are the objective for the next release.
This release is for the terrain drawing and scrolling and the window relationship to the moving player ship.
Picture and source code attached. B Button is accelerate, Left/Right changes direction.
I clicked the one on the right, and thought the other was more of the same. Obviously, the one on the left is yours [noparse]:)[/noparse] Looks like a good start.
For speed, you might be better off organizing your terrain table a little differently. Instead of setting it up by pixel height, you should work it per scanline by setting up a scanline table.
Ex:
Let say we have this setup for terrain (very small scale of course)
Scanline 180 000100010
Scanline 181 001010101
Scanline 182 010001000
At scanline 180 we have pixels at·x·coordinates·4 and 8
At scanline 181 we have pixels at x·coordinates 3, 5, 7 and 9
At scanline 182 we have pixels at x·coordinates 2 and 6
Now that it is broken up per scanline, it will be a lot quicker to parse. We will create a table for each scanline that has an address (for where the pixel locations are for that scanline are at) and have number of entries.
So the entries for scanline 180 are located at address X and contains 2 entries, scanline 181 will be located at address Y and have 4 entries, scanline 182 will be located at address Z and have 2 entries.
The only downside is the lookup table will be 3x larger, but the speed benefits should be worth it.
It's a good thought, but there are some other disadvantages to doing that. The landers follow the line of the terrain as they float along, as do the humanoids. And you also need to know the height of the terrain when the ship drops humanoids off. With the table as is, that's a simple array reference to get the hight. Storing tables of horizontal offsets would mean searching. And the game logic will be in spin, so that's problematic.
I have thought of another couple of possible optimisations for the scheme I've got at the moment though:
1) 292 pixels is overdriving the chroma, and so rather than the authentic zigzags on the horizontal sections, it's a murky looking mess. I could double up the pixels, so rather than single pixels, each element is a 2x2 square of pixels. This will mean I'll need a terrain array in hub-memory that's only half as long, and so half as many hub reads. An optimisation that makes the display look better seems like a good deal.
2) The range of scan lines that the terrain covers is 74 pixels. Storable in 7 bits. And after every pixel, the next pixel is either one up or one down. 8 bits for 2 pixels. So I could store the terrain in half the space again that way. And just as easy to lookup the height with a simple array reference.
Between the two, that's a quarter of the number of hub reads. But a lot of effort re-jigging the data (it took ages to type in in the first place, even using Excel to speed the entry process up).
Another idea would be to use two different look up tables. One divided by scanline for rendering, and one that is just a height map for the game characters to interact with. It would still take more memory yet, but I don't think memory should be too much of a problem since there probably aren't that many unique bitmaps for the graphics.
Also you should take a look at the Defender game wiki page since it has some interesting info on the game.
Thanks Paul for adding this project. I'll definitely have to finish it now.
Defender WIP Release v0.02
1) I finished the rewrite of the sprite draw routine so that it can do appearing and exploding sprites. The game now has landers appearing. Though they don't move after they appear.
2) When I did the landers at first with authentic artwork they looked awful. The horizontal res of Williams defender is 292 pixels, and that's far more than NTSC can manage. So I decided I definately had to reduce that horozontal resolution. First thing was to change the numebr of clocks per pixel in my TV driver. The narrowest pixel that worked without nasty artifacts on my TV was 16 pixels. There's probably a good reason for that number that I don't know. But that's what works. So I then adjusted the resolution so that the picture was just wider than the TV picture, i.e. no left or right border (again for my TV your milage may vary). And it came out at 168 pixels horizontally. It's a shame it's not a straightforward scale of 292, but it'll have to do. It means that I need to scale most things, such as pixels and velocities by 0.575. Or thereabouts! So I've redrawn the player ship and lander artwork to be in proportion.
A nice side effect of this is that it speeds up the terrain drawing.
Objectives for the next release:
a) Change the terrain data so the world is in scale to the screen width. It's important that this is a nice power of 2, so I'll cut it down from 2048 pixels to 1024.
b) Get the landers moving.
1) Adjusted the landscape for a world 1024 pixels wide. It's roughly the same geography as the original, but smoothed as a result of losing data. I might go back and rough it up some more.
2) Got the landers moving. After studying heir movement in the original it seemed that their movement is something like this:
Horizontal velocity for each sprite is constant. Make it random when the lander appears, and leave it as it is unless the lander goes to pick up a humanoid.
Make the lander stick close to the terrain: If the lander is more than A pixels above the terrain, move it down by 1 pixel.
Make sure the lander doesn't hit the terrain: If the lander is less that B pixels above the terrain, move it up by 1 pixel.
Where A is around 40 pixels,and B is around 16 pixels, but slightly different for each lander.
These rules make the lander roughly follow the terrain, but not too slavishly. It looks about right. But let me know if you think it's a bit different.
3) Started to implement player shots. The artwork is about right, but needs a bit more tweaking. It needs some colour cycling. It only works properly when flying left to right. And there's some problem with response from the button. Perhaps some button bouncing issue?
4) Brightened up the landscape as requested - it looks much better. (Keyboard version will definitely happen at some point.)
Did a bit more last night. Finished off the lasers, so that they work in both directions, and (mostly) fire from where the ship actually is. And fixed the bug where 50% of the time the laser wasn't firing. (I was incrementing a loop counter in two different places doh!)
Then I started on the scanner. It turns out that if I'd have followed the layout of the original, I'd have had to divide the y coordinate by 6, and I don't know how to do that quickly in assembler. So instead I've reduced the height of the lscanner part of the screen so I can divide by 8 instead. This has the added benefit that it means that I can have the full number of scanlines for the playfield that the original had.
I'm releasing now because it's time to do another big change. I've run out of cog memory for the renderer. Yet I need to have more code for displaying the status area stuff, the terrain in the scanner, stars, smart bombs and planet exploding. So I'm going to do a second renderer that is specific to drawing the status area and scanner, and take the scanner code out of the main renderer.
By the way, it's occurred to me that I'm doing a Model/View/Controller pattern here without even thinking about it. The assembler in the renderer is nothing but view code. The long words that are in my REND parameter block plus the sprite definitions in the GFX file constitute the model. The spin code is the controller.
The controller launches the views, and then does nothing but manipulate the model. The view does nothing but draw what's in the model. This suddenly struck me because I've now done two views of the same model. One in the playfield and one in the long range scan. Yet the controller hasn't had any code added or changed to do the second view.
Did the big change I spoke about last time. The status screen is now rendered by a single cog, whilst 4 other cogs render the main playfield. That's quite tight, because there's 1 cog for the game logic, one for the TV driver, and hopefully one for the sound, leaving a maximum of 5 for rendering. Initially one cog wasn't enough to render the status area, so I've lowered the resolution of the status screen area. It's now half the resolution of the rest of the screen.
There was a slight problem in that this made for an odd number of frames in the status area, which made it difficult to centre the scanner. So I increased the resolution of each slightly to make it even. So the playfield is now 176 pixels wide and the status area is 88 pixels wide.
I wonder if a split screen with different resolutions is a first for the Prop?
With the extra space for code, I added in a border around the the scanner, and different colours for the different objects.
Added humanoids. Their algorithm for moving is exactly the same as the landers, only the values are different so they wander under the terrain rather then hover over it, and go a lot slower.
Added in the logic for the landers abducting the humanoids. For now they take every opportunity to do so. It's carnage!
Added in color cycling for the laser (or did I do that for the last release?)
The obvious next step is to do the mutants. And then other enemies and missiles.
Just got it running on my SpinStudio board.. I love the lasers!
Feels a little awkward to hold the B button to accelerate, how about a tweak to allow directional controls
to move the ship? That would solve button limitations on Hybrid as well..
Great quality! I'm looking forward to demoing this at the club monday night.
Added mutants in. I think the movement is fairly close to the original. Even including the bug feature where crossing the 0 point on the world will make the mutants change direction and chase you the long way around.
Started on the bombers.
By request added acceleration to left/right as an additional option to the B button.
Changed the sprite renderer to use 8x8 sprites rather than 16x8. Because I've narrowed the artwork a bit, all the sprites will fit in 8 pixels. This means that more sprites can be drawn on a scanline without artifacts.
Had a couple of days chasing nasty bugs, then made a bit of proper progress today.
You can now kill stuff with your laser. I've done this now to test Eric's sounds.
Created proper movement for the bombers. They follow SIN waves. A simple plot of Y=SIN(X) with a different scaling factor for each one. A use for that SIN look up table in the ROM!
Did top to bottom wrap around for enemies. It's part of the bombers movement, and it's part of how mutants do a pincer movement. It's an odd thing to do really, as it makes no sense in the game world. Aliens disappearing into the sky shouldn't reappear from below the ground. But games were rather more abstract in the early days than they are now.
I'm doing work on portability right now, to make things easy for the Hybrid and other boards. If you give me a lost of all of the lines that you have to change, I'll do some easy to change constants so everyone is happy, and you won't have to hack it with each release.
Keyboard compatibility done, but not yet released, but initially as a choice between sound or keyboard. (I've run out of cogs)
I'm using the Hybrid board, so first changes are always the clock
from
_clkmode = xtal1 + pll8x
_xinfreq = 10_000_000 + 0000
to
_clkmode = xtal1 + pll16x
_xinfreq = 6_000_000 + 0000
Comments
OK, here's the first primitive release. It's just the player's ship which can be controlled. But it's got acceleration horizontally and vertically that I think is about right.
Controls are
UP/DOWN.
LEFT/RIGHT to reverse.
B for thrust.
The window position isn't attached to the ship yet, so the ship will fly off one side of the screen, go around the world and come back on the other side.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Help to build the Propeller wiki - propeller.wikispaces.com
Prop Room Robotics - my web store for Roomba spare parts in the UK
Post Edited (CardboardGuru) : 10/31/2007 12:02:30 PM GMT
I thought it was about time I did an update on what I've been doing.
I've added the scrolling terrain. Initially this was really slow, as the graphics renderer is working on one scan line at a time, and has to read through 292 bytes of a terrain array and compare each terrain height with the Y coordinate or the current scan line, and either plot a colour or black. Obviously because of throughput with the hub, and because the cog works exclusively in longs, it's a case of doing 4 at a time. But 3 times out of 4 the terrain long word is out of alignment with the scan line buffer, so it's complicated and slow to do. Initially it was taking 5 cogs just to draw the terrain. But a bit of loop unrolling, and optimisation has meant that can now be done in 4 cogs with a sprite.
I've also been changing the way I draw sprites. The problem is this: When aliens are shot, they split into little 2x2 blocks and fly apart. And they do the same in reverse when they appear. See the GIF below for the step nearest to a complete alien. So either I create 16 tiny sprites for each alien in these cases, or I use a sprite drawing routine that copes with it. I'll go for the latter.
For a bitmapped screen, such a sprite routine is easy. A sprite draw routine can draw it's pixels anywhere on the screen - they don't have to be together. But I'm drawing a scan line at a time, so I need to work out for each scanline whether each sprite crosses that line. Which gets a lot more complicated when the sprite is split up into lots of widely spread parts.
Anyway, I'm only partially through changing the sprite routine, so appearing and exploding sprites are the objective for the next release.
This release is for the terrain drawing and scrolling and the window relationship to the moving player ship.
Picture and source code attached. B Button is accelerate, Left/Right changes direction.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Help to build the Propeller wiki - propeller.wikispaces.com
Prop Room Robotics - my web store for Roomba spare parts in the UK
Post Edited (CardboardGuru) : 11/6/2007 5:05:08 AM GMT
Andre'
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Help to build the Propeller wiki - propeller.wikispaces.com
Prop Room Robotics - my web store for Roomba spare parts in the UK
Andre'
Ex:
Let say we have this setup for terrain (very small scale of course)
Scanline 180 000100010
Scanline 181 001010101
Scanline 182 010001000
At scanline 180 we have pixels at·x·coordinates·4 and 8
At scanline 181 we have pixels at x·coordinates 3, 5, 7 and 9
At scanline 182 we have pixels at x·coordinates 2 and 6
Now that it is broken up per scanline, it will be a lot quicker to parse. We will create a table for each scanline that has an address (for where the pixel locations are for that scanline are at) and have number of entries.
So the entries for scanline 180 are located at address X and contains 2 entries, scanline 181 will be located at address Y and have 4 entries, scanline 182 will be located at address Z and have 2 entries.
The only downside is the lookup table will be 3x larger, but the speed benefits should be worth it.
It's a good thought, but there are some other disadvantages to doing that. The landers follow the line of the terrain as they float along, as do the humanoids. And you also need to know the height of the terrain when the ship drops humanoids off. With the table as is, that's a simple array reference to get the hight. Storing tables of horizontal offsets would mean searching. And the game logic will be in spin, so that's problematic.
I have thought of another couple of possible optimisations for the scheme I've got at the moment though:
1) 292 pixels is overdriving the chroma, and so rather than the authentic zigzags on the horizontal sections, it's a murky looking mess. I could double up the pixels, so rather than single pixels, each element is a 2x2 square of pixels. This will mean I'll need a terrain array in hub-memory that's only half as long, and so half as many hub reads. An optimisation that makes the display look better seems like a good deal.
2) The range of scan lines that the terrain covers is 74 pixels. Storable in 7 bits. And after every pixel, the next pixel is either one up or one down. 8 bits for 2 pixels. So I could store the terrain in half the space again that way. And just as easy to lookup the height with a simple array reference.
Between the two, that's a quarter of the number of hub reads. But a lot of effort re-jigging the data (it took ages to type in in the first place, even using Excel to speed the entry process up).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Help to build the Propeller wiki - propeller.wikispaces.com
Prop Room Robotics - my web store for Roomba spare parts in the UK
Also you should take a look at the Defender game wiki page since it has some interesting info on the game.
http://en.wikipedia.org/wiki/Defender_(game)
Scramble is already done albeit for PropGFX, I'm sure Baggers would share if you ask him nicely....
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
Thanks Paul for adding this project. I'll definitely have to finish it now.
Defender WIP Release v0.02
1) I finished the rewrite of the sprite draw routine so that it can do appearing and exploding sprites. The game now has landers appearing. Though they don't move after they appear.
2) When I did the landers at first with authentic artwork they looked awful. The horizontal res of Williams defender is 292 pixels, and that's far more than NTSC can manage. So I decided I definately had to reduce that horozontal resolution. First thing was to change the numebr of clocks per pixel in my TV driver. The narrowest pixel that worked without nasty artifacts on my TV was 16 pixels. There's probably a good reason for that number that I don't know. But that's what works. So I then adjusted the resolution so that the picture was just wider than the TV picture, i.e. no left or right border (again for my TV your milage may vary). And it came out at 168 pixels horizontally. It's a shame it's not a straightforward scale of 292, but it'll have to do. It means that I need to scale most things, such as pixels and velocities by 0.575. Or thereabouts! So I've redrawn the player ship and lander artwork to be in proportion.
A nice side effect of this is that it speeds up the terrain drawing.
Objectives for the next release:
a) Change the terrain data so the world is in scale to the screen width. It's important that this is a nice power of 2, so I'll cut it down from 2048 pixels to 1024.
b) Get the landers moving.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Help to build the Propeller wiki - propeller.wikispaces.com
Prop Room Robotics - my web store for Roomba spare parts in the UK
Don't forget a keyboard version [noparse]:)[/noparse]
One thing is, you might want to brighten the landscape up a bit, it was dark on my TV, and when it scrolled, you could hardly see it.
Other than that, it's looking great, and I like the baddies appearing sprites.
1) Adjusted the landscape for a world 1024 pixels wide. It's roughly the same geography as the original, but smoothed as a result of losing data. I might go back and rough it up some more.
2) Got the landers moving. After studying heir movement in the original it seemed that their movement is something like this:
- Horizontal velocity for each sprite is constant. Make it random when the lander appears, and leave it as it is unless the lander goes to pick up a humanoid.
- Make the lander stick close to the terrain: If the lander is more than A pixels above the terrain, move it down by 1 pixel.
- Make sure the lander doesn't hit the terrain: If the lander is less that B pixels above the terrain, move it up by 1 pixel.
Where A is around 40 pixels,and B is around 16 pixels, but slightly different for each lander.These rules make the lander roughly follow the terrain, but not too slavishly. It looks about right. But let me know if you think it's a bit different.
3) Started to implement player shots. The artwork is about right, but needs a bit more tweaking. It needs some colour cycling. It only works properly when flying left to right. And there's some problem with response from the button. Perhaps some button bouncing issue?
4) Brightened up the landscape as requested - it looks much better. (Keyboard version will definitely happen at some point.)
It's really beginning to look like Defender now!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Help to build the Propeller wiki - propeller.wikispaces.com
Prop Room Robotics - my web store for Roomba spare parts in the UK
And landscape looks great brighter thanks [noparse]:)[/noparse]
Baggers.
Did a bit more last night. Finished off the lasers, so that they work in both directions, and (mostly) fire from where the ship actually is. And fixed the bug where 50% of the time the laser wasn't firing. (I was incrementing a loop counter in two different places doh!)
Then I started on the scanner. It turns out that if I'd have followed the layout of the original, I'd have had to divide the y coordinate by 6, and I don't know how to do that quickly in assembler. So instead I've reduced the height of the lscanner part of the screen so I can divide by 8 instead. This has the added benefit that it means that I can have the full number of scanlines for the playfield that the original had.
I'm releasing now because it's time to do another big change. I've run out of cog memory for the renderer. Yet I need to have more code for displaying the status area stuff, the terrain in the scanner, stars, smart bombs and planet exploding. So I'm going to do a second renderer that is specific to drawing the status area and scanner, and take the scanner code out of the main renderer.
By the way, it's occurred to me that I'm doing a Model/View/Controller pattern here without even thinking about it. The assembler in the renderer is nothing but view code. The long words that are in my REND parameter block plus the sprite definitions in the GFX file constitute the model. The spin code is the controller.
The controller launches the views, and then does nothing but manipulate the model. The view does nothing but draw what's in the model. This suddenly struck me because I've now done two views of the same model. One in the playfield and one in the long range scan. Yet the controller hasn't had any code added or changed to do the second view.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Help to build the Propeller wiki - propeller.wikispaces.com
Prop Room Robotics - my web store for Roomba spare parts in the UK
Post Edited (CardboardGuru) : 11/13/2007 6:05:48 PM GMT
Quite a lot gone into this one.
There was a slight problem in that this made for an odd number of frames in the status area, which made it difficult to centre the scanner. So I increased the resolution of each slightly to make it even. So the playfield is now 176 pixels wide and the status area is 88 pixels wide.
I wonder if a split screen with different resolutions is a first for the Prop?
The obvious next step is to do the mutants. And then other enemies and missiles.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Help to build the Propeller wiki - propeller.wikispaces.com
Prop Room Robotics - my web store for Roomba spare parts in the UK
Baggers.
Have tried it on My Hybrid and it is great!
I just need to get that joystick with two fire buttons now lol
Good work Steve, it looks excellent and up to your usual standard!
Coley
Just got it running on my SpinStudio board.. I love the lasers!
Feels a little awkward to hold the B button to accelerate, how about a tweak to allow directional controls
to move the ship? That would solve button limitations on Hybrid as well..
Great quality! I'm looking forward to demoing this at the club monday night.
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Buttons . . . check. Dials . . . check. Switches . . . check. Little colored lights . . . check.
— Calvin, of 'Calvin and Hobbes.
- Added mutants in. I think the movement is fairly close to the original. Even including the bug feature where crossing the 0 point on the world will make the mutants change direction and chase you the long way around.
- Started on the bombers.
- By request added acceleration to left/right as an additional option to the B button.
- Changed the sprite renderer to use 8x8 sprites rather than 16x8. Because I've narrowed the artwork a bit, all the sprites will fit in 8 pixels. This means that more sprites can be drawn on a scanline without artifacts.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔Help to build the Propeller wiki - propeller.wikispaces.com
Prop Room Robotics - my web store for Roomba spare parts in the UK
Just one change in this one.
- Added the first of Eric's sounds! Sounds great.
I'll do killing of landers in the next release so I can add that other sound in.▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Help to build the Propeller wiki - propeller.wikispaces.com
Prop Room Robotics - my web store for Roomba spare parts in the UK
Well done to you both CG and eric.
Had a couple of days chasing nasty bugs, then made a bit of proper progress today.
- You can now kill stuff with your laser. I've done this now to test Eric's sounds.
- Created proper movement for the bombers. They follow SIN waves. A simple plot of Y=SIN(X) with a different scaling factor for each one. A use for that SIN look up table in the ROM!
- Did top to bottom wrap around for enemies. It's part of the bombers movement, and it's part of how mutants do a pincer movement. It's an odd thing to do really, as it makes no sense in the game world. Aliens disappearing into the sky shouldn't reappear from below the ground. But games were rather more abstract in the early days than they are now.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔Help to build the Propeller wiki - propeller.wikispaces.com
Prop Room Robotics - my web store for Roomba spare parts in the UK
Post Edited (CardboardGuru) : 11/24/2007 6:45:13 AM GMT
Can someone tell me how to convert EPM_Defender_Sound_Engine_011.spin to audio pin 10 instead of 7?
Aha..
Line 31 in EMP_Defender_Sound_Engine_011 to:
PIN__AUDIO = %00000000_00000000_00000100_00000000
and line 425 to:
CTRAVAL long %00110 << 26 + 10
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Just getting started with Propeller?
Propeller Cookbook
PropDOS
Post Edited (Oldbitcollector) : 11/25/2007 6:48:53 AM GMT
What board are you using?
I'm doing work on portability right now, to make things easy for the Hybrid and other boards. If you give me a lost of all of the lines that you have to change, I'll do some easy to change constants so everyone is happy, and you won't have to hack it with each release.
Keyboard compatibility done, but not yet released, but initially as a choice between sound or keyboard. (I've run out of cogs)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Help to build the Propeller wiki - propeller.wikispaces.com
Prop Room Robotics - my web store for Roomba spare parts in the UK
Looks great already [noparse]:)[/noparse]
I'm using the Hybrid board, so first changes are always the clock
from
_clkmode = xtal1 + pll8x
_xinfreq = 10_000_000 + 0000
to
_clkmode = xtal1 + pll16x
_xinfreq = 6_000_000 + 0000
then joypad
GP_RIGHT = %00001000
GP_LEFT = %00000100
GP_DOWN = %00000010
GP_UP = %00000001
GP_START = %00100000
GP_SELECT = %00100000
GP_B = %00100000
GP_A = %10000000
That's all I need to change, Oh and start pin for keyboard = 12 not 3.
Cheers,
Baggers.
Oh, was gonna say can't kill baddies, but it's collision on right lasers only at the moment, I guess [noparse]:)[/noparse]