KevKelley

I had wondered if a Rampart could be ported...

Ah. I was planning on playing around with it to see if I could get some effects out of it. Thought it was neat.

I was using pfcolors and pfheights playfield options with the standard kernel. I understand you can only set the playfield colors once, unless you use this modification. While I was messing around with code with the statusbarcolor, where I was trying to set the statusbarcolor to a variable, I had noticed it changed the color of the top row of the playfield to be the same as the status bar. I was curious as to why this occurred.

I am curious as to what you mean by all of that. I think I have a general idea but not quite sure what to do with it. Lol. From watching everyone play, I saw some places I can free up. I know my code is probably not the most efficient and trying to squeeze out more space I have had fun reworking lines to get things to fit. That is why my sounds are pretty simple. I saved them for the end.

So I just tried my latest build on a television. Due to work scheduling, much of my testing is on a mix of Stella and AFP. I can see what everyone was saying in the ZPH show. The colored background in Stella is nice and crisp while on the TV I can definitely see how the colors can become an interference. I am considering a couple fixes - utilize the color switch to turn them on or off, reduce the colors to only a couple non-conflicting color schemes, or try to alter the playfield colors instead. The latter may be more difficult since I am using pfcolors and pfheights. The pacing of the game seemed really fast on ZPH. But then I realized that for the sake of getting through stages quickly, I tend to use the small pallet option to test. The problem is that I then load the bays and get points quicker than not. The fixes I am considering is to either change the points gained from a bay or offer a powerful somehow. Perhaps use the ball when not in use. I saw plenty of the border glitches where the jack or pallet would become out of reach. This is from some poorly implemented collision detection. I rarely would notice because whenever I would play around I would stick to the middle. I will rework the collision detection. Some of the issues I found were when Player0,player1, and missile0 (Dock Boy, jack, pallet) all collide with the wall. I noticed on the game over screen it made a horrific sound. Low on space, the sound was some of the last things I had added and didn't quite test as much. Walking around the title screen. I kind of like the joke about being the rare game where you can die on the titlescreen. This issue stems from when I first made 2 banks, I broke up the code and added a titlescreen. When it came to the movement code, I didn't need much of the main gameplay code for moving so at the time I just made a simple movement just for the titlescreen. I'll double check to see if I can fix this up a bit if it doesn't take up too much space. Otherwise I may keep it, especially since when my son was watching he thought it was awesome. Actually he loved every time James or Tanya broke the game so he might not be the best judge 😄. As for the wonky jack moving when it would touch a box, I will have to check some of that code. If a pixel generates under the jack, it will shift. But if you are holding a box you shouldn't be allowed to push the jack and load the pallet at the same time to prevent a person from ramming through a bunch of boxes for a quick pallet. I'll see if I screwed it up somewhere along the way. Diagonal moving. I originally didn't plan on diagonal moving because Jack's don't move like that... But I'll see if I can rework the movement code to keep it 4 directional. I think that covered all the "glitches."

Thank you for playing the game. I can see there are a couple of issues I need to fix but I hope everyone enjoyed it. I am trying to keep this game at 8k for a variety of reasons but I think the fixes necessary are doable! I think I might be able to save some space with some so hopefully I will have an update soon. And I just wanted to mention a couple of the comments from the show that I enjoyed, and forgive me if I do not remember who originally made the comment. Someone made a comment about how this game is in the same vein as early video games like Lost Luggage, where seemingly normal tasks are turned into a game to some varying degree of success. There was also a comment about how this game contains similar elements as other games, like Pressure Cooker. This is kind of by design. This game started as a practice program for me. I wanted to get a better understanding of things like bit operations and pfpixel commands. I settled on a warehouse game because this was a game idea I had come up with 20 years ago along with Bag Boy. I drew upon as inspiration some of my favorite games growing up and tried to take a creative twist. In particular, Defender (grabbing things), and Frogger (putting things in compartments). I also love taking mundane tasks and making them into games. Perhaps these were a precursor to modern games like The Sims? I just hope it translates well to where you can tell what is going on.

UPDATED .bin 3/24/2021! Fixed up Carts minigame. GAME: Crossdock Play the sensational supply chain simulation, where you are Dock Boy, the dedicated depot worker who diligently disperses delivered product from the designated area onto pallets, piled perfectly and primed to be packed into waiting trucks. There is no rest for Dock Boy. The conveyor belt never shuts down so you must keep loading those pallets into the open bays before the time runs out so no dillydallying! GAMEPLAY: The game has 5 gameplay options that you can select from the title screen by having Dock Boy use a jack to grab a pallet and put it into one of the five bays above. They are in the following order, from left to right: 1. Throw boxes - This allows you to toss a box that is in your possession onto the ground. If it touches the ground the box becomes damaged and cannot be put onto the pallet. 2. Random jack - This randomizes the pallet jack placement after each time a pallet is loaded into a bay. 3. Smaller pallets - This reduces the maximum size of pallets from 10 boxes to 5 boxes. 4. No obstacles - This eliminates the spawning of the obstacles. 5. Bays in order - This requires the bays to be loaded in order, from left to right. The switches can only be accessed from the title screen (except the reset switch). Reset - Resets the game back to the title screen. Game Select - This allows you to increase the number of starting lives. Color/BW - This does... something... 🐰 Left Difficulty - A: Faster conveyor belt speed. B: Regular conveyor belt speed. Right Difficulty - A:Faster Dock Boy speed. B: Regular Dock Boy speed. These options can be chosen in any particular order in any particular combination. As the game progresses there are 3 different obstacles that will appear during a stage. These are as follows - Swipe - A bar will move from left to right and then back again. If it hits dock boy or the pallet it will push it in the direction it is going. Following Swipe - Just like above but now as you head to the bay doors it will move up or down with Dock Boy. Bouncing Ball - This will ricochet off of walls and boxes. If it touches a box in your hands the box will disappear. If it hits the pallet it will start reducing the number of boxes on the pallet. There is a way to destroy the bouncing ball though... The conveyor belt and Dock Boy's speed will eventually get faster. Right now those two things will occur at 500 and 1000 points. Also, after an interval of time you will get an extra life. Have Dock Boy pick up one of the boxes that come off of the conveyor belt and put it on the pallet. When the pallet is full (as indicated by a change in the jack color), push the pallet into one of the open bays up top. Each time a bay door is closed you will get a little time added onto the timer and some bonus points. Close all the bays and you get even more bonus points. The faster you go the quicker you build the timer back up. Attached is the latest .bin file. Enjoy! CROSSDOCK_16k_07_04_20.bas.bin CROSSDOCK_16k_07_06_20_a.bas.bin CROSSDOCK_16k_08_26_20_a.bas.bin CROSSDOCK_16k_11_18_20_a.bas.bin CROSSDOCK_16k_02_23_21_a.bas.bin CROSSDOCK_16k_03_23_21_aa.bas.bin

