RPG Project

[ponlork]

Hello I'm new. First let me just say that I'm not very good at programming. I can do simple stuff just to get my ideas across, but when it comes to putting something elaborate together and making it run smooth, I'm very bad at that. I'm more of a visionary. Most of the programming I do is mostly from tinkering around with existing samples until I get something working to my liking. So if I come across very noobish or ask silly questions, please excuse me, thanks.

 

With that being said, for the past week I've been working on a homebrew for the Atari 2600. I'm not very familiar with the Atari, matter of fact I never owned one and I played my first Atari game a week ago through a emulator. However I'm growing a big interest in retrogaming. I feel that working with limitations bring out creativity and imagination and the thought of making something like a RPG on there is very exciting to me.

 

So here's the game I've been working on so far, it's not much but I plan to keep working on it. In the game I used a missile to represent a enemy. I was wondering is there a way to stretch it to make it wider? Or better yet, is it possible to manipulate missiles and turn it into a character? I also notice when I use no_blank_lines the missile is not visible. Is there any other ways to represent a character sprite on screen?

 

I got a ton of questions, but I'll ask them while I come across a problem XD

 

http://www.youtube.com/watch?v=Lr2SdcP2FMY

[+Gemintronic]

This web page is the holy grail of batari references - there are none higher:

http://www.randomterrain.com/atari-2600-memories-batari-basic-commands.html

 

You need to look up the kernel options and see which combination of settings is right for you:

http://www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#kernelopchart

 

Everything is a tradeoff. If you have two multi-colored sprites you lose the missiles. If you want a resized and multi colored playfield it is fixed for the rest of the game.

 

Uber 1337 assembly coders can make their own interpretations on how to draw the missiles. David Crane turned them into jungle vines in Pitfall!. batari BASIC just gives you the ability to reshape them via the NUSIZ and missilexheight variables. Basically, you are stuck with using them as rectangles. You can, however, change their shape every other frame to simulate a more complex shape.

[ponlork]

Thanks, I usually look up things only when I run into a problem. I'll check out those links. I have done a lot of reading on those topics before, however it's pretty difficult for me to grasp things. I'm not very smrat. I can read it a thousand times but I probably won't get it until I do endless trial and error and actually get something working XD

 

A rectangle shape would be awesome. I notice a missile0height thing, but not one for width. Do you know how to make it into a fat shape in Batari Basic?

I'm just barely beginning to understand kernels, I was stumped in that for a while. I didn't realize what it was, or that there were trade offs. Not until I tried using the multisprite kernel and notice a lot of things stopped working.

 

Speaking of kernels, is it possible to switch kernels within the same game? I highly doubt that's possible. I'm also having difficulty with this Title_screen kernel that i downloaded from here,, i forgot who made it but I can't seem to load the multisprite kernel with it :/

 

I'm still not entirely sure what NUSIZ, i assume it has something to do with creating duplicates. I'll read up on it when I need it.

Right now I'm in the process of rewriting everything over again. My first attempt was so sloppy, now I'm keeping a notepad of all my constants that are in use so I won't have to analyze it for hours

Edited October 14, 2013 by ponlork

[Cybearg]

Just wanted to say, that sprite looks great! Not sure how you managed it, unless you have the player1 and player0 sprites on top of one another to create the black outline. Still, really good use of the layered colors.

 

To make missiles wider, you'll need to use NUSIZ0 and NUSIZ1 to set up those parameters. Make sure that they are within your main game loop, as they get lost every drawscreen. You can have up to an 8 pixel wide missile.

[+Gemintronic]

NUSIZ0 and NUSIZ1 change the visual properties of the related missile and sprite. For instance, a NUSIZ0 set to $15 makes player0 twice as wide:

 

SpiceWare just made up some excellent slides in PDF format for a VERY easy to understand description of how the 2600 works

http://atariage.com/forums/topic/217671-spiceware-presentation-slides-now-online/

[ponlork]

NUSIZ0 and NUSIZ1 change the visual properties of the related missile and sprite. For instance, a NUSIZ0 set to $15 makes player0 twice as wide:

 

SpiceWare just made up some excellent slides in PDF format for a VERY easy to understand description of how the 2600 works

http://atariage.com/forums/topic/217671-spiceware-presentation-slides-now-online/

 

Woah that is neat. So much potential now. Can't wait to delve into it. Can the Nusiz also be used to create multiple enemies?

 

 

Just wanted to say, that sprite looks great! Not sure how you managed it, unless you have the player1 and player0 sprites on top of one another to create the black outline. Still, really good use of the layered colors.

 

