AndyMt 140 Posted August 11, 2020 Invaderz View File This is a space invaders inspired game. Use the mouse or joystick to control the player ship. The shield segments can take 2 hits each. If enemies get too close you retreat back to the last level. You lose when all your lives are gone or you fall back to earth level again. Now with 7 playable levels Requires emulator R38! Roadmap: more diverse enemy formations enemy attack raids over the sides power ups (shields, double cannon, disruptors etc.) boss enemy joystick control done music done Different enemy sprites. done Sprite animations. done for player sprite and enemies fade in/out of palettes and backgrounds. done more levels with more backgrounds (all planets of the solar system), done sound effects basics done title screen How to use with the local emulator: Unpack ZIP file into the same directory as the emulator. Start the emulator, then enter LOAD"INVADERZ.PRG" RUN Submitter AndyMt Submitted 08/11/20 Category Games 5 Quote Share this post Link to post Share on other sites
AndyMt 140 Posted August 11, 2020 Based on the experience with Brixx I wanted to go one step further and exploit the full power of the VERA chip. This game now has loads of sprites at the same time of which more or less all are moving. The background is 8bpp in 320x240. Right now only one level is playable, no sound etc. The plan is to have kind of a "storyline" where you defend each of our planets in the solar system. Starting from earth where the aliens suddenly appear. Then the player's task is to drive them out of our solar system. Let me know what you think . Quote Share this post Link to post Share on other sites
SlithyMatt 530 Posted August 11, 2020 Very nice! I see collisions do need some work, but overall it plays quite nicely! I noticed that, unlike the original Space Invaders, you can have shoot while your last shot is still on the screen, but it does appear to be a little throttled. Is it ignoring some clicks outside of a certain window, or just waiting for time to elapse since the last shot? 1 Quote Share this post Link to post Share on other sites
AndyMt 140 Posted August 11, 2020 Yes that is correct - you can have a maximum of 2 shots on the screen and there is a waiting time of 20 frames (330ms) between shots. I didn't want allow too many shots at the same time, as the game would be over quickly. Except if the enemies could shoot as much... same effect. But it get's unplayable above 4 - I tested it. Higher levels might allow up to 4 shots (from both player and enemies). Above 5 the emulator starts to throttle, the CPU then seems to be at it's limit with collision detection. I still have potential for optimizations by using assembler for the collision detection. But already with this much on the screen I'm pretty happy. So I don't know if I will dig into assembler for this. 2 Quote Share this post Link to post Share on other sites
JimmyDansbo 141 Posted August 12, 2020 20 hours ago, AndyMt said: I still have potential for optimizations by using assembler for the collision detection. What language is the game written in ? Quote Share this post Link to post Share on other sites
AndyMt 140 Posted August 12, 2020 It's written in C using cc65. I'm quite happy with it. 1 Quote Share this post Link to post Share on other sites
BruceMcF 237 Posted August 13, 2020 As a long time Galaxian fan, I'm really interested in a game with a shot quota, but "bigger than one". One alternative to a delay on the follow up shot is to allow the follow up shot when the current shot explodes OR passes a certain part of the screen. So, say, in level 1, if the first shot is 40% from the top or higher ... OR exploded ... its follow-up is available. The in level 2, it's 60% from the top, or higher ("congratulations, your fire control has been upgraded!"). Then in level 3, it's back to level 1 but there are two independent "tracks" ("you can been upgraded to two torpedo tubes!"). Then in level 4, same as level two but two independent track. 1 Quote Share this post Link to post Share on other sites
AndyMt 140 Posted August 14, 2020 20 hours ago, BruceMcF said: One alternative to a delay on the follow up shot is to allow the follow up shot when the current shot explodes OR passes a certain part of the screen. Yes, something in the line of this... The delay actually translates to a certain distance, so that effect is already there. But yes - I could allow a second shot as soon as the current one exploded. I'm still fiddling with all the parameters to balance the game. I might also introduce 3 difficulty levels the player can select from. From there difficulty would increase with each level, maybe in ways you have described. 1 Quote Share this post Link to post Share on other sites
AndyMt 140 Posted August 14, 2020 (edited) Version 0.2 is online. I've Improved the collision detection and also the handling of shots. Also added some basic sound effects thanks to @DusanStrakl's example. The Web-Emulator struggles a bit with the PSG emulation. Switch off sound effects by pressing 's'. Edited August 14, 2020 by AndyMt 1 Quote Share this post Link to post Share on other sites
AndyMt 140 Posted September 11, 2020 (edited) Version 0.3 is online now . ATTENTION: requires emulator R38. Uses hardware sprite collisions now. I started implementing multiple levels. Each level has kind of an intro message, to give the game a background story. Also experimented with fade in/out of background images, which looks already quite nice. The enemy formations now behave slightly different per level, at the moment they basically speed up, and move closer. Future versions will improve this. The enemy sprites are still placeholders. Next version will should improve there. I hope you have as much fun playing it, as I have with implementing! Edited September 11, 2020 by AndyMt Quote Share this post Link to post Share on other sites
SplitSpine 1 Posted September 11, 2020 Nice, but could only get to level 2, all aliens dead but the stage did not end. Also. sometimes your shots does not hit most left side aliens. Otherwise nice wish it was harder Game Version: 0.3 Emu Version: Windows R38 1 Quote Share this post Link to post Share on other sites
AndyMt 140 Posted September 11, 2020 Thanks for the feedback . Strange with that hanging level... I'll look into it. The collision detection on the left has an issue which I still try to track down. But it's unrelated to the HW sprite collision detection, that much I know. The difficulty needs some balancing. I find it hard enough, but I never was a good player... Quote Share this post Link to post Share on other sites
AndyMt 140 Posted September 11, 2020 Ok, found the Level 2 bug. New version 0.3.1 is online. Quote Share this post Link to post Share on other sites
SimonD 2 Posted September 11, 2020 Once a column is finished on the end, the invaders should move all the way across the field instead of keeping the same pattern of back and forth. Earth should be the last field instead of the first. Looking forward to further development. 1 Quote Share this post Link to post Share on other sites
AndyMt 140 Posted September 11, 2020 Yes, movement patterns are very basic atm. In regards to the order... had Earth as the final stop, but actually: that would mean the invaders would get closest to our homeworld just before being defeated... So I swapped it around and the task is to drive them out of the system. 2 Quote Share this post Link to post Share on other sites
BruceMcF 237 Posted September 12, 2020 4 hours ago, AndyMt said: Yes, movement patterns are very basic atm. In regards to the order... had Earth as the final stop, but actually: that would mean the invaders would get closest to our homeworld just before being defeated... So I swapped it around and the task is to drive them out of the system. Well, there you go, bill it as the more hopeful sequel to the original ... "Invaderz: Counterattack!" 1 Quote Share this post Link to post Share on other sites
SerErris 70 Posted September 12, 2020 Hi, does not work for me on Windows r38 emulator. I created a SDcard.img from the files and attached it to x16emu. I can see all the files in the emu and it looks like this: But when I load it the screen is getting scrambled and it stops there: The web emulator does it correctly. but I am not able to start it on my windows machine ... any idea, what happened? Quote Share this post Link to post Share on other sites
AndyMt 140 Posted September 12, 2020 I never tried it with an SD card image. I assume it has something to do with the device I'm loading. Until now that's always 'host' so I assume that's the problem. If you just copy all the files into the emu directory it will work. Quote Share this post Link to post Share on other sites
SerErris 70 Posted September 12, 2020 uhh ... and messes up my emu directory Okay, thanks, that explains a lot. I thought it would be actually an sdcard loader. Quote Share this post Link to post Share on other sites
AndyMt 140 Posted September 13, 2020 You actually can have the game and it's files in a different directory and then have a batch file which starts the emulator with the -run parameter. That's how I do it for debugging etc. Quote Share this post Link to post Share on other sites
geek504 44 Posted September 13, 2020 On 8/11/2020 at 4:47 PM, AndyMt said: The background is 8bpp in 320x240. I had no idea you could create different screen resolutions other the ones provided by the SCREEN command, i.e. mode $80 320x200x256 and $81 640x480x16! Quote Share this post Link to post Share on other sites
SerErris 70 Posted September 13, 2020 Use some POKEs in the vscale and hscale registers of Vera. Both set to 64 gives you 320x240 . The depth is not dependent ... can be anything that fits into screenram. Quote Share this post Link to post Share on other sites
geek504 44 Posted September 13, 2020 (edited) 1 hour ago, SerErris said: Use some POKEs in the vscale and hscale registers of Vera. Both set to 64 gives you 320x240 . The depth is not dependent ... can be anything that fits into screenram. So, (monochrome SVGA) 800x600x1bpp = (800 pixels / 8 pixels-per-byte) * 600 lines = 60,000 bytes is possible? Also, (monochrome XGA) 1024x768x1bpp = 98,304 bytes? Also, (monochrome WXGA+) 1280x800x1bpp = 128,000 bytes? Edited September 13, 2020 by geek504 Quote Share this post Link to post Share on other sites
Fnord42 36 Posted September 13, 2020 46 minutes ago, geek504 said: So, (monochrome SVGA) 800x600x1bpp = (800 pixels / 8 pixels-per-byte) * 600 lines = 60,000 bytes is possible? Also, (monochrome XGA) 1024x768x1bpp = 98,304 bytes? Also, (monochrome WXGA+) 1280x800x1bpp = 128,000 bytes? No, have a look here: https://github.com/commanderx16/x16-docs/blob/master/VERA Programmer's Reference.md The VERA does a fixed resolution of 640x480@60Hz, smaller resolutions are actually done via scaling. Quote Share this post Link to post Share on other sites
SerErris 70 Posted September 13, 2020 (edited) lol .. @Fnord42 is right .. max is by all means 640x480. but other than that you are pretty free to play around with the scalings .. Edited September 13, 2020 by SerErris Quote Share this post Link to post Share on other sites