Sknarp

The Multisprite Kernel could use a little love, I can't say for sure that it is the Kernel or the emulator the Atari flashback uses but any game using it doesnt work 100% correctly- I even made a 4k game and with the stock MSK there is still an alignment issue. Everyone including myself thought it was because of my modifications but yeah it happens with a stock MSK.

Hello, I haven't been on the forums for a while so I just saw this, to clarify : CRT The Chromatic was the only actual Atari 2600 game I finished in 2019 and seems to be missing from the list. Stake Toss and Pixel Ninja Pit Jumper are not active WIPs, I was just getting myself familiar with the software Not a big deal but I'm not using RTs suggested code for FP numbers in the Atax-Atax WIP so it remains a solo project, However I did use code provided by Karl G in CRT so credit is due to him ?

I agree with the others. I thought it looked fantastic, but then realized it wasn't supposed to be read as "Maiiard games" so you should make the L's more obvious.

Nice start, I definitely think dev threads are a good idea because there's any number of choices/issues/changes that can come up during the process and you never know what information might be helpful to others in the future.

Thank you, that would be an awesome bit of information to have for sure. I've been using the syntax if !var1=var2 then a lot so if I need to change it to if var1<>var2 then it's not going to cost me any efficiency and I'll just adjust my style, but if it's safe to do it either way it's good to have the flexibility. As for using if !myvar then instead of if myvar=0 then I can't find the exact post right now but I'm positive I got the idea from some previous post on AA about space saving techniques, so it's important from an efficiency standpoint to know if you can't use ORs with the trick. I understand that it'll be a while before we get the definitive answer, I might just do a preemptive rewrite to be safe either way.

Alright, so I went ahead and tested if <> has any advantage over !=, because I would love to know of any way to optimize- unfortunately it makes zero difference. In my tests of four conditonal checks using != vs the same four checks rewritten with <> instead, both sets of four checks take up exactly 32 bytes of ROM (8 bytes per conditional check) and take 64 cycles (16 cycles per) so it's just a matter of programmer's choice of style. I really don't understand why you're saying I can't write a conditional that uses a ! token and an || token... There's no reason as to why you can't in the linked page, and the "more information link" just brings you to another copy of the same warnings with again no explanation and a link back to the first verbatim warning. Also it does seem to work just fine, and even if the chart is accurate it says you can use OR with = and the condition if !varthis || !varthat is the same thing as saying if varthis=0 || varthat=0 so I'm really confused on WHY it would only work when written one way, Is there a source post somewhere that explains where the chart came from?

Nice, added FP only using 74 bytes- most of which are if statements unfortunately but it might be well worth the cycles for sure. Could I ask a couple of questions about the opts you did? I noticed in the for loop for movement you used <> instead of typical equivalency (= or !=)- I couldn't find much information on if this has advantages- is it faster? Does it take less bytes? Also in the main loop you combined the collision checks, but on the win screen you separated out the switch checks, Which is better: using a bunch of &&'d ifs in one line or doing them as single checks over seperate lines? I really appreciate your help and input- your website is one of the main things I refer to when I am curious how to use a function of bB.

It's done to save on space, indexing the memory space of one player and incrementing the index/offset..It's probably better I just show the code rather than fail to explain it. If you want to compile this you'll need the modified includes in the same directory, otherwise there's not enough free space. WIPsourceAA.bas multisprite_kernel.asm score_graphics.asm

I tried to use FP, hung the compiler BAD - eventually got it to work, but it didn't actually have the desired effect because of decimal points being truncated when applied to an integer like x positions. Hanging the compiler (I assume) caused me to eventually be unable to compile any code- and also caused some sort of leak that was making my entire computer slow down. I was able to fix ability to compile by moving the most vital files to a new directory (The old directory will be deleted just to avoid that happening again) and the effects on my computer was mitigated by excessive swearing and a forced reboot. (I probably needed to do a fresh restart anyway, I'm lazy about those) At the moment I am not intending to use Fixed Point anything for anything I will still try tweaking the for loop to see if I can make it look more fluid

