[WIP] CROSSDOCK

[[WIP] CROSSDOCK]

Little status update.

 

Found a little bug when playing the 16k version.  When playing with faster Dock Boy speeds it is possible to grab parts of the playfield.  This is undoubtedly in the 8k version.  It just requires me to change the bottom boundary but it doesn't really impact gameplay too much. 

 

I had just finished up the bonus section with about 500k to spare so I may add a few more things.  There are a couple little details I need to check out before I release it for testing but here is a quick video of what the bonus screens look like.  I had adjusted the variables so that bonus access appears quickly for demonstration purposes.  As a note, once the conveyor belt speeds up, it essentially halves the time you have to get to the conveyor belt.  

 

When you get to the bonus screen there are various animal obstacles you may face:

 

Birds - These will fly around and get in your way.  Some will poop while some will not.  Avoid both birds and poop.

Snakes - These will slither back and forth.  Keep them away from the box.  When they see your box they will slither faster.

Ants - An anthill will pop up. You can squish the anthill or the ants.  Don't let them in the boxes or they will start eating the product, decreasing its size.

Spiders - These will slowly lower and sway in your direction briefly when they reach the bottom.  Upon raising up they will spit some venom because why not.

Rain - Avoid the couple drops of rain that continually fall!

 

You have the potential to earn 224 total points from the bonus screen based on how many boxes you successfully unload, as indicated by the status bar, and a full timer when you return.  Depending on if the game is too hard or easy I may opt to reduce the timer bonus.

 

[[WIP] CROSSDOCK]

3 hours ago, KevinMos3 said:

I've been kinda wondering if you were planning to put that picture from your label mockup in as a title screen at some point.

I'm not sure if I will mess with the titlescreen at all. With what I was working on I don't think I would have enough space. I had a hard time trying to figure out the titlescreens with images before so I had put off learning that so it may be possible down the road.

[[WIP] CROSSDOCK]

Over the last month I had tweaked this game and tried to weed out any glitches or bugs.  I found a few from changing values, extended play, letting my kids do whatever they wanted to try and break it.

I kept the limit to 8k to see if I can do it.  It was a challenge but I was able to make the appropriate fixes with just enough space to spare.  I had added the file to the first page and am proud to say that with maybe some minor tweaking it may be done... 

 

but...

 

I was playing around with some concepts and had started work on a 16k version!

 

I had originally wanted to keep it 8k but was playing around with the idea of special editions with additional features that got me wondering what exactly I could add to this.

While the gameplay for the main game is essentially the same, the 16k version essentially expands on the bonus level.  In the 8k version there are 2 bonuses you can receive.  The first is a bonus box that appears under certain conditions for a brief amount of time.  You grab that box and you are rewarded with some time and a box in hand.  The second bonus is a time bonus.  The timer stops and starts flashing giving you some time to load up pallets.

In the 16k version the second bonus is an opportunity to go to a bonus screen, where you are met with different gameplay.  When the statusbar starts to flash, you have a a limited amount of time to go past the conveyor belt to an outside truck bay.  There, you operate a forklift and you must remove boxes from a truck and place them on the conveyor.  You must do this while dodging the snakes and birds.  Each box unloaded successfully will get you extra points.  There are some rules in the bonus round - the birds (or their poop cannot touch you) and the snake cannot touch the box.  You also cannot move the box while the forks are raised or it will fall off the forklift but you can raise it up if you are not moving.

 

Currently I have 6 different bonus screens that cycle randomly and am still working out the details but I think this is working out pretty well.  By upping to 16k, I added 2 banks and moving things around I added some space here and there so the bonus screen will occupy pretty much one whole bank.  I am considering using the other bank for a possible surprise...

 

And if some are wondering how this ties into the theme, if you had ever worked a loading dock in Florida, you may have had to deal with swarms of birds from bread vendors feeding them their stales, raccoons and cats hanging around the dumpster, snakes slithering around pallets, or even an alligator waddling out of a retention pond... Many of these scenarios inspired the bonus screen.  I was tempted to add bats (which I had also had to deal with) because of bats thrown as enemies in pretty much every early video game but I chose birds instead...

 

BUT until I finish I figured I would offer up the 8k version and see what people think about the modifications from the last update!

 

[best tools for music for 2600?]

There is Miditari.

 

It looks and sounds amazing. I have yet to learn it but the results I have seen are great.

