Jump to content

AndyMt

Members
  • Content Count

    97
  • Joined

  • Last visited

  • Days Won

    6

AndyMt last won the day on August 14

AndyMt had the most liked content!

Community Reputation

96 Excellent

1 Follower

Recent Profile Visitors

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

  1. 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.
  2. 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.
  3. Forgot to mention some cheat-codes in this version : 'L': jump to next level 'R': return to previous level
  4. 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
  5. 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.
  6. 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.
  7. 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.
  8. 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...
  9. 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.
  10. There is Aloevera: But I'll give your converter a try, too. Always good to have options
  11. 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.
  12. 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.
  13. Ok, found the Level 2 bug. New version 0.3.1 is online.
×
×
  • Create New...

Important Information

Please review our Terms of Use