To make missiles wider, you'll need to use NUSIZ0 and NUSIZ1 to set up those parameters. Make sure that they are within your main game loop, as they get lost every drawscreen. You can have up to an 8 pixel wide missile.

 

Aw thanks I made it myself yes that's pretty much exactly what I did. Before I even attempted programming the first thing I did was tinker around with the sprite drawing program in bB. Then I started to like what i see and when I get inspired I start to visualize things and it's difficult for me to stop haha.

 

Oh all this time Ive been putting the Nusiz0 outside the loop. I had no clue what it was meant for, I just followed some sample missile script from a guy on youtube. I'll mess with that next

 

If anybody's interested, I've attach a sample of the game. I finally got done rewriting everything. It was much faster this time around since I got my feet wet. My first attempt I didn't even know how to add comments so I knew it would be drastic if I try to move forward with a jumbo mess of code. I feel more comfortable moving forward now ^__^

 

There's not much at the moment, you may have to use your imagination. Pretty much it's just the basic navigation, and I implemented a battle system. And In order to proceed to the next level you must beat that creepy stalker guy twice, then in the 3rd playfield you will see a Motorcycle. The game ends there. My next attempt I'm going to try to make a racing sequence.

 

I think I would like to release the game in chapters. Then when I have enough content I'll combine them into one cartridge. That way I won't be stuck in development hell and I would feel less pressure. Plus I think it's a pretty cool concept, have a unfinished story, and keep adding more to it whenever I'm inspired. You know I bet the game would work great in Japanese, because Japanese people actually read text from top to bottom. So it won't feel awkward at all.

ponlork.bin

Edited October 15, 2013 by ponlork

[ponlork]

I finally understand what the NUSIZ is for haha I've also found out that there's a Ball function that I can use for an object too which is great. I was hoping we could stretch it wider though, I was going to use it for a bike but it's cool I think it's better if I just draw new sprites with the motorcycle and character sprites together.

 

Oh I also updated the game a bit, now if you get hit by the car, the character's spirit flies out of her body and you turn into a ghost XD that effect wasn't intentional, i just did a minor cock up on the code and i liked the way it turned out.

 

Also I got a question if i may. Is bankswitching necessary for us to code in VisualbB? Because it seems to automatically optimize it if I set the romsize. I'm not exactly sure, the whole bankswitching thing is still confusing to me. Sometimes I can get it to work, other times it's just a blank screen. But if I move it to bank 1 it seems to load fine.

ponlork.bin

Edited October 15, 2013 by ponlork

[Cybearg]

The 2600 can only access 4k of ROM at a time. Bankswitching basically starts you in one bank, then yanks it away and puts in another 4k bank, so the 2600 keeps working as if it was been reading from that second 4k ROM the whole time. In this way, you can make large games by switching from one 4k bank to the next. It all depends on how big your game is.

[+Gemintronic]

If you're OK with thick and chunky movements the you can use playfield blocks as the second color in your sprite. I did this in my game Candybar.

The pink in the Chefs face is a playfield pixel/block.

Also, every released game in my sig has source code. It's not "tutorial" material but maybe it would give you an idea of what can be done.

[ponlork]

The 2600 can only access 4k of ROM at a time. Bankswitching basically starts you in one bank, then yanks it away and puts in another 4k bank, so the 2600 keeps working as if it was been reading from that second 4k ROM the whole time. In this way, you can make large games by switching from one 4k bank to the next. It all depends on how big your game is.

 

Yeah I think I kinda get the concept. It's a bit tricky though. Initially I wasn't going to attempt this project because I thought 4k wasn't big enough. But then I started randomly watching Youtube videos of Atari homebrews and demos, and I started hearing about bankswitching. I'm still not entirely sure how it works but as long as it's possible to expand the memory, and play it on a actual Atari system then that's good enough for me

currently my game is around 6k I believe, theoretically speaking, what's the highest amount of memory I can push it to and get it to work on Atari 2600 hardware?

 

 

If you're OK with thick and chunky movements the you can use playfield blocks as the second color in your sprite. I did this in my game Candybar.

The pink in the Chefs face is a playfield pixel/block.

Also, every released game in my sig has source code. It's not "tutorial" material but maybe it would give you an idea of what can be done.

 

 

Yes I'm open to anything that can let me work around limitations XD that's one of the cool things about programming for the Atari, people have to find clever ways around restrictions. And I always find that fun. Thanks for the suggestion, I may have to use that later for secondary characters.

 

I actually used the playfield in conjunction with the ball in order to make the car. It was kind of a redundant task, but sometimes you just gotta do what you gotta do.

 

