Jump to content

AndyMt

Members
  • Content Count

    107
  • Joined

  • Last visited

  • Days Won

    6

Everything posted by AndyMt

  1. I found a very good guide on the web: https://github.com/ilmenit/CC65-Advanced-Optimizations This helped me a lot .
  2. For me the X16 appealed more for the following reasons: You will be able to look at the board and kind of "see" how it works. I love that! Memory layout and bank switching is very basic, but also easy to understand. The amount of available memory imposes pressure to optimize. I like that! Graphics is somewhat in between an ATARI ST and the Commodore Amiga, so more 16-bit era like. Which allows for good 2D graphics and I'm very happy what I've achieved so far. The pixelated 320x240 resolution adds to the nostalgic feel. The 8 MHz CPU is fast compared to the C64, but still slow enough so that you have to live with certain limitations, which is part of the fun. But it still allows me to use C for programming with some assembler to get around the mentioned limitations. I'm looking forward to "real" hardware. I'd like to show it to my nephews (now 3 and 6 years old) in a few years, to explain and "show" them how computers actually work. I find it still very important to know about those basics. Even with modern computers this helps to understand why certain things work and others suddenly don't.
  3. I also started with a TI99/4A my dad bought for me (and himself) in 1982. It soon turned out be be the "wrong" choice, compared to everyone else in school (some VC20 and mostly C64)... I did some BASIC programming with it, but it wasn't capable enough for what I wanted to do with it. But my favorite was the Atari 260ST we got for Christmas 1985. I upgraded it to 1MB of RAM myself with some soldering... also changed the keyboard later to MX switches. Then we got the 20MB external Harddrive, which was incredible! Of course I've used it for gaming a lot... But the ST got me into "real" programming (GFA Basic, Pascal, C) and was the catalyst for my career in computer science and software engineering. The ST was still easy to understand (it didn't have the "blitter" chip), IO chips, video and audio was all directly memory mapped. I could look at the main board and actually see how everything was connected, where the address and data bus was routed through etc. Switching to PC compatibles in the late 8ies/very early 90ies for my professional career was a shock. Compared to the ATARI ST those were crap really. It took until Windows 95 (98) for me to get back the same "multimedia feel" and easy of use with PC compatibles. More than 10 years to catch up with the ST... 10 "lost" years! That's why the Atari ST will always have a special place in my memories.
  4. The land of chocolate... Probably Switzerland, where I'm from?
  5. There is 2 things to make it work, I struggled with this, too: 1. Binary Files (and PRG file) have to be in upper case letters - this you have done 2. when you load the files in the source code the filename needs to be in lowercase: With cc65 it looks like this: result = vload_host("bg-sky.bin", MAIN_SCREEN_BMP_ADDR); Don't know how it should be in acme.
  6. New Version 0.6: More enemy sprites, final designs These sprites should now be complete. Maybe I'll fine tune them later. VRAM constraints won't allow more enemies, without loading them in the fly. Animated enemy sprites All enemy sprites are now animated with 4 frames each. Despite the number of sprites on the screen this seems to be no performance issue yet. More diverse level compositions The formations of enemies is now more diverse Next I'll probably try to make some enemies break formation and attack. Or maybe I have them close their ranks from time to time. Let's see .
  7. I fully agree on this statement. I use C with some assembler. But even without profiler you can get some indications by looking at the generated assembler code. I do this in case I run into a performance issue. Which until now were surprisingly few. Even though "Invaderz" handles a lot of sprites at the same time, including movements and collision detection, until now these parts didn't require assembler optimisations. Ok - I always consider what the compiler will do with C code I write. So I probably optimise anyway. Until now I only coded the interrupt handlers in assembler - for Vera hardware collision detection and for sound effects.
  8. New Version 0.5: Fixed the collision detection - finally! More enemy sprite graphics. Minor speed and game play changes. Have fun!
  9. Impressive! Me - none. I think a MiSTer doesn't count?
  10. 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.
  11. 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.
  12. Oh boy - should have checked for updates before I posted .
  13. Forgot to mention some cheat-codes in this version : 'L': jump to next level 'R': return to previous level
  14. 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
  15. 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.
  16. 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.
  17. 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.
  18. 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...
  19. 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.
  20. There is Aloevera: But I'll give your converter a try, too. Always good to have options
  21. 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.
  22. 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.
  23. Ok, found the Level 2 bug. New version 0.3.1 is online.
×
×
  • Create New...

Important Information

Please review our Terms of Use