Shame. I just played around this game and found it really neat idea. One of my favorite NES games was Motor City Patrol and I loved the top down GTA games that came later. I thought this one was done really well and the translation of the Crazy Taxi gameplay on an Atari is amazing.

I followed the blog and posts. This project looks cool and is on my want need list.

Whoops. Yeah. counter =x.y Thanks. I'll have to play around with this.

I'm guessing when in assembly it knows where to go?

So data tables can be anywhere?

I think while typing up my question and rereading the code I think I may have answered my own question. I tried replacing the check with this: if z{6} && _sc2 =$05 && _sc3 = $00 then counter=0.0: z{6}=0 So far I haven't gotten anymore inconsistencies.

So I was taking a stab at making some difficulty progression, with one aspect tied to the score. I had it to where if the score hit 500 a bit would change and the counter should speed up and draw pixels quicker. What is odd is that sometimes it happens and then other times the counter pretty much stops. I am not sure if I am overlooking anything. This is the pixel routine temp2 = counter/8 - 5 if !counter & 7 && temp2 < 8 then var31 = dat[temp2] data dat $80, $40, $20, $10, $08, $04, $02, $00 end SKIP_CONVEYOR temp5 = (rand&15)+(rand&2) temp6 = (rand&3)+(rand&3)+4 if e{5} then goto PIXEL_GEN if z{6} then counter = counter +1.0 :goto PIXEL_GEN if !z{6} then counter = counter + 2.0:goto PIXEL_GEN PIXEL_GEN if counter <> 100 then SKIP_PIXEL_GEN pfpixel temp5 temp6 on counter = 0.00 if !d{3} && counter >0 then goto SKIP_STATUS if counter = 0 then statusbarlength=statusbarlength-4 SKIP_STATUS rem conveyor belt SKIP_PIXEL_GEN The check I made is this: if _sc2 =$05 && _sc3 = $00 then z{6}=0 Is it possible that if the timing is right, and the score is met, the counter switches to counter+2.0 and the counter <> 100 condition is never met so it skips the pixel code forever?

Okay. That clarified things further (more scanlines, lower frequency, etc). Thanks

Thank you for your explanation. When reading about it before, I kept picturing that one could just incrementally adjust the Hz and speed or slow things down. I think I have a better understanding now.

So this is a CRT. It doesn't look as bad with ToR. Now I did notice some differences between emulation and the TVs for my manatee game. And then the lighter color beside the ants and bars on this version of Aardvark. And then I noticed these discrepancies on the side of the screen (you can also see it in the Tyre Trax pic up above) on both the CRT and LCD. It looks as if each row may not be aligned.

I had a small CRT too. I didn't try it this time but if I remember I think I tried it back when I first tested this. I'm gonna have to set it up and do some comparisons. Is that something that happens with LCD and flicker management?

So I was playing Tower of Rubble on my Harmony and noticed when I tried a 2 player, the blue guy was a little blurry when compared to the red guy. This made me think back to this post. I had noticed some games didn't appear too bad but it made me wonder if there could be some issue with displaying certain colors. That might make sense as when I considered what games seem to appear blurrier. When I used actual cartridges of games I didn't have any issues. I had a AFP lying around so I compared it to that for reference. Here is what it looks like:

Would the surgery in M.A.S.H. count?

Thank you! I will have to look into all of this. I definitely want to have a good understanding of all the workings of the Atari and seeing how impressive the programs coming out are makes me want to think outside of the box to understand the limits.

I was just curious if at some point changing the Hz would be stable (like if 120hz would be okay but 112hz might cause issues) or if you could get the same effects as using fractional or sub-pixel movement while using a different method and possibly freeing up something. Again, my understanding is probably very simplistic and I was just trying to understand a little more of the hardware and possible methods. I read about how some games may be slower in a different region and it just got me wondering. Thanks for the suggestion

I was thinking about either something like that, or if it was possible to use this as a way to increase difficulty in a game, but I don't know if this would either be more effective or more efficient than other ways. How would one go about less total scanlines or increasing/decreasing the Hz?

I had been attempting to understand some of the development features of Stella and had a question regarding the jitter/roll effect. I had noticed that when shifting from player to developer mode, recovery slider changes from 10 to 2. Does this number mean if the number of frames with scanlines over 262 go over this the result would be jitter or roll? Is this a buffer?

After reading about this, is it possible to use this to slow a game or speed a game up? Can a programmer make a NTSC game but somehow use this to change the speed of there game? Is there a way to go slower or faster? Or do I have a simplistic and complete misunderstanding of how this works?