splendidnut

Hmmm... Although it fits in with the theme of the game, I don't think "scrambling" is a good word to describe what's going on development-wise. If I was working hastily, you would have probably seen more updates by now. So far, every time I've accomplished a few things, I've made it a point to post an update. This allows everyone, including me, to know the progress that's been made. I'd like to think things are way more organized now then when I first started. Not much progress has been made. I took a few days to work on an idea I had for flicker management, which didn't end up working. Then, this past weekend, I started reorganizing some of the code. I needed to split the burger logic and the player/enemy logic into separate banks. For the past few weeks, they've shared a 4k bank which was getting close to being filled. It would have been relatively quick except for the fact that DASM has no understanding of code banks and was giving me a bunch of obscure errors that took WAY too long to figure out. In the end, I discovered I had missed copying a single line when moving code around. After I could finally build again, mysterious game play issues cropped up which took another large chunk of time to figure out what was going on. In the end, I had moved a function and didn't realize in was no longer in the same bank as the table of data it was accessing. (AND yes, I am aware that, in a way, this counters my thoughts of being more organized now ) All these issues could have been avoided if either (A) DASM had better error messages, or (B) I had a better understanding of how to use DASM to its fullest potential. On the plus side, NostAlgae37 has finished all the animations and I spent last Friday night plugging in the data. Since one of those was the animation sequence for player death, I've added in the collision detection necessary to cause player death which seems to be working quite nicely. I'd like to get one more thing accomplished before I post another BIN for download.

Alrighty, so for enemies that land on the plate piles, they need to move to the edge of the burger before moving toward the nearest platform. Is there a limit to how far they can travel up? Such as in level 4, it seems quite a distance if only one or two pieces are on the plate. I would almost think that would cause a position reset when they re-spawn, Thanks for the insight! It sounds like I need to be quite flexible with my enemy AI to allow the different combinations of forcing turns or allow direct pursuit. I just played around with the first level in the arcade game, and it seems very inconsistent: For the most part, enemies were forced to turn at intersections. On ladders with a direct line of sight, they pursued directly. (both Mr HotDog and Mr Egg) On occasion, Mr Hotdog seemed to purse directly when on the same platform... but not all the time. So I guess the big question is do I given the enemies relatively consistent pursuit patterns? Possibly one style per character type? Do I add random hiccups? Do I change the patterns based on levels? There are lots of different ways to go about this... Thoughts anyone?

Ah, that makes sense... I was originally thinking there was some condition (like number of enemies on burger piece) which determined whether they were killed or not when riding the burger pieces. But it makes way more sense that they die and re-spawn in the exact same spot.

That would be a missing feature. Currently the enemies are only stunned when they ride a burger. Then when they stop being stunned, they continue on their merry way, except if they're on a burger pile... then they don't know where to go. Currently I'm unsure of the rules that govern whether an enemy is stunned or killed when riding a burger. Anyone have any insight into this?

If you really want to see bugs come out of the wood work, try level 4 (the one that has the 8 piece tall burgers).... which I've been working on today to try and fix. Seems I'm starting to run out of available processing time... I might need to migrate the game logic to C and start really using the ARM chip.

If they are standing on the pieces they rode, I would say no. If anything, it's an off by one error that is potentially acceptable, for me at least

Time for an update... with New Sprite Graphics done by NostAlgae37 Other things updated: Fixed the bug Arenafoot found - enemies should no longer fall thru condiments on the piles at the bottom. Enemies can now be squashed/killed by falling condiments. Enjoy. chaoticGrill-2018-09-21.bin

Time for another update... not much different from the previous one... except for bug fixes! Mutliple enemies riding on the burgers and burger then dropping the appropriate levels - that all seems to be working now. I've now started work on enemy squashing, which isn't working yet, so it's been disabled. Please let me know if you stumble upon any bugs. Enjoy. chaoticGrill-2018-09-15.bin