[What are your favorite tools in VisualbB?]

37 minutes ago, Random Terrain said:

 

I use Droid Sans Mono With Slashed Zero.

 

Why did it never occur to me that you could change the font!?

[What are your favorite tools in VisualbB?]

The ones mentioned are really good. I had just started to utilize some of them, like Bookmark so I can quickly jump to sections and review code.

 

I really like the keyboard/music program but I have a hard time integrating the code into my games. I am sure it is not as hard as I think but I do wish it was a but more intuitive.

 

I agree that the sprite editor and playfield editor can be clunky. I like them but I'm sure there could be easier ways.

 

I love the color chart.

 

I do wish the font in the editor was somewhat uniform solely for the editing of playfields but it is not a huge problem. Sometimes I edit them on the fly and wish they were easier to read if you have a lot going on.

 

 

[continuous drawing high res PF editors...]

14 hours ago, Random Terrain said:

The VbB playfield editor lets us draw continuously, but drawing on bigger playfields is sluggish. For example, a playfield that is over 80 rows high is frustrating to draw on using VbB.

 

Speaking of drawing DPC+ screens, take a look at this:

 

atariage.com/forums/topic/301174-dpc-drawing-program/

 

It's basically useless for programmers. It's just a toy.

Yes.  There are many times when I would draw and something will not appear as I thought it would or the preview screen would change.  These DPC+ tools are very helpful.

[Cycles Depending on Bank]

So I moved all of bank 2 to bank 4 and the issue stopped. I still have an occasional 263 cycles and while I don't get any screen rolls or jumps on hardware, I still want to try and rectify this so I will look into vblank.   I had tried playing around with vblank, seeing that it took up about 20 bytes, I wasn't able to get things to work since I barely had any space so now I started to moving things around since I have 2 free banks so that I can try using that.

 

I did move a segment of code that didn't seem to interfere with the cycle issue and moved it to the vblank just as a test and it did eliminate the issue so there is hope!

 

Thank you again for the explanations.  I do find the underlying cause very interesting and hope to learn more as I progress.  

[Announcing: 2 New Standalone PF editors]

I like the DPC+ one.  There have been many times where I have a hard time gauging the general look of the playfield so it is cool to see it in one screen. This can be very helpful playing around with ideas.

[Cycles Depending on Bank]

Thank you very much. I will read up on both the bB process and the 6502 tutorials. I think I have an idea on what to do to. I would imagine that if the cycles are only jumping 3 or 4 and never really above that, the moves would be minimal... 

[Cycles Depending on Bank]

Just now, Karl G said:

Also, it may not be clear that this is a bB question since it was not posted in that subforum, which might cause some confusion. 

I suppose I should have specified that it was bB but I really do appreciate the explanation, as I want to understand more than the dos and donts of bB.  Based off what I had seen, reading the explanation of page crossing makes sense. I was tempted to move bank 2 into bank 4 to see if the issue persists but I agree a better solution is needed.

 

I had noticed that I get an occasional 263 cycles normally that I have been working on an moving code to after the vblank sounds like it could work.

 

Implementation of vblank in bB had confused me so I will definitely look into that . I assume I would have to put some code after drawscreen and that would basically take that out of using cycles?

[Cycles Depending on Bank]

I was playing around with expanding my game from 8k to 16k as a test.

 

I had moved my "inline 6lives_statusbar.asm" to the last bank (bank 4 as opposed to the previous bank 2). I made no other changes to the code.

 

When I ran in Stella, the game worked but I noticed the cycles would jump more. I was wondering if certain things use more cycles depending on which bank or how many banks you use.

[Error compiling in VisualBB]

There had also been times where I had a line of code that had something weird, like ending with a ":" or forgetting to place an "=" sign and it wouldn't compile until I rebooted my computer and deleted the offending line.

[[WIP] CROSSDOCK]

I was just getting ready to post an updated binary when I was testing on hardware but I had to get up from the couch for a moment and when I came back I had noticed a couple odd things that I think are probably related to one little change I made. I had noticed the screen was on Game Over when it probably should have paused when I lost a life.

 

The second thing I noticed was that when I got points it seemed to change the timer from maxed out to really low... And then when I continued on my last life the life sprites changed color (and would flicker) and the timer stopped going down.

 

So... I will fix that.

 

