Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store  

cd-w

Members
 View Profile  See their activity

  • Content Count

    2,433

  • Joined

  • Last visited

  • Days Won

    2

Blog Entries posted by cd-w

  1. cd-w

    Juno Todo List

    By cd-w,

    I've made some more progress on my Juno First game. The main change is the addition of a startup screen and the high-score table kernel from the last entry. I've also added SaveKey support, but it is commented out at the moment as I haven't been able to test it properly yet. I've left in the "Enter Name" screen, but in the final version this won't be shown unless a SaveKey is connected. The main game hasn't changed at all yet, except for the scoring which I have divided by 10 (it was too easy to wrap the score before).
     

     
    Here is a list of things left to do now before the game will be complete:

    Test Savekey support.
    Add player and alien explosion sound effects.
    Add "new wave" sound effect.
    Fix hyperspace scoring.
    Fix astronaut collection bug.
    Implement more waves (I'm aiming for either 32 or 64).
    Change background colour during hyperspace (if possible).
    Show score at end of game.
    PAL90 colour conversion.
    AtariVox support.
    Attract mode (not sure yet).

    It looks like there is going to be around 4K spare at the end. I might use this for another set of colours, or I could include an Easter egg (PM me if you have a good small game that you would like to see on a cart - no promises)!
     
    Let me know if I have missed anything from this list, or if you spot any bugs or screen jumps.
     
    Chris
  2. cd-w

    Score Kernel Revisited!

    By cd-w,

    It seems that nobody was impressed with my 16 character kernel last time - the main problem being the introduction of unnecessary flicker! I wasn't entirely happy with it myself, but I couldn't think of a better solution at the time. However, based on batari and Manuel's comments I decided to have another look at the no-flicker 13 char text demos. The 13+2 char demo uses a neat trick of rewriting NUSIZ during a scanline to squeeze in an extra two characters (in addition to using the ball and missile sprites to draw the 13th character). This trick provides exactly what I need for my high score table:
     

     
    The first part of the kernel arranges the sprites like this (P0 is set to 3 copies medium and P1 is set to 3 copies close):

    0--101-10
    Using the NUSIZ trick it is possible to display another copy of P1 (by setting it to 3 copies medium after the third sprite is drawn). This gives the following sprite layout:

    0--101-10--1
    This layout provides the necessary four-part display (Position, Score, Initials, Wave) that I was after! The spacing between the columns isn't perfect, but I think it looks good enough in the screenshot.
     
    The attached code demonstrates this technique. I haven't actually tested this on real hardware, so I hope the NUSIZ trick works in practise (it works fine in Stella and Z26)? Hopefully everyone will agree that this kernel looks much better than my previous attempt!
     
    Chris
  3. cd-w

    16 Char Text

    By cd-w,

    I have written another text kernel which displays 16 characters. This may seem pointless, given my earlier 24-char and 28-char kernels, but it has several nice features:

    Uses less ZP memory (46 bytes total).
    Shows more lines on screen (14).
    Text width is a power of 2 (for easy calculations).
    Kernel has loads of free cycles (around 40 per scanline), e.g. could have a PF image underneath.


     
    The main reason for writing this kernel is to allow the Juno First score table to be displayed nicely on a single line, rather than split across lines. I'm planning to integrate this, together with SaveKey support, in the next release. Note that I haven't included the level number as there is no room to store this in a single page on the SaveKey.
     
    Chris
  4. cd-w

    Juno Playable!

    By cd-w,

    I have done some more work on my Juno First game recently. The game code has now grown rather large, and it is becoming increasingly difficult to make changes without causing breakage or exceeding the scanline counts. Also, I'm now into the tedious last 5% of the implementation, which involves tying up all the loose ends and adding polish. However, I'm determined to finish the game this year without getting distracted by any other shinier projects!
     

     
    The main change in this version of the game is the addition of 8 levels to the game, this means that it is finally possible to play the game properly! The other main changes in this version are:

    A new colour scheme supplied by Nathan (colours change on alternate waves - see screenshot).
    A message display at the bottom of the screen.
    Lots of code reorganising.

    Note: It is essential to play this game with Phosphor mode enabled (-f for Z26, or Alt-P in Stella) or the game becomes (more of) a flickery mess!
     
    The main things left to do now are more levels (I think I can fit around 32 levels in the game), Savekey/AtariVox support, more sound effects, and an attract mode if there is space.
     
    Anyway, let me know what you think of the levels - they are a bit rough at the moment and not properly tuned. I think the game is going to be very hard indeed as I haven't managed to finish these levels without cheating (but it could just be me)!
     
    Have a Happy Easter,
    Chris
  5. cd-w

    Juno Levels

    By cd-w,

    I have done a lot of work on the Juno First levels today. The aliens should spawn further apart (to reduce flicker) and they shouldn't appear directly in front of your ship any more (most of the time). I have also expanded the game to 16 levels, and I will be amazed if anyone can complete them all! Let me know what you think of these levels. In particular, are they too repetitive or too difficult? I haven't made any other alterations to the game yet - the changes discussed in the previous entry will be coming in the next few releases. I'm actually enjoying playing this game myself (which is rare), so I think it is coming along nicely!
     
    Chris
  6. cd-w

    Juno Integration

    By cd-w,

    I've now integrated the Juno title screen and main game together into a 32K ROM (see attached). There isn't anything really new here, but I have sorted some long-standing issues in the code. In particular, the scanline count should now be stable at 262 in the main game - let me know if you see any screen jumps (except between the title screen and game).
     

     
    The main things left to do now are:

    Add a lot of levels.
    In-game sound effects.
    SaveKey support.
    Tune the gameplay and add more polish.

    Chris
  7. cd-w

    Juno Sounds

    By cd-w,

    OK, here is a small update to Juno First. The main change is the addition of sound effects to the game. I initially tried to approximate the arcade effects, but eventually gave up and just went for effects that sounded reasonable. Let me know if they sound OK, and if the background hum is too annoying (I don't want a repeat of Hunchy 2!). I haven't added all the effects yet - I'm still trying to find a reasonable explosion sound for the aliens, and a few other spot effects. This version should also fix the screen jumping issues - let me know if you find any more!
     
    Chris
     

  8. cd-w

    Juno Title Revisited

    By cd-w,

    OK, I'm leaving my text kernels alone for the time being and attempting to get back to coding Juno First. I have attached a minor update to the Juno First title screen code. It doesn't contain anything new, but it integrates together various features that have previously been discussed separately here:

    Contains the awesome Silkworm tune by moderntimes99.
    Displays the score table in white (rather than striped).
    Alternates between logo screen and high score table.


    My plan is to save the high-scores on the SaveKey, but this will have to wait until I dig out my hardware again as the SaveKey isn't yet supported by any of the emulators. I was also planning to use AtariVox sound effects to the game. However, on reading the documentation it seems to require a lot of time to communicate with the SpeakJet chip, and I don't many spare cycles in the Juno code. The next step is to attach the title screen code to the main game and start making it playable.
     
    Chris
  9. cd-w

    More 28 Text

    By cd-w,

    I'm still having fun writing text kernels. The latest version (attached) is an update to my 28char kernel to display multiple lines of text. This new kernel shows a 28x12 display without any restrictions. The kernel doesn't use any illegal opcodes, and there are still around 30 free cycles per-line, so it should be possible to display a few more lines of text with some work. Unfortunately, as before it has a 20Hz flicker, so it is essential to use the phosphor options under emulation. I'm still interested to know if the flicker is bearable on a real TV set?
     
    Chris
  10. cd-w

    13 Lines

    By cd-w,

    I decided to experiment again with my textkernel to see if copying the text into zero page memory would be useful. The advantage of using zero page RAM to hold the text is that it removes the need for the text to be in the same bank as the display kernel. The text can be loaded into RAM in one bank and then displayed by bank-switching into the display kernel. Another practical advantage is that it becomes possible to create text dynamically in RAM without the need for the text to be fixed in ROM.
     
    Fortunately, copying into RAM didn't impose too much of a penalty and it allowed the buffer creation code and display kernel code to be overlapped. As a result, I can now display 13 lines of text on the screen, as shown below:
     

     
    The kernel takes up a whole 4K bank now and is fairly RAM heavy, though some overlapping may be possible (as suggested by supercat in the last entry). The text data is double-buffered, so it would actually be possible to display the last line of text immediately after the second last, though this would look a little odd. I am reasonably happy with this now, as it manages the same number of lines on-screen as the ET Book Cart, while flickering much less! I think this is really as far as it will be possible to go with this approach, without merging the text characters in advance, though I said that last time!
     
    I think this would now make a very nice kernel for a text adventure as it enables text to be loaded from anywhere in ROM. I'm not too keen on this kind of game, so I probably won't be doing it myself. However, I've attached the source code and anyone is free to use it in their own projects (though drop me a line first if you do).
     
    Chris
     
    Edit: textkernel3.zip is the new 13 line kernel, and textkernel_zp.zip is the 12 line kernel from the previous post adapted to use zero page RAM.
     
    textkernel3.zip
    textkernel_zp.zip
    font.zip
  11. cd-w

    Text Kernel Take 2

    By cd-w,

    I've done a little more work on my text kernel. It still displays only 12 lines of text, but the code is cleaner and it now shows lower-case letters and numbers (the text is from "The Hunchback of Notre Dame"):
     

     
    I can get this up to 14 lines by overlapping the buffer creation code with the display code (there are lots of free cycles in the kernel). The problem is that this requires four versions of the copying and kernel code, which takes up nearly the whole 4K and leaves very little room for the actual text. This could be solved by copying the text into zero page memory and then doing a bank-switch into the kernel code. However, the copying code would require 24 iterations of the following code (24x10 cycles = 240 cycles = 3.2 scanlines), which would negate any savings with this method!
     

    lda (TEXTPTR),Y sta BUFFER+? dey
     
    This is probably as good as I can get the code without pre-computing character pairs (as in supercats method), but this would be difficult with lower-case characters ...
     
    Chris
  12. cd-w

    Text Kernel

    By cd-w,

    It has been nearly a year since I updated this blog, and just about as long since I did any Atari programming. However, things are a bit quieter for me at the moment and I decided to write a text kernel as a way to refresh my 6507 programming knowledge. My first attempt is attached to this message and is an extension of the Juno First title screen technique in my previous blog entry. The screen-shot below shows the results - I have managed to get 12 lines of nearly flicker-free text (24-chars wide) on the screen:
     

     
    I would be happy with this if it weren't for a much better text kernel that supercat posted recently, which gets nearly twice as many lines of text on-screen. As a result, I'm going to try to improve this code to see if I can squeeze in a few more lines. I'll post the results here if I manage to make any improvements.
     
    Chris
  13. cd-w

    Juno Title

    By cd-w,

    This is just a quick update on my Juno First project. I have now created the title screen, thanks to some more amazing artwork by Nathan. I was aiming to reproduce the look of the Arcade title screen as far as possible, and I think I have managed to do a reasonable job given the limitations of the 2600 (arcade shot on the right ):
     


     
    The logo is 96-pixels wide and is created using the Homestar/Ruby Runner flickering trick. It is necessary to use the Phosphor option in the emulators (Game Properties->Display under Stella) or it looks like a mess. There is one small issue with this technique when using a real TV, and that is a banding effect between the columns. I think this is caused by colour bleeding, but I'm not entirely sure. This banding effect is shown (exaggerated) in the screenshot below:
     

     
    Anyway, even with the banding effect, I think the logo looks very nice. The binary and source for the title screen are attached at the bottom of this message. This screen will be included in my next Juno code release (hopefully sometime soon). One of the few things missing from the game now is some music for the title screen - there isn't any in the arcade game, but title music seems to be the norm for Homebrew Atari games! If anyone has any spare music that they would like to contribute, then I will be very grateful!
     
    Chris
  14. cd-w

    Juno Update

    By cd-w,

    It has been some time since I last posted an update on my Juno First game. The project has been on hold for a while, but it has not been abandoned completely. One of the reasons that it stalled is because I wasn't completely happy with the kernel. My aim for the game was to have full colour sprites that are updated on every line (1LK). This should make the game visually superior to similar games (such as Beamrider), but it is quite a challenge to achieve!
     
    I managed to get the kernel working, except in one case, which would cause the gridline to jump in an annoying way. The source of the problem is that the alien sprites need to be repositioned at various places on the screen, and this repositioning takes a screen line to accomplish. This repositioning can clash with the drawing of the gridline, as there isn't enough time to do both. In most of the screen this wasn't a problem, as I just delayed the repositioning by 1 line when this happened (with a gap of two screen lines between aliens). However, at the bottom of the screen the ship also needs to be drawn every screen line and this trick doesn't work. My solution was to draw the gridline immediately after repositioning in this case, but this causes the gridline to be drawn one line further down, and leads to the annoying jumping effect.
     
    For a long time, I tried to re-arrange things to avoid the jumping problem. I managed to get within a few cycles of a solution by resorting to some loop unrolling, but I just couldn't make it fit! However, I recently read this post in batari's blog and was inspired to have another go. The suggestion in this post is that it isn't always necessary to waste a complete line on repositioning the sprites, since most of the repositioning code is just waiting for the correct position. Instead, it is possible to implement a series of mini-kernels that each reposition the sprite in a different horizontal position, and also have some spare time to do extra work! However, this technique is difficult to implement and requires a lot of ROM space.
     
    In Juno First, the aliens don't go completely to the edges of the screen, so there are ten different horizontal sprite positions. Therefore, 10 mini-kernels are required to implement the technique. I used the following code to jump to the correct mini-kernel:
     

    ; Set pointer at beginning of kernel lda #>ReposFunctions sta JPTR+1 ; Jump to correct minikernel ldx XPOSITION lda ReposTable,X sta JPTR jmp (JPTR)
     
    The jumping code costs only 15 cycles, but it requires a fairly large table of pointer values. In Juno First, there are 15 pointers required for each of the 10 mini-kernels:
     

    ReposTable DS.B 15, #<Repos0 DS.B 15, #<Repos1 DS.B 15, #<Repos2 DS.B 15, #<Repos3 DS.B 15, #<Repos4 DS.B 15, #<Repos5 DS.B 15, #<Repos6 DS.B 15, #<Repos7 DS.B 15, #<Repos8 DS.B 15, #<Repos9 EndReposTable
     
    Within each kernel it is necessary to hit the RESPx register at exactly the right time and also to set the HMPx value. I accomplished this with the following code fragments. Obviously, the cycle on which RESPx is hit, and the sbc# value must be changed in each mini-kernel.
     

    ReposX ; Reposition Sprite (Coarse) sta.w RESP1 ; Must happen on exactly the right cycle (20/25/30/35/40/45/50/55/60/65) ... ; Fine Tuning (X contains sprite position) txa sec sbc #30 ; Change value for each mini-kernel: 15/30/45/60/75/90/105/120/135/150 sta HMP1 ; Can happen anywhere before HMOVE ... ; Move Sprite sta WSYNC sta HMOVE EndReposX
     
    Anyway, to cut a long story short, I managed to get this technique working in Juno First after a lot of tweaking. The results are attached to this message. The kernel now takes a whole 4K bank and is the most convoluted bit of code that I ever hope to write! However, it has got rid of the annoying jumping gridline, so I am pleased with the results. I have also made a number of other tweaks to the Juno code since my last posting:
    Homing bullets are now implemented (although slightly buggy)!
    All the different alien types have their own movement and firing patterns.
    You have three warps (shown by the W's at the bottom of the screen). Pressing Select will make your ship disappear for a short time (handy for avoiding bullets).
    There is a nice reverse-explosion when the ship appears on the screen.
    You have to hit fire to start the game, and to resume after you die.
    The game now has all of the important features that I planned to include, although there is still a lot of polishing to do. I'm not going to make any rash predictions about when I will get this finished, as at least the following tasks have still to be completed:
    Implement lots of levels with different alien types.
    Make something happen when you pick up an astronaut!
    Add some cool sound effects!
    Add a title screen and high score table (see previous post).
    Add more polish if there is space, e.g. music, attract mode, colour schemes, etc.
    As always, let me know if you find any bugs or have any suggestions. The game works in both Stella and Z26 (use phosphor mode), but I haven't tested it on real hardware. I will strongly resist any changes to the kernel now, except if there are any bugs
     
    Chris
  15. cd-w

    Highscores

    By cd-w,

    Well, it has been 5 months since my last blog entry! A lot has happened to me in this time, including finishing a book, getting engaged, moving house, and changing jobs. Most of these have been good things, and I will try to write about them in more detail in the future. However, it has all left me with very little time to do any Atari programming. I started the year with big ideas (i.e. PoP) and planned to enter the 8K minigame competition (with Juno First), but this has not been possible. It also looks like I will be busy for some time to come, and as a result I haven't been able to help out with this years' holiday cart. However, there is one small Atari project that I have managed to make some progress on, and I though I would post the initial results here.
     
    A feature that is missing from most Atari games, but is ubiquitous in the Arcades, is the "high score" table. Now that the SaveKey is available there seems to be no good excuse for this omission. I though it would be a good idea to try and write a generic Top-10 highscore routine that people could include in their games. I also wanted to include a highscore feature in Juno First, should I ever find time to finish the game. It turns out that it is quite difficult to design a high score routine as there are lots of exceptions that can occur, e.g. if the savekey is removed, or errors occur during reading or writing. As a result, I first designed a state chart which covers most of the possibilities:
     

     
    The main difficulty of developing for the Savekey is that it isn't currently emulated in either Stella or Z26. I had hoped that it might be possible to use the Savekey with the Stelladapter, but this doesn't seem to work. My Atari stuff is still in deep storage since I moved, so I haven't been able to test my code properly, but I have written some initial code that follows the state chart above. The code is completely unoptimised and takes up a full 4K, but I wanted to check that it works before I start shaving cycles. Also, I figured that anyone else using this code would probably want to customise it themselves, and any heavy optimising would get in the way.
     
     
    Edit: Minor code update - fixed some obvious bugs and optimised a bit - still untested on real hardware:
    controllerpics.zip
     
    The initial code and binary is attached above. In Stella, it gets stuck waiting for you to attach the Savekey, while in Z26 is acts as if the Savekey were connected. I have attached a couple of screenshots below so you can see the main screens. I will be grateful if someone could try this on a real Savekey, although it may corrupt any data that you have on there, so be very careful! Let me know if you find any bugs or have any suggestions for improvements. The text kernels are just for demonstration purposes and will be improved later.
     
     
     
    Chris
  16. cd-w

    Krokodiles

    By cd-w,

    Last week I received a shiny new Krokodile Cartridge (KC) in the mail. I had been on the waiting list for some time, so it was great to finally get hold of one. It came at a good time, as I needed some way to test my Juno First game on real Atari hardware since exceeding the limits of my Supercharger (SC). In addition to permitting binaries over 4K, the KC has a number of other advantages over the SC: it doesn't require the weird audio setup that I was using to transfer game images, it has a lot more RAM than the SC, it permits multiple games to be stored, and it keeps its content when the power is switched off. As a result, my old SC will now be retired from game development duties, unless I am actually developing for the SC itself, e.g. if I revive my PoP game.
     
    There is one small problem with the KC though: it doesn't have a Linux driver. This is an issue for me as I do most of my computing work under Linux. I do have a Windows installation, as it is sometimes unavoidable, but I would prefer not to have to use it everytime I need to write to the KC. As a result, I decided to investigate the Mac OS-X driver to see if there was some way to port it to Linux, since the two systems have many similarities. SpiceWare was kind enough to send me the source code for his OS-X driver, and a copy of the KC serial transfer protocol document. It quickly became apparent that the protocol was very straightforward, and it wouldn't take too much work to port the driver across. However, as my C coding is rather rusty these days, I thought I would have a go at porting it to Java instead. The advantage of this is that the same code would work across multiple platforms, and it would be easier to build a GUI.
     







     
    To cut a long story short, I have spent the last couple of days rewriting the KC driver in Java. The serial port communication is accomplished using the Java Communications API. I am actually using the RXTX implementation of this API, as it is available on many more platforms than the Sun version, and seems to be more actively developed. The latest version of my Java code is attached to the bottom of this entry, and there are basic instructions in a README file. It can already download a single file to the KC under Linux, and I have tested it with a variety of different bankswitching schemes. This is actually all that I need, as it lets me test my Juno First game on the KC, but I am planning to clean it up a bit and add multicart support in the near future. I haven't tested it on other platforms, but the Java code should work fine if the correct RXTX implementation is used. Anyway, let me know if this is useful to anyone, or if I am the only Linux hacker around here? At the moment the code is really only intended for experienced Java hackers, but I will improve it further if there is any demand. I don't have any plans to add a GUI at the moment, but I may do this in the future (or someone else might volunteer ).
     
    Chris
     

  17. cd-w

    Krok Redux

    By cd-w,

    It appears that my Java port of the Krokodile Commander software generated almost no interest at all I guess all the people who were previously asking for a Java version on the forums were actually just wanting a Mac OS X version. Nonetheless, I have done some more work on the Java version to add multicart support, and increase the transfer speed. The new version is attached to this entry, and the documentation is contained in a README file inside the zip. It is still a command-line application, but it now has essentially the same feature set as the OS X version, except for the cart database. This is probably as far as I will go with this as it now does everything that I want with the software. However, if anyone else would like to improve it, e.g. add a GUI, then they are more than welcome to modify the source code.
     
    Chris
     
    EDIT: I have attached a precompiled version of the jkrok software for Linux x86 below. Instructions are in the README inside the zip. Let me know if there are any problems, as this was done in a hurry!
  18. cd-w

    Japan

    By cd-w,

    I haven't been very active on the AA site recently. This is not because I have lost interest - it is just that I have been travelling around the globe recently as part of my work. I have just returned from Japan, and I though I would write a little bit about it here. I won't bore you with the work side of things, instead I want to write about the three days that I had to myself in Tokyo.
     
    This was my first trip to Japan, and I wasn't sure what to expect. The country has a kind of mythical status among computer gamers, being the source of so much gaming culture. The impression that one gets before visiting is that Japan is some kind of futuristic technological utopia - naturally the reality is somewhat different! It is certainly true that games and cartoons have a firm place in Japanese culture, but they are only a small part of the whole picture. From a technology point of view, Japan is roughly the same as the US or Europe, though they do have slighly better mobile phones (all G3) and musical toilets!
     
    I don't want to shatter your illusions of Japan completely, so I will confirm that Tokyo is a very impressive city, and walking down its streets is an exhiliarating experience. This is mainly because the city itself is so huge and vibrant. I have visited New York many times, and so I though I knew what a big city was like, but Tokyo is something else. It is really lots of smaller cities all compressed into one huge mega-metropolis. Each sub-city in Tokyo has a different feel, but at no time did it feel intimidating or over-crowded (except on the subway). The people were all very friendly and helpful, and I had no trouble getting around, despite my mininal understanding of the language. Naturally, one of the first places that I went to visit was the Akihabara electric city.
     
    cnc_nes__.eps_.zip
     
    Akihabara is basically an area of around 5 blocks square completely filled with technology stores. It was a bit overwhelming at first as the place is filled with flashing signs, loud music, and shopkeepers all vying for attention. However, it doesn't take long to block it out and after a few minutes I was hunting for the good stuff, i.e. retro games. About 50% of the stores were selling electrical items (e.g. microwave ovens), and around 30% were mobile phone shops, so it was relatively easy to make progress. It didn't take long for me to locate the famous Super Potato store which is probably the most well-known place for retro games in Tokyo. It is basically two smallish rooms completely stuffed with consoles, games, and accessories. You can find just about anything from Nintendo, Sony, and Sega there, including lots of game-and-watch machines, weird console accessories, and various toys. They even had a Japanese Vectrex, and an Atari 2800, but they were very expensive. I had a great time just looking at everything, but in the end I bought very little as I didn't plan ahead properly, and my skills at decoding Katakana were very limited. I found a few other retro games stores in Akihabara, but Super Potato was definitely the best. I also picked up a Nintendo DS-lite and a copy of New Super Mario Bros just for good measure!
     
    The rest of my time was spent sampling the excellent food, and looking at the various tourist attractions in Tokyo. In the end, 3 days was nowhere near enough and I am already attempting to engineer a return visit. I would highly recommend anyone to go there if they haven't already been. It is definitely a cultural experience and very different from western norms.
     
    On another note, I have made a bit of progress with my Juno First game. The latest version is attached to this message. It doesn't look too different, but the code has been substantially restructured and improved. Basically the previous version had completely exhausted the available memory and cycles, so it was necessary to do a lot of unrolling and optimising before any further progress could be made. This took a lot of time, and required cycle counting for almost the whole game! However, this version should now have enough free space to enable me to complete the game. As usual, let me know if you find any bugs, or have any suggestions.
     
    Chris
     
    cnc_nes.zipcnc_nes__.al_.zip
  19. cd-w

    Missiles

    By cd-w,

    Here is another quick progress update on my Juno First game. I have now implemented the missiles, which were the final missing feature in the game. Up to 8 missiles can be shown simultaneously on screen (using flicker). There is still a bit of tearing when the missiles pass over the grid lines, but I hope this isn't too noticable. The missile firing patterns are rather boring, but I will improve this later. I was originally planning to use one of the missile sprites for regular missiles, and one for homing missiles. However, it looks like I might have to drop homing missiles from the game. The problem is that the missiles can't be distinguished from one another, and I can't work out how to efficiently implement a suitable homing algorithm. The best that I could do was to move the missile directly towards the player, but this didn't look very convincing and was nearly impossible to evade. I have been trying to remain relatively faithful to the arcade game, but there are some features that probably won't be possible. My latest thought is to implement slow and fast missiles instead of homing missiles, unless anyone can think of a better solution?
     
    Chris
  20. cd-w

    Problem Solving

    By cd-w,

    I am often struck by the similarity between the activities of game playing and game creation. In both cases, there is generally a long sequence of problems to be solved with an eventual goal in mind. These problems can have complex dependencies, and finding a good solution can make the difference between reaching the goal and starting over. As I have previously noted, I actually gain more enjoyment from creating games than I do from playing them. According to some friends of mine in the games industry, this is not uncommon. Many of them suck at playing games, though they are experts at creating them
     

     
    With this in mind, I have made some further progress on my Juno First project. To get this far, I have solved a very long sequence of problems, many of which I didn't think would be possible. Nonetheless, there remain many more problems that will have to be addressed if the game is to be completed. As time progresses, these problems are getting harder to solve as available resources on the Atari are diminished. The main changes to the game this time are:
    The aliens now move around the screen. They all use the same basic movement pattern at the moment, but I think this looks very cool!
    The game has now been expanded to an 8K ROM which has thankfully relieved many of the memory pressures. I eventually adopted the scheme that supercat posted last time (thanks!). I'm not quite sure that it will work if the game starts in the wrong bank, so I would be greatful if someone could check the code (just before SEG BANK2).
    The explosion sprites have been altered and there is now a flame effect when the spaceship moves forward and backwards. Also, the spaceship will explode and then reappear if you collide with an alien. I am very grateful to Nathan for all of his help with this.
    There are still a few remaining issues in the code. In particular, the spaceship will explode if an alien hits the flame. This is because I am using harware collision between the aliens and spaceship. I think I will need to move to a software region-checking approach, but this is going to take a lot of cycles. If anyone has an efficient techniqe for checking if a moving sprite enters a fixed region then I would be very grateful. The next step is to go through the code carefully to spot possible optimisations as there are now very few cycles remaining anywhere.
     
    Chris
  21. cd-w

    The Next Step

    By cd-w,

    I spent the weekend working on my Juno First game, so here is another update. The main changes this time are:
    There is now an explosion animation for the aliens, and some of the sprites are animated at their largest size.
    The alien spawning code is in place, so the aliens appear one by one at the beginning.
    The length of the laser beam shortens as it goes up the screen (I know I said this wouldn't be possible )
    There is now a basic 6-digit score at the bottom of the screen.







     
    The main problem now is that the game has reached the 4K ROM limit, so I haven't implemented the velocity on the spaceship yet (this will require a large table of values). The only kind of bankswitching that I have done so far on the Atari is the Supercharger scheme. I am tempted to make a SC version of Juno First for a certain competition as this would enable a more colourful kernel and possibly multiple sprite copies. However, before I go down this route, I would like to implement a standard 8K version using F8 bankswitching. If anyone has some template code or knows of a good method then I would be grateful for advice. If there are any bugs or issues with the game, then let me know. Also, if the screen turns red at the edges then let me know as this means that the game has run over the cycle limit.
     
    Chris
     

  22. cd-w

    Flicker Fest

    By cd-w,

    This is just a quick update on my Juno First game. I hope people don't mind me using this blog as a beta testing area. However, I find it useful to post these development versions as the folks here are quick to spot bugs and problems that I might not notice otherwise. The previous versions had a number of serious bugs, but I hope that most of these have now been resolved. The main features this time are:
    All 20 possible sprites are now displayed on screen. This causes some serious flickering, but this should not be so bad in the final game as the sprites will be moving and the maximum number will only rarely be reached. The flickersort routine uses almost all of the vblank area, so let me know if you see any screen rolling.
    I have started to implement the collision detection code, so it is now possible to shoot the aliens. An explosion effect will be added later.
    The sprite movements should be a bit smoother, and the spaceship velocity decreases if you do not hold the joystick foward or backwards.
    Some of the sprite sizes and colours have been tweaked thanks to suggestions by Nathan.
    Anyway, let me know if you sport any problems, or have any suggestions? The source code is included in the ZIP file as usual.
     
    Thanks,
    Chris
     
     
     
  23. cd-w

    Two's Complement

    By cd-w,

    The Atari 2600 is a difficult machine to program, but the 6502 assembly language in which this programming is done is relatively easy to understand. Nonetheless, there are certain features of this language that I still don't completely understand. One of these is the indexed indirect mode that I taked about in a previous entry, but this is not a particularly useful feature. The other issue for me is two's complement binary arithmetic which I view as a necessary evil. Two's complement is not specific to the 6502, but this is the only context that I regularly come in direct contact with it. I undertand the principles behind the notation, but something always seems to go wrong when I attempt to put it into practice.
     
    Two's complement notation allows you to represent numbers in the range 0->255 or -128 to +127. The numbers 0->127 are represented the same way in both schemes. Similarly, if you only need to deal with positive numbers then there is no real difficulty. However, negative numbers get a bit more tricky! In this case, the upper bit of the number represents the sign, e.g. 0xxxxxxx is a positive number and 1xxxxxxx is a negative number. You might think that -1 would simply be represented as 10000001, but this is not how things are done as there would be two zero values (+0 and -0). Instead, to convert a number into its negation you invert the bits and add 1, so -1 becomes 11111111, which is 255 in the normal way. This scheme is very clever as it does not require any extra hardware to cope with negative numbers, but can be a pain from a programming perspective.
     
    The problem that I have with two's complement is that you have to be very aware of the ranges of your numbers or nasty things will happen, e.g. 130-5 can give you unexpected results if you are not careful! Also, if you try to mix numbers of both kinds, or do signed comparisons on unsigned numbers then you are likely to end up with a headache. In the past, I have usually avoided these problems by sticking to positive numbers, but in my Juno First project the complexities of two's complement have been unavoidable. In particular, the speed of the spaceship is represented as a number from -16->16, and the coordinates of the aliens are represented as numbers from 0->255 which wrap around. I have spent the last week trying to get the aliens to move forward and backwards properly. This has been significantly complicated by the fact that the aliens move at different speeds depending on where they are on the screen, i.e. aliens in the distance move slower than those in the foreground.
     
    The results of my efforts are attached to this message. The aliens are stationary (for now), but move forward and backward according to the movement of the spaceship. In Juno First, the top of the screen acts as a kind of scanner which shows the aliens far in the distance. If you move backwards, then these aliens appear from behind, i.e. the play area wraps around. The movement of the aliens is slighly jerky, but I hope that the illusion of perspective is there. Let me know if you think this looks OK, or if this could be done in a better way, also let me know if the flicker is acceptable (using the phosphor option on Z26 or stella helps a lot).
     
     
     
    The code for the alien movement is not yet complete. In particular, if you change direction some of the sprites will disappear for a bit until the flickersort code moves them back into the right order. I haven't yet figured out completely how to avoid this, but I think that it can be addressed using a circular buffer. I am still using a sprite index in this version, but I have implemented Manuel's cool suggestion, where the index values are the same as their positions within the index. Thanks for all the other suggestions - I still haven't completely decided on the final solution. However, the flickersort and index creation are now done by the same code which saves a lot of cycles. I realised that the values in the index were precisely those that were not swapped during the flicker sort routine
     
    The game is still coming along nicely, but I really could use some extra memory! There are now just four main parts of that have to be done in the core before the game will become playable:
    Finish the sprite sorting/disappearing issue, so that the sprites are always drawn in the correct order.
    Implement collision detection, so that the aliens can be destroyed.
    Implement procedural movements for the aliens, so that each type of alien moves in a different way.
    Figure out how to spawn new aliens, so that they appear in the correct place at the right time.
    Chris
     
     
     
    :!: EDIT:
     
    After various comments yesterday about jerky sprites I went back and looked at the alien movement code. A bit of searching revealed an implicit assumption that the sprite positions were in a strictly increasing order, though this is not always the case when using flickersort. I have now removed this assumption and posted the new version below. Unfortunately this change is rather computationally expensive, so there are less sprites on the screen. However, I hope that this now removes most of the jerkiness from the sprite movements? If so, then I will work on optimising this solution.
     
     
  24. cd-w

    Programming on Paper

    By cd-w,

    I have always preferred programming on paper for some reason. I think this is because I didn't have a computer at home when I first learned to program. The only computer available to me for a long time was in my school, and its usage was strictly controlled and very limited. As a result, I used to write out my programs by hand in exercise books, and spend my precious computer time typing-in these listings and attempting to debug them. At the end of the session, I would print out what I had done and then spend the time away from the computer working out the bugs. These programs seldom worked, but they were a great learning experience.
     
    This is still the way that I prefer to work, though I don't generally write out the initial program listings by hand anymore. Instead, I type up a rough version of the code directly onto the computer, and print out a copy that I then study for optimisations and bugs. I think the main problem that I have with programming directly onto the computer is that you only get to see a small part of the code at once. With paper, you can spread out all of the different parts on your desk and get a real picture of how it all fits together. There are various IDEs and folding editors that attempt to address this problem, but I prefer to use a standard text editor (xemacs) and printer paper.
     
    The best kind of paper listings were the old fanfold kind, where each listing was essentially a continuous sheet of paper. You could spead it out on the floor and follow the control flow up and down the paper. When I first started at University, the lab had an old chain printer which printed out listings on 160-column fanfold paper. Actually I think it was a dot-matrix printer, but it was still called a chain printer as this is what it had replaced. This printer was managed by a supervisor who would put each listing into a pidgeon hole for later collection. The advantage of the 160 column format was that you had a huge amount of space next to your listings in which to make notes, draw diagrams, and document your code. Unfortunately this printer and the supervisor were replaced by a laser printer around 10 years ago now. I still think that I would be a better programmer if I had this printer, but these days I make do with 2-up laser printed listings.
     

     
    The point of this nostalgic trip is that for the last week or so I have been carrying around a listing of my Juno First kernel. Every time I have had a few spare minutes, usually on the bus or train, I have taken out the latest listing and started tightening the code. Occasionally I will spot a neat trick, or solve a difficult timing problem, which generally causes a big smile to appear on my face, and probably causes those around to question my sanity! At times like this my girlfriend usually makes comments about geeks and the reason they have trouble finding women
     
    Anyway, I think that the Juno First Kernel is now nearly complete, though obviously this is just the first step of the game itself. The latest version is attached to this message (the source code is in the ZIP archive). This code fixes many of the bugs in the previous version, and includes a variant of Manuels flickersort routine for displaying multiple sprites within the same horizontal region. The flicker will be much less noticable in the actual game as the sprites will be moving and should only occasionally overlap. Also, it will look better on an actual TV (use the phosphor option in Z26 or Stella to see this). The alien sprites do not move yet, but this is my next task. I still haven't come up with a solution to the HMOVE problem outlined previously, though I might just live with the lines as they are not too distracting. Overall I am very pleased with the way that the game is turning out so far ...
     
    Chris
  25. cd-w

    More Harmony

    By cd-w,

    I've been doing a bit more work on the Harmony project recently (together with batari and Thomas Jentzsch).
    It was a bit of a struggle, but it actually seems to be working now - teaser shots below:
     



     
    Chris
AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...