cd-w

Looks good and plays well - perhaps you should get together with some of the other BASIC developers and put together a multigame cart? My only suggestion would be to limit the number of "boosts" that you get. The game is much easier if you hold down the fire button the whole time. Chris

Yes, it asks for a password for the ftp server for me too. Chris

Any chance of posting the kernel code? The extra eyeballs around here might spot something, though I can't guarantee it! Sounds good - I'm not a fan of flicker myself unless it is the interlaced kind used to get extra colours. From what I can see, Dark Cavern makes sure that the missile sprites never overlap vertically? On the other hand - I think you could get 3 ball sprites on screen comfortably by using a single ball/missile sprite and intelligent flicker, though it might be annoying of the ball stated flickering just as you were about to hit it! There are lots of possible schemes, but the best that I could come up with was something like: Player 1 - Invader1 (Either intelligent flicker between brick rows, or use missile 2 For Invader 2) Missile1 - Ball (Intelligent flicker between brick rows for multiple balls) Player 2 - Powerup Pill Missile 2- Invader 2 (or swap with Powerup) Ball - Bat OK, I will stop now or it is going to be called "BobAnnoyed", but I can see this is going to be a great game! Chris

I take your point - I was thinking purely of the upcoming competition. Ehhh...maybe. I've thought about that. Might be tough to fit it in the kernel - and that would probably be the easy part. But if enough people want 'em bigger I'll look into it. If you are using a 2LK you can make the sprite 4 lines high by doing something like: tya lsr cmp YBALL php pla However, this will require 4 extra cycles, and it will make the balls look a bit chunky. The problem is that it is hard to draw an asymmetrical PF while repositioning sprites. Though it could possibly be done with a blank line between brick rows. I don't think a line between rows would spoil things too much. However, as you say below the flicker looks much worse in the emulator. If the sprites were in formation (space invader style) then you could use doubling/tripling to avoid the flicker, but then that would affect the missile sprites too ... If I use PF0 the colors will match the brick rows - it looks goofy. I've toyed with some other ideas but I'm really not sure if there is a good solution. On the other hand, flicker doesn't look so bad on real hardware! (It looks awful in emulation.) Good point - you would have to be very tight with your timings to swap the colours at the border. An alternative would be to stretch a missile or ball sprite to 8 clocks and then wrap it tround the screen edge, but this would lose you a sprite, or would require flicker again ... Anyway, I can't wait to see how this turns out - the 2600 homebrew scene is certainly going strong at the moment! Chris

