Jump to content


New Members
  • Content Count

  • Joined

  • Last visited

Everything posted by dmx

  1. Conversions look great! - I'll ask Sparkler for permission (I'm sure he's fine with it.) I assume there are plenty of skilled musicians around these parts, but should the need arise somehow, I'll be happy to have a go at the music.
  2. Wow, this looks great! It'll be fun to try out a real port! Hope you don't mind if I tweet about it? 😊
  3. Great news indeed! Let me know if you need anything off ROF-64! Cheers, dmx
  4. My pleasure to help. Looks like this is shaping up nicely, looking forward to playing it
  5. Oops, sorry, didn't intend my quick'n'dirty search replace job to be actually assembled, only to be used as a reference, but seems you got it right anyway. Nice work!
  6. Some tables are "word" tables, while some are split into hi/lo e.g. Table TableH = * + 1 !word something !word something While others: TableL !byte <something !byte <something TableH !byte >something !byte >something And so on And yes, I do recommend to build a "good" binary first, then when reversing, do a file compare (windows: fc \b myre.bin good.bin) to confirm they match. Often one gets a tiny bit wrong, and have to hunt for it maybe for days!
  7. Very interesting, I had no idea, but that explains a lot!
  8. My pleasure to be of help! Fantomas, That's excellent stuff. Now someone can write a RLE to that converts the Tiled output back into game data, and you're on the way! I used the object layer in Tiled to mark where to place "fires" and those "floor lights" (aka rats), then put the co-ordinates and sizes into code. Another option could be to automatically generate asm for this.
  9. Hi there. Thanks for your interest in Bruce Lee - Return of Fury I wrote a little "post-partum" about it on my site: https://rebelandroid.com/games/bruce-rof Anyway. The first thing to do is to make the code relocatable - all the tables (map data, map properties, text lookup table, colours, map init, exec routines) and self-modifying code + irqs must be "labeled" properly so that you can move stuff around at will without side-effects. That's a given. The graphics are mostly the same as the C64 version - but the C64 screens are stored as 40x11 rows, where every odd line is the even char | 0x80 - I didn't quite see that on the atari version, but I may be mistaken. Ron J. Fortier said to Retro Gamer Magazine (issue 145) that the C64 version was sort of an atari "emulation". That's why I think you should base your code on the original, not the "inferior" port - and, true enough, the Atari version plays much smoother. I think this is due to the "emulated" port - instead of using multicolour sprites, he opted for TWO double sized single colour sprites for each character, except the Ninja. Additionally, an extra sprite is used whenever Bruce kicks or gets "hurt bad". Edit: AND that's not all, he ran out of sprite pointers/memory, so the sprite frames are doublebuffered and copied in using CPU on every frame. Phew. Needless to say, this can be quite inefficient, and so the C64 can't really keep it at 50 (60) hz, so he's forced to skip a frame or two to get enough time. However, it's still the version I grew up with and love, so I lean towards it - no offense. I'll be happy to be of assistance should you need it. Best regards, dmx
  • Create New...