Schlortt

Since we want to always share our source code, I have been wanting to post this for some time, but I wanted to add better comments first. I did try to add comments to communicate what the general purpose of a section of code is, but there is still a lot that will need to be interpreted. This was written in MADS and requires BATCMP9.xex to be in the source folder. I hope that this is useful to someone. If anyone reviews the code and thinks of tips you would like to share with us, that would be most welcome. We are relatively new at this as War Room is the first game that we created that was created entirely in assembly. This started out as a movement demo for acceleration, deceleration, skidding, etc. As the ABBUC contest deadline loomed, we didn't have a new entry so we worked quickly to make this an entry which ended up being a very rudimentary game. Since we were developing it up to the last minute, you will see some hard coded memory locations. We also added the Halloween characters for our "final" release after ABBUC since the ABBUC version still had some shortcomings that we thought needed to be fixed. One of the nice aspects is that since the game really doesn't come close to pushing the abilities of the computer so we were able to leave the code pretty straightforward. I don't think there is anything novel here but we hope that since the examples are so simple, they can be beneficial for learning: 1. DLI - a very simple DLI that changes the playfield colors after that top of the screen 2. VBI - Deferred - again, very basic - it updates player locations, checks CD, disables break key and other housekeeping. It also uses a very sloppy shortcut to stop the players from turning to double-width which was a recurring bug that would happen- as I recall, this bug was properly fixed, but the code to set it to single-width is still in the vbi. 3. Self-modifying code. In order to save space, we overwrite the lo byte and hi byte of the LDA target. 4. Custom character set - very basic character set changes 5. Simple movement physics - acceleration 6. Very simple AI - I know what the AI is doing, and I very rarely win - simply stated, the AI is more aggressive when it has more life left than the opponent. If it has less life or equal life, it runs around shooting bullets. The big advantage that the AI has, is that it shoots very accurately. 7. PAL/NTSC detection and adjustments to try to make gameplay and music the same speed. The characters were built with Paul Lay's player editor - 16 frames, 15 high. The order of the frames is listed in the source - left, left, right, right, down left, down left, down right, down right, up left, up left, up right, up right, Up, Up, Down, Down. I would attach some/all of those files but it won't let me attach .apl files. Any questions regarding sound & music will need to be deferred to Eric. I tried to acknowledge the help we received in creating this, but I am sure that I missed someone. Eric probably has more to add because I don't know who he worked with. Enjoy! batcmp9.xex Published WarRoom.asm

I wish a book/guide like that did exist. Generally, I develop and run in Altirra with both settings. I know I am consuming too many cycles in the VBI when NTSC doesnt work and PAL continues to work. Because we only had real NTSC hardware and we expect a large number of potential players to have PAL systems, Eric traded with someone to get a real PAL Atari. An emulator is great but not enough to trust at release time. At the end of our development cycle, NTSC is always faster because so much of the timing is cycle based. The last step is to speed up the game when running on PAL. This is where I use those extra PAL cycles and, if any on the fly calculations need to be done to convert the speed, the heavy lifting is done in the PAL sections. Another note is that most speed adjustments are set at startup in our games so if you want to speed them up more, you can start Altirra in PAL and switch to NTSC after the game is loaded.

Thanks! I see that the video is from the ABBUC version. The latest software that Eric posted yesterday is much better for those on PAL. The ABBUC version was a little sluggish on PAL. I also wanted to acknowledge Playsoft and his great player editor http://www.playsoft.co.uk/aplayed.html Eric and I used the player editor to update characters and create new characters. We were frantically using it yesterday because we really wanted to get it released on 'H'alloween.

The multicolored tires is a sign that gprior (623)/ prior (53275) are not set. Enabling the 5th player (bit 4) is what allows you to set the missiles to a single color. I see in your code, you set 623. 623 is a shadow register for hardware register 53275. Shadow registers get copied to hardware registers by the OS routines during the vertical blank as I understand it. Additionally, the clock memlocs (18,19,20) are also managed by the OS routines so that should explain the clock not working. I think this explains what is going here, but whether you use the OS or write custom routines to meet your specific needs is up to you.

Try using the hardware registers for PM color since you are using a GTIA mode. POKE(704+i, PMColor[i]); // Set Player colors should be POKE(53266+i, PMColor[i]); // Set Player colors

Here is an example of what Irgendwer is referring to. In the first picture, you can see the car is ahead of the tires. This is because the position of the car was updated, then the DLI kicks off before the tire position is updated to match the car. In the second picture, there are missing interrupts (red circles) and it looks like some of the tires weren't drawn.

See the attached. In this instance, there needs to be an interrupt where the orange line is. You see that it is missing because the empty orange oval on the left should have a Yellow line in it indicating an interrupt.

The easiest to fix will be the top car. In your VBI, set the Missiles' horizontal position to match the horizontal position of the highest car. The highest car shouldn't need a DLI. Edited: If you want all your players to be horizontally in sync with the tires, you would update the player horizontals in the VBI instead of the main program. The harder part will be to synchronize the DLI's. If you load in Altirra and use Antic Visualization (CTRL+8 three times), you will see the dynamic interrupts you are creating on the left side of the screen. If you slow down execution (System/Speed Options/1%) you will see that things are a bit out of sync. Using this method should help you see how it is executing.

