Stupid question I probably shouldn't be asking...

[Dragnerok X]

This is an open boat I'm on, don't be afraid to share your comments!

 

Please?

[+atari2600land]

I think the white one is better. You can see the animation better.

[Dragnerok X]

I think the white one is better. You can see the animation better.

 

That's what I was thinking. It's just, at the same time, the "flashy" one has a cool explosion-like psychadelic effect. It's a tough decision.

 

[SeaGtGruff]

This is an open boat I'm on, don't be afraid to share your comments!

 

Please?

I'll take a look tonight-- I'm making some changes to GOSUB right now, then I have a meeting to go to this evening, and won't be home until later tonight. It sounds like you have all of your problems licked except for the randomization, so that's what I'll focus on.

 

Michael

[Dragnerok X]

This is an open boat I'm on, don't be afraid to share your comments!

 

Please?

I'll take a look tonight-- I'm making some changes to GOSUB right now, then I have a meeting to go to this evening, and won't be home until later tonight. It sounds like you have all of your problems licked except for the randomization, so that's what I'll focus on.

 

Michael

 

Thanks!

 

Here's my current source for when you're ready.

 

Combat_DX.bas

 

EDIT: Whoops, I forgot to mention one last thing. It seems there is a small bug that when player1 kills player0, both missiles show up on the left side of the screen and neither is usable. When the "Death" sequence ends, the missiles return to normal. For some reason it seems that this doesn't effect player0 killing player1.

 

Good Luck!

Edited February 3, 2007 by Dragnerok X

[SeaGtGruff]

Your problem with the random number generator is coming from calling the rand function too many times to get the kinds of value ranges that you want. The rand function returns a number between 1 and 255, from a fixed series of values-- i.e., number X will always be followed by number Y (where X and Y are specific values from 1 to 255). So the more often you call rand, by putting it in a loop and repeatedly invoking it until you get some acceptable value, the quicker the series will start to repeat the same numbers over and over again. One way to get around that is to call rand just once when a random value is desired, and then adjust the returned value until it's within the desired range, as you can see in the changes I've made.

 

Michael

combat_DX.bas

Combat_DX.bas.bin

[Dragnerok X]

Your problem with the random number generator is coming from calling the rand function too many times to get the kinds of value ranges that you want. The rand function returns a number between 1 and 255, from a fixed series of values-- i.e., number X will always be followed by number Y (where X and Y are specific values from 1 to 255). So the more often you call rand, by putting it in a loop and repeatedly invoking it until you get some acceptable value, the quicker the series will start to repeat the same numbers over and over again. One way to get around that is to call rand just once when a random value is desired, and then adjust the returned value until it's within the desired range, as you can see in the changes I've made.

 

Michael

 

Much better!

 

Now what about the missile problem (mentioned above)?

[SeaGtGruff]

Much better!

 

Now what about the missile problem (mentioned above)?

Sorry, I didn't see that question! The problem was caused by setting missile0x and *missile1x* to 0 in the kill_player0 routine. In contrast, the kill_player1 routine sets missile1x and *missile1y* to 0. So I changed kill_player0 to set missile0x and *missile0y* to 0, and now life is good again.

 

Michael

combat_DX.bas

Combat_DX.bas.bin

[Dragnerok X]

Much better!

 

Now what about the missile problem (mentioned above)?

Sorry, I didn't see that question! The problem was caused by setting missile0x and *missile1x* to 0 in the kill_player0 routine. In contrast, the kill_player1 routine sets missile1x and *missile1y* to 0. So I changed kill_player0 to set missile0x and *missile0y* to 0, and now life is good again.

 

Michael

 

Wow! That was horrendously obvious.

 

Thanks!

 

Edit: So, in your opinion, which looks better. The "flash" effect or white?

Edited February 4, 2007 by Dragnerok X

[SeaGtGruff]

So, in your opinion, which looks better. The "flash" effect or white?

