427 replies to this topic

[kisrael]

Oh, forgot to mention, this program shows "the hard way" that a lot of the emulators don't quite have "real time" sound...the old version of Z26 I was using wa worst, Stella was a bit better, ol' PCAEwin was best. It definately detracts from the fun on an emulator. I'm thinking about having Al run me a small batch of carts of this...

Oh, note...it looks like the CODE tags might not preserve some of the crucial leading spaces that the no lnenumber technique depends on? Ugh.

And batari--thanks. I've had this idea kicking around my head for a number of months, and this is pretty much exactly what I had in mind (except maybe i had a dumbish idea for some higher-rez playfield graphic title screen) Batari BASIC really made it happen. I still had a few stumbles with the compiler...most often a line contaning nothing but a space choking things, but sometimes a line just WOULDN'T compile...I'd cut it out, and add it in a slightly different way, but I swear sometimes it felt like the EXACT SAME LINE just started working, just because I cut and paste it. Not quite that bad, but still.

Attached Files

•  necgdrumma.bas   4.77K   43 downloads

Edited by kisrael, Wed Jul 20, 2005 7:56 PM.

[batari]

kisrael, on Tue Jul 19, 2005 10:34 AM, said:

Well, I dunno. I'd like a bB (btw, I like "bB" because batari sometimes has his first initial

I like it... It kind of has that "geek chic" feel to it.

Quote