This looks great - I definitely think you should push this towards a full game (perhaps a 4K minigame). A few minor comments: Can you make the ball sprites a bit bigger? How about doing intelligent flicker on the invaders so they only flicker when occupying the same vertical space? (I haven't done this myself yet, but there is some good information on the stella list). The flickering left/right border is a bit annoying (I am very sensitive to flicker) - can you just fill PF0 to make this solid? You could make the invaders move left/down/right/down like in space invaders, or swoop down like galaxian to give some variety? Chris

This discussion moved to the Stella mailing list: http://www.biglist.com/lists/stella/archiv...7/msg00031.html It looks like this is part of the PoP kernel, so I am hoping to see some more developments there soon! Chris

You should definitely have a shot at writing your own game - I get more fun out of it than actually playing the games - it is a lot like doing a very difficult crossword puzzle Now that Batari Basic is available, the learning curve should be less steep. Thanks for the bug report - the game is running very close to the limits, so I need to spend some more time optimising the code. Chris

Great - I'm glad you enjoyed it, and that it works on real hardware! There should be some more levels coming soon, though most will be easy levels at the beginning to allow less experienced players (i.e. my girlfriend) to make progress! I always wanted to be a games programmer back in the day, but I never could get my head around assembly language then Chris

Well, at least I think it'll get better than 2003 (2 new games) and 2004 (3 new games). With "Go Fish!" and "Fall Down" already out of the door, we only need 2 more new releases within the second half of the year to top that Greetings, Manuel 888944[/snapback] There should be a minigame multicart coming out later this year, and your own "Crazy Balloon" game is just about finished. I don't have any plans for Hunchy II yet, but we will see how it works out. Chris

I like the idea of a practice mode - it should be very easy to implement. I will try to put something like this in the next release. Post it in the Homebrew forum here - I'm sure we would all like to see it! After your nifty scrolling text demo, I am expecting something special Chris

Thanks The guards are probably a bit too difficult in the current version. I am planning to change the sprite graphics soon and hopefully this will make it easier to jump over the guards. However, I will also reduce the jump height if that doesn't help. I am still not sure what to do about the players lives. I think a limited number of lives will make it very difficult to progress in the game. However, I'm also not too keen on giving the player infinite lives as this seems like cheating. Perhaps I should include a time-restricted level skip mechanism like in "Crazy Baloon"? Any suggestions welcome. Chris

OK, I have attached a new version of Hunchy 2 to this message. The game is now fully playable, and the only things not yet working are the scoring and lives. You can change levels with SELECT (F2 in Z26) as before. The main changes are: 7 Levels Title Screen Music (thanks to Manuel) The ZIP archive includes the source and ROM - please let me know if you find any bugs! Enjoy! Chris h2v03.zip

Thanks - the source code compiles fine under Linux with gcc. Lex and Yacc should definitely help you - I wouldn't dream of writing my own parser anymore! Basically, Lex takes the input and converts it into lexical tokens which solves the spacing issue, e.g "if x then" becomes ["IF","VAR(X)","THEN"], and Yacc takes these tokens and converts them into a parse tree to match the grammar (and rejects any invalid syntax), e.g. ["IF", "IF"] would be rejected. I would offer to do this for you, but it has been several years since I used these tools. I will let you know if I think of any more suggestions. Chris

I'm not sure exactly how BlockChange works, but if you could extend it to have a separate entry for every scanline then you could combine X & Y as follows to save 3 cycles: dey +2 bmi EndKernel +2 lda BlockChange,Y +4 bne KernelLoopa +2 beq KernelLoopb +2 EndKernel Chris

This looks like a great idea. I think it will also make a good prototyping tool for experienced developers. It should allow a game idea to be tested before investing a lot of effort on a custom kernel. Unfortunately I can't actually run it as I am a Linux user, but I hope that you are going to release the C source at some point? Are you using LEX/YACC (Flex/Bison) to parse the source files as this should solve the spacing issues? You are probably not looking for suggestions yet, but I think that presenting the registers as 2D arrays would make some things easier to express, e.g. if CXM0P(7)=1 then ... I will be interested to watch how this develops. Chris

Thanks for the feedback - I haven't actually completed all the levels myself yet without cheating! I was planning to give the player a limited number of lives, but perhaps I should revert to the infinite lives of the original? I'm not quite sure what you mean by a nudge onto the ladders. Do you mean that you should be put on the ladder if you miss it by a few pixels? I am currently aiming for a 4K ROM size, so I was planning around 8 screens, with a few different combinations of bells/missiles/guards for each. I may go for an 8K ROM at some point if things get tight though. The levels are deliberately copied into the memory which will allow changes to the game area in later versions, e.g. disappearing blocks, moving platforms, etc. I don't think I have enough sprites left for powerups without flickering, but I will keep it in mind. Also, the annoying sound effects will be improved in a later version! Cheers, Chris

Thanks - it was certainly inspired in-part by Miner 2049, but hopefully the controls are more responsive, and I have managed to avoid flickering the sprites. I hope you enjoy the latest version. I haven't actually played Jumpman - is there a version for the 2600? Yes, there isn't any way to kill the guards. The best method of avoidance is probably to make him fall down a hole. You can also move fast up ladders by holding up and jump together to allow you to gain some distance. Thanks - the simple ideas are usually the best in my experience! Chris

Thanks for all the positive feedback! I have attached the latest version of Hunchy II to this message. There are now 4 levels which can be changed by the SELECT switch (or by collecting all the Bells on a level). Let me know what you think, in particular: 1) Are the levels too easy/hard? 2) Is the gameplay too repetitive? 3) Do the controls feel OK? Also, let me know if you have any other suggestions for improvements or find any bugs/glitches. Enjoy! Chris h2v02.zip

That, and do it like they did in other ports: let go of the button - slow draw Hold the button - Fast draw 886085[/snapback] There was a previous discussion of Qix on the 2600, and a mockup screen posted in this thread. It definitely should be possible (but rather difficult) to replicate most of the game. Chris