I might have some fun with this ghost mode thing, since it frees up the player1 sprite, i'll probably use it to make another ghost sprite telling her she's dead lol and then she has to find a way to get resurrected. Most of the things i do is completely on the fly, i dont plan anything i just go along with it.

Edited October 16, 2013 by ponlork

[+Gemintronic]

This is just an opinion. Here is how I see the combat screen set up:

 

* Both players for the character sprite.

* Resized playfield blocks for the enemy sprite

* Use the missiles and ball to create the action icon in the center.

 

The flicker is pretty heinous. Though you really did a creative job implementing it

[ponlork]

Thanks for the suggestion. Yes as of right now, everything is really atrocious. However I'm more trying to give a visual of how I would like my game to be like, so people can kinda sorta get an idea. When I get the core mechanics down, I think rewriting and embellishing later is not as difficult. There's a slew of things that I want to include that I haven't even touched yet. I still don't know what .asm is, or how to use the bottom portion to make fonts. I'll figure it out later.

 

I'm definitely going to revamp the battle system. I'm currently using player0 to do 4 cycles of animation lol I have player1 free, I might change it so it only flicker once. The concept of cycling frames was still new to me, I thought up a temporary solution to do that because the multisprite kernel didn't work for what I was trying to accomplish.

 

But now I'm reading a thread about using multikernels in the same game, and man that got me excited. I just may have to rewrite my entire code all over again haha i just wish I had more time to experiment with all the different functions. It'll probably take me at the end of the competition of my game, until i realize what i can do, and then I'll probably try to rewrite everything over again. Or maybe when I'm done, I can assemble a group of more qualified people to enhance it. There's only so much i can do. Like i said, I'm more of a visionary. I'm a horrible programmer. And I have no aspirations of becoming one.

 

I'm thinking about switching the game to more of a dark tone. I might make the car accident scene more gory. Then when she's in the spirit form, i'll start using the player1 to draw dead people and a grim reaper haha

[+Gemintronic]

VisualbB has a score font editor. You just gotta remember to back up your original score_graphics.asm.

 

.asm files are the "real" assembly code batari BASIC generates. When you program in BASIC the code gets translated into assembly along with a game engine also in assembly called the "kernel". The kernel manages how stuff looks on the screen. There are also assembly based libraries like pfhscroll.asm that adds faster and more fine grained horizontal scrolling.

 

Just to reiterate: when you set your kernel options you are actually choosing which base game engine batari BASIC uses for your game

[Cybearg]

And to answer your earlier question, you can have up to 64k on a ROM if you use the standard or multisprite kernels. 32k if you use DPC+.

[ponlork]

VisualbB has a score font editor. You just gotta remember to back up your original score_graphics.asm.

 

.asm files are the "real" assembly code batari BASIC generates. When you program in BASIC the code gets translated into assembly along with a game engine also in assembly called the "kernel". The kernel manages how stuff looks on the screen. There are also assembly based libraries like pfhscroll.asm that adds faster and more fine grained horizontal scrolling.

 

Just to reiterate: when you set your kernel options you are actually choosing which base game engine batari BASIC uses for your game

 

Ahh I see. I was going to ask about that. I did try to modify the score graphics once. But when I went to Score Editor, it would say Not a Valid Score Graphics ASM file. At first I thought it was a software bug, but now I believe I may need to have a asm file in my projects directory.

 

I took a glance at the assembly code, I am so glad there's a batari compiler because there's no way in hell I would have even attempted that XD it's like writing on punched tape or something. I can see why it was so difficult for programmers to make decent games for the Atari back then.

 

I'll probably never fully comprehend all the internal workings and capabilities of it, but it's cool I'll just get by with what I can do right now lol I mainly want to create a Atari game that has actual plot and lots of dialogue, which is something I never seen on a Atari game. That's one of the things that motivated me to make one, I grew up on the NES era and back then, RPGs weren't as prominent in the states. As a NES owner back in the day, i had a lot games that lack depth and i would sometimes fantasize there being some ultra secret code to make the game more Vast where you go outside the boundaries of the game XD but that's kinda like how I imagine Atari. People don't expect a epic adventure, but I'm sure many back then wished they had games like Princess Rescue on it growing up.

 

 

And to answer your earlier question, you can have up to 64k on a ROM if you use the standard or multisprite kernels. 32k if you use DPC+.

 

Man that is crazy. The Atari 2600 is really exceeding my expectations of what it's capable of. It's quite amazing for 70's technology. I'll probably limit mines to 16k for now, and if I go over the limit, I'll increase the size haha. It'll be so awesome if I can get it run on a actual 2600. I should probably purchase the system soon.

 

