Jump to content

Schlortt

New Members
  • Content Count

    25
  • Joined

  • Last visited

Community Reputation

39 Excellent

About Schlortt

  • Rank
    Space Invader
  1. That tool uses the .apl extension. You want to “save” or “save as” so you can retrieve the sprite later. To create the data to use in your program, choose “list” and it will save a text file that you can open and extract the data you need. Use notepad or your text editor of choice. Keep two separate files: the .apl and the .lis. The tool does not provide a way to load from the .lis file.
  2. Thanks for sharing! I had that exact TV that I used with my 800. I think it was an RCA 13" which was color and a huge step up from the previous black and white television I had. It was a huge cost at the time because a 13" black and white TV could be purchased for less than $90 while color was over $200. I am talking base model prices without a remote and not cable ready, I don't even remember what the cost of a Trinitron was back then.
  3. Even the original NES version had some flickering. One example is if you don't use the warp in World 1-1. Toward the end of the level, if Mario is on the ground, you have Mario and 4 Goombas on the same horizontal line. Mario and the 1st and 3rd Goombas are solid. The 2nd Goomba flickers slightly while the fourth Goomba is very transparent due to flickering. Watch here: https://youtu.be/1qcTwuKozs8?t=77 Obviously, 5 objects that are each composed of two players on the same horizontal line is a nightmare for PM graphics if you are striving for a flicker free game. If someone is considering using character graphics, one thing in the original that bodes well for the A8 is that Goombas share the same colors as the background Black, white? and (orange above ground and blue when underground) so you would have enough colors for the Goombas. Also, when you are underground, I don't think you have anything that you need to mask since the background underground is black. Above ground, there are a lot of shrubs, etc that would create a lot of overhead and tons more work.
  4. Zone Ranger is one example that uses XOR but to perfectly mask, especially on a character that stays in focus like this, you would want to pre-render or use an AND and then an OR. The explanation that resonated most for me was in the "Image Masks" section of this article: https://en.wikipedia.org/wiki/Mask_(computing) I know Popmilo has done a lot of work in this area. See this thread as well which discusses performance and other concerns: http://atariage.com/forums/topic/242523-software-sprites-too-much-complicated-on-atari-8-bit/?view=findpost&p=4082808&hl=%2Bsoft+%2Bsprites
  5. If I heard the right song based on the timestamp you provided, I think this is the same tune from the C64 version. I can't find any details about the name of the song, though:
  6. I hadn't seen Vroom before. When I watch videos of it, it is very interesting to me that most of the motion seems to be in the road and not on the road side. I realize that is somewhat of an illusion as there is shading an the perspective keeps changing, but solid colors sides and road could work. I found this interesting on the old style racers: http://www.extentofthejam.com/pseudo/ And then someone implemented the ideas in Javascript: https://codeincomplete.com/posts/javascript-racer/ When I look at the source for the Javascript and how many things are easily rendered and calculated with built in polygons or trig functions, it makes me appreciate the work of the 8 bit developers even more.
  7. James Hague later wrote the book Halcyon Days which is interviews with classic game programmers and Atari 8 bit is well represented. Its free to read at his site Dadgum.com.
  8. I had a wico red ball. It was good and reliable but I never understood why they put a button on top of the ball when no arcade game that I knew of had a button on the ball. One interesting stick that I had was the Amiga Power Stick. It was way too small and very sensitive. One interesting thing was that if you pushed the stick into the base, it would signal all directions simultaneously. The best use of this on the Atari 8 bit was with "Beyond Castle Wolfenstein" because it would immediately take you outside the castle (which meant you survived even if you didn't complete your mission.)
  9. Mr. Do and Mountain King. I remember liking the music in Tail of Beta Lyrae. I enjoy the title screen music in Spider so much that I spent much more time on the title screen than I ever did playing the game. I assume the last option in your poll was offered in jest but it would have applied to Spider for me if the music had been in game.
  10. I had to look at this a few times because I am so used to MADS. With MADS, this: stx rejx ... rejx equ *+1 ldx #$ff ... rti would look like this in MADS: stx rejx ... rejx ldx #$ff ... rti If we think about what "rejx" is, it is an address. For the purposes of this exercise, let's say that rejx is at address $3550 If you look in memory at $3550, you will see: $3550 $A2 $FF $A2 is the HEX ASM command for Load Absolute value into X. $FF is the value that will be loaded. So... if we LDX #$01 STX rejx+1 We just stored a #$01 in $3551 it is now: $3550 $A2 $01 which means LDX #1
  11. That high score screen looks fantastic. It seems like something that could be made into a standard "utility" type component that could be used by a lot of games. The reason that I think this would be a great candidate for a "universal module" like this is: 1. It doesn't have to be completely optimized and customized compared to functions used during game play where you have to squeeze out every cycle to get desired frame rates. 2. Maybe I am only speaking for myself, but it does things that I don't enjoy programming like list sorting, player initial entry, save to disk. 3. If multiple games moved to the same format of saving high score tables, I would guess that over time, people would think of ways to work with that data. I know that yours is specific to "SKI-IT" so the utility would need to allow for configuration of values (title, scores instead of times, etc.) Also note that I am not suggesting that you build this, it was just a thought I had after seeing your brilliant work. Also, I am assuming a pre-coded high score utility like this doesn't already exist but if it does, I look forward to hearing about it.
  12. Thanks! I like it. Same speed as using ZP and saves a ZP memloc for just one extra byte of memory.
  13. I am enjoying this thread as an exercise in seeing how many ways this can be done. When I was trying to learn how to use DLIs,every example from the old magazines and De Re Atari all pushed A, X, Y to the stack at entry and pulled them back right before the RTI. Even if you aren't using ZP, the cycle savings on this thread vs what you find in those old sources are invaluable. The way I count storing x and loading it vs transferring it to the stack is 8 cycles vs 11 cycles: ; Save X at beginning STX XTemp ; 4 cycles ; Load X before RTI LDX XTemp ; 4 cycles Total: 8 Cycles and 6 bytes of memory (placing XTemp in ZP would be 6 cycles and 4 bytes of Memory) VS ; Save X at beginning TXA ; 2 cycles PHA ; 3 cycles ; Load X before RTI PLA ; 4 cycles TAX ; 2 cycles Total: 11 cycles and 4 bytes of memory. my cycle counting source is: https://www.atariarchives.org/alp/appendix_1.php BTW, I think that if you did put XTemp in ZP, you could also use it in your VBI for temp storage for other purposes. When I say "temp storage" I am referring to a value that only is used during the same instance of the DLI/VBI in which it was created. Also, using XTemp outside of the DLI\VBI could be disastrous because an interrupt could happen at any time and use the wrong value. If my thinking is wrong on this, please let me know.
  14. If someone has the inclination and energy, it would be nice to have "Giant List" exclusively for Atari 8 bits like the one that James Hague built for multiple developers of the 8 bit era: http://dadgum.com/giantlist/. I would expect several individuals are in both lists but I didn't spend a lot of time looking. For example, Paul Lay is in your list and James Hague's list but Hague's list doesn't include Paul's work that is more recent than 1991: Lay, Paul [TB] Freeway Ace (1985, 800, Page 6) Sprong (1985, 800, Red Rat) [T] Freeway Ace (1986, 800, Page 6) [T] Floyd the Droid Goes Blastin' (1986, 800, ANALOG) [TB] Revenger (1986, 800, Page 6) Floyd The Droid On The Run (1986, ST, ANALOG) Missing...One Droid (1986, 800, Bug-Byte) [T] Munchy Madness (1986, 800, Page 6) Boulder Dash-like [T] Heavy Metal (1988, 800, Page 6) Mad (ST, Page 6) Boulder Dash-like Crossland (1988, ST, Soundware) [T] Star Rider (1989, 800, Page 6) Pogotron (1989, 800, Artronic) [T] Hot Blocks (1990, 800, New Atari User) Tetris-like Spaced Out (1991, ST, New Atari User)
  15. 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
×
×
  • Create New...