Jump to content

borgar

Members
  • Content Count

    33
  • Joined

  • Last visited

Everything posted by borgar

  1. After the initial burst of work on this game to a reasonable looking state, things have as expected slowed down. Only a few things added this time Changed game over to defeat/victory with score "calculation" (bonus points for any lives at end of game) Some enemies have a chance to drop seeker bombs (slower bombs that move toward player) Made credits more like other info pages
  2. Yes indeed. I have tested this and had no problems importing and drawing a screen from binary input. Many thanks.
  3. Using the namespace prefix gives me .\screen_test.asm:57:9: error: not defined ident '_main' lda #<_main.rawdata ^ .\screen_test.asm:43:1: note: searched in this object only
  4. I have upgraded to BETA2 and Petaxian runs fine I can now use the Prog8 const from my assembly which is excellent. However, I'm still struggling with figuring out how to import raw data. I.e. I want to add full screen char data either as binary or as asm code. AND access this from Prog8. All I basically need is a way to figure out the address to the first byte of this data. Right now I can not e.g. see any way that %asmbinary is even useful. You mentioned using a lable but I can't get this to work. This might not be a bad idea to add an example for this btw. In any case I'm trying something like this: main { rawdata: %asmbinary "data.bin" sub start() { uword charPtr = &rawdata charPtr++ ; Only to prevent removal of variable during compile } } but get the following error .\screen_test.asm:57:9: error: not defined ident '_rawdata' lda #<_rawdata ^ .\screen_test.asm:43:1: note: searched in this object only start .proc ^
  5. Thank you. There is actually a slightly bigger enemy (though marginally so) that appears at stage 9 and later. I guess you just have to practice to get that far. BTW, the enemies are actually 4 (2x2) characters in size. I support movement "within" the characters using the 16 PETSCII characters that cover all the variations of 2x2 "sub bits". I was inspired by PET/C64 Galaga (which this is basically a clone of). I don't currently support any larger enemies though that is of course completely possible, e.g. Galaga had a 3x2 char sized enemy. It is something I have noted down as a possible improvement.
  6. A new update of Petaxian has been uploaded with the following main changes : Added random "attacks" for enemies (with increased bomb frequency) Updated to non-uniform waves. Remixed to 12 stages. Add stage start "announcement" Add stage completion time bonus points Unsurprisingly there is a lot work left after the basic gameplay mechanics is implemented. It certainly makes one appreciate all the other non-coding work that goes into games (I certainly see why having professional level designers and testers are necessary). I want to add some sort of proper "game end" (and show current high score) but after that I suspect updates to this game will slow down. I have a couple of other game ideas I'm considering (none especially original).
  7. There are plenty of tutorials for 6502 assembly out there (here is one that starts gently https://codeburst.io/an-introduction-to-6502-assembly-and-low-level-programming-7c11fa6b9cb9). It might not be a bad idea to do read a few such documents before jumping into videos. I think you probably should not start out with something too ambitious for your first attempts. You probably can a lot of smaller programs without having to deal directly with the stack pointer. You can start by transferring parameters in the registers (A, X and Y) and/or direct memory addresses (Zero Page or not) and limit your self to implicit stack use with JSR/RTS. I'd also recommend taking looking at Prog8 (https://prog8.readthedocs.io/en/latest/#). This gives you something a lot faster than Basic while not being as completely low level as assembly. Prog8 allow inclusion of assembly into the program fairly gracefully when you need "full speed" and if you just need a few really fast (non-recursive) functions you don't not need to learn to use the program stack. And since Prog8 produces assembly output (before producing the binary with 64tass) it will also allow you to learn a lot from looking at the produced output when you are interested. BTW, back in the day (80's) when I did some limited machine code programming I basically had no understanding of the stack and the only stack related commands I used was just JSR and RTS. But what I wrote then was basically stuff gleaned from some assembly examples in various C64 magazines and I probably only understood about half the 6502 instruction set.
  8. And it turns out you are 100% correct here. For Petaxian the output from 7.0-beta compiler runs fine in the current compiler.
  9. Nice! I guess I have to jump over to the 7 real soon. I was waiting for an official release of the new XC16 emulator, but there are so many updates now I'd like to use. I can always test using VICE for a while.
  10. I tried this screen { testlabel: %asmbinary "data.bin" ... } but get the following error : screen.p8:3:9: no viable alternative at input 'testlabel:'
  11. Ok, so I have a questions about adding larger sets of data in Prog8. Since the byte/ubyte data structures are limited to 256 bytes I have so far just split data into multiple arrays. That works well enough for now. However, let's say I want to update a full screen (40x25 for C64, more for CX16). It gets awkward to split this up into many arrays. It looks like perhaps %asminclude might be something but it's not obvious how to use this. I created a file screen.asm which contains my screen data : screen_char BYTE $20, $20, $20 .... and include this in a module screen { %asminclude "screen.asm", "screen" ... } and attempt to get hold of this label with something like uword ref = screen.screen_char without any luck (I tried various with and without various prefixes). According to the doc I should have access to the labels. I expect I'm doing something wrong but without any examples I don't know how to use this beyond this.
  12. Did a quick update of Petaxian with a workaround for the NES keyboard emulation (thanks to desertfish for pointing out that this was pretty trivial to add).
  13. I've uploaded a new version of Petaxian. Lots of updates since the first version More variations of enemies and movement patterns Simple sound effects Actual "score" counting Joystick control (though the NES keyboard stuff is causing some issues) And lots of various smaller adjustments and optimization of code etc. etc. Just be warned that the NES keyboard emulation seem start up with joystick byte 1 set to 0 (= all buttons pressed) instead of 255. That causes the game to autostart the first time. I could work around this using a non-NES keyboard key to start the game, but since I added joystick support that seems inappropriate. Everything works fine if the game is started with -joy SNES (or NES).
  14. Since I've been doing a bit more programming for my game I thought I should give a bit more feedback about Prog8. I've naturally come across a few things here and there that ideally would be "fixed", but generally I find Prog8 to be a nice and simple language to work in. Since we are working closer to "the metal" than I normally do I think the simple types and limited syntax makes perfect sense. I especially like how easy it's to integrate in assembly functions with the Prog8 code. Apart from the odd actual bug I think this is where I would really like to see a bit of improvement. I've already mentioned the issue with variables only used in assembly being optimized away. I'd prefer to have these in the Prog8 part of the code for a few reasons. One is visibility, perhaps the variable is later needed in the Prog8 code. The other is that we don't really know where we can put this in standalone assembly since Prog8 program might put it's own variable in the same "space" (at least when using ZP variables). I've been using the workaround (having dummy assignments in other code) but think it would be more elegant to have a way to mark a variable as "used in assembly" so it's not optimized away. I was also going to add a ticket about constants being removed in assembly output as well, but found that someone already have covered this (https://github.com/irmen/prog8/issues/22). I'd just like to add that I also think this would be nice. I have found debugging a bit more of a hassle than in my "day work", but that has more to do with the emulator and the nature of the platform. Though when I struggled at worst (and finally did have a look at this using the debug option in the emulator) it turned out to be a emulator bug, at least that is what I believe (Keyboard NES controller emulation kicks off with all bits reversed).
  15. Ah, I'm looking forward to testing the new rnd function. I have noticed that I seemed to get noticable clustering patterns. I'll probably wait a new build of the emulator.
  16. That's basically because I don't really know how to use the assembler (at least not yet), so I just went for the default program declaration the feels natural to me. It's at least 30 years ago since I last touched assembly language (and that was on M68000 systems). So I'm more or less starting over from scratch and haven't really gotten to the the more assembler manual yet. I have started reading up on the 6802 instruction set though. Not too hard to get a basic grasp of that given the small instruction set.
  17. Let me again state that this is probably a very minmal problem and it could be covered by expanding the documentation for asmsub a bit. However, if you would like to add it to the compiler I suggest adding it to the asmsub declaration. asmsub get_low(ubyte value @A) uses (testvar) clobbers(Y) -> ubyte @A { %asm {{ sta testvar lda #$0F and testvar tay lda tbl,y rts }} I.e uses (testvar) (or something similar) just lets the compiler know that testvar is no longer a potential unused variable, even if there is no actual use in the assembly code. I assume you are parsing this line anyway to match call parameters.
  18. I basically assumed that it would be fine to use ZP_SCRATCH variables as long as I avoided calling any subroutines "In between" use. That seem to be correct then. BTW, the main problem with using the various zero page location is that we won't know which are used by the code until after compile is done. Note that this isn't likely an especially serious challenge but it's sort of would belong in a block similar to "clobbers" (i.e that the compiler marks variable as "used" if it's listed for the asmsub).
  19. I've written a couple of assembly routines as a test and this seem to work fine. However, I was wondering how to use "temp" variables in the asmsub. I.e. I could not just add ubyte tmpvar in the module file and then have the asmsub use this e.g. with sta testvar I figured out that this is because the compiler removes the variable since it's unused in the actual prog8 code. Is there a way to indicate that a variable is in use in a asmsub? BTW, I used P8ZP_SCRATCH_REG since I found that in the asmsub's in textelite.p8.
  20. I've uploaded a new version of Petaxian making it a bit more like a proper game. Now loop over 8 stages, 3 different enemy types (requiring different 1 to 3 hits to kill). And some simple sound effects. I basically just copied the X16 sound code from Tehtriz.
  21. Thanks for the hints. I have already taken a peak at the asm output for what I think is the revelant sub and there might very well be a few things that might be possible to optimize. But since there are no problems getting it to run on the cx16 I think I'll focus on getting a bit more of the main functionallity completed before I concentrate on C64 speed.
  22. I've uploaded my first version of the Petaxian game now (very much inspired by C64 Galaga). It's no where near a complete game, but it's sort of playable. As expected in this thread it's written in Prog8 which has certainly allowed me to make this a lot faster than trying to re-learn 6502 machine language (last used in 1987 when I upgraded from C64 to an Amiga 500). Though I'm a bit tempted to look closer at assembly to see if I can speed this up enough to get it to run smoothly on C64. It can be compiled and run on C64 as well but it slows down when there are a lot of moving "bits" on screen at once.
  23. borgar

    Petaxian

    Version 0.5

    37 downloads

    I had been lurking on the forums for a few months when I found Prog8 and though this looked interesting. I.e. I could learn a new language and test out the emulator. I recently saw some good demos using C64 emulator but just based on PETSCII graphics and I though this looked surprisingly cool. Then I remembered the old Galaga game on the C64, the one using just (a few) petscii chars. I thought making something similar would be a nice challenge. The game is continuing to move toward what I consider a complete (but short) game. There are now 12 levels at which point the game will end in victory (bonus points for lives remaning). I am currently inclined to thinking that it's ok to end up with a fairly short and "completable" game. I still need to add some sort of simple high score handling. And there are always places that could use a bit of extra polishing but perhaps it would be better to spend that effort on another game.
  24. Petaxian View File I had been lurking on the forums for a few months when I found Prog8 and though this looked interesting. I.e. I could learn a new language and test out the emulator. I recently saw some good demos using C64 emulator but just based on PETSCII graphics and I though this looked surprisingly cool. Then I remembered the old Galaga game on the C64, the one using just (a few) petscii chars. I thought making something similar would be a nice challenge. The game is continuing to move toward what I consider a complete (but short) game. There are now 12 levels at which point the game will end in victory (bonus points for lives remaning). I am currently inclined to thinking that it's ok to end up with a fairly short and "completable" game. I still need to add some sort of simple high score handling. And there are always places that could use a bit of extra polishing but perhaps it would be better to spend that effort on another game. Submitter borgar Submitted 05/01/21 Category Games  
  25. I laughed out loud reading this tread. I have to admit I also had an extensive collection of "offsite backups" on the C64. I had a nice archive of games saved with turbo tape and several notebooks containing indexes with tape number and counter position for each "backup". My only defense is that I stopped any nefarious practices as soon as I started to earn enough money to actually purchase games. I have certainly given a significant amount of money to the industry over they years and have bought a lot lot more games than I will have ever have time to play (according to my backlog on Steam, GOG and PSN, not to mention all the un-played physical disks etc.) Seems a bit unfair to be honest. Back in my C64 days I had plenty of time but no money for games. Now it's the opposite, not enough time to play all the games I buy
×
×
  • Create New...

Important Information

Please review our Terms of Use