Right now the main things going on with Crossdock is that I am trying to find a balance in game play to where the timer does not run out too fast. I will get it okay but then when the counter speeds up the timer depletes much too fast. I have been trying to move little things in the code to make more room for better adjustments but when I change one little thing another one pops up. I keep thinking of trying to level kitchen counters - I get one leg right only to mess up the other 3. 

 

If I can get the pacing at both speeds right, Crossdock will be almost ready for release.

 

...I just got my son down so I started to play around with the code.  I think I found the issue.

 

My last adjustment involved me increasing time rewarded for a bay filled.  While I had a check for statusbarlength>224, since I increased the reward it would push that number over 255.  That issue was actually present in the past but I never got close to a full status bar.  So I consolidated some code freeing up more space and I added that the time reward is only if your status bar is under a certain length.  So far it seems to work but I will do some more testing so I don't prematurely post a broken game.

 

I had changed this

  if z{6} && f=69 then statusbarlength=statusbarlength+40 
  if !z{6} && f=69 then statusbarlength=statusbarlength+80
  if statusbarlength>224  then statusbarlength=224
  if z{1} && f=69 then player1x=(rand&63)+20 : player1y=(rand&31)+15 

into this:

  if f<>69 then goto BAR_CHECK
  if z{1} then player1x=(rand&63)+20 : player1y=(rand&31)+15 
  if z{6}  && statusbarlength<215 then statusbarlength=statusbarlength+40 
  if !z{6} && statusbarlength<175 then statusbarlength=statusbarlength+80 
BAR_CHECK
  if statusbarlength>224  then statusbarlength=224

 

[The State of Batari BASIC]

6 hours ago, Random Terrain said:

Just remember that my adapted version of the bB page is similar to a dictionary or an encyclopedia. You basically just go there to look stuff up or to copy and paste code. It's not a tutorial. To help make things a little easier to find, the page has a table of contents, an expanded index, frequently used page links, a keywords/constants/registers list, a quick reference list, and so on.

 

We need somebody who is good at teaching and writing and has knowledge of batari Basic and assembly language to create tutorials that can take a new user from the hand-holding grade school stage all the way up to the equivalent of high school and beyond. Hopefully that person won't burn out part of the way through.

Whenever I I had gone to your site, it was one of two ways.

 

The first is that I was just reading or re-reading a section for the heck of it.

 

The second would be I was thinking or trying to program something and I would look to see what could work.  I want different playfield elements?  Colors?  I would look up each section to see if they may have the answer.  

[The State of Batari BASIC]

28 minutes ago, Random Terrain said:

In 2018, I got permission from an author to make an online batari Basic tutorial based on two of his books. I'm not a teacher or a writer, so I had a hard time getting started. I've been working on it again recently (off and on for about a month). It could take me 7,000 years to finish it, so I don't know if I should spend my time on other things that I can actually finish or keep working on the online book that I may never finish.

I had always wondered about books for bB. I can picture your website in book form with little code examples like the old programming books back in the day.

[Intentional Glitches]

40 minutes ago, Mr SQL said:

That code you didn't expect could be an Fx routine  in your next game.

 

In the 80's we used artifact colors by exploiting NTSC "glitches" that PAL color circuitry lacks. 

 

Today a concern might be weather your game will still run on the Flashback Portable or the Retron77 as well as a classic Atari console.

 

bitd we were careful to make sure our software would still run without extra features from glitches when they weren't available. imo that's still a good idea today so that folks can enjoy the games on as many Atari platforms as possible.

 

I hadn't thought of Flashback or Retron compatibility with glitches.  I had only experienced it in Stella and I corrected the issue before trying it on hardware but I noticed no cycle issues and it didn't impact the main loop (since it was in the Game Over screen).  Currently I only test on the AFP and hardware.  I have a FB9 but I hadn't tested on that yet but you make a great point and I should probably start testing on more options as that would increase the amount of potential enjoyment.

But if all works well that would be pretty neat.  I didn't stick with it since the effect didn't quite fit with my game. It didn't make sense why the screen would constantly redraw backwards and the sprites act all Matrix-like for a warehouse game.  I do think it would be more of a pain trying to discover such glitches and then see if they a) fit in with the game and b) work. 

 

I did wonder if there were any known glitches.  In Crossdock, I use pfcolors and pfheights.  I forgot about defining the color and changed some things that resulted in the top row changing colors.  RT's site mentioned it was a known bug with the top row.  I had actually liked it and incorporated it into my game but I as wondering about things that might have been more impressive than a row changing colors, more like the graphical issues I experienced.