I think the white explosion looks better.

 

Michael

[Dragnerok X]

So, in your opinion, which looks better. The "flash" effect or white?

I think the white explosion looks better.

 

Michael

 

O.k. I think I've reached a consensus. I'll work on polishing this up today and might even have demo 5 ready before the super bowl!

 

 

EDIT: EDIT: If you read this edit, I decided myself. If not, ignore this altogether and scroll down.

Edited February 4, 2007 by Dragnerok X

[SeaGtGruff]

I just thought of something. Should I Have the missile constantly moving until it reaches the other side of the screen or put a limit on how far it can move (like traditional combat).

As far as realism, it makes sense to have limits on how far the missiles can move-- but then again, in real life the tanks would aim closer or farther by changing the angle of elevation of the turret, and that would be kind of difficult to incorporate into Combat. Maybe you could compromise by putting limits on the missiles' range, but let the tanks pick up "power pellets" (special artillery?) that let them shoot all the way to the edge of the screen? Each "power pellet" could be good for only a certain number of shots, before reverting back to the normal artillery. Perhaps you could have the "power pellets" be dropped at random locations during the game via parachute, and let the tanks race each other to be the first to pick up the "power pellet"? For that matter, you could put limits on how much artillery the tanks have, and when they run low or run out, they have to race each other to pick up artillery packets that flash at random locations-- similar to the way the man in Dark Cavern must pick up more bullets when the pistol icon pops up from time to time. And you could use different colors for different kinds of artillery packets-- normal (limited range) or special (infinite range).

 

Keep in mind, I'm just throwing out ideas, without worrying about how you'd actually accomplish any of them within the limitations of your program, batari BASIC's kernel, the 2600's graphics, and the type of game controller being used!

 

Michael

[Dragnerok X]

Combat DX: Demo 5 - Missile Navigation (Carnage)

 

* Added straight-firing missiles

 

* Added collision-based missile return system

 

* Added a Cool Death Sequence

 

* Set up a random respawning system

 

* Again, even more code clean-up

 

* More surprises even my co-producer, SeaGTgruff, doesn't know!

 

Next up, add a battlefield (playfield based). I might even hold a level design contest once I get the engine set up.

 

 

Combat_DX___Demo_5.bas

 

Combat_DX___Demo_5.bin

[Dragnerok X]

Current status:

 

*Pretty much open for comments now on demo 5.

 

*I've already started working on the playfield. SeaGTGruff (or who ever can answer this first), why doesn't my "test" playfield show up?

 

Combat_DX.bas

 

BTW: From the looks of it, it appears I won't be able to get much more then a single map in until I "cut down" on the sprite count. Probably the first and most effective thing to do would be to have both players share the same sprites for similar situations (i.e. the tank rotation ones). I'll try to get to this once I have the playfield down and all related collision detection and such.

[SeaGtGruff]

why doesn't my "test" playfield show up?

There were two problems with it.

 

First, you were using lowercase x in the playfield statement, and the default is to use uppercase X. You can use other characters for on and off, but if you do, you need to include them in the playfield statement so batari BASIC will know which is which. The following information is from the 0.99a prerelease notes in batari's blog:

 

playfield command - specify entire playfield at once:

playfield:
(syntax: playfield: <off> <on>
<off> and <on> are optional. they specify the symbols to use for on or off for pf blocks. Default:. and X
example:
  playfield:
  X.X...X..XX..X.XX.X....XX..X.X..
  X.X....XX..X.X..X.X...X..XX..X.X
... etc.

So if you want to use lowercase x instead of uppercase X, you would do the following:

 

  playfield: . x
  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
  x..............................x
  x..............................x
  x..............................x
  x..............................x
  x..............................x
  x..............................x
  x..............................x
  x..............................x
  x..............................x
  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

The other problem is that you specified only 28 characters on each playfield row. I didn't try it, but I think it would have drawn the playfield if you'd just used uppercase X, or had specified what the off and on characters are, but the playfield probably would have come out differently than expected. If want to draw a playfield border using just the central 28 playfield positions, then you should pad the left and right sides of the rows with periods, as follows:

 

  playfield:
  ..XXXXXXXXXXXXXXXXXXXXXXXXXXXX..
  ..X..........................X..
  ..X..........................X..
  ..X..........................X..
  ..X..........................X..
  ..X..........................X..
  ..X..........................X..
  ..X..........................X..
  ..X..........................X..
  ..X..........................X..
  ..XXXXXXXXXXXXXXXXXXXXXXXXXXXX..

Michael

 

PS -- I like the way the destroyed tank rematerializes!

combat_DX.bas

Edited February 6, 2007 by SeaGtGruff

[Dragnerok X]

There were two problems with it.

 

First, you were using lowercase x in the playfield statement, and the default is to use uppercase X. You can use other characters for on and off, but if you do, you need to include them in the playfield statement so batari BASIC will know which is which. The following information is from the 0.99a prerelease notes in batari's blog:

 

playfield command - specify entire playfield at once:

playfield:
(syntax: playfield: <off> <on>
<off> and <on> are optional. they specify the symbols to use for on or off for pf blocks. Default:. and X
example:
  playfield:
  X.X...X..XX..X.XX.X....XX..X.X..
  X.X....XX..X.X..X.X...X..XX..X.X
... etc.

So if you want to use lowercase x instead of uppercase X, you would do the following:

 

  playfield: . x
  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
  x..............................x
  x..............................x
  x..............................x
  x..............................x
  x..............................x
  x..............................x
  x..............................x
  x..............................x
  x..............................x
  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

The other problem is that you specified only 28 characters on each playfield row. I didn't try it, but I think it would have drawn the playfield if you'd just used uppercase X, or had specified what the off and on characters are, but the playfield probably would have come out differently than expected. If want to draw a playfield border using just the central 28 playfield positions, then you should pad the left and right sides of the rows with periods, as follows:

 

  playfield:
  ..XXXXXXXXXXXXXXXXXXXXXXXXXXXX..
  ..X..........................X..
  ..X..........................X..
  ..X..........................X..
  ..X..........................X..
  ..X..........................X..
  ..X..........................X..
  ..X..........................X..
  ..X..........................X..
  ..X..........................X..
  ..XXXXXXXXXXXXXXXXXXXXXXXXXXXX..

Michael

 

Fixed it! It's nice to see the playfield working now... sort of.

I'll still need to update the collision detection, but first, will need

to cut down on the sprite count because I just ran out of room.

 

I remember you touched the concept earlier, but what was that way you could use one sprite for two players? As I remember, it had something to do with "Labeling" the sprite, but I could be wrong.

 

 

PS -- I like the way the destroyed tank rematerializes!

 

Thanks!

Edited February 8, 2007 by Dragnerok X

[Dragnerok X]

Suddenly...

 

*thread is bumped hundreds of topics up whilst an old ENIAC computer under Albert's basement fills the floor with punch-card material whilst trying to process all of the information.*

 

I guess I've waited too long and have procrastinated too much on this game (mostly working on my website) that I almost forced *GASP!* myself to do this.

 

 

I really need (and am almost beginning to want) to work on this, so... here I am!

 

The first things I have to do are not only upgrading my kernel to the vastly superior bB 1.0 release, but most importatly, I need the release to work in the first place.

 

The problem is, I just set up bB 1.0 on my computer and am frustrated. I've set it in it's own folder with the newest version of 2600IDE and have the z26 emulator, my roms and my source in separate sub-directories within that folder. Also I've permanently set the environment variable to the main directory as seen on bataribasic.com. The thing is, even though bB goes through its little "compile sequence", it isn't compiling anything! I select a source file and no matter which one it is, it always displays the same amount of bytes left, not actually compiling the code. Then, once it hit "Run compile", if there is an already existing .bin file of the same name as the selected source in the folder, it will run, if not, it crashes.

 

Any ideas?

Edited March 27, 2007 by Dragnerok X

[SeaGtGruff]

I guess I've waited too long and have procrastinated too much on this game

 

I was just wondering last night if you were still working on this.

 

The problem is, I just set up bB 1.0 on my computer and am frustrated. I've set it in it's own folder with the newest version of 2600IDE and have the z26 emulator, my roms and my source in separate sub-directories within that folder. Also I've permanently set the environment variable to the main directory as seen on bataribasic.com. The thing is, even though bB goes through its little "compile sequence", it isn't compiling anything! I select a source file and no matter which one it is, it always displays the same amount of bytes left, not actually compiling the code. Then, once it hit "Run compile", if there is an already existing .bin file of the same name as the selected source in the folder, it will run, if not, it crashes.

 

If you're using 2600IDE, you'll need to fix the compile bat that 2600IDE uses. You can actually just use the regular bB 1.0 compile batch, but you need to copy that file to the name that 2600IDE uses. I was able to get 2600IDE working with bB 1.0, so I'll review everything and then post my setup for you to look at.

 

Michael

[Dragnerok X]

 

I was just wondering last night if you were still working on this.

 

 

I am, and I too was beggining to wonder.

 

 

If you're using 2600IDE, you'll need to fix the compile bat that 2600IDE uses. You can actually just use the regular bB 1.0 compile batch, but you need to copy that file to the name that 2600IDE uses. I was able to get 2600IDE working with bB 1.0, so I'll review everything and then post my setup for you to look at.

 

Michael

 

O.k. then, tell me what needs to be "fixed".

 

Or better yet, could you post your bB directory that I may tweak mine based on that?

Edited March 28, 2007 by Dragnerok X

[SeaGtGruff]

 

If you're using 2600IDE, you'll need to fix the compile bat that 2600IDE uses. You can actually just use the regular bB 1.0 compile batch, but you need to copy that file to the name that 2600IDE uses. I was able to get 2600IDE working with bB 1.0, so I'll review everything and then post my setup for you to look at.

 

Michael

 

O.k. then, tell me what needs to be "fixed".

 

I just copied the new 2600bas.bat to 2600baside.bat, but I had made a few changes to 2600bas.bat first. For one thing, I added the set commands for the new environment variables inside the batch file, and took them out of my system environment variables, so I can conceivably set up multiple installations of different versions of bB without them interfering with each other. I also adjusted the line spacing or command spacing (around the pipes and redirectors) a tad in some places, as well as changed the Unix "/" directory slashes to the Windows "\" directory backslashes. Anyway, this is my 2600baside.bat file:

 

@echo off

rem Change the next line to point to whatever your main bB directory path is!
set bB=C:\Atari2600\bB
set Path=%Path%;%bB%

if X%bB% == X goto nobb
if exist sed.exe goto havesed
if exist %bB%\sed.exe goto havesed
goto nosed

:havesed
preprocess.exe < %1 | 2600basic.exe -i %bB% > bB.asm
if errorlevel 1 goto bBerror
if X%2 == X-O goto optimize
postprocess.exe -i %bB% > %1.asm
goto nooptimize

:optimize
postprocess.exe -i %bB% | optimize.exe > %1.asm

:nooptimize
rem If you don't want to generate an assembly listing, remove -l%1.lst from the next line.
dasm.exe %1.asm -f3 -I%bB%\Includes -l%1.lst -o%1.bin | sed.exe "/Label mismatch/d" | sed.exe "/shakescreen/d;/rand16/d;/debugscore/d;/pfscore/d;/noscore/d;/vblank_bB_code/d;/PFcolorandheight/d;/pfrowheight/d;/pfres/d;/PFmaskvalue/d;/overscan_time/d;/vblank_time/d;/no_blank_lines/d;/superchip/d;/ROM2k/d;/NO_ILLEGAL_OPCODES/d;/minikernel/d;/debugcycles/d;/mincycles/d;/legacy/d;/PFcolors/d;/playercolors/d;/player1colors/d;/backgroundchange/d;/readpaddle/d;/multisprite/d;/PFheights/d;/bankswitch/d;/Unresolved Symbols/d" | sed.exe "2,/-->/!{ /-->/,/-->/d; }" | sed.exe "s/--> 0./Possible duplicate label: /"
rem yes, I know :) This is the first attempt to make DASM's output more useful!
goto end

:nosed
echo sed.exe not found.  Continuing without it.
pause
preprocess.exe < %1 | 2600basic.exe -i %bB% > bB.asm
if errorlevel 1 goto bBerror
if X%2 == X-O goto optimize2
postprocess.exe -i %bB% > %1.asm
goto nooptimize2

:optimize2
postprocess.exe -i %bB% | optimize.exe > %1.asm

:nooptimize2
rem If you don't want to generate an assembly listing, remove -l%1.lst from the next line.
dasm.exe %1.asm -f3 -I%bB%\Includes -l%1.lst -o%1.bin
goto end

:nobb
echo bB environment variable not set.

:bBerror
echo Compilation failed.

:end

 

I'm also attaching the file, but I had to add ".txt" to the end of it. Note that the attached version does not include the three remarks that are shown in the listing above, about changing the bB directory path and removing -l%1.lst (there is also a remark that's from batari). Save the attachment, remove the ".txt" extension so the name is just 2600baside.bat, put the file in your main bB directory, put the 2600IDE.exe file in your main bB directory as well, and edit the 2600baside.bat file so it sets the new bB variable to whatever directory path you're using. Also, you might want to create a shortcut to the 2600IDE program and give it the following properties:

 

