KevKelley

I was curious. I was testing my game Crossdock and I had came across a couple of weird issues, but I had so far only had it happen on the Atari Flashback Portable. The main issue I had was that during gameplay, once you fill all the bays at the top of the screen, each bay is then reset using a bit. The issue was that after all the bays were closed, the doors never reset. I've only had this happen this one time and couldn't figure out why. I haven't had it happen in Stella or on hardware and I was going to double check my code later to see if I did something by accident like reuse a variable but the question I had was if there had ever been any known bug issues with the AFP? I know I had read some things about adjustments to make certain games compatible so I was wondering if there is something I need to pay much attention to when working out bugs, or as long as it works on hardware I should be fine?

So I decided to explore Option F. I found a line that was left in from some previous code so I had removed that and then reworked and consolidated some of the code in the intro/game select menu freeing up enough space to accomplish the goals of redrawing the jack. I now have 58 bytes free in Bank 1 so I will try and work in a little more sound and hopefully seek out any other glitches. New binary will be posted in the first post!

So I came up with two possibilities for a fix. E In the first I rewrote some of the code for the collision between your player and the jack by assigning each direction a value and then choosing the sprite based on that . Doing this helped save some space in Bank 2 to where I can make the code to skip over drawing the jack until after the "+5" is drawn. I was also able to add a check at start up and after a jack spawns to have the jack in a particular preferred orientation. The only problem with this one is that I created a new problem that escapes me at the moment: when you move diagonally with a pallet your player may face left or right but the pallet may face a different direction. This leaves me with the following: 7 bytes of ROM space left in bank 1 52 bytes of ROM space left in bank 2 The other fix is less complicated: F I basically skip the movement of the player until the "+5" is done being drawn. The only downside is that I would still like to re-spawn the jack to where it faces a different direction and THAT fix escapes me at the moment. This leaves me with the following: 6 bytes of ROM space left in bank 1 27 bytes of ROM space left in bank 2 I was playing around with this all night to try and find a good fix but it seems that I plug one hole and I get another. CD_05_27_2020_E.bas CD_05_27_2020_F.bas CD_05_27_2020_E.bas.bin CD_05_27_2020_F.bas.bin

Ooh. That's a good one. When I upped it to 8k I moved the code for the jack direction into Bank 2. That bank is tight on space so while I can stop the grabbing, I gotta find a fix for the number from changing to a giant jack. Thanks!

Started working on some optimization to free up some space and get more out of it. Lined up all my like valued variables and reworked some code to simplify some things. Also fixed a couple mistakes, like the counter going down when the bonus time occurs. I added jack randomization after a certain amount of points, modified some of the sounds, and changed the bay color to green when a pallet is full (some of the feedback I had received mentioned that when the pallet jack gets covered by the pallet it can be difficult to tell if it is maxed out). Updated binary in first post.

Thanks! It is fun to make these games out of work-related tasks or operations, like loading boxes on a pallet. Imagine if games progressed down this line. We would be playing Warehouse Loader 3D instead of Duke Nukem

So maybe a different direction would be assigning each sprite a value. Then a random number outside of the mainloop (r=Rand) and assign each box a value (y=r+1, y=r+2, etc), and then have y point to a data table for what the corresponding sprite would be. Once all boxes are filled then clear the boxes and go back to the random number and start over? Hopefully with enough sprites, positions, and randomizations, it could make a sequence difficult to remember? I'm just typing out loud playing with this idea to see if it works. Or if this is a rabbit hole I don't really want to go down or not.

Yeah. I suppose that would be it. Once every box would be matched it would then reset, flash the new order of sprites, and then start over.

I had just started playing around with an idea. The playfield consisted of 12 boxes. I wanted to flash a sprite in each of the 12 boxes and then disappear. Then one of the 12 sprites would randomly appear and you would have to place that sprite in the correct box. Essentially a game of memory... The only thing I was worried about is that a pattern would develop and it would be easy to guess.

I understand the concept of data tables and have had limited use of then but I was wondering if there is a way to randomly seed a data table. Say I want to randomly generate a series of 12 values to draw 12 different sprites, and then recall them in that order every time needed, or until I reset it, would I simply randomly generate the first number in the data table and then add onto the subsequent values?

New binary. Obstacles should appear. Adjusted timer a little. Also fixed issue with too many lives causing a game over and obstacles maxing out your status bar.

These are the areas I will be tweaking to see what combination of effects work: Pallet size Theeasy small pallet setting is pretty much all right for now. It was intended for my kids. For an adult, there is sufficient time to load the pallet and bays. Where as my kids like to walk a lot and goof off. The large pallet size (10 boxes) might be too big, as I had noticed the timer depletes faster than I can fill the bays and replenish it. I may look at something smaller, like 8 boxes to see if that small change makes a difference. Conveyor/counter speed The conveyor belt may need to speed up a bit, as I had found times where I was too fast and was waiting for boxes (as the conveyor belt is not that reliable), losing time in the process. But I believe I have the statusbar tied to the counter but I have ideas to slow it down or maybe check every other frame... Or improve the status bar code. Right now the two bonuses appear under different conditions. The first shows up after about every 100 boxes comes off the conveyor belt and last for about 20 boxes, or two pallets worth of no timer and possibly some gains. The second I haven't gotten to yet so I'll wait and see for that one. That comes after 200 boxes off the conveyor but only on a couple non-obstacle stages. Statusbar I had played with different increments of the statusbar in the past when I first started it. Also if any other programming issues pop up. As I have used up most of the space I may have to get creative or learn some new things. I welcome any constructive feedback as I feel this is close to being complete and I would very much like to make this into a cartridge when I'm done. I think this would be a cool one to see on a shelf.