[Intentional Glitches]

I accidentally screwed up on a line of code garbling up my lives counter. 

 

A little while back I was playing around with code that had an unintended consequence of reversing my playfield and having the sprites scroll down all garbled, kind of like in the Matrix.

 

Got me wondering...

 

Had anybody found any interesting graphical (or other types) of glitches that had a cool effect? 

 

Is it worth it to explore these issues as a way to add some special effects and is it worth it with time and space restrictions?

[Randomly Seeding Data Table?]

I never considered that. I have yet to use for and step commands but this could be interesting. Now I am a little confused briefly looking at this.  Would the rr## be the assignment for the sprite location and the sp## the sprite?

 

 

[Randomly Seeding Data Table?]

I didn't plan on showing them at the same time. Sorry. I should have clarified.

 

 

 

 

[Unholy]

I personally like the animation as is. But maybe tweak it and see if you find something better?

[[WIP] CROSSDOCK]

So when I made my fix to the massive jack bug, I made a new bug - the 671 point bug, where the bay doors would not reopen at 671 points.  At first I thought this was a glitch with my Atari Flashback Portable because I also experienced a colorswitch glitch (or fat finger fumble) and loosely associated the two together.  I later replicated the bug on hardware but not Stella (but that is because I changed the score value effectively circumventing 2 other variables). You can read about the problem here.

After looking into the code, I believe I fixed the issue.  I essentially inserted the movement check code from the massive jack bug fix into the bay door code.  I switched out 2 bits for 2 unused bits (e{5} and e{6} for s{5} and s{6}) and things should be cool now.

 

Updated binary in the first post!

[Testing on AFP]

I think I may have found the issue...

 

Each bay door is assigned a bit ( e{0}, e{1}, e{2}, e{3}, e{4} )

 

There is a check to see if it drops the pallet and continues or drops the pallets and clears all the doors.

 

I had recently cleaned up the code.  It previously checked for the bay doors like this:

 

if e{0} && e{1} && ... then...

 

I had changed it to check for the bits like this:

 

if e=%00011111 then...

 

What I could tell is that in my latest build I had added a bit check for e{5}, which involves skipping the movement code.  Before there was never any interaction between the door check and the movement check but when I wrote the code to prevent grabbing the flashing numbers, I inserted the movement check inside the door check code.  That would then make e=%00111111 and then skip the re-open code.  Now I don't know why it happened both times at the same score but I had tried a third time and it did not have any interaction so there may be a third factor in play that I am not aware of yet. I realized I also use e{6}, which turns on or off based on 2 counters associated with the level change and obstacle selection - (W and V).  After each stage is completed, W goes up.  When W reaches a certain value V then increases.  This makes sense as to why it happened at the same weird interval.  So my solution would then be to swap out the bit with another unused bit and go from there.

I jumped to it being the AFP because in the same session I had the color switch issue so hopefully this fixes that and there are no issues between the AFP, Stella, or Hardware.  

[Testing on AFP]

So after testing on hardware again, I couldn't replicate the color issue but at 671 points the bay doors didn't open. It must have been from some new code I had implemented as that didn't happen the other day and I must not have fully tested it beyond an initial "does it work" test. 

 

That is also an odd number for the bay doors not to open, as each pallet is basically equal 10 points (10 boxes), each bay is a bonus 5 points, and completion of all bays gets 25 points so at no point should the number be 671...

 

I don't believe I hit any boxes when I checked the score so that is weird. Unless I'm missing something.

 

I had also noticed that at that point instead of flashing "+25" it flashed "+5." This leads me to believe it skipped the +25 code, which would also have the reset.

 

Hopefully that should be easy to find.

 

Now the weird color issue I am leaning on AFP issue.   

 

Thanks for the help! 

[Testing on AFP]

Thanks. 

 

I am going to keep testing things and see what happens. I gotta go over the code and see if I slipped up somewhere. I had instances in the past where a typo would cause weird graphical errors or some wacky actions and sounds. These sounded a little specific of an action, which is helpful in that it gives me a place to look.

 

I had another issue, but after thinking about it I think my fat finger may have pressed one of the other buttons on the AFP (it involved the color switch, which is by the fire button) but I did see that there is an issue with the AFP saving the state of the color switch.

 

I will also have to look more into some of the know issues with the AFP.