I wonder how big this thread would have to get and how mature bB would have to be before we could make a pitch to Al that it should have its own forum.  (Actually, Al mentioned to me that this thread kind of isn't in the wrong place, the Newbie Forum was more meant to be for Davie's tutorials and discussion about that, not about Newbies in general. He doesn't mind it being here or anything, though personally it seems like a lot of clicks to get here sometimes...)

I wonder if the response warrants its own forum now, as the thread has 325 replies and 9000 page views in just two weeks. I suppose it's up to the powers that be in any case...

[Jess Ragan]

The game's comin' along fine. Just check out the latest version!

JR

Attached Files

•  jgame.bin   4K   87 downloads

[s0c7]

Jess Ragan, on Tue Jul 19, 2005 11:23 PM, said:

  My only complaint is the random enemy movement... the rival jet looks like it's being flown by a coffee addict.

I'm not sure how they did the movement in Phantom II (the coin-op I based it off of), but the jerky movement is present in it too, so it kind of fits what I was going for. Does make it harder to hit. I may try to smooth it out a little later.

Thanks for all the kind words. Can't take credit for the subtraction solution (thanks batari!).

Edited by s0c7, Wed Jul 20, 2005 7:30 AM.

[s0c7]

kisrael, on Wed Jul 20, 2005 1:10 AM, said:

I'm including the text of the game here becuase I think it uses some good practices available with the 0.2 Alpha that I haven't heard much talk about: it shuns line numbers, uses descriptive labels for both goto-locations and variable names.

Part of the fun for me is writing old school Basic (nostalgia factor), so I hope batari always keeps line numbers, etc. in as an option.

However, I agree that if you are < 30 yrs. old you probably need to stick to structured programming (especially if you have never done Basic before).

[Jess Ragan]

Here's the latest version of the game... it's gotten to the point where you can actually call it a game now!

However, there's some weird, quirky crap going on that I can't quite figure out. I tried to randomize the location of the fuel pods that you collect to stay alive. The problem with this was that the pods would sometimes land right on top of you, giving you undeserved points.

My solution for this was to toggle the location of the pods from left to right and back again. Great idea, right? The compiler doesn't seem to agree. Rather than shifting the position of the pods from left to right, it wants to put them on whatever side it damned well pleases, despite my rewriting the toggle code several different times.

The game also insists on ramping the difficulty much too quickly. You're supposed to collect three fuel pods before the fireball picks up speed, but it almost seems to happen purely by chance... picking up one pod is sometimes enough to turn the sluggish projectile into a blazing ball of fury.

Finally, there's the slight annoyance of double deaths. After you're struck by the fireball, pressing the fire button causes you to die again the moment you appear onscreen, even though the positions of both characters have been reset. This doesn't happen when you run out of fuel, however, which to say the least strikes me as weird.

If you've got any idea what I'm doing wrong, let me know. I'm including the code with this post.

1 rem smartbranching on
2 rem Fireball dodgin' game
3 rem by Jess Ragan, for Batari BASIC
4 rem
5 rem initialize all variables used in the program
6 rem x/y is ship position, a/b is fireball position
7 rem v/w is ship direction, c/d is fireball direction
8 rem t is fuel gauge, u is game timer, l is level
9 rem
10 x = 90 : y = 45 : v = 0 : w= 255 : t = 24 : u = 0 : s = 1 : f = 0
20 a = 45 : b = 24 : c = 1 : d = 1 : l = 1 : j = 140 : k = 60 : p = 0
30 score = 0
31 rem set up screen; character positions
32 rem fuel pods will be included next
33 rem
40 COLUPF = 128
50 COLUP0 = 84 : player0x = x : player0y = y
60 COLUP1 = 68 : player1x = a : player1y = b
65 missile0x = j : missile0y = k : missile0height = 2
70 scorecolor = 15
80 pfhline 8 10 24 on
81 rem choose animation frames
82 rem ship animation depends on current direction
83 rem
90 if w <> 255 then 110
100 player0:
 %10000001
 %10011001
 %11011011
 %11111111
 %10111101
 %00011000
 %00011000
 %00011000
end
110 if w <> 1 then 130
120 player0:
 %00011000
 %00011000
 %00011000
 %10111101
 %11111111
 %11011011
 %10011001
 %10000001
end
130 if v <> 255 then 150
140 player0:
 %00011111
 %00001100
 %00011000
 %11111111
 %11111111
 %00011000
 %00001100
 %00011111
end
150 if v <> 1 then 170
160 player0:
 %11111000
 %00110000
 %00011000
 %01111111
 %01111111
 %00011000
 %00110000
 %11111000
end
161 rem fireball animation is next on the menu
162 rem fireball animation dependant on the 'u' timer
163 rem
170 if u > 4 then goto 200
180 player1:
 %00001000
 %00010000
 %00010000
 %10011110
 %01111001
 %00001000
 %00001000
 %00010000
end
190 goto 210
200 player1:
 %00100000
 %01000010
 %00100101
 %00011000
 %00011000
 %10100100
 %01000010
 %00000100
end
201 rem joystick movement determines ship's direction
202 rem
210 if joy0up then v = 0 : w = 255
220 if joy0down then v = 0 : w = 1
230 if joy0left then v = 255 : w = 0
240 if joy0right then v = 1 : w = 0
241 rem screen borders stop ship from advancing
242 rem
250 if x < 20 then x = 20
260 if x > 160 then x = 160
270 if y < 10 then y = 10
280 if y > 80 then y = 80
281 rem screen borders reverse fireball's direction
282 rem
290 if a < 20 then c = 1
300 if a > 160 then c = 255
310 if b < 10 then d = 1
320 if b > 80 then d = 255
321 rem move onscreen characters
322 rem ship is propelled forward at a constant rate
323 rem
330 x = x + v : y = y + w
340 for i = 1 to l : a = a + c : b = b + d : next i
341 rem holding down fire button activates retro rockets
342 rem this doubles the speed of your ship
343 rem
350 if joy0fire then x = x + v : y = y + w
351 rem it's the final countdown!
352 rem the 'u' timer advances.  When it reaches ten
353 rem 'u' is reset to zero and the fuel gauge shrinks
354 rem
360 u = u + 1
370 if u = 10 then pfpixel t 10 flip : t = t - 1 : u = 0
371 rem watch your fuel gauge.  Keep it replenished
372 rem by grabbing fuel pods.  If you fail to 
373 rem collect a pod in time, you will perish!
374 rem 
380 if t = 7 then 1000
381 rem set player sprites, then draw them
382 rem
390 COLUP0 = 84 : player0x = x : player0y = y
400 COLUP1 = 68 : player1x = a : player1y = b
401 rem time for some blinking fuel pod action!
402 rem
410 missile0x = j : missile0y = k : missile0height = 2
420 NUSIZ0 = $00
430 if u < 5 then 450
440 NUSIZ0 = $10
441 rem check for collisions
442 rem
450 if !collision(player0,player1) then 1000
455 if !collision(player0,missile0) then gosub 2000
460 drawscreen
461 rem you go back, Jack, and do it again
462 rem wheels turnin' round and round
463 rem
470 goto 90
995 rem it's game over, dude!
996 rem the ship cycles through colors then
997 rem vanishes from sight.  Press the fire
998 rem button or reset to restart the game
1000 for t = 1 to 5
1010 for i = 16 to 30
1020 COLUP0 = i : scorecolor = i : player0x = x : player0y = y
1030 COLUP1 = 64 : player1x = a : player1y = b
1040 drawscreen
1050 next : next
1060 if switchreset || joy0fire then 10
1070 COLUP0 = 0 : scorecolor = 15 : player0x = x : player0y = y
1080 COLUP1 = 64 : player1x = a : player1y = b
1090 drawscreen
1100 goto 1060
1991 rem when the ship touches a fuel pod,
1992 rem the player's fuel supply is restored
1993 rem and points are awarded depending on
1994 rem what fuel is remaining.  The next pod
1995 rem is placed randomly on the screen
1996 rem
2000 i = t - 6 
2010 for t = 1 to 5
2020 i = i * 5
2030 next
2040 score = score + i
2050 t = 24 : pfhline 8 10 24 on
2060 rand = a
2070 if s = 0 then s = 1 : j = 40 : goto 2090
2080 s = 0 : j = 140
2090 k = rand
2100 if k > 70 then k = k - 70 : goto 2100
2110 k = k + 10
2120 f = f + 1
2130 if f = 3 then f = 0 : l = l + 1
2140 if l = 6 then l = 1 : p = p + 1
2150 if p = 6 then l = 5 : p = 5
2160 return

JR

Attached Files

•  jgame.bin   4K   73 downloads

[kisrael]

s0c7, on Wed Jul 20, 2005 6:28 AM, said:

kisrael, on Wed Jul 20, 2005 1:10 AM, said:

I'm including the text of the game here becuase I think it uses some good practices available with the 0.2 Alpha that I haven't heard much talk about: it shuns line numbers, uses descriptive labels for both goto-locations and variable names.

Part of the fun for me is writing old school Basic (nostalgia factor), so I hope batari always keeps line numbers, etc. in as an option.

However, I agree that if you are < 30 yrs. old you probably need to stick to structured programming (especially if you have never done Basic before).

Well, I'm 31. I cut my teeth on the old school BASICs, but I've been programming since 1994 or so using more modern systems. It's really tough to go back: you can't remove a line without risking killing a GOTO somewhere else, you can't easily change the order of stuff, you can't just cut and paste lines you have to renumber, and hope you don't run out of room....

...overall I'm more into Atari 2600 nostalgia than BASIC nostalgia when it comes to bB.

[s0c7]

kisrael, on Wed Jul 20, 2005 9:11 AM, said:

Well, I'm 31. I cut my teeth on the old school BASICs, but I've been programming since 1994 or so using more modern systems. It's really tough to go back: you can't remove a line without risking killing a GOTO somewhere else, you can't easily change the order of stuff, you can't just cut and paste lines you have to renumber, and hope you don't run out of room....

...overall I'm more into Atari 2600 nostalgia than BASIC nostalgia when it comes to bB.

To each his own . I'm a 8-bit Avalon Hill collector, so I'm kind of predisposed to it for that reason as well (they were mostly written in Basic with horrible quality control so you had to go in and debug them a lot of the time )

I'm closing in on 36, so I had a few more years exposure.

In the end, any program (procedural or structured) created with bB is a cool thing.

[s0c7]

Jess Ragan, on Wed Jul 20, 2005 8:39 AM, said:

I tried to randomize the location of the fuel pods that you collect to stay alive.  The problem with this was that the pods would sometimes land right on top of you, giving you undeserved points. 

I haven't really looked at your code yet.... but in the above situation I would probably stick some code in after the pod location is calculated to check if it is the same as the player position. If it is, loop back and get a new random placement.

[vdub_bobby]

Jess Ragan, on Wed Jul 20, 2005 6:39 AM, said:

Here's the latest version of the game... it's gotten to the point where you can actually call it a game now!

Pretty cool, though extremely hard once the enemy speeds up. May I suggest allowing diagonal movement?

[stephena]

kisrael, on Wed Jul 20, 2005 2:42 AM, said:

Oh, forgot to mention, this program shows "the hard way" that a lot of the emulators don't quite have "real time" sound...the old version of Z26 I was using wa worst, Stella was a bit better, ol' PCAEwin was best. It definately detracts from the fun on an emulator.

Unfortunately, this is the 'nature of the beast' when dealing with emulation. We're trying to emulate a real-time system on a non real-time OS, so it's never going to work as well as the real thing. The only way to do so would be to use a non-multitasking OS (DOS, Amiga in custom chip mode, etc).

In fact, given all the obstacles, it's a wonder that any of the emulators work as well as they do.

[kisrael]

stephena, on Wed Jul 20, 2005 9:34 AM, said:

kisrael, on Wed Jul 20, 2005 2:42 AM, said:

Oh, forgot to mention, this program shows "the hard way" that a lot of the emulators don't quite have "real time" sound...the old version of Z26 I was using wa worst, Stella was a bit better, ol' PCAEwin was best. It definately detracts from the fun on an emulator.

Unfortunately, this is the 'nature of the beast' when dealing with emulation. We're trying to emulate a real-time system on a non real-time OS, so it's never going to work as well as the real thing. The only way to do so would be to use a non-multitasking OS (DOS, Amiga in custom chip mode, etc).

In fact, given all the obstacles, it's a wonder that any of the emulators work as well as they do.

I know. I'm quite impressed by all the emulators. It's just a bummer when making an interactive sound toy...
though I thought OSes had special "real time multimedia" stuff? Or is that too complex, or just not up to it?

[Eckhard Stolberg]

kisrael, on Wed Jul 20, 2005 6:51 PM, said:

I know. I'm quite impressed by all the emulators. It's just a bummer when making an interactive sound toy...
though I thought OSes had special "real time multimedia" stuff? Or is that too complex, or just not up to it?

Stella and z26 both use the SDL library for input and output, which helps with keeping the code easily portable between different systems. And if this library doesn't support any "real time multimedia" functions in it's sound subsystem, then the emulators won't be able to use them without making portability more difficult by adding special sound handlers for each supported platform.

BTW, if you have a fast computer, you can reduce the sound buffer size in z26 with the -s command line option. The default size is 4608. Maybe you can find a smaller number which still works on your computer. This should speed up the reaction time for sound changes.


Ciao, Eckhard Stolberg

[stephena]

kisrael, on Wed Jul 20, 2005 6:51 PM, said:

I know. I'm quite impressed by all the emulators. It's just a bummer when making an interactive sound toy...
though I thought OSes had special "real time multimedia" stuff? Or is that too complex, or just not up to it?

It could be done, but it would involve platform-specific code (as Eckhard mentioned). But even then, there would still be some latency. The only way for it to work like a real Atari is to have full control over timing (ie, "play the sound NOW"). With current systems, that translates to "play the sound as soon as you get a chance". I've been able to use a buffer as small as 128 bytes in Stella/Linux with a very fast computer and good sound card, but it still isn't real time. And as long as you work on a non real-time system with software timers, this will always be the case. The best one can hope for is to minimize the effect.

Now, for platforms that don't have an OS, or ones where you have full access to the hardware timer, emulation can be made very accurate. As an aside, that's why platform scrollers/demos were so smooth on the older Amiga computers. They tied the drawing routine into the VBI, so you were assured that the video/audio ran at the same time every frame (to the accuracy of the hardware timer, which is a d?#n good bit better than software timers on current OS's).

[s0c7]

Jess Ragan, on Tue Jul 19, 2005 11:23 PM, said:

My only complaint is the random enemy movement... the rival jet looks like it's being flown by a coffee addict.

Y'know what... you're right! Just went back and played Phantom II and everything moved way more smoothly than I remembered (combination of late at night and San Miguel I guess.... ).

Anyhow, I've smoothed out the enemy jet and increased your starting score to 5.

*** 7/20 - You know the routine. Go to post 350 for the latest version.

Edited by s0c7, Wed Jul 20, 2005 9:12 PM.

[batari]

s0c7, on Wed Jul 20, 2005 8:28 AM, said:

kisrael, on Wed Jul 20, 2005 1:10 AM, said:

I'm including the text of the game here becuase I think it uses some good practices available with the 0.2 Alpha that I haven't heard much talk about: it shuns line numbers, uses descriptive labels for both goto-locations and variable names.

Part of the fun for me is writing old school Basic (nostalgia factor), so I hope batari always keeps line numbers, etc. in as an option.

However, I agree that if you are < 30 yrs. old you probably need to stick to structured programming (especially if you have never done Basic before).

You'll always be able to use line numbers. I'm an old-school Basic programmer myself, and I still use them both as a matter of habit and since I'm not creative enough to think of good, descriptive labels.

[Jess Ragan]

s0c7, on Wed Jul 20, 2005 2:52 PM, said:

Jess Ragan, on Wed Jul 20, 2005 8:39 AM, said:

I tried to randomize the location of the fuel pods that you collect to stay alive.  The problem with this was that the pods would sometimes land right on top of you, giving you undeserved points. 

I haven't really looked at your code yet.... but in the above situation I would probably stick some code in after the pod location is calculated to check if it is the same as the player position. If it is, loop back and get a new random placement.

Tried that. It resulted in the system hanging. I suspect that the randomizer isn't really random at all, although this is usually the case with randomization routines. There are ways to seed the randomizer to create the illusion of unpredictability, however... I'll have to experiment a little with the code to see if I can improve it.

By the way, is there any way to reset the game so that all variables and functions are initialized? I'm still having that problem with double deaths, even when I loop back to the very beginning of the program where the variables are reset to their default values.

JR

[kisrael]

batari, on Wed Jul 20, 2005 2:44 PM, said:

You'll always be able to use line numbers.  I'm an old-school Basic programmer myself, and I still use them both as a matter of habit and since I'm not creative enough to think of good, descriptive labels.

Well, you don't have to label every dang line...just the subroutines!

What killed me though was trying to rearrange things, removing a line that was the target of a GOTO was a killer...

[batari]

Jess Ragan, on Wed Jul 20, 2005 5:41 PM, said:

Tried that.  It resulted in the system hanging.  I suspect that the randomizer isn't really random at all, although this is usually the case with randomization routines.  There are ways to seed the randomizer to create the illusion of unpredictability, however... I'll have to experiment a little with the code to see if I can improve it.

The random number generator only changes when you do something like a=rand. It does not change if you use something like "if rand<value then ..."

So you'd have to use something like "a=rand:if a<value then ..."

Quote

By the way, is there any way to reset the game so that all variables and functions are initialized?  I'm still having that problem with double deaths, even when I loop back to the very beginning of the program where the variables are reset to their default values.

You could use some inline asm:

asm
ldx #128
lda #0
clearvars
sta 0,x
inx
bne clearvars
end

Just don't call it in a subroutine and it should work. Note that everything is indented except for clearvars and end... the indentation doesn't seem to get through to messages.

EDIT: Forgot... You'll need to seed the random number generator after the routine or it will break the randomizer... one way would be:

rand=INTIM | 1

Edited by batari, Wed Jul 20, 2005 5:28 PM.

[Jess Ragan]

Can that ASM be used with line numbers?

JR

[batari]

Jess Ragan, on Wed Jul 20, 2005 6:49 PM, said:

Can that ASM be used with line numbers?

JR

Yep ... put a linenumber before the asm keyword.

[yuppicide]

I've already emailed Retro Gamer. I just asked who would be the best person to speak to and they gave me his email address. So, when the time comes just let me know.. or if Batari would like to PM me here I'll give him the info.

[kisrael]

batari,
hope you're cool with the new forum layout, and me writing the "sticky" intro message.

Would you like a single (possibly sticky) bug report and/or feature request thread?

I do have a minor bug to report, I didn't yet put together a code sample (but I could), but it seems like on .... goto doesn't work with alphanumeric labels. Does that seem possible?

[s0c7]

Not quite ready to break off into my own thread yet.

I'm hoping I can finish this over the weekend. Still have audio, etc. to get around to. I'm still play tweaking right now. In this latest version, if the score is 10 or less there will be 2 enemy jets on the screen. Over that, only one. As a kind of bonus, if you get to 25 a bomber will come out (which is easy to hit). At 26, back to one enemy jet.

**** Update 7/21 - Now has its own thread.

Edited by s0c7, Thu Jul 21, 2005 9:13 AM.

[kisrael]

Hey--
Al just gave me moderator priveleges for the forum...obviously I'm not gonna try to become a dictator or anything.

I do think it would be good for the forum, especially for new people, if we started more new topics rather than posting everything in this one thread. I gave "Solar Plexus Preview" its own thread but respected s0c7 saying "Not quite ready to break off into my own thread yet."

Please let me know if you have any suggestions. This seems to be a good spirited forum, and I doubt I'll be doing much moderating at all.