Thanks for the complements. There will be more levels coming soon, once I figure out the best way to pack them into 4K. Chris

Hi Folks, While the G8 protests are raging outside here, I have been staying indoors working on an enhanced version of Hunchy. The game has now changed so much that I am calling this version Hunchy II, and keeping the old version as a mini-game. I wanted to get away from the purely linear behaviour (running from one side to the other) of the original, and so the objective now is to collect the bells which are scattered around the screen. There are also ladders and platforms now, and the guards can chase after you. The basic gameplay is inspired by "Chuckie Egg" which is one of my favourite 8-bit games. There is still a lot to do, but the attached version shows the display kernel for a single level of the game. The main problems at the moment are a few graphical glitches, and a serious shortage of memory. If the background turns white, or the screen flickers, then please let me know! The current level is just to demonstrate the main kernel features - the actual game levels will be more interesting. Any suggestions for improvements will be welcome. As usual, the source code is included, though it is a bit of a mess at the moment. Let me know what you think. I will be posting regular updates to this thread. Chris PLEASE NOTE: The latest version of Hunchy II can be found HERE! h2v01.zip

Thanks for the suggestion. It seems that this code is OK after all - the timings were just getting screwed due to a carry flag not being properly set elsewhere in the code. This was causing HMOVE to be called at the wrong time ... Argh, I think I should call it a night. Chris

Apologies for raising this thread, but I have another related sprite positioning problem. For some reason, the following kernel code fragment fails to work as expected. The missile sprite is incorrectly positioned, and for certain values the TIA seems to enter an infinite loop (I have verified that this also happens on real hardware with my Supercharger): ; Load Missile Data lda (BPTR),Y ; [67] + 5 sta HMM0 ; [72] + 3 ; Commit Movements sta HMOVE ; [75] + 3 ; Draw Missile (M0) sta ENAM0 ; [2] + 3 asl ; [5] + 2 asl ; [7] + 2 sta NUSIZ0 ; [9] + 3 I understand that the HMxx registers should not be modified for a certain number of cycles after the HMOVE. However, is there any restriction in altering them before the HMOVE, and should the ENAxx and NUSIZx registers not be touched after an HMOVE? Ensuring that the HMOVE happens on exactly cycle 76 does not seem fix the problem. Any advice would be appreciated as this is causing me some real head scratching. Chris

I can't wait for the upcoming Frogger movie. It is bound to be a hit with the ladies Chris

This is a fairly obvious hack, but here goes ... If you want to display more than 2 sprites, you can use the missile and ball graphics to construct pseudo-sprites. Obviously you can only display a limited number of shapes, but if you are clever, you can obtain the appearance of extra flicker-free sprites. The following code fragment illustrates how to draw a man sprite using only missile 0: Kernel sta WSYNC sta HMOVE ; [0] + 3 ; Draw Sprite (SwitchDraw Variant) cpy PSWITCH ; [3] + 3 bpl PSwitch ; [6] + 2/3 lda (PPTR),Y ; [8] + 5 sta ENAM0 ; [13] + 3 sta HMM0 ; [16] + 3 asl ; [19] + 2 asl ; [21] + 2 sta NUSIZ0 ; [23] + 3 PContinue dey bpl Kernel ; SwitchDraw Routines PSwitch bne PWait ; [9] + 2/3 lda PEND ; [11] + 3 sta PSWITCH ; [14] + 3 SLEEP 6 ; [17] + 6 bcs PContinue ; [23] + 3 PWait sta HMCLR ; [12] + 3 SLEEP 8 ; [15] + 8 bpl PContinue ; [23] + 3 ; Player Data ; Bit 7-4 = HMove ; Bit 3-2 = Missile Width (1, 2, 4, or 8 pixels) ; Bit 1-0 = Missile Enable Player1 DC.B %00000000 DC.B %00000110 DC.B %00000010 DC.B %00000110 DC.B %11111010 DC.B %00001010 DC.B %00001010 DC.B %00001010 DC.B %00001010 DC.B %00010010 DC.B %00000110 DC.B %00000010 DC.B %00000110 DC.B %11111010 DC.B %00001010 DC.B %00010110 I have attached the full code to this message which allows you to move the sprite around the screen. Chris msprite.zip