Jump to content

AndyMt

Members
  • Posts

    249
  • Joined

  • Last visited

  • Days Won

    15

Everything posted by AndyMt

  1. New Version 0.5: Fixed the collision detection - finally! More enemy sprite graphics. Minor speed and game play changes. Have fun!
  2. Impressive! Me - none. I think a MiSTer doesn't count?
  3. I'm developing in C (cc65) for my games, too. The X16 is fast enough, for C - with a little bit of care in coding style. And - Matt's video is an excellent start.
  4. I haven't tried, but I assume you add both PRG in the same Zip file. When uploading you can specify which PRG shall be started first. That one then has to load the others.
  5. Forgot to mention some cheat-codes in this version : 'L': jump to next level 'R': return to previous level
  6. I've used this script for a while now, thanks a lot for this. I'm think I stumbled across something in regards to the conversion. As it's a bit complicated I'll try to explain it: Colors appear different in emulator: Recently I noticed that the colors in the emulator appear slightly different than in Aseprite (using your script). Looking at the script it appears it rounds everything to a palette entry ending with "0" for each rgb value: 0x00, 0x10, 0x20, 0x30... 0xE0, 0xFF << you can see here that there is a gap of 31 values at then end and 16 in between all others... The emulator produces each entry mostly with the same hex digits for each tuple (using screenshots and Gimp to determine color values). So: 0x00, 0x11, 0x22, 0x33... 0xEE, 0xFF << here the gap is 17 between each color value. why this can be an issue: The script currently adds 8 and then discards the lower nibble. I think the thresholds for each of the 16 values per color value needs to be different. Right now there is a big gap in the brighter colors, which leads to color bleeding towards the slightly dimmer ones. Script algorithm changes: What I have done now is to change the script slightly and emit the above RGB values, so Gimp, Pro Motion, Aseprite etc. show the right colors (as the emulator would) and also use those for dithering. Of course VERA then can only use the upper 4 bits of each palette entry. Tools like Aloevera etc. take care of that. Using this delivered better results for me when working with large (320x240 - haha) bitmaps like I used in Brixx and Invaderz. It probably doesn't matter that much for sprites and tiles etc. I attach my (not very elegant) version of the script so you can see the difference. 12-bit Palette Quantize V2.lua
  7. New Version 0.4: Some gameplay changes: Level is lost when bottom enemy progresses to shields/fortress. You then fall back to the previous level and can try to advance again. If you fail level 1, then the game is over, too (or all lives lost). Enemy movements get more difficult with each level. They move faster, they advance faster. Patterns still the same Player sprite now has more realistic lag, when changing direction. Let me know what you think about this one. It was just unrealistically fast with the mouse, so I made it more difficult. Other improvements: More Levels! The background story is now more complete. The descriptions for levels > 2 don't yet match the description in relation to enemy behavior or motherships etc. Different enemy sprites I experiment with different enemy styles now. Most will probably be replaces later again. I like the martians, though ... Sprite animation for player sprite Player spaceship now shows thruster plumes and tilts when moving.
  8. New Version 1.0 Yes - I consider this game complete as of now . Powerups now appear at the spot the last brick disappeared. Added one last bonus level with the X16 logo Works on emulator R37 and R38.
  9. Yes, I use your script, thanks for it. But it naturally leads to some colors being combined. That in return results in bleeding where there should have been dithering.
  10. What Aloevera cannot do is dithering and optimizing a palette for any given picture with constraints like number of palette entries to use etc. That's something I miss. I use Gimp and Aseprite for this, but they both don't entirely cope with the 4096 color palette of Vera, so the results could be even better...
  11. 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.
  12. There is Aloevera: But I'll give your converter a try, too. Always good to have options
  13. 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.
  14. 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.
  15. Ok, found the Level 2 bug. New version 0.3.1 is online.
  16. 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...
  17. 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!
  18. I've started using HW sprite collisions for my current project the last few days. To answer the first question: yes collisions are detected among the same group of sprites. So for example I assigned the same group to enemy sprites and the laser shots of my ship. VERA reliably detects collisions. Which brings me to HW vs SW collision detection: until now I can't see a real disadvantage using HW detection. I mean you have to combine the 2 anyway. HW detection just tells you that there was a collection in a group of sprites. You then have to figure out which sprites were involved. At least in my current project (see "Invaderz" demo) it really helped to reduce lag and improve performance a lot.
  19. I'm not sure if @DoubleA refers to the CLR or the .Net (or .Net Core) framework itself. The CLR itself is considered very stable in the industry and is extremely compact. But then - without the .Net framework is not of much use. But I personally never experienced the .Net Framework as bloated, especially since .Net Core.
  20. No, you don't need assembler at all if you don't want to with cc65. It will for sure offer more performance than Basic. But if you just want to get going right away - Basic is the right choice. No installation needed, except for the emulator.
  21. Oh nice! I can already see something like "Elite" coming...
  22. I'm also one of those using cc65 and implement my games for the X16 in C. Sometimes there is a need of implementing some optimized parts in assembler (interrupt handlers, sound effects player, etc.). cc65 has the advantage that combining C and assembler is easy. I sometimes check the generated assembly code, to see what the C compiler does and the hand-optimize some of it. Or I change the way I do my C code. I also didn't experience any case of cc65 being really broken... if so, it was possible to fix it myself as the source is on github. Basic was too limited for me and I wanted the comfort and usability of cross development tools on a PC - and then run it on the emulator. So I went for Visual Studio Code and cc65. But hey - the beauty of the X16 is that there are different ways of programming for it.
  23. Oh sorry, for me it wasn't 100% clear who does what . No, the web emulator is still on R37.
×
×
  • Create New...

Important Information

Please review our Terms of Use