Deimos Lander

[jbanes]

A couple more screenies...

 

 

I hope to see you all at the ECCC tomorrow!

 

P.S. Ignore the misspelling. That's currently being fixed.

[Thomas Jentzsch]

Wow!

 

How many levels will it have? Will there be variations (e.g. varying or reversed gravity) for increased replay value?

[jbanes]

I'm glad you approve.

 

How many levels will it have?

The current plan is to cram 32 levels spread across 4 missions, then see how much space is left. Some of those levels will take up more than one screen.

 

Will there be variations (e.g. varying or reversed gravity) for increased replay value?

Of a sort. For one thing, you won't need to beat all 32 levels to complete the game. So that right there will increase the replay value. Missions will be unlockable to prevent repetition from setting in. (With a SaveKey, you might even be able to save which missions you've unlocked. ) Also, there is a way to "die", but you don't have lives. This will increase the challenge, and prevent players from getting to the later levels until they're good at the game.

 

I'm also considering adding a few minigames related to the storyline, but those will have to wait to see if I have any space left after I've accomplished my main goals.

[ScottHuggins]

I'm just curious how much of this is bB and how much is 6502 assembly? This is really impressive.

[jbanes]

I'm just curious how much of this is bB and how much is 6502 assembly?

About 90% bBASIC, and 10% ASM.

 

This is really impressive.

Thanks!

[Thomas Jentzsch]

About 90% bBASIC, and 10% ASM.

Would it work without ASM?

[jbanes]

About 90% bBASIC, and 10% ASM.

Would it work without ASM?

The core of the game would. It hasn't changed too radically from the last BIN I posted. However, the extra features, storyline, and all that would disappear.

[Thomas Jentzsch]

The core of the game would. It hasn't changed too radically from the last BIN I posted. However, the extra features, storyline, and all that would disappear.

That was my understanding too. Thanks.

[+batari]

The core of the game would. It hasn't changed too radically from the last BIN I posted. However, the extra features, storyline, and all that would disappear.

That was my understanding too. Thanks.

One thing this game needs is something to replace the three zeros that are permanently in the score.

 

What I'd do is change the score_graphics.asm to add definitions for hex A, B, and C to read "Fuel:" combined or something. You'll need to tweak the ORG's and RORG's at the beginning first. Then hijack the score, which may need to be done before every drawscreen as the BCD mode might choke on the non-BCD numbers, but maybe not; I haven't messed with it too rigorously.

 

One method (though there are probably others) is to do add some dims first:

 

dim sc1=score

dim sc2=score+1

 

Then hijack the score by:

sc1=$AB

sc2=sc2 & $0F

sc2=sc2 | $C0

 

You will probably have to change some other things depending on how you determine the fuel empty condition.

 

For an example of this technique, take a look at the Hunt the Wumpus game in the contest forum.

[jbanes]

One thing this game needs is something to replace the three zeros that are permanently in the score.

Ah, but you're presuming that I'll never give you more than 999 units of fuel.

 

Point taken, though. I'll add it to my list of things to do. I already hijack the score for the level routine, so it shouldn't be difficult.

[MausBoy]

You've come a long way with this. I'm extremely impressed, it's the best bB effort yet imo. I think Batari's idea is a good one, but if having over 999 in fuel is a factor, I know you could fit "FUEL" into 16 pixels.

[Thomas Jentzsch]

Bugs:

- sometimes you land safely with the fuel indicator red

- the message at the end of the game was corrupted and displayed 300 lines

- the scanline count is not constant (mainly around 260-264)

 

Suggestions:

- change the color of the ship, color it like the fuel indicator, so that you can concentrate on one spot in the final phase

- display the remaining lives

- priorize messages (e.g. when I partially miss the platform, the message should be crash and no too fast)

- make a short break after the crash or landing before displaying the message

- disable ship and plattform during message

- change the colors of the messages in sync with the playfield changes

- make a PAL60 version for testing on read hardware

- transfer remaining fuel to next level (partially, only if successful in 1st try?) or start with a lot of fuel and add only a low amount to it with each new try and/or level.