Is it their movement speed, or is the jerkiness happening when you are on the same Y as the enemy? If it's the later, I think it's a kernel-related issue that's over my head.

Switch Support & Game Modes When I was programming in the switch support I saved 4 bytes on every switch check by using bit checks instead of bB keywords Title screen now supports Select Switch as well as Fire. Main game now supports Reset Switch. Win Screen supports both the Select Switch and Reset Switch. Two game modes (LEFT "Difficulty" Switch) and Two difficulty settings (RIGHT "Difficulty" Switch): Less than 150b left. Let me know if there are any game-breaking bugs I need to fix. New binary! Enjoy WIP_ATAX-ATAX_by_SKNARP.bin

Player0 sprite: The player0 sprite wasn't completely centered, This was easy enough to fix The sprite looks almost exactly the same during gameplay, but now won't be offset if you turn around in a tight area, this helps to ensure you won't get stuck in a wall. Kernel Timing I used something like 15 cycles where I had 12 to work with, there was always a bit of room to go a little over-cycle at this point in the kernel (I belive at least 10-20 over was the wiggle room), but I found that one of the opcodes was unneeded (STA PF0), so I removed it and should be cycle exact now. Two Week Progress Report Currently at 16 screens (not counting the title), and 528b free. I also still have 28 variables free. I am now 14 days into development of this game. I still have some time this evening so I might still get more done tonight.

No, apparently I have Build 566, I'll have to update. Thank you RT

My apologies if this has been mentioned already, but I couldn't find anything in the search. inline ASM throws some warnings- "asm is not a recognized keyword" and more frustratingly "end is a duplicate label definition" if you use more than one block of inline asm, the latter has an annoying tendancy to pop up every time I write any line of code, anywhere in the program, which constantly snaps the window around to focus on where the warning is being generated from.

Very cool. It's quite difficult, I can't get more than 8 notes in, and that requires some concentration to pull off.

NTSC runs roughly 17% faster than PAL (someone with more knowledge feel free to correct this number) So anything you can do within the timing of an NTSC should be able to be done in the timing of a PAL. Your timing will be different, so the kernel and anything else that makes assumptions about the passage of time would need to be adjusted. NTSC and PAL also use different colors, so you'll have to adjust any time a color is being used. (And probably can't exactly replicate the NTSC colors) I believe it could be done, but would require some time and effort.

Small fixes: I forgot to mention in the last update that I put a cap on the counter which controlled when the player could shoot- this fixed a glitch where sometimes you couldn't fire right away (because the counter had wrapped back to zero) After posting the binary, I also took another look at the title screen and decided that some of the letters looked too blocky, so minor edits to the title screen. The HP bar hack: One byte of RAM is used to be able to draw to 8 pfpixels right below the bottom of the normal playfield area. This was based on a suggestion I received to add a health bar. (This is the binary that I posted) After posting the binary, I then received another suggestion that the health bar should change colors, so I used one more byte of RAM to be able to change the color. Now I have an HP bar that goes from green (full HP) to yellow (when HP is below 45%) to flashing red (when HP is below 11%) This trick takes about 100 bytes to pull off, mostly because of the conditionals used to decrease the size and change colors of the bar, making it the least optimized part of the whole program. 916b of free ROM (with 12 screens) becomes 806b free. The 30 bytes of free RAM becomes 28 bytes. I'll have to really evaluate if this feature is worth the cost, but for now I'll leave it in until space gets crunched more- at which point I may either need to remove it or (hopefully) find a way to optimize the conditionals. Adding playfields Further changes since the last post. I added a couple more playfields, this brings it up to 14 playfields with 660b free. After looking at what I have so far, I shuffled the default order of the playfields around so that there's better continuity from one screen to the next. I still need to add a few more, then I can start programming in the different game modes. EDIT: I figured out how to draw the HP bar on ONLY the left side of the screen, but to do so I have to draw it as 2 scanlines tall instead of the 3 scanlines tall it is in the binary.

