Jump to content

AndyMt

Members
  • Content Count

    24
  • Joined

  • Last visited

  • Days Won

    3

AndyMt last won the day on June 29

AndyMt had the most liked content!

Community Reputation

32 Excellent

1 Follower

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. This is great! It will help me designing some game sound effects. I have a feature request though: Could the program dump the register hex values for the channel settings on screen somewhere at the bottom? I know it shows any changes at the top right, but its cumbersome to collect all the values. And is shows the bit values.
  2. Well - 128 for sure is enough and to fill basically the entire screen with sprites isn't my goal ;-). I'm more concerned about my game logic, collision detection etc. I'm implementing with cc65 in C. I wasn't sure if the performance will be fine or if I have to optimize some code in assembler. Looks like this isn't necessary.
  3. Ok - so now version 0.6 is out. It features the mighty twin laser cannon . The game now can have up to 20 sprites at once on the screen. Looks like at least the emulator is totally fine handling this. If the hardware comes close to that I'm not worried implementing a "real" shoot'em up game some day!
  4. So I managed to implement my first 3 power ups . Wasn't that hard. I also started some refactoring of the code. Looks already better now. Now I have a basic sprite move/collision detection engine. The next power up will be a double laser cannon . I'm thinking about implementing Space Inavaders
  5. I updated to version 0.4 which now has basic sound support. You can enable/disable by pressing the 's' key. Next step is to implement some power up. I think I'll start with duplicating the ball.
  6. I'm using cc65 in combination with a Visual Studio Code plugin. Until now I only use C, but at some point I will have to use some assembler, too. I briefly looked into millfork, there is a X16 adaptation for it. But I figured that the above combination of languages will suit me better.
  7. I'm sure this is possible. How about a Basic compiler instead of a new language? There should be a few text editors on Github for the C64, which should be easily portable. In any case I would go for assembler.
  8. Our PSU is 180W but the stock machine without expansions will use far less than that. Great! I'll fire up Blender then .
  9. Any ideas what kind of power supply will be needed? Atx I assume, but how much power output will be required? I think about designing my own C128 style case and a bulky 300W Atx PS won't fit in there. Yes - I know the X16P and C will be delivered in a case... I'll use that for something else.
  10. I think this is more of a Basic or even Kernal problem. It looks like the location header is not taken into account when calculating the actual size. What happens if you load let's say 4k? If then 2 bytes are missing as well, then it's consistent. If not, then there is some error in there. What happens if you load the 8k into base memory? Let's say at 16k?
  11. @SlithyMatt Yes your framework is definetly on my list. Memory is not that much of an issue with the X16 and it would be a good reason to look into banked memory .
  12. Uploaded a new version (0.3). Now we have some additional levels . I also improved the collision detection further. The paddle now allows to control the ball so that it almost moves in a vertical line. Not entirely - that would be too easy, right ? Some cheat codes added, too: l: level switch - this way you can check all the levels without playing them a: autoplay - for testing collision detection Have fun! I'll upload the source code to github at some point - but I want to do some proper cleanup first. All code is inside a file named "cc65test.c" atm. I started with sound effects - but Vera's PSG doesn't provide me with the effects I'd like. So I also tried the YM2151, but that's a lot more complicated. Any easy way to get sound effects from some sort of library and a "player"?
  13. Yes, using the mouse with the emulator is tricky. It would need to continue reporting mouse positions to the prg even if the mouse is outside of the window. That also applies to the native emulator on Windows, it also happens there.
  14. The angle can be modified by letting the ball hit the paddle more at the sides. If ball is coming from the right and hits the left hand third of the paddle then it is redirected in a more steep angle. That way you can get it back upwards. Imagine the paddle is curved. I consider to change that to be depending on the movement of the paddle. So the ball would inherit some impulse from the paddle movement. Not sure how Arkanoid worked...
  15. I'll dig into it tomorrow (midnight here now). But then I'll need some additional artwork for "Brixx" :).
×
×
  • Create New...

Important Information

Please review our Terms of Use