I just recently realized the Atari only has 1 button. But I saw in Princess Rescue that it's possible to use two buttons with a Genesis controller. Does anybody know how that works?

[+Random Terrain]

I just recently realized the Atari only has 1 button. But I saw in Princess Rescue that it's possible to use two buttons with a Genesis controller. Does anybody know how that works?

 

randomterrain.com/atari-2600-memories-batari-basic-commands.html#2buttons

[ponlork]

 

randomterrain.com/atari-2600-memories-batari-basic-commands.html#2buttons

 

Wow that is great to know if I want to take my game further. I'm not exactly sure how it works, but I assume it's using a rapid fire method to detect a different input? Well as long as it's possible. Maybe it's possible to create 3 buttons with extra combinations haha that's actually the idea I had in mine for my game. I might make the Menu access by using button input combinations.

 

Speaking of the fire button, I notice in some code I would see something like "joy0fire !l" what the hell is that exclamation point at the end? One day I'll dig deep into researching it but right now I'm just a tad curious.

[+Random Terrain]

Speaking of the fire button, I notice in some code I would see something like "joy0fire !l" what the hell is that exclamation point at the end? One day I'll dig deep into researching it but right now I'm just a tad curious.

 

I'm guessing that you saw something like this:

__

   if !joy0fire then goto __Tasty_Pilgrim

__

The ! stands for NOT.

 

You might want to check this out:

 

randomterrain.com/atari-2600-memories-batari-basic-commands.html#joysticks

[ponlork]

 

I'm guessing that you saw something like this:

__

   if !joy0fire then goto __Tasty_Pilgrim

__

The ! stands for NOT.

 

You might want to check this out:

 

randomterrain.com/atari-2600-memories-batari-basic-commands.html#joysticks

 

Oh okay. all this time I've been working with only && XD it's nice to know that there's a NOT command. I was wondering is this is like a "Does not Equal" command. like "If this does NOT equal that than do this"? I used to mess with LUA and I always found that handy. in Lua it was ~= I believe.

 

Also another thing that I was wondering about, should I use gosub instead of goto for retrieving frames from other banks? Because at first I used goto frame1 bank 2 but after doing that too much, it would just turn into a black screen. But if I use gosub it would work. I read something about gosub once but I think it said that it takes up 2bytes so I assume using it will eat up memory so I just avoid it.

 

Thanks for the help. Told you I'm pretty clueless lol darn it's midway through Oct and I'm broke. I may have to put this project aside for a few weeks until I raise money for rent. I should move back in with my mom, I would have all the free time and creative freedom in the world haha but nah I gotta be responsible.

Edited October 16, 2013 by ponlork

[bogax]

if !joy0fire then

 

is equivalent to

 

if joy0fire = 0 then

 

but uses slightly less code and takes slightly less time.

 

 

actually joy0fire is true if joy0fire is 0

and

 

if joyfire = 0

 

will give you an error

 

 

it would actually be

 

if !joy0fire

 

is equivalent to

 

if INPT4{7}

 

INPT4{7} is joy0fire

 

 

if !x

 

is equivalent to

 

if x = 0

Edited October 16, 2013 by bogax

[+Random Terrain]

Also another thing that I was wondering about, should I use gosub instead of goto for retrieving frames from other banks? Because at first I used goto frame1 bank 2 but after doing that too much, it would just turn into a black screen. But if I use gosub it would work. I read something about gosub once but I think it said that it takes up 2bytes so I assume using it will eat up memory so I just avoid it.

 

A black screen is usually caused by a screw up in the code, not because goto was used instead of gosub. The main reason people use gosub is so different parts of a program can share the same chunk of code.

 

If a program is large enough to be spread out over multiple banks, instead of having a main loop in one bank that does a bunch of goto-ing and gosub-ing to other banks, it's better to use goto to continue the main loop from bank to bank and have frequent goto-ing or gosub-ing happening within each bank. Since jumping to another bank uses up a lot of time, keeping the frequent jumps within a bank will save time.

[ponlork]

if !joy0fire then

 

is equivalent to

 

if joy0fire = 0 then

 

but uses slightly less code and takes slightly less time.

 

 

actually joy0fire is true if joy0fire is 0

and

 

if joyfire = 0

 

will give you an error

 

 

it would actually be

 

if !joy0fire

 

is equivalent to

 

if INPT4{7}

 

INPT4{7} is joy0fire

 

 

if !x

 

is equivalent to

 

if x = 0

 

hmm I normally just put if joy0fire haha so how many inputs are there for joy0, is it just 0 and 1? and does 1 represent when the joy0fire is in use? if so, I can see how that can come in useful.

 

 

 

