Line 31 in EMP_Defender_Sound_Engine_011 to:
PIN__AUDIO = %00000000_00000000_00000100_00000000
and line 425 to:
CTRAVAL long %00110 << 26 + 10
Then for the video, I make the following changes... (tv_drv_005)
Starting at line 147
movs VCFG, #%0111_0000
movd VCFG, #1
movi VCFG, #%0_11_111_000
then at line 302
tvport_mask long %0000_0111<<12
I hadn't noticed that there was keyboard support, I use a SpinStudio
(A type of Protoboard/Demoboard setup) to which I have a custom
NES controller plugged into the standard Hydra NES0 pins.
My start pin for the keyboard is 26. I'll have to find that change
and test it out.
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Just getting started with Propeller?
This week I've mostly been grappling with the concept of a combined KB/TV driver. That's not done yet, and not in this release. What is here is:
Cross Prop Board compatibility. Now compatible with the Hybrid and Proto/Demo boards. There's three blocks at the top of the main SW_DEFENDER file, uncomment the one you need. It's now occurred to me that OBC says there's a change to Eric's sound driver needed as well. You'll have to do that separately for now.
More color cycling. Your ship and the bombers look a bit more groovy.
Pods. They wander around sparkling and feeling all superior.
Mutant sound. Happens randomly when there are mutants on screen. I wondered at first how to queue up this sound, but playing MAME it became obvious that the sound happens when a mutant fires a shot. And that happens randomly when ever they are on screen. I've picked a 1:128 chance per mutant per frame, which sounds about right. But I might have to tweak it for difficulty when there are some actual lethal bullets flying.
The game looks really great! I love the way the enemies all warp in like the original. You sure did manage to get a truckload of stuff going on graphically at the same time! Many kudos.
BTW, I should have mentioned for those people without gamepads: You can use a keyboard in this version, but you'll lose sound. Find these lines at 206 in SW_DEFENDER_009.SPIN and comment out the first and uncomment the second.
sfx.start(@sfx_start_flags)
'key.start(KEYSPIN)
Keyboard controls are
a= Up
z=down
caps lock=reverse
shift=thrust
enter=fire
Awesome! Everything looks and sounds great! There are a couple things I have noticed tho, if you fire a whole bunch of times just standing still, it will erase the laser (I assume it does so because the first laser is erasing itself as dies out) but it will also erase a line from your ship.
Also when you change directions and fire, the laser will fire behind your ship.
The part when you blast away on a single line. What's happening is that there is more happening on a single line than the cog can draw in time. The laser is one of the slowest things to draw, because there is so many pixels on a single scanline. When you get 4 or 5 of them being drawn over each other on the same scanline, it's too much. It needs some optimization and possibly some sneaky shortcuts.
The laser not starting at the right place when you reverse is kludge to stop the laser getting written outside of the scan line buffer. I'm sure I'll come back to it, but it'll do for the moment.
OK, I finally gave up on trying to combine the keyboard and TV drivers in one cog. They both have very exacting timing requirements, and when you do a waitvid, you can't deal with KB timing. With interrupts it'd be possible, but the Propeller model is to use multiple cogs as a replacement for interrupt routines. Which is OK till you run out of cogs. Oh well. KB users will just have to continue to make the choice between keyboard and sound. There's no more I can do.
On the positive side, lots more features.
Uses new sounds from Eric's 009 sound engine.
Dropped in JT Cook's Screen Cap routine. But it doesn't work for me. Obviously it needs customising per game, but I'm not sure how to do it. And the PC EXE doesn't appear to give any progress or error messages. JT, perhaps you could take a look? One interesting problem even once it is working is that the resolution is different on the status screen from the rest of the screen.
Changed from a fixed array of sprites to a sprite allocation model. This is so that sprites that are created after some other sprites have been killed reuse the same slots. This will limit the total number of sprites I have to deal with.
Improved the behavior of lander becoming mutant. Now the humanoid is absorbed into the lander, then explodes, and has the LANDER_DIE sound.
Added scoring. The digits are somewhat oversized because of the lw res of the top of the screen, and really big scores will run off the left hand side of the screen. But there's nothing to be done.
Added proper humanoid falling behaviour. Big falls kill the humanoid.
Added bonuses for catching the humanoid, and small humanoid falls. The bonuses are displayed with 2 sprites each because 3 digits into 8 pixels wide won't go.
Added status display for smartbombs. But smartbombs not done yet.
When all the humanoids have been killed, planet now disappears and explosion sounds. I'll make something more of this later.
Is the screen capture·code in this release? I can take a look at it. Also you did include the serial driver into the code right? But the different resolution split screen shouldn't be a problem, though it may look funky if it is an odd multiple compared to the main screen. If the HUD is 1/2 the screen resolution then you send two pixels per pixel.
Before I do dive into it (which can probably be today after work) what is the Y resolution of the game, the X resolution of the HUD and X resolution of the game field?
Thanks. Just reading your post prompted me to why it didn't work. I'd done the OBJ for the FullDuplex driver. But I wasn't actually calling start on it. It's now working. All I need to do is add the code to send double pixels for the scanner.
Yes, the (non functioning version) is in the zip. But I'll do another release with the fixes late tonight. Together with a nice high quality screen grab.
For info, the dimensions are:
Y = 222 (30 scanner, 192 main playfield)
Scanner X = 88
Playfield X = 176
Kudos, I know working with other people's code can be chore, esp when there is no documentation on it [noparse]:)[/noparse]
One thing I would recomend too is after you save the bmp, you should take it into a paint program and double up the X pixels again. otherwise it will look really skinny.
Steve, great release! Time for me to get all the human sounds in....
I've definitely got some sound balancing to do; adjusting levels and tweaking some things so they sound good together. I'll save than until all the sounds are in though.
I noticed a couple of times that when I killed all the humans the ground disappeared but I did not hear PLANET_EXPLODE. Not sure yet if that's my bug or yours. I also noticed that the red led on the Hydra lights up when I kill the first human; I think I might have left that debug code in my last release. I'll pull it out next time if its coming from me.
For some reason the screen settings did work for my Proto/SpinStudio board. I did the same edit on the tv driver and sound driver and all was well. Sharing a working binary with our local propeller heads. All in all VERY NICE!
Any chance you get make the ship handle faster? Seems a little sluggish compared to what I recall on the original game.
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Just getting started with Propeller?
Hi JT,
It wasn't a chore at all. There are just so many interesting bits of software to explore that it takes a while to try them. But now I've got the screen grab added in I'm really pleased with it. I only got stuck because I tried to do it after several straight hours of programming other defender features. When it didn't work straight away, I didn't have the brain energy left to think it through.
Eric,
Yes, I've been feeling like I've been treading water the last week or two with very slow progress. Mostly because I was fixated on this keyboard thing. So I cracked on yesterday and spent most of the day on Defender itself and got a lot done.
When all 10 humans are dead, I set the terrain color to black and start the sound in successive lines. If the terrain has gone, then I MUST have cued the sound.
rend_terrain_color:=$02
sfx_start_flags |= sfx#SOUND__PLANET_EXPLODE
Don't know about the LED, I use it all the time for debugging so it might come on at any time in one of my releases.
Jeff,
I can't test on the Proto/SpinStudio. Can you work out what changes so need to be changed in the block at the top of SW_DEFENDER_xxx.SPIN and let me know? Then we can make the changes easy for everyone.
Just had a look at your Propeller Cookbook. Nice Work!
Defender WIP 0.11 In Space Everyone Can Hear You Scream
Dropped in Eric's latest sound drivers, so now there are various humanoid sounds.
Contains the fixed version of JT's Screen Capture function. To make it work you have to uncomment 'uart.start(31, 30, 115200), and comment out the sfx1.start and sfx2.start calls in UseSFX1() and UseSFX2(). Then follow the instructions in the readme.txt and/or http://forums.parallax.com/forums/default.aspx?f=33&m=198032
My usual method for working the speed of items is to run MAME and capture a movie. Then view frame by frame in animation studio, and count the number of pixels travelled in a single frame. I did that early on with the ship movement, so I thought it was correct. I had to estimate the amount of acceleration, but the top speeds I could measure.
Just to be sure I've just taken another approach. I've run MAME in one window, with the invincibility cheat on. And in another window I've run WinTV with the output of the hydra on. I can resize both windows, so I placed them one above the other, stretched to be the same with. And actually pressing thrust on both the versions at the same time causes the terrain to fly by, not only at the same rate, but also with the actual features of the landscapes in sync. It's spot on.
I did the same vertically, and the vertical movement top to bottom takes exactly the same time too. At least within the bounds of visible perception.
So I'm absolutely happy that the ship has authentic movement. Most of the aliens though I only guessed at, and played around with parameters till it seemed right by memory.
Anyhow, at some point I'll gather all the parameters that that tweak the gameplay (but don't break anything) and put them together in a CON block. That way people can customize the feel of the game to how they like it.
I thought I'd just say a bit more about the sprite allocation model I'm using. The issue is that Defender has a big cast of sprites. 20 landers/mutants, 10 humanoids, 5 pods, 5 bombers, 25 swarmers, 7 baiters, several bonuses. That's going on for 80 sprites needed in a table. There's no way the prop can deal with that in a scan line rendering system such as I'm using.
But luckily they are rarely in action all at once, as the player shoots some of the earlier sprites before later waves arrive, and usually pick off the contents of each pod one by one. etc. So I've got a fixed sprite table that's much smaller - currently 28. And I only allocate slots when I need them. Each time I need a new sprite the table is scanned for empty entries, and one is returned.
Of course the problem is what happens when new sprites are needed and there aren't any slots left? What I do is to steal them where the player hopefully won't notice. First I check through for empty slots, and if that fails, I search through for a mutant that I can reuse. Mutants get created and killed constantly and buzz around all over the place, so it's unlikely the player knows how many they should be, and probably won't notice one going missing.
After mutants, I look for landers to steal (but not ones that are currently abducting a humanoid).
And I could probably look for swarmers to steal too if all of those fail.
Finished off swarmer motion. This was not straightforward, and took a number of attempts to get something I was happy with.
Added alien bullets. These work so that they go fast if the alien is at the other side of the screen, and slow if the alien is nearby. Which makes aiming a doddle. Just set the velocity equal to the distance between the alien and the player, divided by the number of frames it needs to take to get there. The only problem is that that results in the alien aiming where your ship was, not where it will be. Proper leading fire is does by also adding the ships current velocity into the nullet velocity.
Swarmer bullets are a slight variation. They go twice as fast, but are less accurate. The inaccuracy is created by losing a few of the least signifiant bits from the velocity of the bullets.
Bombers also now lay mines. But because of code space restrictions in the renderer, these are just bullets with zero velocity. Which works well enough.
Added baiters. These appear at the right time, but don't move as yet.
Added "Level Completed" screen. This was more complicated than you'd think. Because there are no tiles in this engine, all the text had to be made up of sprites. But as there aren't enough sprite slots for every letter, 2 letters are squeezed in per sprite.
A further problem with the level completed screen was that 10 mutants all on the same scan lines was too much for the engine, and the last couple didn't display. I made an optimisation by making the renderer not draw the terrain when the terrain color is set to black. That fixed it.
Created a SW_DF_CUSTOMISE file which I've started to add constants which set the game play and difficultty levels. I'm trying to get as close as I can to the feel of the original, and it's good to have all the tweaks in one place. And it makes it easy for everyone else to have a tinker too if they aren't quite happy with a setting.
Eric, I think I've included all the sounds up to now, but if you notice I've missed any, let me know so I can add them.
Looking very good indeed!
Do you anticipate implementing the high score screen? HIGHSCORE is one of my remaining unimplemented sounds and if you don't think that screen will make it in then I'll brush that sound off for now.
BTW, I've noticed that the AA key makes this game far too easy. Should I trust you guys not to use it, or mess with the people that try it?
I'm inclined to limit it, as when showing the game off to friends or at exhibitions or whatever, some people will press the AA key and think that's the actual fire button and declare the game too easy, and not like the original.
Options are:
a) I could either filter out laser shots if they occur too quickly after the previous one. I could tweak the time frame to be just longer than the time of the AA button repeat rate.
b) I could implement an overheat function where the AA autorepeat will work for a while, but then overheat and prevent use for a period.
I would definitely go for option "a" and see how it plays; it's a great idea to deal with the 'AA' button issue and if you can pull off option "a" without affecting gameplay then the fix would be entirely transparent to the user; it would appear as though you just disabled 'AA' which is what you wish you could do in the first place. It might be interesting to write a quick test app to measure the time between button presses and see how fast a human can repeatedly press 'A'. I bet that with a thumb controller a person can't match the AA speed so the filtering may turn out to be a no-brainer.
I had a busier day than I was expecting yesterday and didn't get a chance to do any Defender stuff. But here at last is the release I promised.
Uses the new sound command API.
Adds collision detection. Collision of bullet or alien with ship causes bullet/alien to die and CMD__YOU_DIE to play. But player doesn't actually die as yet.
Added in logic for playing CMD__HUMAN_RETURNED and CMD_BOMBER_DIE for when they are implemented.
Bug: For some reason the Thrust sound isn't working for me. But I didn't have time to investigate what I'm doing wrong.
thrust_command |= sfx1#CMD__THRUST_HIGH
should be
thrust_command := sfx1#CMD__THRUST_HIGH
and
thrust_command |= sfx1#CMD__THRUST_LOW
should be
thrust_command := sfx1#CMD__THRUST_LOW
and
delete the line...
thrust_command := sfx1#CMD__IDLE
The thrust_command field only has 3 valid values: CMD__THRUST_OFF, CMD__THRUST_HIGH, CMD__THRUST_LOW.· You only need to set it and leave it.· You'll probably also need to add·some lines to set it to CMD__THRUST_OFF when a level is completed or the game ends or the player dies.
I also noticed there are still a few 'sfx_command |=' instead of 'sfx_command :=' lingering around.· Don't have time to test that fix yet, but I noticed that sometimes the fire sound drops out for a while and perhaps that is related.·· I· have a full day ahead of me so probably won't get to debug it until tonight.
Now that we've said one can detect AA by measuring the fire rate, why not detect BB and use it as the missing 5th button? It even helps a little that B is thrust since you don't tend to rapidly hit it, so the risk of a BB misdetect due to rapid B mashing is very small. Then you could do:
Oh shoot. I forgot about the Hybrid guys. Are they running Atari sticks? What do they do for Hyperspace and Smartbomb? Is that why left/right are trust and direction today, for Hybrid support?
Eric - we are using Atari style interfaces on the Hybrid.
Mostly I just use a simple 1 fire button joystick although, the best controller I've found so far is the old Master System controller, very similar indeed to the NES controller.
It may be best though to just go for a combination of joystick and keyboard like the good old 8 bit days!
Comments
No it's on left lasers too. BUT you've found a bug where shooting left past the wraparound point doesn't work.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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/25/2007 10:13:12 AM GMT
as for lasers, glad to help bug finding :P
Then in the sound section as mentioned...
Then for the video, I make the following changes... (tv_drv_005)
Starting at line 147 movs VCFG, #%0111_0000 movd VCFG, #1 movi VCFG, #%0_11_111_000 then at line 302 tvport_mask long %0000_0111<<12I hadn't noticed that there was keyboard support, I use a SpinStudio
(A type of Protoboard/Demoboard setup) to which I have a custom
NES controller plugged into the standard Hydra NES0 pins.
My start pin for the keyboard is 26. I'll have to find that change
and test it out.
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Just getting started with Propeller?
Propeller Cookbook
PropDOS
(I haven't uploaded the version with KB support yet.)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Help to build the Propeller wiki - propeller.wikispaces.com
Prop Room Robotics - my web store for Roomba spare parts in the UK
This week I've mostly been grappling with the concept of a combined KB/TV driver. That's not done yet, and not in this release. What is here is:
- Cross Prop Board compatibility. Now compatible with the Hybrid and Proto/Demo boards. There's three blocks at the top of the main SW_DEFENDER file, uncomment the one you need. It's now occurred to me that OBC says there's a change to Eric's sound driver needed as well. You'll have to do that separately for now.
- More color cycling. Your ship and the bombers look a bit more groovy.
- Pods. They wander around sparkling and feeling all superior.
- Mutant sound. Happens randomly when there are mutants on screen. I wondered at first how to queue up this sound, but playing MAME it became obvious that the sound happens when a mutant fires a shot. And that happens randomly when ever they are on screen. I've picked a 1:128 chance per mutant per frame, which sounds about right. But I might have to tweak it for difficulty when there are some actual lethal bullets flying.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔Help to build the Propeller wiki - propeller.wikispaces.com
Prop Room Robotics - my web store for Roomba spare parts in the UK
BTW, I should have mentioned for those people without gamepads: You can use a keyboard in this version, but you'll lose sound. Find these lines at 206 in SW_DEFENDER_009.SPIN and comment out the first and uncomment the second.
sfx.start(@sfx_start_flags)
'key.start(KEYSPIN)
Keyboard controls are
a= Up
z=down
caps lock=reverse
shift=thrust
enter=fire
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Help to build the Propeller wiki - propeller.wikispaces.com
Prop Room Robotics - my web store for Roomba spare parts in the UK
Also when you change directions and fire, the laser will fire behind your ship.
Keep it up!
Glad you like it.
The part when you blast away on a single line. What's happening is that there is more happening on a single line than the cog can draw in time. The laser is one of the slowest things to draw, because there is so many pixels on a single scanline. When you get 4 or 5 of them being drawn over each other on the same scanline, it's too much. It needs some optimization and possibly some sneaky shortcuts.
The laser not starting at the right place when you reverse is kludge to stop the laser getting written outside of the scan line buffer. I'm sure I'll come back to it, but it'll do for the moment.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Help to build the Propeller wiki - propeller.wikispaces.com
Prop Room Robotics - my web store for Roomba spare parts in the UK
OK, I finally gave up on trying to combine the keyboard and TV drivers in one cog. They both have very exacting timing requirements, and when you do a waitvid, you can't deal with KB timing. With interrupts it'd be possible, but the Propeller model is to use multiple cogs as a replacement for interrupt routines. Which is OK till you run out of cogs. Oh well. KB users will just have to continue to make the choice between keyboard and sound. There's no more I can do.
On the positive side, lots more features.
- Uses new sounds from Eric's 009 sound engine.
- Dropped in JT Cook's Screen Cap routine. But it doesn't work for me. Obviously it needs customising per game, but I'm not sure how to do it. And the PC EXE doesn't appear to give any progress or error messages. JT, perhaps you could take a look? One interesting problem even once it is working is that the resolution is different on the status screen from the rest of the screen.
- Changed from a fixed array of sprites to a sprite allocation model. This is so that sprites that are created after some other sprites have been killed reuse the same slots. This will limit the total number of sprites I have to deal with.
- Improved the behavior of lander becoming mutant. Now the humanoid is absorbed into the lander, then explodes, and has the LANDER_DIE sound.
- Added scoring. The digits are somewhat oversized because of the lw res of the top of the screen, and really big scores will run off the left hand side of the screen. But there's nothing to be done.
- Added proper humanoid falling behaviour. Big falls kill the humanoid.
- Added bonuses for catching the humanoid, and small humanoid falls. The bonuses are displayed with 2 sprites each because 3 digits into 8 pixels wide won't go.
- Added status display for smartbombs. But smartbombs not done yet.
- When all the humanoids have been killed, planet now disappears and explosion sounds. I'll make something more of this later.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔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) : 12/2/2007 9:41:27 AM GMT
Before I do dive into it (which can probably be today after work) what is the Y resolution of the game, the X resolution of the HUD and X resolution of the game field?
·
Thanks. Just reading your post prompted me to why it didn't work. I'd done the OBJ for the FullDuplex driver. But I wasn't actually calling start on it. It's now working. All I need to do is add the code to send double pixels for the scanner.
Yes, the (non functioning version) is in the zip. But I'll do another release with the fixes late tonight. Together with a nice high quality screen grab.
For info, the dimensions are:
Y = 222 (30 scanner, 192 main playfield)
Scanner X = 88
Playfield X = 176
Cheers!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Help to build the Propeller wiki - propeller.wikispaces.com
Play Defender - Propeller version of the classic game
Prop Room Robotics - my web store for Roomba spare parts in the UK
Post Edited (CardboardGuru) : 12/2/2007 6:13:21 PM GMT
One thing I would recomend too is after you save the bmp, you should take it into a paint program and double up the X pixels again. otherwise it will look really skinny.
I've definitely got some sound balancing to do; adjusting levels and tweaking some things so they sound good together. I'll save than until all the sounds are in though.
I noticed a couple of times that when I killed all the humans the ground disappeared but I did not hear PLANET_EXPLODE. Not sure yet if that's my bug or yours. I also noticed that the red led on the Hydra lights up when I kill the first human; I think I might have left that debug code in my last release. I'll pull it out next time if its coming from me.
Looking sweet!
For some reason the screen settings did work for my Proto/SpinStudio board. I did the same edit on the tv driver and sound driver and all was well. Sharing a working binary with our local propeller heads. All in all VERY NICE!
Any chance you get make the ship handle faster? Seems a little sluggish compared to what I recall on the original game.
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Just getting started with Propeller?
Propeller Cookbook
PropDOS
It wasn't a chore at all. There are just so many interesting bits of software to explore that it takes a while to try them. But now I've got the screen grab added in I'm really pleased with it. I only got stuck because I tried to do it after several straight hours of programming other defender features. When it didn't work straight away, I didn't have the brain energy left to think it through.
Eric,
Yes, I've been feeling like I've been treading water the last week or two with very slow progress. Mostly because I was fixated on this keyboard thing. So I cracked on yesterday and spent most of the day on Defender itself and got a lot done.
When all 10 humans are dead, I set the terrain color to black and start the sound in successive lines. If the terrain has gone, then I MUST have cued the sound.
rend_terrain_color:=$02
sfx_start_flags |= sfx#SOUND__PLANET_EXPLODE
Don't know about the LED, I use it all the time for debugging so it might come on at any time in one of my releases.
Jeff,
I can't test on the Proto/SpinStudio. Can you work out what changes so need to be changed in the block at the top of SW_DEFENDER_xxx.SPIN and let me know? Then we can make the changes easy for everyone.
Just had a look at your Propeller Cookbook. Nice Work!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Help to build the Propeller wiki - propeller.wikispaces.com
Prop Room Robotics - my web store for Roomba spare parts in the UK
- Dropped in Eric's latest sound drivers, so now there are various humanoid sounds.
- Contains the fixed version of JT's Screen Capture function. To make it work you have to uncomment 'uart.start(31, 30, 115200), and comment out the sfx1.start and sfx2.start calls in UseSFX1() and UseSFX2(). Then follow the instructions in the readme.txt and/or http://forums.parallax.com/forums/default.aspx?f=33&m=198032
- Contains an early implementation of Swarmers.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔Help to build the Propeller wiki - propeller.wikispaces.com
Play Defender - Propeller version of the classic game
Prop Room Robotics - my web store for Roomba spare parts in the UK
Post Edited (CardboardGuru) : 12/2/2007 3:28:54 PM GMT
My usual method for working the speed of items is to run MAME and capture a movie. Then view frame by frame in animation studio, and count the number of pixels travelled in a single frame. I did that early on with the ship movement, so I thought it was correct. I had to estimate the amount of acceleration, but the top speeds I could measure.
Just to be sure I've just taken another approach. I've run MAME in one window, with the invincibility cheat on. And in another window I've run WinTV with the output of the hydra on. I can resize both windows, so I placed them one above the other, stretched to be the same with. And actually pressing thrust on both the versions at the same time causes the terrain to fly by, not only at the same rate, but also with the actual features of the landscapes in sync. It's spot on.
I did the same vertically, and the vertical movement top to bottom takes exactly the same time too. At least within the bounds of visible perception.
So I'm absolutely happy that the ship has authentic movement. Most of the aliens though I only guessed at, and played around with parameters till it seemed right by memory.
Anyhow, at some point I'll gather all the parameters that that tweak the gameplay (but don't break anything) and put them together in a CON block. That way people can customize the feel of the game to how they like it.
I thought I'd just say a bit more about the sprite allocation model I'm using. The issue is that Defender has a big cast of sprites. 20 landers/mutants, 10 humanoids, 5 pods, 5 bombers, 25 swarmers, 7 baiters, several bonuses. That's going on for 80 sprites needed in a table. There's no way the prop can deal with that in a scan line rendering system such as I'm using.
But luckily they are rarely in action all at once, as the player shoots some of the earlier sprites before later waves arrive, and usually pick off the contents of each pod one by one. etc. So I've got a fixed sprite table that's much smaller - currently 28. And I only allocate slots when I need them. Each time I need a new sprite the table is scanned for empty entries, and one is returned.
Of course the problem is what happens when new sprites are needed and there aren't any slots left? What I do is to steal them where the player hopefully won't notice. First I check through for empty slots, and if that fails, I search through for a mutant that I can reuse. Mutants get created and killed constantly and buzz around all over the place, so it's unlikely the player knows how many they should be, and probably won't notice one going missing.
After mutants, I look for landers to steal (but not ones that are currently abducting a humanoid).
And I could probably look for swarmers to steal too if all of those fail.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Help to build the Propeller wiki - propeller.wikispaces.com
Play Defender - Propeller version of the classic game
Prop Room Robotics - my web store for Roomba spare parts in the UK
Defender looks ever more defenderish.
Eric, I think I've included all the sounds up to now, but if you notice I've missed any, let me know so I can add them.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Help to build the Propeller wiki - propeller.wikispaces.com
Play Defender - Propeller version of the classic game
Prop Room Robotics - my web store for Roomba spare parts in the UK
Post Edited (CardboardGuru) : 12/4/2007 11:22:36 PM GMT
Do you anticipate implementing the high score screen? HIGHSCORE is one of my remaining unimplemented sounds and if you don't think that screen will make it in then I'll brush that sound off for now.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Help to build the Propeller wiki - propeller.wikispaces.com
Play Defender - Propeller version of the classic game
Prop Room Robotics - my web store for Roomba spare parts in the UK
I'm inclined to limit it, as when showing the game off to friends or at exhibitions or whatever, some people will press the AA key and think that's the actual fire button and declare the game too easy, and not like the original.
Options are:
a) I could either filter out laser shots if they occur too quickly after the previous one. I could tweak the time frame to be just longer than the time of the AA button repeat rate.
b) I could implement an overheat function where the AA autorepeat will work for a while, but then overheat and prevent use for a period.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Help to build the Propeller wiki - propeller.wikispaces.com
Play Defender - Propeller version of the classic game
Prop Room Robotics - my web store for Roomba spare parts in the UK
I had a busier day than I was expecting yesterday and didn't get a chance to do any Defender stuff. But here at last is the release I promised.
Bug: For some reason the Thrust sound isn't working for me. But I didn't have time to investigate what I'm doing wrong.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Help to build the Propeller wiki - propeller.wikispaces.com
Play Defender - Propeller version of the classic game
Prop Room Robotics - my web store for Roomba spare parts in the UK
and
and
The thrust_command field only has 3 valid values: CMD__THRUST_OFF, CMD__THRUST_HIGH, CMD__THRUST_LOW.· You only need to set it and leave it.· You'll probably also need to add·some lines to set it to CMD__THRUST_OFF when a level is completed or the game ends or the player dies.
I also noticed there are still a few 'sfx_command |=' instead of 'sfx_command :=' lingering around.· Don't have time to test that fix yet, but I noticed that sometimes the fire sound drops out for a while and perhaps that is related.·· I· have a full day ahead of me so probably won't get to debug it until tonight.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Help to build the Propeller wiki - propeller.wikispaces.com
Play Defender - Propeller version of the classic game
Prop Room Robotics - my web store for Roomba spare parts in the UK
Now that we've said one can detect AA by measuring the fire rate, why not detect BB and use it as the missing 5th button? It even helps a little that B is thrust since you don't tend to rapidly hit it, so the risk of a BB misdetect due to rapid B mashing is very small. Then you could do:
A:Fire
AA[noparse]:([/noparse]Nothing)
B:Thrust
BB[noparse]:D[/noparse]irection
Start:Smartbomb
Select:Hyperspace
Up:Up
Down[noparse]:D[/noparse]own
This sure is an interesting thread!
Eric - we are using Atari style interfaces on the Hybrid.
Mostly I just use a simple 1 fire button joystick although, the best controller I've found so far is the old Master System controller, very similar indeed to the NES controller.
It may be best though to just go for a combination of joystick and keyboard like the good old 8 bit days!
Coley