- scoring: sum remaining fuel, bonus ships

- add difficulty levels (varying: lives, fuel, gravity, speed tolerance, ship/landing pad size...)

- more than one landing pad/level

 

suggestions:

- add option for checking vertical speeds too

- reverse gravity

- invisible playfield (visible only while thrusting)

- two player option (split controlling vertical/horizontal speed)

 

More later...

[jbanes]

- sometimes you land safely with the fuel indicator red

Added to my list.

 

- the message at the end of the game was corrupted and displayed 300 lines

Which message? The Game Over screen, or the printer paper screen?

 

- the scanline count is not constant (mainly around 260-264)

Is this inside the "core" of the game (i.e. the flying and landing part) or is this when it switches between screens?

 

- display the remaining lives

There are no lives. There's an algorithm that kicks you out of the game if you suck too badly. The intent is to prevent the player from beating his head against a wall, and force him to use earlier levels to practice. In training, for example, you can actually complete all 8 levels, and still get a Game Over screen. This happens more immediately in later missions, and tie in to the story line that weaves through the game. There are actually two separate failure screens on Mission 2. Unfortunately, you'll have a hard time seeing the second screen as there aren't enough levels yet to trigger it.

 

If you feel like the game is kicking you out too soon, let me know and I'll tweak it a bit. I want the player to feel like he's having more than enough opportunity to win, but without letting him continually beat his head against a wall. He should have his fair shot, then be forced to go back to the beginning of the mission if he can't cut it.

 

- priorize messages (e.g. when I partially miss the platform, the message should be crash and no too fast)

Added to list. I'm also planning to add a "missed" message to clarify when the ship is partly off the platform.

 

- make a short break after the crash or landing before displaying the message

