Fort Apocalypse
-
Content Count
1,599 -
Joined
-
Last visited
Posts posted by Fort Apocalypse
-
-
Here's the full sourceYou need to place includes before anything else. Particularly, if you put them after the "set" directive, they might be ignored. Hmmm.... Maybe I should have the compiler generate a warning instead?
Thanks! That was definitely it. Yes, it would be great to have a compiler warning if it's not too hard. The more compilation warnings the better, IMO.
-
0.4 release
For one or two players.
Dragon and Eye are enabled and attack and can kill you. You can kill them with the staff. Rooms make sense (somewhat) and there is somewhat of a map. Two castles. No point to game yet except to kill dragons and floating eyes with staff.
What do you think? All ideas are welcome!
-
This is great!
BTW - I love moon patrol! I'm not sure what a scrolling/jumping shooter would look like with this, but it would be interesting for sure. I think that having things run at you from the sides and having to jump over them, or having to jump from platform to platform and retrieve something would be cool. This reminds me a little tiny bit of Dark Castle (because of the bats and the cave). Boy Dark Castle would be neat to bring to the 2600.
I just played it and had these thoughts:
* I also experienced the deal with not being able to shoot the bat when it was too close, but it wasn't a big deal (In real life if a huge bat were that close, I'd be a little distracted and have a harder time shooting it, but some may make the opposite argument that it would be easier to shoot.)
* When I wasn't using the shield and touched a bat I thought I'd die, but I didn't. It might be better to die and have a life counter instead of health?
* If the bats either dropped their bombs when they were closer to you and if their bombs could drift toward the player, that would make it a little more difficult.
* It might be better if the player could move just a little faster (but not much).
* I think replacing some bats with more bats might be good. So something like if you kill a bat, more bats appear until you've killed like 20 bats. Having bats drop down from the ceiling would be cool.
-
0.3 released. slip through walls bug gone, wand makes you teleport, more rooms. no monsters yet.
-
Just curious if anyone is currently still working on this project at Atari, whatever it will be called.
I'm guessing that it isn't dead yet, and I know we are in radio silence mode, but there was all that hubbub a couple of months back, and just want to make sure all is relatively ok and still on track for Spring 08 (even if there was a slip I won't complain). -
-
I've also tried including both in the top:
include div_mul.asm
include div_mul16.asm
and then I get the error:
---------- Capture Output ----------
> "C:\Atari2600\bB\2600bas.bat" C:\Atari2600\projects\fmadventure\2padv0.3.bas
2600 Basic compilation complete.
DASM V2.20.07, Macro Assembler ©1988-2003
bytes of ROM space left
--> cycle74_HMCLR f084
> Terminated with exit code 0.
-
Hey,
I'm doing the following at the top of my bB game:
include div_mul16.asm
and then at one point I do this:
handleroom
temp6 = proom // 10
rem *** remainder (last digit) stored in temp1
if temp1 = 1 then gosub room1
if temp1 = 2 then gosub room2
if temp1 = 3 then gosub room3
if temp1 = 4 then gosub room1
if temp1 = 5 then gosub room2
if temp1 = 6 then gosub room3
if temp1 = 7 then gosub room1
if temp1 = 8 then gosub room2
if temp1 = 9 then gosub room3
if temp1 = 0 then gosub room1
return
when compiling I get the following error. Can anyone see what I'm doing wrong? I want to get the remainder of dividing proom by 10 in order to get the last digit of that number (for now it is just as proof of concept).
---------- Capture Output ----------
> "C:\Atari2600\bB\2600bas.bat" C:\Atari2600\projects\fmadventure\2padv0.3.bas
2600 Basic compilation complete.
DASM V2.20.07, Macro Assembler ©1988-2003
bytes of ROM space left
--> cycle74_HMCLR f084
914 bytes of ROM space left
914 bytes of ROM space left
914 bytes of ROM space left
--- Unresolved Symbol List
div16 0000 ???? (R )
Fatal assembly error: Source is not resolvable.
> Terminated with exit code 0.
-
Thanks, Robert! This is really good info!
-
I'm trying to make a game where Daffy Duck is running around trying to catch a diamond. Of course, you control the diamond and poor Daffy needs some AI. Also, I'm using a Superchip and set const pfres to 32, but apparently you can't use pfcolors with it, as this is the result:
So, basically, I'd like some help here.
From removing pfcolors I noticed that it appears that the following is occurring:
* if pfres is 32 then rows 1-21 (0 based) are being skipped for assignment by pfcolors
* if pfres is 31 then rows 1-20 (0 based) are being skipped for assignment by pfcolors
* if pfres is 30 then rows 1-19 (0 based) are being skipped for assignment by pfcolors
...
(skipped a bunch)
* if pfres is 15 then rows 1-3 (0 based) are being skipped for assignment by pfcolors
* if pfres is 14 then rows 1-2 (0 based) are being skipped for assignment by pfcolors
* if pfres is 13 then row 1 (0 based) is being skipped for assignment by pfcolors
So pfres 12 is the best you can get away with. You'll also want to fix the x, y limits on daffy since he loses his eyes if he overlaps to the left too much.
Looks neat! I think if you wanted to you could get by without any AI and just have daffy pick up diamonds and have to watch out for traps (flying pies, etc.).
-
This is totally awesome! The collision detection is great and bat swooping!
-
Actually I think maybe I'm going over the gosub limit. Batari said on Random Terrain's page that only 6 bytes are there for the gosub stack.
Update:
Robert was right. If anyone ever gets a black screen during the game and can't figure it out, look for somewhere in the code where you are doing something like:
if gamebits{0} then gosub handlep1 else chkexitp0
instead of
if gamebits{0} then gosub handlep1 else gosub chkexitp0
(it was missing a gosub, so when it did a goto to that tag, it would return once more than necessary)
-
For the colors question look at this (under colors):
http://www.randomterrain.com/atari-2600-me...c-commands.html
To use curtis's minikernel put his file in the "includes" directory under your "bB" directory (the batari basic directory, not the directory with your code in it). In other words, unzip the playerscores.zip and put the .asm files into that dir.
Then at the very end of your game's source file (game.bas) put these lines in: (indent them all by at least one space, don't use tabs for ident, because it messes up bB in version 1.0)
rem should be last lines in game
inline playerscores.asm
inline bcd_math.asm
(note: the bcd_math stuff just makes it easier to add to the score)
Then up above in the code you'll want to initialize the score to 00 (although it should start as 00 anyway) for each player and set the scorecolor:
player0score = $00
player1score = $00
player0scorecolor = 0
player1scorecolor = 222
then use the following code to add 1 to the score (example):
player1score = addbcd(player1score, 1) : rem Adds 1 to player1score
-
For the colors question look at this (under colors):
To use curtis's minikernel put his file in the "includes" directory under your "bB" directory (the batari basic directory, not the directory with your code in it).
Then at the very end of your game's source file (game.bas) put these lines in: (indent them all by at least one space, don't use tabs for ident, because it messes up bB in version 1.0)
rem should be last lines in game
inline playerscores.asm
inline bcd_math.asm
(note: the bcd_math stuff just makes it easier to add to the score)
Then up above in the code you'll want to initialize the score to 00 (although it should start as 00 anyway) for each player and set the scorecolor:
player0score = $00
player1score = $00
player0scorecolor = 0
player1scorecolor = 222
then use the following code to add 1 to the score (example):
player1score = addbcd(player1score, 1) : rem Adds 1 to player1score
-
Rob,
Thanks!!! That is awesome info!
-
Can anyone see why the screen is going black after game is started? Also, I'm ready to jump into ASM land if it helps me debug this stuff myself. If you can light a candle for the darkness about how you would go about figuring this out step by step it would really be helpful to me and probably a lot of other bB programmers.
Also I have noticed that the multisprite kernel is not very forgiving when it comes to compilation. A lot of times you have no idea there is an invalid param name or similar, like when I named a param pfroom instead of proom in a conditional - it didn't say anything during compilation indicating that it was a bad var name. Would be nice if that could be a little better in the next bB version if that is possible.
Finally I know I've started up a number of threads on this already, but there is something wierd about playfield collisions both in standard kernel (as I noticed when rewriting sprites in Ultimate Indy 500 that basically made me frustrated enough to quit it for a while) and in the multisprite kernel (in the 2 player Adventure game I'm working on below). It would be really nice if someone at some point could take a look at those also and if those are bB bugs to maybe fix those in a future release also (odds are it is something I'm doing wrong, but I can't see what it could be so I'm leaning toward bB bug for both of those).
TIA!!!
-
Probably just stating what you already know, but you will need to do something after the collision so they don't keep colliding. Something good to do might be to offset the x and/or y coordinate(s) of one or both of the players enough so that after a collision is registered, they will not keep colliding.
Like Michael said, since you only have two players, the most efficient way of doing this easily in bB is via setting a bit in one of the params. If you are playing traditional tag then one or the other player is "it" and whenever there is a collision you could change who is it if you are defining the first bit in the variable a to be that flag by doing the following:
a{0} = !a{0}
That basically just flips the first bit of the variable a.
Then you can check that bit and highlight the player to indicate which is "it" if you wanted like:
if a{0} then (change player0 to light blue and player1 to dark red) else (change player0 to dark blue and player1 to light red)
For collisions then you could do:
if collision(player0,player1) then player0x = player0x - 5 : player1x = player1x + 5 : gosub handlepoints : a{0} = !a{0}
and then define handlepoints like:
handlepoints
if a{0} then (add point for player0) else (add point for player1)
return
Later on you might want to take a look at the player scores minikernel by curtisp. That will let you show two two digit scores in the color of each player.
Good luck!
-
Ok, I forgot there is no pfpixel in multisprite so no shovel for now. Two items both have actions now:
* Wand of Izgborsh - widespread mayhem
* Staff of Grobazz - shoots magical burst of energy
Thought that would be more interesting than a gun, and slightly less violent
No monsters yet... that will be next
-
Maybe on a different level might be to have the adventurer have to leap from "floating" island to island. If you did that maybe to fire (up) you would have to point up while you pressed the button. It could be a little like joust, except with the flying bats/demons and no ostriches or eggs. And you could propel yourself upwards with a shield. Just an idea.
-
Only suggestions so far would be to use a life counter for lives and health counter for the "shield left" (if you are doing this in bB). And some sort of big boss at the end that you have to keep hitting to kill it.
-
That looks awesome!!! MausBoy taught me you could use Alt-P and F12 to take screenshots when there is a little flicker just so everyone else can see a glimpse, but I recommend everyone taking a look!
-
Something else that would be nice is an example of how to handle sprite2-5 collision detection when using multisprite kernel. This is how I just did it, but it would be nice if someone could post what they think to be the best solution:
findclosestp0
closestitemnum = 0
templowdistance = 255
tempitemx = shovelx : tempitemy = shovely : tempitemroom = shovelroom : gosub gettempdistp0
if !p0inventory{0} && tempdistance < templowdistance then templowdistance = tempdistance : closestitemnum = 1
tempitemx = gunx : tempitemy = guny : tempitemroom = gunroom : gosub gettempdistp0
if !p0inventory{1} && tempdistance < templowdistance then templowdistance = tempdistance : closestitemnum = 2
return
gettempdistp0
if tempplayerx > tempitemx then tempdistance = tempdistance + (p0x - tempitemx) else tempdistance = tempdistance + (tempitemx - p0x)
if tempplayery > tempitemy then tempdistance = tempdistance + (p0y - tempitemy) else tempdistance = tempdistance + (tempitemy - p0y)
if tempitemroom <> proom then tempdistance = 255
return
-
A few I learned that weren't on:http://www.randomterrain.com/atari-2600-me...c-commands.html
Thanks. I wonder if no paddles with the multisprite kernel will change with the next update.
That would be great! Curtis said it wouldn't be possible to hack it with the current multisprite kernel in this post. But if the multisprite kernel could be changed somehow to allow it, it would be awesome.
-
A few I learned that weren't on:
http://www.randomterrain.com/atari-2600-me...c-commands.html
for bB 1.0 were:
Paddles:
* there is no way to use paddles with multisprite kernel (according to Curtis it isn't even hackable with the current kernel)
* to check paddle button 0, use: if joy0right ...
* to check paddle button 1, use: if joy0left ...
* to check paddle button 2, use: if joy1right ...
* to check paddle button 3, use: if joy1left ...
Hacks:
I was shown by Michael that you can get 12 rows of vertical resolution in the playfield with the regular kernel by doing the following immediately after defining the playfield:
pfscroll upup : pfscroll upup
However, the caveats are (1) I'm not sure that it continues to work if you mess with pfscroll some more and (2) if you redefine the playfield (even if you are just setting it again to what it is currently) you should NOT call pfscroll up : pfscroll up, otherwise every other time the playfield AND score will be shifted up a bit. To get around this, I was told (and just tested this) that you can just do pfscroll up : pfscroll up once after the first playfield definition, and then set a bit and check it whenever you redefine the playfield so that you won't call pfscroll up : pfscroll up for subsequent playfield redefinitions. Example:
(be sure to define some variable up top, for example I've called it "myvariable")
playfield:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
X..............................X
X..............................X
X......X.....XXXXXX.....X......X
X......XX..............XX......X
X......XXXXXXXXXXXXXXXXXX......X
X......XXXXXXXXXXXXXXXXXX......X
X..............................X
X..............................X
X..............................X
X..............................X
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
end
if !myvariable[0] then pfscroll upup : pfscroll upup : myvariable[0] = 1
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
2 Player Adventure
in batari Basic
Posted · Edited by Fort Apocalypse
Here it is! "Finished".
Am too low on space to fit baby dragons in at the moment, but if you can help me find space, I'll add them in as well as ability to reset the game and a better win reward (currently you get death)
2padv0.5.bas2padv0.5.bas.bin