Thanks! My understanding of the enemy movement is that the enemies are suppose to alternate between taking ladders and platforms... with a preference for ladders. Which might explain the "coin flipping" and "last second" direction change that you're seeing. I think the pickle might be different... as he seems to take a more straight/direct path towards the player. Let me know if this lines up with what you're seeing. My current implementation of enemy movement is overly simple... and gets tripped up because it doesn't properly identify intersections... which is the main cause of the enemies getting stuck on the ladder. I've been putting off redoing the enemy movement code while I concentrated on the burger dropping logic (one of the most important aspects of the game). But now that I'm starting to work on the enemy squashing code, my overly simple enemy logic is working against me. So that'll probably jump up the priority list.

Time for a buggy update. I've added the ability to give the enemies a ride on the burgers with the additions necessary for the burger pieces to drop multiple platforms when an enemy is riding. It's a bit buggy... sometimes a burger gets stuck between platforms, and sometimes the enemy doesn't ride the burger. But it's fun to have the ability to send the enemies for a ride. Also... added another level... for testing purposes of course... SELECT switches levels. To summarize: - Enemies can now ride burgers... (buggy) - Enemies are stunned afterwards. - Burgers can fall more the one platform... triggered by enemy riding... (buggy) - Added a level... now there are 4. Enjoy. chaoticGrill-2018-09-08.bin

Thanks for letting me know... I enjoyed watching.

Over the past week, I ended up doing a lot of rework on the burger dropping code which spilled into reworking the level layout data structure which then spilled into the player/enemy movement code. The results: - Burger dropping appears to be completely functioning. - There are now 3 (three) levels included with the ability to rotate thru using the SELECT switch. - Enemies will appear to get stuck on occasion... this is part of a patch I added to prevent an infinite loop from occurring. Here is the updated version: chaoticGrill-2018-09-05.bin

How about some burger dropping action? Burger dropping seems to be working properly now... FYI, music is currently turned off in this build because it was getting annoying... that and it makes it easier to hear the rudimentary sound effects. chaoticGrill-2018-08-30.bin

And now both the Player and the Enemies appear to correctly obey the level layout Here is a bin of the latest update: chaoticGrill-2018-08-25.bin

Well actually...if I could correct myself... the short story would be yes... but not enough to share yet

The short story is no. After last summer, I got busy with other things and the project was thrown on the back burner. I did some work back in January, surprisingly, which involved improving the player movement logic... which I've started working a bit this morning. It's now in a very good state. The player appears to properly obey the level layout. Now if I can get the enemies to follow suit... That'd be enough progress for me to share another build. We will see what today brings. As a side note... Back in March, I was contacted by another homebrew developer who was/is very interested in doing a Burgertime remake. Whether this person wants to reveal themselves or not, is up to them. So it's quite possible there will be a Burgertime remake in the near future... whether it's this one, or that one. Well that's interesting... Do you happen to have a reference for that mention in Zeropage Homebrew? I'd be interested in seeing it. I kind of went looking for it thru one of the videos... skimmed it a bit... but didn't stumble upon it I will say that Zeropage Homebrews is a very neat concept.

Wow, you have quite a few esoteric motherboards there. Looks like a few are missing the essential pieces (missing BIOS, riser boards, etc...)

Just downloaded the new version... I'm really liking the new phosphor emulation mode. The flicker (with phosphor mode on) definitely looks closer to what I see on my 1997 CRT TV. Thanks for all your hard work!

Quite a nifty little game. Looking forward to seeing this progress.

I just realized that this seems very similar to C--.

Ah. I missed that the first time thru. Nice to see easy inclusion of an assembly language file... But what about a block of inline assembly code? I'll admit, that I was spoiled by Turbo Pascal in that aspect. I don't think I've ever come across a C compiler that has done it as nicely as Turbo Pascal (version 6+). Here is an example of a full procedure: Procedure ClearMem(MSeg,size:word); assembler; asm mov ax,MSeg mov es,ax xor di,di xor ax,ax mov cx,size shr cx,1 stosw end; And an inline block; procedure PrintError(s:string); begin asm mov ax,03h int 10h end; writeln(s); end; That would be my feature request.

Do you plan on allowing inline assembly code?

Ata-C by Gip-Gip: https://github.com/Gip-Gip/AtaC

Thanks for the compliments! I'm hoping to keep my motivation going... and try to get this done in the near future. Hopefully sooner, rather than later.