Already on the list. (I'm trying to keep the time between restarts short for testing. That's why there's no explosion. )

 

- disable ship and plattform during message

I'll think about it. There are serious advantages to the way it is now. For example, you can clearly see when you miss the platform by only a few pixels. Giving the player barely a few seconds before you take away that information might leave them without an understanding of what they did wrong.

 

- change the colors of the messages in sync with the playfield changes

I don't understand.

 

- make a PAL60 version for testing on read hardware

Not gonna happen. Yet.

 

- transfer remaining fuel to next level (partially, only if successful in 1st try?) or start with a lot of fuel and add only a low amount to it with each new try and/or level.

Let me nip this one in the bud right now. I have considered the concept of carrying extra fuel and have rejected it. It would have no real effect on the game other than to make the occasional level a lot easier than it should be. Which would muck with the challenge curve, and leave the player in a bit of a sticky situation.

 

- scoring: sum remaining fuel, bonus ships

Not applicable.

 

- add difficulty levels (varying: lives, fuel, gravity, speed tolerance, ship/landing pad size...)

Flip the left difficulty switch. Right now it just lowers the fuel, but it will probably tweak a few other things in the future.

 

- more than one landing pad/level

I'll think about it. In the long run, I don't think it will be useful. The unfortunate fact is that bBASIC can't show more than two sprites at a time. In addition, there is no real "score", so there's no incentive to go for the other pad. My long term plans for Missions 3 and 4 will have an alternate target on some levels that will be required in order to complete the mission. This should provide the desired effect.

 

suggestions:

Uh oh.

 

- add option for checking vertical speeds too

I may add this when the left difficulty switch is flipped. We'll see. For now there's a lot more game that needs to be implemented first.

 

- reverse gravity

- invisible playfield (visible only while thrusting)

I don't think these would work for this game.

 

- two player option (split controlling vertical/horizontal speed)

We'll see.

 

Thanks for the feedback, Thomas!

[Thomas Jentzsch]

Which message? The Game Over screen, or the printer paper screen?

printer paper screen

 

Is this inside the "core" of the game (i.e. the flying and landing part) or is this when it switches between screens?

I noticed when switching screens. I would notice other errors when having a PAL60 version for testing.

 

There are no lives. There's an algorithm that kicks you out of the game if you suck too badly.

Not a bad idea, but the algorithm should be absolutely transparent to the player. Else he may sometimes feel cheated by the algorithm. Which is no good.

 

I'll think about it. There are serious advantages to the way it is now. For example, you can clearly see when you miss the platform by only a few pixels. Giving the player barely a few seconds before you take away that information might leave them without an understanding of what they did wrong.

You can make him press a button, but IMO one or two seconds is long enough. And when the ship explodes, he won't be able to see anyway.

 

I don't understand.

The color changes one or two lines after the playfield changes. Either make that in sync or center the color change inside the playfield block. Else it looks a bit unproffesional.

 

Not gonna happen. Yet.

 

Flip the left difficulty switch. Right now it just lowers the fuel, but it will probably tweak a few other things in the future.

IMO you shouldn't just use the switch. Offer free combining the options.

 

I'll think about it. In the long run, I don't think it will be useful. The unfortunate fact is that bBASIC can't show more than two sprites at a time.

No big problem. The second pad could show when you have landed (flickering). And when you have launched, the first pad would disappear.

 

In addition, there is no real "score", so there's no incentive to go for the other pad.

No incentive? You have to get to the second pad to finish the level. That should be enough, no?

 

 

I may add this when the left difficulty switch is flipped. We'll see. For now there's a lot more game that needs to be implemented first.

See above. Not just a fixed combined option, please.

 

I don't think these would work for this game.

Well, it works for Thrust. The extra code required is minimal, so you get a lot of additional gameplay for almost nothing.

[jbanes]

printer paper screen

Does the paper work at the beginning of the game, or does it always fail? (It certainly shouldn't be at 300 lines! )

 

I noticed when switching screens. I would notice other errors when having a PAL60 version for testing.

Ok. I figured this might happen for now. My aim is a stable 262 lines, but this is still under development. A PAL60 version will be more feasible when I get to correcting these sorts of issues. I'm just glad it's not in the bBASIC. *whew*

 

There are no lives. There's an algorithm that kicks you out of the game if you suck too badly.

Not a bad idea, but the algorithm should be absolutely transparent to the player. Else he may sometimes feel cheated by the algorithm. Which is no good.

Agreed. As I said, I'll work on tweaking that as time goes on.

 

You can make him press a button, but IMO one or two seconds is long enough. And when the ship explodes, he won't be able to see anyway.

A fair point. Of course, I could just crack the ship when he hits the pad only partway. I'll keep this in mind.

 

I don't understand.

The color changes one or two lines after the playfield changes. Either make that in sync or center the color change inside the playfield block. Else it looks a bit unproffesional.

Now I'm even more confused. The pfcolors changes are pushed to the bBASIC engine just before the playfield changes to the message. The two should appear simultaneously on the next call to the kernal.

 

 

Flip the left difficulty switch. Right now it just lowers the fuel, but it will probably tweak a few other things in the future.

IMO you shouldn't just use the switch. Offer free combining the options.

We'll see. Again, there is a lot more game to be finished before I can look into this. The current difficulty switch settings are a holdover from the 4K version.

 

No big problem. The second pad could show when you have landed (flickering). And when you have launched, the first pad would disappear.

In addition, there is no real "score", so there's no incentive to go for the other pad.

No incentive? You have to get to the second pad to finish the level. That should be enough, no?

Ah, you mean refueling pads? That I have considered (especially with multi-screen levels), but I haven't made any commitment yet.

 

I don't think these would work for this game.

Well, it works for Thrust. The extra code required is minimal, so you get a lot of additional gameplay for almost nothing.

Thrust is a different game. Adding the features here would require that the fuel amounts be reworked to fight against the negative gravity. Also, the controls would need to be modified to allow for reverse thrust (Thrust allow rotation), and it probably wouldn't fit with the storyline very well.

 

Keep in mind that you're looking at a very rough work in progress version. I think you'll find that some of the more overarching features won't make sense in the final product.

[Thomas Jentzsch]

Does the paper work at the beginning of the game, or does it always fail? (It certainly shouldn't be at 300 lines! )

Failed only at the end.

 

Now I'm even more confused. The pfcolors changes are pushed to the bBASIC engine just before the playfield changes to the message. The two should appear simultaneously on the next call to the kernal.

It's most obvious at the title screen, with the high contrasting cyan in the middle. Look at the A, E or S. First the playfield changes for their middle line and ~2 lines later the color changes to cyan.

 

Ah, you mean refueling pads? That I have considered (especially with multi-screen levels), but I haven't made any commitment yet.

Refueling pads are a good idea. Though not mine.

 

Thrust is a different game. Adding the features here would require that the fuel amounts be reworked to fight against the negative gravity. Also, the controls would need to be modified to allow for reverse thrust (Thrust allow rotation), and it probably wouldn't fit with the storyline very well.

Agreed, reverse gravity may not fit, but invisible playfield IMO seems to match the game. Anyway, it's your game. I am just suggesting ideas, you decide what fits into your game and what not.

 

I think you'll find that some of the more overarching features won't make sense in the final product.

Sure.

[SeaGtGruff]

Now I'm even more confused. The pfcolors changes are pushed to the bBASIC engine just before the playfield changes to the message. The two should appear simultaneously on the next call to the kernal.

It's most obvious at the title screen, with the high contrasting cyan in the middle. Look at the A, E or S. First the playfield changes for their middle line and ~2 lines later the color changes to cyan.

If I understand what you're referring to, that's the way bB's pfcolor changes work with the no_blank_lines option. I don't know if there's an easy way to do anything about it, since it will require some reprogramming of the kernel.

 

MR

[jbanes]

Does the paper work at the beginning of the game, or does it always fail? (It certainly shouldn't be at 300 lines! )

Failed only at the end.

I loaded the game up in z26, and was able to see it the first time around. The colors were also horribly corrupted. However, it didn't seem to happen on subsequent loads, nor did it happen on all machines I tried it on. I'm thinking it might be a z26 bug (especially since the same screen works fine elsewhere), but I'll keep an eye on it. Thanks for the heads up!

 

Now I'm even more confused. The pfcolors changes are pushed to the bBASIC engine just before the playfield changes to the message. The two should appear simultaneously on the next call to the kernal.

It's most obvious at the title screen, with the high contrasting cyan in the middle. Look at the A, E or S. First the playfield changes for their middle line and ~2 lines later the color changes to cyan.

If I understand what you're referring to, that's the way bB's pfcolor changes work with the no_blank_lines option. I don't know if there's an easy way to do anything about it, since it will require some reprogramming of the kernel.

Now I understand! Thomas, you're talking about the alignment of the colors to the playfield blocks, right? Yeah, that's kind of a bBASIC thing. The title screen will eventually be replaced, and some of the levels where it's more obvious will probably be smoothed out a little. Otherwise, it's just an artifact to live with.

 

 

Agreed, reverse gravity may not fit, but invisible playfield IMO seems to match the game. Anyway, it's your game. I am just suggesting ideas, you decide what fits into your game and what not.

*Nod* I'll keep it in mind for my bag of evil tricks.

 

Hey, Thomas, you mind if I ask you a couple of technical questions? After you mentioned the varying scanline count, I realized that bBASIC is running at 264 scanlines. Shouldn't that be 262 scanlines? Or is 264 a perfectly acceptable scanline target?

 

Also, PAL-60. That's just NTSC with different colors, right? Same scanline count and everything?

 

Thanks for your input, Thomas! It's useful to talk through some of these things. Same goes for the rest of you guys.

[SeaGtGruff]

I loaded the game up in z26, and was able to see it the first time around. The colors were also horribly corrupted. However, it didn't seem to happen on subsequent loads, nor did it happen on all machines I tried it on. I'm thinking it might be a z26 bug

I've run it only once in z26, but the colors looked okay. One thing about z26 is that it sometimes starts up with the PAL palette instead of the NTSC palette if the scanlines are more than 262. So if the colors start up "corrupted" again, try pressing the minus or hyphen key a couple of times to cycle through the three color palettes (NTSC, PAL, and SECAM).

 

Hey, Thomas, you mind if I ask you a couple of technical questions? After you mentioned the varying scanline count, I realized that bBASIC is running at 264 scanlines. Shouldn't that be 262 scanlines? Or is 264 a perfectly acceptable scanline target?

 

Also, PAL-60. That's just NTSC with different colors, right? Same scanline count and everything?

NTSC *should* have 262 lines, but I think some NTSC Atari games had fewer than that (there's a document out there on the web somewhere that lists the number of scan lines for different games). TVs have some degree of flexibility with regard to the number of scan lines, but you should stick as close to the ideal numbers (262 and 312) as possible, and PAL doesn't like odd numbers because of the way the color signal alternates between lines. If you want to get technical, 262 and 312 aren't really the right numbers, because they should be 262.5 and 312.5. And the Atari's NTSC and PAL line rates are slightly different than the ideal NTSC and PAL line rates, so even if you use 262.5 or 312.5 lines to get an interlaced screen, you still end up with frame rates that are different than the ideal NTSC and PAL frame rates.

 

Anyway, there was a change in one or more of bB's 0.99c include files which cause the number of lines to be 264 instead of 262. You can fix it by opening the "std_kernel.asm" file and scrolling down to the following code, which is near the bottom:

 

 ifnconst vblank_time
 lda #43+128
 else
 lda #vblank_time+128
 endif

Change the second line as follows, then save the file. When you recompile your program, there will be 262 lines instead of 264. I also tried the changed file with the "set tv pal" option, and it still produced 312 lines as it should.

 

 ifnconst vblank_time
 lda #41+128; <--- make the change here
 else
 lda #vblank_time+128
 endif

As for PAL/60, it's my understanding that it uses the NTSC number of lines-- 262, or really 262.5-- instead of the usual PAL number of lines-- 312, or 312.5-- but it uses the normal PAL colors instead of the NTSC colors. So to make a PAL/60 game, all you have to do is take the NTSC version and tweak the colors. The following list is a very approximate guideline for converting the NTSC hues to the PAL hues:

 

NTSC $0x = PAL $0x

NTSC $1x = no PAL equivalent (use $2x?)

NTSC $2x = PAL $2x

NTSC $3x = PAL $4x

NTSC $4x = PAL $6x

NTSC $5x = PAL $8x

NTSC $6x = PAL $Ax

NTSC $7x = PAL $Cx

NTSC $8x = PAL $Dx

NTSC $9x = PAL $Bx

NTSC $Ax = PAL $9x

NTSC $Bx = PAL $7x

NTSC $Cx = PAL $5x

NTSC $Dx = PAL $3x

NTSC $Ex = no PAL equivalent (use $3x?)

NTSC $Fx = no PAL equivalent (use $2x?)

 

So for example, if you're using color $44 on an NTSC Atari, you would try using color $64 on a PAL Atari. Or if you were using color $86 on an NTSC Atari, you would try using color $D6 on a PAL Atari. The preceding list should put you very close to the nearest equivalent color, and then if you need to tweak it a little bit to get a better match, you can try an adjacent hue or an adjacent luminance. But be careful, because "adjacent hue" doesn't have the same meaning in the PAL palette as it does in the NTSC palette. That is, in the NTSC palette if color $58 wasn't exactly the color you wanted, you would try $48 or $68 (adjacent hues), or maybe $56 or $5A (adjacent luminances), or maybe a combination of both ($46, $4A, $66, or $6A, etc.). But in the PAL palette, the hues skip numbers-- they go down with the even hues, and they go up with the odd hues (as compared with the nearest NTSC colors). So if you tried $58 in the PAL palette but it wasn't exactly the color you wanted, you would try $38 or $78 (adjacent hues), instead of $48 or $68 as you might expect!

 

MR

[supercat]

If you want to get technical, 262 and 312 aren't really the right numbers, because they should be 262.5 and 312.5. And the Atari's NTSC and PAL line rates are slightly different than the ideal NTSC and PAL line rates, so even if you use 262.5 or 312.5 lines to get an interlaced screen, you still end up with frame rates that are different than the ideal NTSC and PAL frame rates.

 

NTSC should have 227.5 chroma clocks per line, 262.5 lines/field, for a field time of 59,718.5 chroma clocks per field. At a chroma rate of 3,579,545.45MHz, that translates into 16,683 microseconds per frame, or 59.94 frames/second.

 

The Atari 2600 outputs 228 chroma clocks per line, 262 lines/field (typical) for a field time of 59,736 chroma clocks per field. That's 16,688 microseconds per frame, or 59.92 frames/second. If a game output 261 lines/field, that would be 59,508 clocks/field, or 16,625us/field (60.15Hz) If one wanted to do interlacing, one should probably use 261.5 lines (59,622 clocks, 16,656us/field, 60.03Hz).

 

"Real" PAL is interlaced and has the color phase reverse every frame (two fields), requiring an odd number of scan lines (625 for a full frame). The 2600's PAL circuitry for whatever reason doesn't do things that way; it outputs the same color phase every frame. Since television sets require the color phase to reverse on every line, this thus requires having an even number of lines.

 

"PAL-60" from what I can tell is nothing more than a way of taking advantage of most PAL sets' ability to cope with a wide range of vertical scan frequencies. If you run an NTSC game on a PAL 2600 driving a PAL set, the scan frequencies will work but the colors will be all wonky. "PAL-60" fixes the colors while leaving everything else as-is.

[jbanes]

SeaGtGruff, thanks for the info. I figured I might have to make a fix to bBASIC if it was wrong, but it looks like you've already done the footwork for me.

 

Supercat, TMI. We all read the spec sheet. The question is, is there information above and beyond the spec sheet? A simple, "264 lines is wrong; the programmer isn't exploiting any undocumented features" suffices.

[+atari2600land]

Where is a binary file of the version of Deimos Lander with the paper? I must have missed it somewhere.

[SeaGtGruff]

If one wanted to do interlacing, one should probably use 261.5 lines (59,622 clocks, 16,656us/field, 60.03Hz).

Yep, 261.5 lines are closer to the standard NTSC frame rate than 262.5 lines are.

 

The PAL signal has 283.7516 color clocks per line, times 312.5 lines per field, times 50 fields per second, giving 4433618.75 color clocks per second. But the PAL Atari uses a color clock rate that's 4/5 of that, or 3546895 color clocks per second (I think; the specs say 3546894 Hz, but I suspect that this may come from taking an approximate value of 4433618 Hz times 4/5, and dropping the fraction from the answer). If we divide 3546895 color clocks per second by 228 color clocks per line, and then divide again by 312 lines, we get a frame rate of about 49.86 for the PAL Atari. And if we apply the "4/5 rule" to the real PAL color clock, we see that 283.7516 times 4/5 is 227.00128, so the 228 color clocks that the Atari uses are about 1 color clock more per line, versus only 0.5 more on the NTSC Atari (228 instead of 227.5).

 

SECAM is another story-- as I understand it, 282 R-Y color clocks on some lines, and 272 B-Y color clocks on the other (alternating) lines. I guess it was simpler for Atari to create an 8-color SECAM palette than to try to generate a palette that's more comparable to their NTSC palette (128 colors) or PAL palette (104 colors).

 

MR

[jbanes]

Where is a binary file of the version of Deimos Lander with the paper? I must have missed it somewhere.

Closed alpha testing. I'll get a BIN out to the public when I'm ready to handle a massive outpour of suggestions.

[Thomas Jentzsch]

Supercat, TMI. We all read the spec sheet. The question is, is there information above and beyond the spec sheet? A simple, "264 lines is wrong; the programmer isn't exploiting any undocumented features" suffices.

Some versions of Artillery Duel display just 241 (-21) lines, causing some (but not all!) NTSC TVs to roll. Desert Falcon displays up to 281 (+19) scanlines, I don't know if it rolls too. Some prototypes are displaying ~286 scanlines and even they don't roll on all TVs.

 

So 264 lines isn't "wrong" as all TV have more or less tolerance. You just should stay within the limits (maybe +/- ~12 lines) and, most important, constant. E.g. Thrust is displaying 270 scanlines and nobody has ever complained yet.