Full-Width Playfield?

[MausBoy]

Is there any way to stretch the playfield so that it takes up the entire width of the screen? It looks like there are 3 columns on each side that can't be used. I have been working on a few games that have really nice backgrounds, but the effect is ruined when scrolling playfields pop up and dissapear an inch into the sides. I know I can use PF0 = 255 to block out those parts of the screen, but that just sucks.

 

Can this be changed by altering the kernel? If so, does anyone know how, or which files and what parts of them I would need to work on to do it? I don't mind if it makes all the playfield blocks wider.

 

If it can't be done to the standard kernel, is it something that could be achieved using the superchip's extra ram?

 

I really appreciate any help anyone can give on this subject, it's something that has really been holding back a few of my better games.

[jbanes]

Is there any way to stretch the playfield so that it takes up the entire width of the screen? It looks like there are 3 columns on each side that can't be used.

Four, actually. And no, it's probably not feasible. (At least not unless you know what you can give up.) The PF0 register has to be updated before the first pixel is displayed. BBASIC, however, currenly uses that time for several other things. Updating PF0 would normally not be such a big deal, except that bBASIC has an asymetrical playfield.

 

What that means is that bBASIC has to be carefully timed to update each side of the screen, making the kernal all that more difficult to cram stuff into. Not only that, but right now you're getting 8 playfield blocks for each byte of RAM. Support for PF0 would get you only 4 blocks per byte, meaning that you'd have to waste about 22 bytes of memory to fill those 4 columns on either side.

 

I have been working on a few games that have really nice backgrounds, but the effect is ruined when scrolling playfields pop up and dissapear an inch into the sides. I know I can use PF0 = 255 to block out those parts of the screen, but that just sucks.

I'm not quite sure what the issue is? Perhaps you could post an example of the specific issue you're seeing?

 

If you're getting a bit of bleed into the sides (not sure how that would work?) you can use the ball (and/or a missile) to cover that area. As long as it's the same color as the background, it will effectively make that area disappear.

 

If you mean that you can move sprites into that area, I highly recommend that you limit them at the border. As long as nothing ever goes out of the playfield area, the player won't even realize that there are black bars on his screen. Games like Pitfall II and A-VCS-Tec use this to good advantage.

 

If it can't be done to the standard kernel, is it something that could be achieved using the superchip's extra ram?

Quite possibly, yes. If you don't mind wasting the RAM and rewriting the kernal a bit, it could probably be done.

[MausBoy]

The issue I am referring to is that the background extends to the edges of the screen, while the playfield does not. So if a game scrolls left/right or right/left, it looks like playfield elements pop onto the screen an inch in, and dissapear before reaching the other edge. I know that I can use the PF0 = 255 command and create a border that sprites can't move into, but it makes the screen much smaller and it dosn't look nearly as nice; plus with a low res screen I need all the space available not just the middle of it.

 

It's good to know that it could probably be done with the extra ram, but without someone willing to help or at least point me in the right direction I wouldn't know where to start.

[jbanes]

The issue I am referring to is that the background extends to the edges of the screen, while the playfield does not.

I think I understand. You're saying that you have a background color other than black, which means that the areas around your game become noticable? I could see that being an issue. Unfortunately, the solution would probably be dependent on the game. Even a few screenshots with an explanation of what sprites/missiles/balls/bBASIC features you're using could help us devise a solution for you.

 

