Jump to content

cd-w

Members
  • Content Count

    2,433
  • Joined

  • Last visited

  • Days Won

    2

Everything posted by cd-w

  1. Yes, it amazing how much space can be saved when you really put your mind to it. I have now managed to free about 30 bytes of ROM (and there is plenty of free RAM), so I will have a go at implementing a better gravity routine soon. Chris
  2. Thanks - I'm glad you liked it (your "Go Fish" game is much better though!). I couldn't figure out how to make a good laser sound with the TIA, so I went with this instead. If anyone has a better effect then please let me know ... Chris
  3. I don't think a faithful version will be possible on the 2600, as there are a lot of sprites on-screen at the same time. However, I could probably implement the bit where you have to construct the spaceship instead of just collecting fuel. Chris
  4. Thanks for the feedback. There is already a bit of a gravity effect to stop you plummeting instantly when you release the thrust, but it could be better. Also, there should probably be a delay when you are moving downwards, and you hit the thrust, though this would probably make the game a lot harder. I don't think I have space in 1K to implement the fractional technique, but I might work on an extended version later. Thanks, Chris
  5. Hi jussts, Those sprites are fantastic, and will make my game look a lot better! The Quasimodo sprite is rather gruesome, but stll great. In the extended version of the game, Esmeralda will appear in the window in every level, and will come down to meet Quasimodo on the final screen. There is a picture of this on the Hunchy Development Page. At the moment, the Esmeralda sprite is not animated, but it would be great if she could greet Quasimodo in some way (I was just going to have her bouncing up and down!) The height of the sprite is not a problem. Many thanks, Chris
  6. I have attached the ROM (and source code) for my second Atari 2600 1K minigame to this message. The idea for this game came about while I was working on a new missile routine for Hunchy. The actual game was inspired by JetPac on the VIC 20 (and other platforms). The aim is simply to collect fuel for the rocket ship, and avoid the missiles. The controls are left/right and thrust (fire button). I didn't have space for a score or energy indicator, so the sky is used instead. The height of the sky indicates your energy level (you die when the sun sets), and the colour of the sky indicates the game level. There are 16 levels in total, and the sky colour changes every second level. The number of missiles, and the quantity of fuel that you need to collect increases on every level. Anyway, let me know what you think. I'm not sure that the gameplay is quite there yet, so if you have any suggestions then I will be happy to hear them. Chris jetman01.zip
  7. Thanks for the feedback, and I am glad you enjoyed playing it. The game is currently running at half speed, so it would certainly be possible to increase the speed after completing all the levels. I have attached a version of the game without the delay, so you can see what this would be like! Unfortunately I can't find the space in the 1K version to implement this properly, but I will keep it in mind for the extended version. Chris hunchyfast.zip
  8. Martin, I am not sure why you are having problems with the ZIP file. However, you can download the ROM file and ZIp archive directly with the following links: Hunchy v0.3 (NTSC) Hunchy v0.3 (PAL) Hunchy v0.3 (ZIP) I would also be interested to see your 2600 port of the game. Chris
  9. Thanks, it is definitely better than my version - I will incorporate it in the next release. Also, I am using a 2pixel/line (2LK?) resolution in the vertical direction. Chris
  10. Thanks - I have attached a new version which uses this routine. There is also a preliminary 50Hz PAL version included in the archive this time. Chris hunchy03.zip
  11. I'd be very grateful if someone here has time to design some sprites (or just a main character sprite) for my Atari 2600 Hunchy game (see this thread), as graphics are really not my strong point. The game is based loosely along the plot of "The Hunchback of Notre Dame", and the "Hunchback" arcade game. What I need is basically are three sprites as follows: 1) The main game character Quasimodo, who should ideally have a hunched back. 2) The gypsy girl Esmeralda, who is to be rescued by Quasimodo. 3) A soldier/guard who is defending the wall along which Quasimodo runs (apparently the current version looks like a girl with a blue dress)! The sprites are currently all 8 (width) by 16 (height) pixels, and ideally I would like to stick with these sizes (particularly the width). Each line can be a different colour (on a black background), though ideally all the animation frames would have the same colour scheme. At the moment, only the Quasimodo sprite is animated, though a bit of animation on the other sprites would be welcome. Thanks in advance, Chris
  12. You will be happy to know that this is the very last level of the game! I'm not sure this one is possible as I haven't managed it myself yet ...
  13. Thanks for the pointer - I will change this in the next release of the code. I have tried my code on real hardware with my Supercharger and it appears to work. However, I'm running on PAL hardware and outputting an NTSC picture, so it is probably not the best test of compatibility. Do you (or anyone else) have a version of the VERTICAL_SYNC macro which is known to work, as the old versions do not seem to be available from the DASM page? Chris
  14. I have attached an updated version of my hunchy game to this message. The key change is that the game is now 1K in size (ready for the minigame compo). The other changes are: 1) The graphical glitches are now mostly fixed (thanks vdub_bobby). 2) The damsel (Esmeralda) is now gone along with the final screen, as it wouldn't fit into 1K. 3) The levels should be a little bit easier to complete, and there is an extra level. 4) The GPL license has been removed Please let me know if you find any glitches or bugs, as the code had to be obfuscated a bit to fit into 1K. Also, let me know if you have any suggestions for the upcoming 2K "Deluxe" edition. Chris hunchy02.zip
  15. I am attempting to convert some colour values from NTSC to PAL using the TIA Color Charts. This is proving to be a difficult process, and so I have two questions: 1) Has anyone already produced an approximate mapping of colour values between PAL and NTSC. 2) Is there really no PAL value for pure yellow? Thanks, Chris
  16. Thanks for all the comments - it's very encouraging to see so many downloads in such a short time, and hear that people are having fun playing it. I thought I would reply to the posts in one message rather than individually: 1) The level with the vine and the single overhead missile (level 12) can be done by waiting for the first two missiles to pass, and then catching onto the swinging vine immediately after the third missile passes overhead. I'm not sure about the level 2 screens after this one (level 14) as this is one level that I haven't managed to do myself yet. I might need to tweak the timing on this one a bit. 2) I'm not sure why it is difficult to grip onto the vine. You simply need to jump towards the vine and release the fire button and hunchy will grip automatically? 3) The enemies who jump up at you are supposed to be soldiers or guards. The top bit is supposed to be a helmet, covering their eyes. I admit that graphics are certainly not my strong point, and I intend to ask the pixel artists around here if they can design some better sprites! 4) It would be great to release a cart containing all the 1K games that have been produced for the minigame competition this year! 5) I hadn't really given the license issue much thought as I tend to release all my code under GPL. Basically I just wanted the code to be free for people to use in their own projects. However, the point about the code being derived from other examples is certainly true, and I will release the next one without any license to be fair to everyone. Chris
  17. Thanks for the suggestion. I put the player data in one spot and it did indeed save space (and fix the glitch). I've been optimizing it all weekend and it is now just a few bytes over 1K in size. I will post an update here once I have workerd out the last remaining issues. I just hope the minigame competition this year doesn't change the file sizes! Chris
  18. Yes, there is a bit of a glitch with the player for the first few pixels on the LHS. The write to GRP0 happens on cycle 27 which is just a bit too late. I think I need to juggle things around a bit in the kernel, or learn how to use the VDEL registers properly. Any suggestions on how I can tighten the Kernel would also be welcome. Chris
  19. I have finally managed to finish my first Atari 2600 homebrew project. The results should be attached to this message. It is basically a version of the classic Hunchback game. I don't think this game has appeared on the 2600 before? The source code is included in the attachment (GPL licensed). There are still a few graphical glitches, so I would welcome any suggestions for improvement. I was hoping to make it a 1K minigame, but at the moment it is a bit over 1.5K in size. Please let me know what you think, and any suggestions for improvement. Chris BTW: There are 15 levels in total - I think they can all be completed, but I haven't managed to complete the last 2 myself yet! NOTE: The latest version can now be found here. hunchy01.zip
  20. Many thanks - for some reason I thought you had to completely reposition everything from scratch each time. I've now got it working properly by tweaking HMBL on every scanline. Chris
  21. I am currently trying to get my head around sprite handling on the 2600. I think I have the main concepts down now, but I am having some difficulty putting it into practice. I am trying to draw a swinging rope ladder using the ball sprite (see attached file). The code mostly works, but for some reason the sprite position is incorrect every few scanlines. It looks like the sprite position is being updated too soon (before the HMOVE), but as I understand it, the RESBL and HMBL shouldn't take effect until after the HMOVE? Perhaps this isn't actually the problem at all. The code seems to work better under Stella than Z26, but clearly this isn't much use! Anyway, I will be very grateful if someone can spot the problem! Chris rope.zip
  22. To elaborate, the problems are as follows: 1) Higher resoulution: the 6x6 pacman character is generated using the PF, so the size can't really be reduced without making it unrecognisable (e.g. 4x4). 2) Position Pac Man closer to the opposite side of the current movement direction: The yellow colour of the PacMan character is accomplished by changing COLUPF at exactly the right time in the kernel. If we move the character to the left or right then the timings will get very complex! 3) A Radar Screen: not enough spare cycles to display this (only 10 free cycles over 8 scanlines). All of these problems could be solved by moving over to a prite-based approach, but that would essentially mean starting again from scratch ... My original idea was to create a game that had much larger characters than could be accomplished using the regular sprite hardware. Also, I wanted to see how far the PF hardware could be strecthed. However, I can see now that this isn't such a great after all! I think I might abandon this first game attempt and start on something a bit different using real sprites ... Thanks for the feedback. Chris
  23. I agree that the resolution is a little low, but I don't think I have the space cycles for any of these suggestions. As I see it, the only feasible options are: 1 - reduce the speed to give more reaction time 2 - play a sound when a ghost is nearby to warn the player 3 - redesign to use sprites instead of a purely PF-based approach Chris
  24. Hi Folks, I have attached a new version of my Pac Adventure demo to this message. The maze now contains objects, some of which can be collected (see screenshot). All that really remains now is to get the ghosts moving around the maze, and add some polish. The demo works well in both Stella and Z26, and displays a constant 60fps/262 lines. However, for some reason the graphics are garbled when I try it on real hardware with my supercharger. Does anyone know why this might be the case? The source code is included in the ZIP file. Many thanks, Chris pacadv02.zip
  25. Hi Folks, I have now spent a ridiculous amount of time refining my scrolling maze demo, and I thought it was time to post an update. Apologies for starting a new thread, but the old one had got a bit off topic. The new version should be attached to this message, and as usual the full source code is included. I have now decided on a game concept, which will be a cross between Atari Adventure and PacMan (thanks to JoustPong/FlapPing for the inspiration). Basically, you will control a PacMan-like character who will wander around the maze, avoiding ghosts (instead of dragons), and collecting keys to open doors. To kill the ghosts, you will collect power pills in the usual PacMan way. The demo attached to this message has the basic PacMan movement, and scrolling maze stuff working. The ghosts and objects have yet to be implemented, though some of the basic code is already in place. In particular, every second screen line is reserved for displaying the objects/ghosts, which will allow them to be displayed in a different colour. The code has also been completely overhauled since the last scrolling maze demo. Anyway, before I go any further with the coding, I thought I would ask for a bit of help: 1) Do you think the basic game concept will be interesting enough? Any suggestions for improvement would be appreciated. 2) Any suggestions for a game name? I need something a bit better than PacAdv, and that won't generate any lawsuits! 3) My artistic skills are practically non-existent. If anyone can design a better 6x6 PacMan sprite, then I would be very grateful. 4) The kernel is about as tight as I can make it, but there are not quite enough cycles to set the border colour to black on every line. Any suggestions for improvements to the DRAWOBJ and DRAWPAC macros at the beginning of the code would be welcome. Also, any other suggestions for code improvements will be welcome. Well, that is all for now. As usual, feel free to take the code and use it in your own projects. Chris pacadv.zip
×
×
  • Create New...