I love the player editor. Up to 16 frames of animation and each frame can have its own colors. The best thing is that it is an easy way to see what the third color of the overlapped two players will be. List the file and you have text that you can paste right into your BASIC program, assembly or C. He isn't paying to host that site anymore, but I hope he will add the standalone version to this thread.

This not precisely what you are looking for because it isn't a vertical scroller and it uses Antic $D or Graphics 7, but Rain of Terror (RoT) does a lot of DLI vertical management. It sets interrupts as needed and as chutes and fallers drop causing the interrupts to "cascade" down the screen. To see the effect, load up the attached .xex in Altirra and hit (CTRL-F8) three times to get to display list analysis. Run on warp speed for a while and the chutes will really start to come out. I had never worked with DLIs or assembler before RoT and threads from this board got me through it. The following is going from memory and it has been almost a year since I touched this code. I apologize in advance if my terminology is wrong and I also acknowledge that I likely violated some key principles of good coding but here is a description of what I did- Static DLI Lines: In the attached picture, you can see the playfield color changing dlis that have to fire in the same place regardless of what the falling chutes are doing. The color bands at the top are normal DLI stuff starting where you see the number 14. There is another DLI (30) that just does another color band change. (skip 31& 32 to 48,49 for now). The DLI on line 50 changes a color register from light purple to the green mountain and your last DLIs (80,81,82,84) change the ground color. Dynamic DLI Lines: The player DLIs are more complex. The player assignments are: p0=x-hairs (not affected by DLIs) p1=red plane, white chute P2=purple part of trooper (prior to being shot) p3=Trooper before chute open and trooper that has been shot (no chute) and falling fast. CHUTE OPEN DLI: At the beginning of the game, the chute opens higher on the screen. The 31,32 is where it can open a the start of the game and it will progress all the way down to the 48&49. The plane can't fly below this line because this is where p1 turns white and P1 HPOS is changed. The real DLI action occurs from 50 to 80 as there can be many copies of p1/p2 chutes and multiple copies of p3 (fallers). All of this was managed in the DLI and VBI. I really created 4 different DLI types and the end of each DLI changed the vector based on what needed to be done when the next DLI was hit. The 4 DLITypes were: onechange (e.g. change playfield color or change 1 HPOS) twochange - change 2 values (e.g.change p1&p2 horizontal position) chutesFaller - special DLI when Faller and Chute are on the same vertical line (change p1&p2 horizontal position and change p3 horizontal position) Ground Vector - it changes the ground color. Setting DLI Lines: 14,30,50,80,81,82,84 were always on but the "cascading" DLI lines were set in the VBI. In other words, I had to determine the vertical position of a player that needed its HPOS set, figure out the memory location of the display list line above that player by storing a 141 (antic mode 13+128) in the corresponding display list line. As the players were repositioned floating/falling down the screen, I kept a list of where I need to add interrupts in the display list. - Chute Open DLI was rather easy to manage because it only moved one line down when it did move. The worst part was every DLI between 51&79 was reset to 13 (Gr. 7 or ANTIC $D) in the VBI and specific lines were turned on based on the vertical positions of chute1, faller1, chute2, faller2, etc. This was fine in PAL but really pushed the limit on NTSC for VBI overrun. The VBI builds a list in this format: DLIType, lobyte*,value,lobyte(1), value(1),number of DLI changes,lobyte,value, etc An example would be 1,1,50,2,3,80,24,99 - this would change the chute (p1) to HPOS 50 on the first DLI line and on the next DLI line, it would change P3 to HPOS 80 and change PF color 2 (53248+24=53272) to 99. The VBI would also Reset the DLI so that it pointed to the vector for the color change on the first DLI line at 14. The pointer for the list would be reset in the VBI. The DLI not only made changes to the screen, it also set up the next DLI - The DLI code in each of the vectors would first make the changes to the screen and then set up the next DLI based on the "list" above. This included changing the vector and overwriting the constants and updating the list pointer. This allowed the beginning of the DLI (the time critical portion) to be more efficient with cycles. SPEED- If a chute and a faller were on the same line, I would have to make 3 changes in a single DLI - P1 HPOS, P2 HPOS and P3 HPOS. Fortunately, P1 and P2 were set to the same value so only one horizontal position value had to be loaded even though two values had to be stored. I didn't think it would be fast enough loading values from memlocs so I used constants and self-modifying code. The ground vector was created because it was more efficient to store three colors than rebuild a list every VBI for each the ground color changes. *The convenient thing is that changing player color, playfield color, and player horizontal all of the hardware registers have the same hi byte ($D0) so the lobyte is overwritten to store to the appropriate register. allasm2.xex

What is the standard practice when configuring memory for programs written in assembly on the Atari 8bit? I can think of three ways to do it: Static definition, macro driven and allocation at run time. -The first two are akin to hardcoding and would still have to be compiled for a specific memory size. For example, if you had a game that could fit in 16k, you would just set your RAMTOP, Screen Memory, Player memory, etc accordingly and it should run on any Atari 400, 800, XL, XE that had 16k or more memory. Is this correct? -Would there be any advantage, in terms of compatibility, to using the third (runtime allocation)? In assembly, I see this as a slight disadvantage because references to screen memory, player location, etc. become more difficult or add cycles using indirect indexing.