Defender
CardboardGuru
Posts: 443
Defender. A game ahead of it's time when released in 1980. Spurned for a while because people used to space invaders didn't understand it, there was far too much to think about. But when it caught on, considered the best video game of all time by many. I often pondered about how it worked, with it's smooth acceleration and a window on a larger landscape lazily following the players ship around.
When I bought my Hydra, it was for just one thing. To remake Defender. But somehow I got sidetracked into thinking about tiles and sprites, and did Donkey Kong instead. And then I got busy with proper work-for-money projects.
But tonight I got the urge to start on the Defender project. So I took a copy of Dodgy Kong as a starting point, and started pulling stuff out of it that I wouldn't need, and hitting it with a hammer to crudely model a new screen size. Bizarre Defender DK hybrid picture attached.
Original Specs
Defender was 292 x 240 resolution. 16 colours, with some of the colours using palette rotation.
Screen split into 32 pixels high scanner, 206 pixels playfield, 2 pixels divider.
The landscape is 2048 pixels wide.
Discussion
240 pixels high is more than NTSC can manage. Will have to compromise on size. 224 pixels is 16 pixels short of the original. Halving the hight of the scanner was first choice as it leaved the playfield unaltered. But it looks very odd. Might have to lose 16 pixels from playfield instead.
292 pixels overcranking the chroma horizontally. But making it less would mean compromising on sprite artwork or making less of the landscape visible on screen at once. Better to overcrank the chroma, and deal with any issues that creates.
No need for tiles. Just a renderer hardcoded to draw scanner border and landscape and overlay sprites. Sprites don't need to support mirroring. Fixed 16 colors shared by background and foreground will be lots faster to draw that the 4+4 colour scheme used by Dodgy Kong. Which should mean much faster rendering. In fact there are few enough different kinds of sprite that if there is a problem with a 16 colour palette they could be stored as hi-color to minimize processing.
Store landscape as simple array of 2048 hight bytes.
P.S. If anyone has already started on a Defender, please speak up now before I get too involved in this. No point in duplicating games.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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/27/2007 4:44:03 AM GMT
When I bought my Hydra, it was for just one thing. To remake Defender. But somehow I got sidetracked into thinking about tiles and sprites, and did Donkey Kong instead. And then I got busy with proper work-for-money projects.
But tonight I got the urge to start on the Defender project. So I took a copy of Dodgy Kong as a starting point, and started pulling stuff out of it that I wouldn't need, and hitting it with a hammer to crudely model a new screen size. Bizarre Defender DK hybrid picture attached.
Original Specs
Defender was 292 x 240 resolution. 16 colours, with some of the colours using palette rotation.
Screen split into 32 pixels high scanner, 206 pixels playfield, 2 pixels divider.
The landscape is 2048 pixels wide.
Discussion
240 pixels high is more than NTSC can manage. Will have to compromise on size. 224 pixels is 16 pixels short of the original. Halving the hight of the scanner was first choice as it leaved the playfield unaltered. But it looks very odd. Might have to lose 16 pixels from playfield instead.
292 pixels overcranking the chroma horizontally. But making it less would mean compromising on sprite artwork or making less of the landscape visible on screen at once. Better to overcrank the chroma, and deal with any issues that creates.
No need for tiles. Just a renderer hardcoded to draw scanner border and landscape and overlay sprites. Sprites don't need to support mirroring. Fixed 16 colors shared by background and foreground will be lots faster to draw that the 4+4 colour scheme used by Dodgy Kong. Which should mean much faster rendering. In fact there are few enough different kinds of sprite that if there is a problem with a 16 colour palette they could be stored as hi-color to minimize processing.
Store landscape as simple array of 2048 hight bytes.
P.S. If anyone has already started on a Defender, please speak up now before I get too involved in this. No point in duplicating games.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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/27/2007 4:44:03 AM GMT
640 x 480 - 12K
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Joking aside, I think that would be a pretty sweet port. The only thing that I hated about arcade defender is you had to hit a button to change directions instead of left and right.
IIRC I think the defender hardware used a bitmapped buffer instead of tile/sprite combo (as most of the early Williams games did).
If you need a hand on anything let me know, as I've already done two defender titles. Defender/Joust for gameboy, and Super Dropzone for PS1 and Gameboy advance.
But looking good so far.
Also, when I started scramble, I finally realised WHY they titled the screens 90degrees in the arcades. it's mainly so you can have MORE sprites on a horizontal line, as when rotated it's now vertical [noparse]:)[/noparse], also it means you have more height for score panel / radar etc.
Baggers.
Edit: PS, it's gotta be done, it's such a great classic game.
What do you mean? It took me minutes to get that far!!!
Actually, I regret that others don't post pictures and source early enough. It's all about the community and learning together, and giving each other encouragement. I'd love to see a time line of screenshots for other peoples games too, right from the first pixels they manage to display. I want to encourage everyone to not slave away in private until they have something impressive, but to make their mark in the sand with something very un-impressive - and then keep posting until the project is finished.
If I hadn't posted DK early, there's no way I would have got past the early tinkering stage.
You're right about the bitmapped buffer. It's very obvious when the ship explodes and the debris tears through the landscape. But 292*240*4bits = 35040 bytes for the frame buffer, so that's definitely not the way to go with the remake.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Help to build the Propeller wiki - propeller.wikispaces.com
Prop Room Robotics - my web store for Roomba spare parts in the UK
or if you want, you can use a cheat, and have 16 characters made up of 2x2 pixels, starting top left, then move two pixels right etc, if you're not sure what I mean let me know I'll knock up a bmp to show you. then use those to plot to the character map screen, will also help your scrolling landscape too. and you won't need a large bitmap double buffered screen. [noparse]:)[/noparse]
Baggers.
The only point in time when it's obvious that the original had a bitmapped screen is during that explosion. It's brief and non-critical. I'll just do the same explosion without it tearing through everything else on screen.
Here's the outline of what I'm planning to do. No frame buffer, no tile maps.
3 different paths through the renderer.
1) Draws the scan lines where the long range view and status is. (32 scanlines)
2) Draws the dividing line (2 scanlines)
3) Draws the main playfield (190 scanlines)
(3) consists of drawing for each scanline:
a) Clear to black.
b) Stars - from a formula, or a random number generator with a known seed.
c) From a terrain byte array, draw a pixel where the height matches the current scanline.
d) From a missile array, draw a missile if appropriate. (actually 2 arrays, one for the player's laser, one for enemy missiles).
e) Sprites.
Now I think about it there's one more time when the bitmapped nature of the original is obvious. When the "Williams" logo is drawn. But again it's far from critical, and I might be able to cheat by modifying sprite definitions on the fly.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Help to build the Propeller wiki - propeller.wikispaces.com
Prop Room Robotics - my web store for Roomba spare parts in the UK
Yeah, I'd go for the modifying sprites for the williams.
PS, are you doing it keyboard play also? as joypads aren't really enough buttons, or are you going to use left and right for thrust/reverse? and select for teleport? A & B for fire and smartbomb.
Having played the original *too much*, I never once thought it was anything other than a bitmap game. There is a lot of motion in the game, that's not character aligned, and lots of stuff that draws over other things, bitmap style. Not a big discussion, just curious as to the non-bitmap triggers you guys have.
The bombers, leave bitmap trails everywhere, landers could have been sprites, but when they overlap, bitmap draw errors are seen. When you shoot a lot, bombers on the screen, landers shooting, etc... there is a nice matrix style slowdown. Don't know if that was a bug, but it's an excellent element of the game.
On some ports of this game, one shot from the player will eliminate everything on a line, as the shot carries through to the end of the screen. The original didn't do that, and it significantly changes the gameplay. I've always wondered how they did collisions with all that stuff happening on a lowly 6809. Was the bitmap actual 2K pixels, with hardware scrolling?
Baggars, I loved the direction button! One key game dynamic was moving up and down, firing and thrusting. Was a complex affair, that got one into the arcade trance proper. The direction flip was cool, because it helped with that complexity, and put one into various movement modes, that were key, if they were leveraged during intense gameplay. A reverse at the wrong time is deadly.
I remember one other thing too, that really added to the difficulty --might make it variable, just for kicks. Vertical movement was scaled such that the average rapid fire (~100ms) from the player was just a scanline wider, between shots, than the height of the lander. If one really focused on that effort, clearing a screen proper was possible, but only if you really wanted it. There were some people who simply were not capable of that feat, and they were just not ever gonna be Defender players. Kind of cool way to set the bar, IMHO. Jarvis did this a lot! (evil bastard) A small tweak to this completely changes the game dynamic, particularly in the space "all humans lost" elements of the game, and will bring it to an element where mere mortals can play.
Missiles were always bright white too. I'll bet that was for fast bitmap drawing, with no color complications. They seemed to just blast over the top of everything. Given all the action and color, IMHO that was a good thing! Player didn't stand a chance without being able to see those up front and close.
I really like your suggestion about posting from start to finish. I'm about to start on some 2600 style games. Paddle stuff. I'll do just that, because reading the dev log really is educational and fun. Watching you get through DK, helped me a ton, and playing the final result really meant more because of that.
The Atari 8 bit conversion scaled well and ran in 160x192 4 color mode. Clearly the Prop can do better than that. I'll go and hook up the 400 for a screenie or two. Overall, it played well, with some shortcuts. It rendered into a bitmap screen, using software sprites and some shortcuts. Enemy movement was often 4 pixels, to keep sprite images in RAM down, as well as bit mashing. It also took the one shot kills all collision approach. The feel of the playfield was good though. Maybe it's worth looking at?
(if not, I won't post it)
This is goofy, but I've ran some metrics on the firing bit. Did a silly report in HS, way back when. The upper limit for the best of human players, firing on a nice leaf spring, non click style, arcade button, is about 60ms. Most solid, capable people can get a 80 to 100ms cycle time, with below par being about 150ms. On an Atari style joystick, and most conductive spot type game pads, double those numbers (roughly) I believe that's why the Atari port, triggered a player shot on both button press and release. It's an option that might really help with overall playability, when that time comes.
Defender was particularly demanding because sustained button mashing cycle time numbers are a lot lower than peak ones are. The best of the best can sustain their ~80ms cycle time over a number of shots. A lot of people drop to just over 100ms, for long bursts, and many get erratic, which is death in this particular game.
Given those numbers, and the effort, it's no wonder platformers got so damn popular!
Looks like I'm rambling... sorry.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Thx. I hadn't considered keyboard play, but it's a good thought. For the controller I was thinking left/right for changing direction, B for thrust, A for fire, START for smartbomb and SELECT for hyperspace. There's a slight problem there as the Hydra controller has a SLOW button that repeatedly toggles the START button. So I might filter the START button so that multiple presses within a short period only set off one smartbomb.
Actually, on the controller there are also AA and BB buttons, which seem to mirror what A and B do, at least on DK they do. Anyone know offhand how to read them separately?
Hi Potatohead,
Great post. Yes, there is no doubt that the original Williams game was bitmapped. And apparently with no hardware scrolling or blitter. Amazing really for a 1MHz 6809. Though there are a lot of shortcuts, such as updating some elements of the display slower than others, and moving the aliens by bigger steps when the game slows down, and limitign the number of aliens on screen at once by simply moving some to the furthest part of the wraparound world when it got too busy.
But the number of colours and resolution just make it unachievable on the Hydra. It's over the 32K ram space with just the frame buffer. So it has to be done with another approach. But it'll still be possible to get a look closer to the original than any of the 8 bit home computer ports.
Thanks for the thoughts on the feel of the game, and the fire rates. I think it's going to be far harder to get right than DK, as it's a less deterministic system.
Progress
I won't post a screenshot as it would look exactly the same as last night's. But I've changed the sprite definition and rendering from 4 colour to 16 colour. I was thinking that this would mean less work and be faster, but actually most of the sprite bit juggling happens after the sprite has been converted to hi-color, so it makes no difference. And is actually a little slower because twice as much needs reading from the sprite definition in hub memory. However, DK uses a fixed 16x16 size for sprites but defender sprites can be variable sized and smaller.
But I think the main way that I'm going to speed up sprite drawing is by having them pre-shifted. I.E. 4 copies of each sprite tile definition offset so that the sprite code just copies LONG to LONG (with mask) rather than having to shift and combine.
It's fantastic to start from an existing game that I know inside out rather than from scratch. When I think back to the days of hacking with nothing recognisable appearing on screen when I started DK. I'm glad I don't have to go through that again.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Help to build the Propeller wiki - propeller.wikispaces.com
Prop Room Robotics - my web store for Roomba spare parts in the UK
CardboardGuru, No worries, go for both controls, as keyboard is always a good addition, in fact I've been thinking lately, of doing a new game/keyboard routine. which instead of having all the keys mapped etc. it just reads specified keys, and puts them into bits, for your joypad values. yes, it's an extra cog, since it's a keyboard routine and not the spin joypad one, but being directly joypad specific, can be a LOT smaller footprint than the current keyboard routine.
Just thinking about Shift Key for thrust and Enter for firing and AZ for up and down, Space to change direction, and TAB for smartbomb, brings back my school days playing defender on the BBC Model B. [noparse]:)[/noparse]
Oh and pre-shifting sprites will be a good idea, as we used to do that on the speccy with the sprites in the good ol' days.
PS, I'll be posting a pic soon too of my next propeller prog.
No hardware assist? Jesus, that 6809 was a monster in capable hands. Miss programming that bugger to this day. Back then, I had the 6502 Atari, with lots of hardware goodies. A good friend had a CoCo. We always got more done on that thing because of the 6809 being so flexible. Too bad about the Moto stock graphics. Almost high level, by comparison to the self-modify & bit mangling on the 6502, programming wise.
I think Defender is actually pretty deterministic, it's just got layers. Most everything Jarvis did exhibited this quality. Each specific thing behaves in very specific ways. The art of it is in the combination and balance, leaving just enough room for a very aggressive, and capable, human to punch through. FYI, if you do some USENET searches on Jeff Minter, and his port of TEMPEST to the Jaguar, his dev log notes, on these matters, are golden. He posted regularly and often about his decomposing, tweaking, then expanding on the TEMPEST engine. The art is exposed there. Might be worth a look, as it's a similar problem in the case of Defender, sprites, etc...
His approach was to take the core of the game, get player moving, shots, playfield rendering nicely, then layer in the baddies, one by one, tweaking for max game action, then scaling that over the levels. Brilliant stuff. I really had no idea how an engine like that would even be realized, until after following that development. Going back to play those early games, just makes me appreciate them that much more.
..on the firing bit, I gotta say something else. Defender was all about managing ones own resources. Extreme blasts were necessary, but the scale of the game was such, that sustaining them actually put a physical barrier on one's play, usually resulting in a shorter game. Strategy was key, where you moved, how you attacked, when, etc.. all were totally important. If it were physically possible for a person to just hit the upper limit on shots, the game would actually be easy. IMHO, a lot of time and thought went into scaling that right in the sweet spot. Again, you have to really want it and work for it, to get a sustained game session. Of course, the trance was what we were all there for, so of course we wanted it! Quarter, after quarter...
There is little in the Arcade today, that does this. Story is the primary element, as are power ups, special characters, etc... All cheap ***, IMHO. Knowing ones own self, as well as the game, planning, tuning, honing, that's where it's at. If you compare a bad *** classic player to a modern day one, the differences are stark.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Post Edited (potatohead) : 10/27/2007 7:06:44 PM GMT
I am working a game right now, but I am using one of the Hydra TV drivers. After I conjur up a new TV driver I'll post some screenies and source. I have saved older versions so I'll have to grab screenshots of older versions to show the evolution of it.
Baggers: I never played the GBC version of defender/joust, but were you involved in the Spy Hunter/Moon Patrol port? I thought the version of Spy Hunter was done really well.
And your right about not many in games in the arcade today being up to scratch when it comes to playing the old classics, but I guess us Retroheads would say that lol.
JTCook, No I wasn't involved in Spy Hunter/Moon Patrol ports, but they are both classic arcade games, and again worthy of being ported to a Propeller. I remember ploughing many a 10p into both those games in the arcades, good times [noparse]:)[/noparse]
so any takers on it, help yourself [noparse]:)[/noparse]
Post Edited (JT Cook) : 10/27/2007 8:39:00 PM GMT
Lastly, your approach is a good one, "a sparse sprite engine" basically, for a game like this you will be on the + side for tracking objects like the people etc. on the ground, so no tile map should work pretty good.
Anyway, good luck with this one, can't wait to see the done game!
ANdre'
I guess I don't really mean deterministic. What I mean is that the rules that that define how the games plays is harder to discover than in DK. For example, I've taken some movies of action in MAME to examine them in Animation Shop. When you move up and down the screen, it looks fluid at full speed, but actually sometimes the ship moves one pixel at a time and sometimes two. From top to bottom it travels 189 pixels in 105 frames. Whereas DK moves an exact and predictable number of pixels each frame for just about every animation in the game, defender is keeping track of positions and or time at a higher granularity than pixels or time. If the game is busy and it doesn't draw something this frame, it's get drawn further along it's part next time. Looks like I'll be approximating velocities and acceleration.
There are more clues as to how the game was done on such a slow processor without hardware assists. The sprites are not masked. They are copied to the frame buffer as complete rectangles including black background. And then it looks like any sprite that doesn't move between two frames is not redrawn every time. Which can leave holes in them for a few frames if another sprite has crossed it's path.
All in all the program is working hard to give a rough approximation of it's internal model. And it's model looks to to based on fixed point variables. Fractional pixels and/or speeds related to real time, rather than integral pixels and frames.
Andre,
Yes, the terrain height array will make humanoid walking and falling and alien lander terrain following a cinch.
You didn't get your version published because it was too good eh? That sucks. A character mapped defender sounds awful.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Help to build the Propeller wiki - propeller.wikispaces.com
Prop Room Robotics - my web store for Roomba spare parts in the UK
Good question Baggers. The version of Mame I'm using isn't the same as I used when I was taking movies of DK, so it's always possible something could be different. As far as I can see "show only changes" doesn't exist as an option any more.
I'm running the command line version. M.A.M.E. v0.117 (Jul 10 2007). There's no configuration file, so it's whatever the standard options are. Attached is the output of -showconfig.
UPDATE: I've also uploaded a couple of frames that show the non-masked nature of the sprites. The two landers are moving towards each other. In the first picture, you see that the lander on the right has partially overwritten the one on the left with black. That 1 extra pixel of black is because the lander is on an odd X coordinate, and must be writing entire frame buffer bytes of 2 pixels. The next frame shows the lander has moved to an even coordinate, and so the overwrite is smaller. And in the second you can also see the top edge of the overwrite.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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/30/2007 10:35:39 AM GMT
My sprite routine as it stands does proper masking of sprites to anything behind them, but it's the work of a couple of minutes to remove that. As shown above Williams Defender is much more crude and doesn't do any masking. So in doing a remake, where easily possible should one reproduce the visual imperfections, or do a remake that works as nearly as possible to the original, but looks better.
What say you good people?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Help to build the Propeller wiki - propeller.wikispaces.com
Prop Room Robotics - my web store for Roomba spare parts in the UK
Another question, I never looked at the DK sprite rendering driver, did you have a sprite and a sprite mask, or did you evaluate each pixel independantly and deside to plot it or not?
DK was more constrained by memory than speed, so the sprite engine has all the bells and whistles to calculate the mask on the fly and to flip the sprite image horizontally and vertically. That said, it was only just fast enough to display all the sprites for DK.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Help to build the Propeller wiki - propeller.wikispaces.com
Prop Room Robotics - my web store for Roomba spare parts in the UK
As for 2 pixels per write, I'd go with saying it's a 16 colour screen, making it a byte per two colours [noparse]:)[/noparse]
You know, looking at the DK renderer again, I think it might be quicker if I did that! It's probably completely over engineered. You know how these things are, you write them according to a pre-conceived idea of how things should be. Then when they are working you usually don't go back and reconsider if there's an easier way, unless you hit a problem.
Baggers, Two 16 colour pixels held in one byte? I hadn't thought of that!
BTW, that explains why all the sprites are odd numbers of pixels wide. Maximum use of sprite table space, whilst allowing for a one pixel shift in the definition.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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/30/2007 3:39:23 PM GMT
Reading your post made me look. After a few sessions, the following hit me:
Seems to me the tweaks were made with one core ideal behind them; namely, stealing from the action in ways that do not detract from what the player is currently doing. Considerable thought was given to this, as it's not always obvious in a game session that it's happening. I think very simple rules were applied, based on a few key variables: player position, speed, shots, overall number of baddies present on screen. These were compared to actual enemy positions, shots. From there, solid deductions about where the player focus should be are made and acted on.
Vertical position seems to be a core element. Where the ship is, plus or minus some pixels, gets priority over other things.
So, you are mid-screen firing at enemies, clumped together over a human, for example. At this moment, the ship could skip a frame, and one would not really notice, because the shots from both the enemy and player, as well as those vertical enemies are the focus. They get the frame rate. One actually can track from the shots fired, or does not care as it's a quick up, down, up, fire like mad moment. Lots can be done at this moment in time, but only if warranted, thus the number of baddies variable.
Other stuff, say a stray lander floating up high, or behind the ship, gets moved, or skip drawn, as needed to maintain the focus.
I suggest a vertical priority band, with weighting to emulate this. Vertical position differences could be linked to number of frames and would nail a lot of the cases I see. At the very least, that seems to be one of the core drivers behind many of the decisions.
Also noted enemy shots, that are gonna miss the player get skipped too. Does this engine do that many vector calcs, or is there some simple rule that could accomplish that? IMHO, that's the question for a whole bunch of these render rules. 6809 had sub, add, mul, rol, ror, shl, shr, and a very robust set of compares. I would bet money every last one of those rules boils down to a couple of those instructions and a table to decide from that gets built while rendering.
The entire game will skip frames when the bombers are drawing, but only if the player hits one. Tried this a batch of ways, and it seems to be when there are enough enemies (like the little swarmers + lots of landers) are there, hit the bomber and get a batch of slow frames. That's gotta be something coded in for coolness. Identical cases do not exhibit that slow down, if the bombers are not present and hit.
If it were me, I would go for the original look, given it's got some speed advantages; otherwise, it's minor, IMHO. If the game could just render everything all the time, it's intense enough to not be significant.
Edit: Just noticed one other thing too. Many, if not all, the enemies are modal. Two modes: they are either focused on you, or off doing their thing.
If focused on you, more shots, more of the time, and more aggressive movement toward the player. These get render priority too. If not focused on you, then less shots, less aggressive movement, and far lower render priority.
I've seen landers disappear, even within the vertical priority band. They were not focused on the player! IMHO, that's key too.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Post Edited (potatohead) : 10/30/2007 4:00:54 PM GMT
Correction. When the ship is moving up and down the screen, it moves exactly 2 pixels at per frame. But it accelerates to that speed. It takes 25 frames to go from stationary to top speed of 2 pixels per frame. But it stops on a dime. I think this is one of the little things that makes you feel in complete control when playing Defender. It's like mouse acceleration, it enables you to move long distances quickly, whilst being accurate for small moves. You know half the fun of doing remakes is making these little discoveries about the artistry of the original developer(s).
I've decided to store the sprite locations like this:
I..YYYYY_YYYyyyyy_XXXXXXXX_XXXxxxxx
I = invisible. So I can test for invisibility by the sign of the value.
. = not used.
UPPERCASE X&Y are pixel coordinates.
lowercase x&y are fractional parts.
X values go 0 to 2047 and wrap around, so 11 bits for the integer part. That set the basic format. Leaving 5 bits of fraction of a pixel. And Y only needs 8 bits for the integer part.
So moving down the screen is done by adding 64 to the y coordinate at top speed. If I have a velocity variable, I can accelerate over 32 frames by adding 2 each time. Close enough to the real thing.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Help to build the Propeller wiki - propeller.wikispaces.com
Prop Room Robotics - my web store for Roomba spare parts in the UK
info@caextreme.org
If that doesn't work, my other friend sellam ismail that runs the vintage computer festival can probably get his email and or a message to him at www.vintage.org, I will actually email him now and see if he knows Eugene.
Andre'