It occurred to me that the "extra playfield pixels" I referenced in the last post could be re-purposed to do something useful. I had 40 cycles of free time at the bottom of the display kernel, I wrote a simple hack that uses 28 of those cycles to draw the contents of a variable to PF1, I chose the freed up "score" variable for this, added a little bit of code to the main loop and.... now I have an HP bar. The player's color was the only indicator of health before, going from bright yellow to dark yellow to signify shield, and bright white to dark grey to signify ship damage. I admit it was a little convoluted but it was the most efficient way of doing it I could think of at the time. Now there is an HP bar just below the bottom of the playfield so there is an additional indicator of remaining HP. The only issue with the way I implemented this is that there is a mirror/repeat of the HP bar on the right side. Please try the binary and tell me if this works, or if I should just remove it. Note: This is still a WIP so gameplay is not 100% implemented yet- but there's enough for you to play around with for the purposes of this test. WIP_AA_HPTEST.bin

Daily Progress Report: Kernel improvements, adding more playfields. Did some more editing of the MSK, moved some subroutines into the empty space previously occupied by the scorepointer routines, this saved an additional 22 bytes. Then I went into the scoregraphics, deleted all of the bytes used for drawing the numbers, and adjusted the ORG offset to save another 80 bytes that was being wasted defining the score digits 0-9 This puts the free space over 1K (960+22+80) 1062 bytes of ROM free. 30 bytes of RAM free. After adding a couple more playfields, I noticed that the last row the playfield was being printed twice. In the kernel there was a few STA PFx commands at the bottom that I had removed. When I put them back in, it fixed the double row issue- but it brought back a pretty common bug- there was a few pixels of extra playfield, 1 scanline high by about 1 pfpixel wide. I went back to the bottom of kernel and moved the PFx opcodes to the top of the list of STAs so they happened a few cycles earlier, and finally the bottom of the screen is totally clean. Adding two more playfields brought me down to 916b free - even though the playfield only uses 19 bytes of data there's an unfortunate amount of padding. I don't think I should devote any more time to trying to shave off bytes though, instead I'm just going to see how many playfields I can realistically fit in while still allowing myself a little bit of room for the game modes I have planned.

After reading the suggestions of BNE Jeff, I moved a couple subroutines into the extra space (where I previously had to sleep or align 256). This is pretty well cleaned up and has additional savings of 22-44 bytes over the previous posted versions. multisprite_kernel_NOSCORE.asm

Thanks for the information, after some consideration I went with And not only did I avoid sacrificing 22 bytes, I actually saved another 22 bytes! Very happy with the results.

Today's improvements: gave the sprites more character, freed up some RAM for a change. I managed to remove the final bit of the score routine, which was swapping around temps and scorepointers. This means lots of extra RAM: 13 variables that are unused (4 from not needing a minikernal, 6 from the scorepointers, and 3 from the score). I'm not sure if temp1,temp2 and temp6, temp7 are usable, but if they happen to be then the second chunk would be 8 spaces long instead of 6 and the third would be 5 long instead of 3. Contiguous space is always nice to have. Right now I'm only using variable a-i, that leaves j-z(17) and the freshly freed variables(13) for 30 free variables. I also took some time to make the sprites look a bit better.

Hello, so at the bottom of the kernel (HERE if you want to see what I'm talking about ) I've found only two ways of making sure it's aligned so that the positioning of objects doesn't get messed up, either which looks really inefficient, or this which looks like a better implementation, but seems to waste 22 bytes compared to the other. I don't know which I'm "supposed" to use, but would like to save the bytes if possible. Is there another way of doing it that I'm missing? EDIT: I believe this achieves the same thing... could these bytes could be used for something? It still feels like a waste if the data isn't being used for something, but at least this doesn't sacrifice that extra 22 bytes of ROM space.

Removed the noscore const check previously it had a jsr to a routine I'd removed, so the whole check is gone now, in case someone accidentally set a constant. Cleaned up the part of the code where the sixdigitscore was patched in, it looked like at least 3 separate people had rewritten it, with the indentation changing abruptly. I aligned the indents and deleted obsolete comments so it's easier to read, no change in functionality. scoreremoved_multisprite_kernel.asm