Target: C:\Atari2600\bB\2600IDE.exe <-- Be sure to specify whatever directory you put bB 1.0 in.

Start In: C:\Atari2600\bB\Projects <-- Be sure to specify whatever directory you keep all of your bB programming projects in.

 

Michael

2600baside.bat.txt

[SeaGtGruff]

I forgot to mention, when you run 2600IDE, be sure you do *not* tell it to create a batch command file, because if you do, it will replace the new bB 1.0 batch file with the old bB 0.35 batch file.

 

Michael

[Dragnerok X]

I forgot to mention, when you run 2600IDE, be sure you do *not* tell it to create a batch command file, because if you do, it will replace the new bB 1.0 batch file with the old bB 0.35 batch file.

 

Michael

 

That's probably what I did wrong. Michael, quick question. I seem to be getting an error message of some kind in the command prompt window when it's run, but it disappears to fast to catch what it's saying. How do you take a screen capture in Windows?

 

Ignore that, I just got it to work. The problem was the fact that I had incorrectly set the enviornment variable earlier. Now, as it appears, my first "update" will need to be correcting the player x values.

 

So, at what value (number) does the new 1.0 release alter the x values?

 

BTW: Updated my avatar in celebration of my 500th post.

Edited March 28, 2007 by Dragnerok X

[Dragnerok X]

*Minor bump considered miniscule compared to the last occurs. This time, Albert's Colossus computer comes on and is only able to fill a jar with punch-card material. Albert grunts slightly whilst trying to pick up the last of the ENIAC's mess, kicks the thing, misses, and accidentally kicks over his precariously placed kerosene lantern. Too bad he decided to be environmental and powered his machines with propane canisters*

 

[+batari]

So, at what value (number) does the new 1.0 release alter the x values?

IIRC, it moves them 14 pixels to the right.

[Dragnerok X]

So, at what value (number) does the new 1.0 release alter the x values?

IIRC, it moves them 14 pixels to the right.

Okay, I'll make the correction. Just wondering, what lead to the horizontal push?