A black screen is usually caused by a screw up in the code, not because goto was used instead of gosub. The main reason people use gosub is so different parts of a program can share the same chunk of code.

 

If a program is large enough to be spread out over multiple banks, instead of having a main loop in one bank that does a bunch of goto-ing and gosub-ing to other banks, it's better to use goto to continue the main loop from bank to bank and have frequent goto-ing or gosub-ing happening within each bank. Since jumping to another bank uses up a lot of time, keeping the frequent jumps within a bank will save time.

Now that I think about it, last night I recently updated VisualbB 1.0 from Build_554 to Build 566 because the ImgtoCode program in build 554 didn't work with the Titlescreen kernel I was experimenting with. And in the new build it would give me a warning error that I had a extra "End" in there. So that might have been the cause for the black screen. The Sprite Editing program is much better in the new build also, the old one had a scrolling bug which was quite frustrating. Is there a reason why build 566 isn't featured on the main page of the Visual bB 1.0 thread? I assume all those links were up to date.

Anyway, speaking of Titlescreen, I finally started messing around with it. Is it possible to use any of those functions in game? There was one function that I really like, and it was the animation example where it acts like a Sprite sheet. Is it possible to only display part of a Sprite? That would really come in handy for animation.

I think I'm going to try to release one more update before I go on hiatus. I hope to make this one worthwhile.

Edited October 17, 2013 by ponlork

[bogax]

 

 

hmm I normally just put if joy0fire haha so how many inputs are there for joy0, is it just 0 and 1? and does 1 represent when the joy0fire is in use? if so, I can see how that can come in useful.

 

 

I don't know what the other bits of INPT4 read

I think the only thing of use is bit 7 ie INPT4{7}

bit 7 will be 0 if joy0fire is pressed and 1 if not.

 

[Cybearg]

The ! not is useful for any command, but in the case of joy0fire, it is checking for whether a bit is zero or one.

 

In non-bitwise cases, ! means "is zero" and without the exclamation means "is not zero." For instance:

 if variable = 0 then...

Could be written as:

 if !variable then...

Likewise, this:

 if variable > 0 then...

can be written as:

 if variable then...

This is necessary for bitwise operations (when you're checking individual bits to see if they're on or off), but it's also a more code-efficient way to check a variable's zero/not-zero status and I believe it can be used in expressions as well, such as:

 if !(variable > 5) then...

... though sometimes that may lead to compilation problems, so it's always best to use the most straightforward logic necessary to do things. in this case, !(variable > 5) would be more easily written as variable <= 5

 

In bit operations, like with the joy0fire thing, the bit can only be true or false, hence the "joy0fire" for true and the "!joy0fire" for false. The code is actually checking a single bit in a byte that it receives from the controller.

 

There are, likewise, bits for up, down, left, right, select, reset, color/BW, left difficulty, and right difficulty, plus up/down/left/right/fire for joystick 1, all of which can be programmed to do whatever you like. If you really wanted, you could have your game controlled by the reset/select/difficulty switches and have both joysticks do absolutely nothing. The only switch on the 2600 you have no control over is the power switch.

 

And for reference, a "not equals to" sign would be:

 if variable <> 5 then...

... As opposed to the C-style !=, which doesn't work in BASIC.

Edited October 17, 2013 by Cybearg

[+Random Terrain]

Is there a reason why build 566 isn't featured on the main page of the Visual bB 1.0 thread? I assume all those links were up to date.

Anyway, speaking of Titlescreen, I finally started messing around with it. Is it possible to use any of those functions in game? There was one function that I really like, and it was the animation example where it acts like a Sprite sheet. Is it possible to only display part of a Sprite? That would really come in handy for animation.

I think I'm going to try to release one more update before I go on hiatus. I hope to make this one worthwhile.

 

 

I think jwierer said once that he doesn't like to update that thread often because he doesn't want to wear people out with updates, and on top of that, the latest version of the moment could have a bug or bugs. I personally wouldn't mind if he had an update every day. I'd download it and use it. We can always post bug reports in the thread.

 

That's one of the reasons why the Visual batari Basic Guide is so far behind in describing the latest features. Jwierer will add something cool, but I can't mention it on the VbB page until the latest version of the program is released, but it usually won't be released for weeks or maybe even a month or more, then I won't remember what needed to be added to the page after it is finally released.

 

 

 

 

Anyway, speaking of Titlescreen, I finally started messing around with it. Is it possible to use any of those functions in game? There was one function that I really like, and it was the animation example where it acts like a Sprite sheet. Is it possible to only display part of a Sprite? That would really come in handy for animation.

 

Somebody else will have to answer those questions.