I have updated the first post with a new .bin and .bas. Since the Zero Page Homebrew show, I think I squeezed as much as I can out of the 8k. I have 2 bytes free in Bank 1 and 27 bytes free in Bank 2. I had fixed the collision issues, changed the color selection, and added bonus features. As mentioned in the previous post, I had gotten rid of my problematic and poorly written collision detection for a simple boundary. The pallet or jack shouldn't leave the playfield anymore and Dock Boy shouldn't be able to grab the wall and turn it into a box! Also, as some had pointed out about the background color, now the default is a black background but if you switch to BW, the background changes color when you load a bay. The first bonus feature appears at a particular interval. It is indicated by the player and pallet flashing. The status bar does not decrease during this period giving you a grace period to place boxes on the pallet and getting it into the bays (which will give you more time thus slowing your demise). The second comes during another interval and is currently only in a couple of the stages with no obstacles. A flashing box will appear by the bays for a short period of time. Grab it and you fill up your status bar and get a box in hand. I am currently testing to see if the first bonus lasts long enough to be a benefit, if the second bonus appears frequent enough to be a benefit, and if the game is still balanced. I will be tweaking the values, as well as seeing if there is any other way I can squeeze more code as I have one more minor fix I want to work on but it is only really noticeable when I am on Stella on my laptop.

I had never heard of that game but it looks fun and similar to some of the concepts I was considering for this series of games. It looks doable, although may be beyond my skill. I was planning on a forklift game with similar ideas but haven't gotten that far yet. I never intended to work on Cross Dock as much as I did but I learned a lot doing it so I figured it was worth it. I have also come to realize there are many classic arcade games I have never even heard of. I really do need to get a little MAME set up for my tv.

I have been following this since the beginning. It is such an amazing story and exciting to see something see the light of day 40 years after it should have! I look forward to an official release. This game had quickly risen to my favorites for a variety of reasons - graphics, innovative game play, enjoyability, etc.

Ah. I see. I just went through to see why I thought it was working and I noticed that there was one line where I didn't replace the rand command so it seemed like it was random, but it was just one of the coordinates. Had I ran it longer I probably would have noticed my mistake when everything would spawn in a column. So I guess the 30 bytes I saved was it not running rand at all then and not some magic trick. Darn. I must have missed somewhere where it stated constants cannot set const to a rand value. Thanks!

Now I had noticed that in some instances it would generate the same number each time, like with the temp variables. Would this because they are wiped each frame and the constant draws up the same number in the same order the next time it is called?

I was trying to find ways to get more space in my game. I have been avoiding adding additional banks to force myself to learn some tricks, so to speak. I noticed that when I swapped something like this: temp5=(rand&3)+20 into this: const c_R3=rand&3 temp5=(c_R3)+20 it saved 30 bytes but I did not see any difference in performance. I was wondering if anyone understood the reason as to why. I was looking up through the forums and Random Terrain's site but saw nothing that indicated why. I assume it is just how it compiles?

I had thought that while the game was done the original programmer was working on the ROM that was released earlier but was busy. I may be wrong but I I saw they had commented late last year that things were hectic and things haven't really calmed down since. This was a project that I was looking forward to because the game is really wonderful to and a shame it never came out back in the day.

I think the sound issue from the Game Over screen was a result of some old code that I had never deleted (and I don't know why I had it in the first place). It was a collision code between player1 and Player0 but I also had a variable in there that was also used in the game over screen when I had originally used the shakescreen command. But I opted to get rid of that and I guess I never deleted the other associated code. So if you were holding the jack when you died, at the right time the sound would stick... I think. I made the fix late last night and didn't check to see if that was the cause.

So I went back and tried again to no luck. I also tried messing with the one in the batari basic folder to no luck. I even deleted the pf_scrolling.asm along with editing the default to test, which then ate up more bytes. Space isn't too much of a big deal. I was going to add a .bas file up top. I also think I fixed the issues with the pallet exiting the playfield - I had a collision detection between the playfield and the pallet. I think if it jumped too far it would go out of bounds... and since grabbing the pallet also affected the player0 and player1 sprites, I think it would make things go crazy. I also noticed that when I got rid of the collision detection in favor of boundaries, I hadn't experienced any scanline issues over 262. I still got some more things to mess around with tonight but at least I got one thing fixed.

I had something similar happen in Manatee Madness. I was having the grass sprout up and there was that one sliver where the color was different. I can't remember my fix. I remember playing around with the colors of the rows for playfield and background on the bottom of the screen until it disappeared, but then again I had it solid on the bottom so maybe it was easier.

I had also tried that as well as . Didn't make an impact. I also changed the original, tried different names, tried different placements in the code (which would sometimes cause an issue). The only time it showed something different was when I moved default.inc in the folder and did includesfile default.inc. Bank 1 then shot in the negatives by about 1000 bytes. I will try again later to see if I missed something. Internet was down so I was going off my phone.

I had tried copying the default.inc into the game directory. Commented out scrolling and renamed the file. I put an includesfile in my code and it appeared to make no difference in size.