BTW, since you're bumping into bBASIC limitations, have you considered getting into assembly? You don't have to leave bBASIC entirely behind (it's pretty easy to integrate the two by modiying the bBASIC includes), but you probably need more power than the standard kernals can offer you.

[MausBoy]

I've thought about getting into assembly, but I haven't even completed a bB game yet. I've tried to learn 6502 assembly more than once in my life, it's not fun for me. I have always had ADD, so trying to do something that tedious that I don't find fun is pointless. I was hoping I would slowly but surely learn it by example while using bB, but people don't do a lot of integrating the two and then discussing it openly, besides MR.

 

I don't have the ball, or either missile to work with in the game I'm most wanting to apply this to. It's a horizontal scroller, similar to balloon fight. Obstacles that scroll onto the screen are made up of pfpixels, so the only two options are cut off the sides or find a way to extend the playfield. Think super mario brothers, if the pipes and blocks suddenly appeared a few inches in with each step, instead of scrolling in from the edge.

 

I use the pfcolors/background option, so my backgrounds are things like sunsets over a green field, so the edges are extremely noticeable. i like the screen being wide and reaching the edges. I guess I can cut off the sides with PF0=255 but it would be so much nicer to have a full width game.

 

I might just have to hold out hope that MR will create something with his superchip code that uses the extra ram to create a full width playfield, because without a lot of help and guidance I don't think I could do it myself.

[jbanes]

I've thought about getting into assembly, but I haven't even completed a bB game yet.

What'choo talkn' 'bout, Willis? I've seen your work. It's good stuff. Just because nothing has been published yet doesn't mean that you haven't completed sufficient work. The fact that you're running into production quality issues tells me that you're more than ready to move on.

 

Most people would ignore a little glitch like this because nothing can really be done about it. You, on the other hand, are actively looking for a solution despite the fact that you know that bBASIC can't do it without heavy modifications. In fact, you've stumbled across the one flaw that pretty much every Rapid Prototyping Tool in existence has shared: They are limited.*

 

The dirty little secret is that you can't put out a professionally polished product using a Rapid Prototyping Tool alone. VB programs regularly require components written in C or C++, and bBASIC programs need some work done in assembly. Even the uber-simple (but still quite cool ) Solar Plexus needed custom work done before it was ready to head to a cartridge.

 

 

I've tried to learn 6502 assembly more than once in my life, it's not fun for me. I have always had ADD, so trying to do something that tedious that I don't find fun is pointless.

ADD? Sounds like life's way of making things interesting.

 

Tell you what. If you're just looking for an interesting assembly project capable of holding your attention, perhaps you'd like to help me complete a tech-demo I've been working on? I have a feeling that this demo is right up your alley.

 

It's a pretty simple and straightforward program, so I can explain every bit of it without too much trouble. I'd also be happy to explain any other assembly matters that you may have questions on. And if that isn't incentive enough, I will happily pay to have a vanity cart of it made for you once it's done.

 

Let me know.

 

mausboy.binmausboy.asm.txt

 

 

 

* In the case of bBASIC, Batari has stated that bBASIC's limitations are at least partly intentional. He wanted to lower the barrier to entry rather than replace the long-standing practice of coding in assembly. The result is that more folks are interested in 2600 development than ever before.

[MausBoy]

The dirty little secret is that you can't put out a professionally polished product using a Rapid Prototyping Tool alone.

 

You underestimate how badly I want to do just that. It's just unfortunate that with every project I've had so far, everything falls into place except for one limitation that stops everything dead.

 

With Our World Wins it was running out of cycles in huge amounts;

With Save Yourself! it was a lack of variables (maybe I should go back to this first project now, superchip-equiped eh?);

With Matario it was lack of multiple sprites on the same scanline;

With Blob it was not being able to do color sprites AND use the missiles;

With Marble Mission it was horrid collision detection routines;

With Maus To The Rescue it was lack of variables and playfield table rom space;

With Project Eden it was an inability to manage rom space and fit all my sprites in bank 4;

 

With Jelly Baby it's the way the screen is cut off at the sides if you want to use scrolling playfields.

 

This time, and every other time, I honestly thought I was developing something that would work within bB's limitations, until that smack-your-forehead moment when I realised what was completely missing something simple. I'm going to try ONE more time to achieve something completely fun and playable using only bB though.

 

I've been itching to do an Adventure type ball-as-hero game, and those sure are cake with bB. I'm stumped on why it was ever called 'the firefly construction set', it's seems to me that the first thing people would have thought of when they saw what bB does easily is Adventure. So, I'm going to put together one of those, only with an RPG style turn-based battle system (thanks to the new superchip variables). While I'm working on it, I'll explore what assembly can do for me. That way I can take breaks from the disgusting hard stuff to work in bB, which is actually fun.

 

I was surprised when I opened mausboy.bin, I wasn't expecting what it was. I read through the source, I can tell what each part does and what the instructions are for. I could probably add the final animation frames, but I wouldn't even know how to mirror everything for the second half of the animation. It would be cool to include that as part of the intro to every game I release. Thanks for putting the time and effort into it, and commenting the source. It does seem like a good program to learn how to do some things with. I think large 3-d rotating sprites are a new thing on the VCS, aren't they?

Edited September 20, 2006 by MausBoy

[jbanes]

You underestimate how badly I want to do just that. It's just unfortunate that with every project I've had so far, everything falls into place except for one limitation that stops everything dead.

There will always be a bBASIC limitation that you can't overcome. Why? Because you want to produce high-quality titles. The only way you can do that is if you get down to the metal.

 

With Our World Wins it was running out of cycles in huge amounts;

Cycles which could be reclaimed with highly efficient assembler, and/or coding tricks unavailable to bBASIC.

 

With Save Yourself! it was a lack of variables;

Technically, you've got 128 of them. bBASIC only provides 26 + a few temps. The rest are used on stuff that makes its rapid prototyping abilities possible, but are not required for a professional product. For example, the playfield in RAM is atypical of 2600 games. In most cases, it's far more efficient to use the playfield directly from ROM. That's 48 bytes right there.

 

With Matario it was lack of multiple sprites on the same scanline;

Well, there isn't too much that can be done there. You can flicker (obviously), and there are some interesting tricks like Andrew's Splatograph (I think that's what he called it) for multiple high color images.

 

With Blob it was not being able to do color sprites AND use the missiles;

With your own kernal, this can become possible again. Of course there are tradeoffs, but an application-specific kernal will often be superior to bBASIC's generic (but amazingly well written) kernal.

 

With Marble Mission it was horrid collision detection routines;

Now that one sounds solvable without asm. Are you thinking of revisiting it some point?

 

With Maus To The Rescue it was lack of variables and playfield table rom space;

Well, the variables again can be solved by using asm. As for the playfield, I actually have a bBASIC-compatible solution when using bankswitched cartridges. I developed it for Deimos Lander after I realized that the playfield data was required to be in the last bank. (Which wasn't very useful considering that I wan't to fit more levels.) If it's something you could use, let me know and I'll PM you my tool chain.

 

With Project Eden it was an inability to manage rom space and fit all my sprites in bank 4;

Not a problem with a custom kernel.

 

With Jelly Baby it's the way the screen is cut off at the sides if you want to use scrolling playfields.

Definitely not a problem in ASM.

 

Seriously, everything you've said comes out to be, "I'm ready to move to asm because I'm finding bBASIC too limiting." You just need to decide to take that step. I'll happily help out, as I'm sure will many others around here.

 

I was surprised when I opened mausboy.bin, I wasn't expecting what it was.

Yeah, Dragnerok X gave me the idea. So I started off on it just to see if it was possible. I was actually able to get the first frame into bBASIC, but the playfield configuration prevented me from doing any more in bBASIC. So I redid it in ASM, and that's as far as I got. I figured it would be a neat toy, showing the exact same logo that's in your signature. In the final product, the fire button should play a tune, and the left/right directions should change the speed and direction of the spin. Up and down would stop the animation and restart it at its default speed.

 

What I learned from the experiment was useful in some of the ASM I've been doing for Deimos Lander.

 

I read through the source, I can tell what each part does and what the instructions are for.

Really? I would have thought my use of Y indirect addressing would have been a bit confusing.

 

I could probably add the final animation frames, but I wouldn't even know how to mirror everything for the second half of the animation.

It would be pretty easy to do. If you notice, each frame is referenced in a list of frames. By doubling up the references to the frames, the sprites can be rearranged. The only tricky bit is to turn the sprites around so they face the right direction. This isn't all that hard though. All that's needed is to do a compare on the frame counter. If the counter is above a specific threshhold, you set the flip bit on the sprites.

 

If you're interested, I can explain in more detail how that would work.

 

It would be cool to include that as part of the intro to every game I release. Thanks for putting the time and effort into it, and commenting the source. It does seem like a good program to learn how to do some things with.

No problem. I thought you'd find it interesting.

 

I think large 3-d rotating sprites are a new thing on the VCS, aren't they?

I certainly can't think of any other instances. The idea for the color palette came from supercat's Ruby Runner game, which I believe he was inspired by some 2600 work done on Dragon's Lair. (I think it might have come from ZylonBane? No idea if that was the originating point, however.)

[MausBoy]

If I were to load as many docs and stuff onto a 1.44 disk right now to take home for a few day crash course in ASM for VCS, what would you recommend?

[SeaGtGruff]

I've thought about getting into assembly, but I haven't even completed a bB game yet. I've tried to learn 6502 assembly more than once in my life, it's not fun for me. I have always had ADD, so trying to do something that tedious that I don't find fun is pointless. I was hoping I would slowly but surely learn it by example while using bB, but people don't do a lot of integrating the two and then discussing it openly, besides MR.

Well, assembly is a whole 'nother animal. It isn't too difficult to learn assembly, but it almost requires a different way of thinking, because you're doing things on the machine's level. To be more correct, assembly is a tad above the machine's level, since the machine understands only "machine code," which is just a bunch of numbers. Assembly takes machine code and replaces most of the numbers with easy-to-remember "op codes" (operation codes), address labels, different types of notation for the different addressing modes, and other niceties that make it more preferable to write programs in assembly than in machine code.

 

But batari BASIC-- or any other high-level language-- is usually even nicer to work in than assembly is, because it's generally easier to do things. The trade-off is that high-level languages usually have limitations imposed by the way they do things, or by restrictions in their command sets (i.e., which commands they do have vs. which commands they don't have), etc. With assembly, there aren't any limitations arising from the language; your only limitations are those imposed by the machine itself. For these reasons, you'll tend to get some people who prefer to work in a high-level language like bB (for the greater convenience it offers), and other people who prefer to work in assembly (for the greater power/flexibility/control it offers).

 

The thing is, bB actually lets you have the best of both worlds, because it has high-level commands that help simplify the process of writing a program, but it also supports in-line assembly code, and it's customizable as well. It's true that there aren't many people besides myself who discuss ways to mix bB and assembly together, or who customize bB, but I don't think it's because they don't want to talk openly about it (and I do realize you weren't trying to imply that they're being secretive about it). The problem is that most people who understand 6502 assembly and the Atari 2600 well enough to mix in-line assembly with bB, or to customize bB, are more likely to program in straight assembly. And the people who are attracted to bB because of how much easier it is for them to program in it, are less likely to understand assembly and the 2600 well enough to mix assembly with bB.

 

I don't have the ball, or either missile to work with in the game I'm most wanting to apply this to. It's a horizontal scroller, similar to balloon fight. Obstacles that scroll onto the screen are made up of pfpixels, so the only two options are cut off the sides or find a way to extend the playfield. Think super mario brothers, if the pipes and blocks suddenly appeared a few inches in with each step, instead of scrolling in from the edge.

 

I use the pfcolors/background option, so my backgrounds are things like sunsets over a green field, so the edges are extremely noticeable. i like the screen being wide and reaching the edges. I guess I can cut off the sides with PF0=255 but it would be so much nicer to have a full width game.

 

I might just have to hold out hope that MR will create something with his superchip code that uses the extra ram to create a full width playfield, because without a lot of help and guidance I don't think I could do it myself.

The problem you're running up against is that bB's two existing "canned kernels"-- the standard one and the multi-sprite one-- both have limitations, and there's really no easy way around that. If you try to create a generic "all-purpose" kernel, then you're going to have to give up some things in order to have other things. This isn't a failing of bB; it's just as true if you're writing pure assembly. The 2600 simply isn't fast enough for you to do everything you could possibly do on any given scan line of the screen. For example, before bB was even created, I once toyed with the idea of writing a sort of "super kernel" that would do everything the 2600 was capable of, as far as the graphics are concerned. But it just isn't possible, because there's not nearly enough time to do everything while the scan line is being drawn. What you end up having to do is make hard choices about what things you really need or want to do on each scan line, and what things you can live without. Then you try to design a kernel that does what you need or want it to do, and hope you can pull everything off in the time limits imposed by the 2600. You may hear 2600 programmers talk about "racing the beam," or trying to change the various graphics registers before the TV's electron beam reaches a certain point on the scan line. But in some cases you also need to *wait* for the beam to reach a certain point on the scan line so you can change graphics registers. For example, if you want to draw an asymmetrical playfield, then you must load the PF0, PF1, and PF2 registers before their left copies are displayed, but you must also wait until after the left copies have been displayed before you can change the PF registers for the right copies. So not only do you have a very limited amount of time for getting things done, but you also have to do things at just the right times or the display won't come out the way you want it to.

 

Just about every game ends up needing to have its own custom kernel, and unless two games are very similar to each other, it usually isn't very feasible to try to copy the display kernel from one game and use it "as is" in another game-- you almost always have to modify it in some way for the new game. That means bB's "canned kernels" simply cannot be adequate for whatever game you might want to create. You're either going to end up needing to work within the rules and limits of the canned kernel(s), or you're going to have to create your own kernel(s). It's actually pretty amazing that bB's canned kernels are as flexible as they are.

 

In your case, it sounds like the best thing for you to do is to copy the includes file for the standard kernel, rename the copy to something else (so you don't lose the original), and then modify the new kernel to take out the things you don't need, so you can add the things you want. Or it might be a lot simpler to just create a new kernel from scratch, because sometimes it's very difficult to take some existing code and modify it-- especially if you didn't write the existing code. Trying to decipher and understand someone else's code well enough to modify it successfully can be a real pain!

 

MR

[SeaGtGruff]

If I were to load as many docs and stuff onto a 1.44 disk right now to take home for a few day crash course in ASM for VCS, what would you recommend?

I would definitely get the 6502 reference page from www.6502.org:

 

http://www.6502.org/tutorials/6502opcodes.html

 

Just save the whole web page to your disk. The links won't work right when you try to view it at home, but if you know HTML. you can change the hyperlinks, or just scroll the page up and down instead of tring to use the hyperlinks to jump around the page.

 

I would also get the Stella programmer's guide:

 

http://members.cox.net/rcolbert/stella.pdf

 

Those two documents are musts, in my opinion.

 

MR

[MausBoy]

Everyone makes it sound like I'm trying to edit a demo. I honestly think bB was made for the purpose of creating original VCS homebrews, not just demos made by modifying someone elses code and then playing with the 'presets', it is actually a BASIC compiler. I just want a version of that compiler that can handle the type of BASIC program I enjoy writing, and I don't think I'm wanting too much. Every game project I've started but one stays well below the limited number of cycles available.

 

I don't mind learning ASM but I honestly want to have a set of games that I'm really proud of that I made with bB, without any good knowledge of ASM. I think they are something I'll like having once I know ASM well. I'm just really wishing I could hurry up and finish a few of them. With all the new kernel changes that are released, it still looks like the language will catch up with my needs sooner than later, so I'm holding out.

Edited September 21, 2006 by MausBoy

[jbanes]

If I were to load as many docs and stuff onto a 1.44 disk right now to take home for a few day crash course in ASM for VCS, what would you recommend?

1. A copy of DASM with the VCS.H and MACRO.H files.
   
2. A copy of Stella. (I cannot stress how important Stella's debugger is to learning what the 2600 is doing. Activate the debugger with the '~' key.)
   
3. The 6502 Introduction website. (I spidered it using WGet so I could have a copy on the go.
   
4. The HTML version of the Stella Programmer's Guide. (I also spidered this. The HTML version is easier to read, and can be quickly searched.)
   

Those are the key things you need. Of particular importance is understanding the way the 2600 works. Tutorials like 2600 101 are good for getting up and running, but they gloss over the details of how it actually works.

 

The most important part is that you have 76 cycles per scanline, and 262 scanlines for a total of 19912 cycles per frame. (Multiply by 60 frames per second, and you get 1,194,720, the exact frequency of the 6507 in the 2600.) Each of those 76 cycle scanlines is time for you to run your program in. You can chose to draw the screen or run logic. Take your pick.

 

Thankfully, some of those scanlines aren't displayable. You've got:

• 3 lines of VSync
  
• 37 lines of VBlank
  
• 192 visible lines on the screen
  
• 30 lines of overscan
  

A naive kernal would run:

• 3 lines of VSync
  
• 37 'STA WSYNC's (VBlank period)
  
• 192 lines in the kernal
  
• 30 'STA WSYNC's (Overscan period)
  

Of course, that would use all your time up, leaving none for logic like bBASIC. Which would be bad. Sooo... we use a timer. Most programs look like this:

• 3 lines of VSync
  
• 43 stored into the TIM64T timer + a single 'STA WSYNC'
  
• 192 lines in the kernal
  
• 35 stored into the TIM64T timer + a single 'STA WSYNC'
  

The timer is kind of a neat trick. You see, the 2600 doesn't actually NEED you to call 'STA WSYNC'. That's only to keep your kernal in sync with the scanline. If you fail to call it, nothing happens. However, the VSYNCs are necessary. These VSYNCs tell the TV to start a new frame. Without that call, you have no signal. Easy enough, right? Right.

 

So back to the timer. TIM64T (look it up in the stella guide) counts down a single number every 64 cycles. So putting 43 in the timer means that it will count down for approximately 36.2 scanlines, or almost the needed 37 lines. (64 * 43 = 2752 cycles / 76 cycles per scanline = 36.2 scanlines.) The idea is to do your logic with time to spare, then test the timer for zero (using 'lda INTIM') until the timer is up. Once it's up, you know that you're less than one scanline away from your next task. So you store to WSYNC once to get back in sync.

 

Cool, huh?

 

This is where bBASIC comes back into play. The bBASIC 'drawscreen' routine is a PERFECT example of this. If you open the 'std_overscan.asm' file (preferrably from the 0.35 version, the new one is a bit confusing) you can see this in action. bBASIC uses the overscan period for you to run your code until the next 'drawscreen'. It then sets up the VSYNC (three lines!) and uses the following VBLANK period to position items on the screen. Once that period is over, it calls the kernal to render each line. After that is rendered, it sets up the overscan timer and returns to your code again.

 

I highly recommend reading the std_overscan.asm file until you understand it thoroughly. It's the key to really getting into assembly programs. Kernals are easy to understand in comparison. You put the data in GRP0, it shows up on the screen. Easy.

 

Well, except for the matter of positioning. That's a little tricky. The good news is that you can position absolutely. By calling the RESP0 (RESP1 for the second sprite) you can set the horizontal position of the object. This works by waiting until the TV beam is where you want the object on the line, then calling RESP to store that position. The bad news is that this is in 15 pixel increments. So you'll need to nudge the object over to where you want it by setting an HMP0 value (HMP1 for the second sprite) and calling HMOVE. You only need to call HMOVE one time to nudge the object.

 

The sprite takes up the ENTIRE vertical part of the screen. (As an experiment, try putting %11111111 in GRP0 for an entire frame.) So there's no actual horizontal positioning. What you do is, you don't put any binary 1's into the GRP variables until you're ready to show something. So you keep the lines blank until you're ready, then load your image data one line at a time. When you're done, you put all zeros back in the GRP variables to make the image disappear on following scanlines.

 

Does that all make sense? I know it's a lot to absorb, but I'm confident you can do it quickly. Here's the key thing: If you have any questions, can't understand any part of this, or are stuck on a problem during implementation, PLEASE ASK IMMEDIATELY. We can get you up and running pretty darn quickly, hopefully before you lose your concentration on the item at hand.

 

Some other great resources:

• 2600 Advanced Programming Guide - Great tips for making advanced code.
  
• The Batari BASIC help file - I cannot stress how useful the color chart is on this thing. Also, it sometimes helps to look at the same commands (such as sprite doubling/flipping/stretching, etc.) from a more familiar perspective. Remember, bBASIC is just a pretty layer on top of the 6502 assembly. It should all translate.
  
• Andrew Davie's ASM Tutorials - They're probably a bit too slow-paced for you, but there's some great example code in there that you know WORKS. For example, I developed the MAUSBOY.ASM program by taking the Our First Kernal code and reworking it to eliminate the redundant calls to WSYNC and the like.
  

 

Some tips:

 

1. Never be afraid to search AtariAge for info on how to pull off a tricky bit of code. You can always ask without penalty, but searching will sometimes be faster.

2. If things go wacky (and they will!) step through the code line by line in the Stella debugger. You can see exactly where it's getting its data from, and usually find the bug rather quickly. This is especially important when you're missing your deadline on updating an item, and either see nothing or garbage.

3. Look at the ".bas.asm" files to see how your code translates into asm. Investigate each of the files referenced in the "defaults.inc" file to understand what code is what. It will help you get a clear picture of what code is yours, and what code is bBASIC's.

 

I better start seeing some "why did you do this that way", or "how does XYZ work" questions soon!

[Piggles]

Everyone makes it sound like I'm trying to edit a demo. I honestly think bB was made for the purpose of creating original VCS homebrews, not just demos made by modifying someone elses code and then playing with the 'presets', it is actually a BASIC compiler. I just want a version of that compiler that can handle the type of BASIC program I enjoy writing, and I don't think I'm wanting too much. Every game project I've started but one stays well below the limited number of cycles available.

 

I don't mind learning ASM but I honestly want to have a set of games that I'm really proud of that I made with bB, without any good knowledge of ASM. I think they are something I'll like having once I know ASM well. I'm just really wishing I could hurry up and finish a few of them. With all the new kernel changes that are released, it still looks like the language will catch up with my needs sooner than later, so I'm holding out.

 

 

You can do it!