Jump to content

ilmenit

Members
  • Content Count

    426
  • Joined

  • Last visited

  • Days Won

    2

ilmenit last won the day on August 27 2013

ilmenit had the most liked content!

Community Reputation

521 Excellent

About ilmenit

  • Rank
    Moonsweeper

Recent Profile Visitors

11,186 profile views
  1. Your workaround may work in some cases. With detail mask you are telling RC to "multiply distance" of pixels marked areas between destination image and the current output. By applying the detail mask you are changing what is "global optimum". Therefore RC minimizing the "global distance" (Norm. Dist.) may jump out of the previously found "local optimum" by repositioning the sprite. Unfortunately it may never "jump out", especially if "number of solutions" in LAHC algorithm (/s parameter) is small or when the newly calculated Normalized Distance is too big from the previous one.
  2. The "line error" is a known bug existing in RC from he beginning. RC is emulating ANTIC and was created basing on awesome documentation prepared by Phaeron; during development it was tested also on his Altirra. However at the time Altirra had imperfect sprite emulation related to sprite repositioning (what is going to be drawn on the screen when you reposition a sprite to a location where "beam" is actually drawing it. Before RC, considering that there was nothing in the past needing exact behavior, no emulator had it properly implemented. After Phaeron fixed Altirra and wrote good description of what Atari is exactly doing in such situation, I planned to fix the RC too. However meanwhile Phaeron implemented to RC multi-threading and huge number of optimizations. Fixing the problem in such optimized code is not easy, as I had no time to understand exactly how the optimizations he implemented work. Phaeron can be probably the best person to fix the bug now, however none of us touched the RC code for a few years now. Other fix "by hiding the problem under carpet" could be by "rejecting solutions" during the emulation phase. Program there could check if sprite is repositioned to a position where it would trigger the bug. However also this would require better understanding of the emulation caching Phaeron did. I unfortunately work on some out-of-Atari projects and don't have time to get back to this. As RC is random by nature if you run a few conversions of the same picture in parallel, most probably some of them won't have bugs. Also as you found out - the longer RC works, the bigger chance of the bug there is. RC works by iteratively finding better positioning of the sprites and changes of color registers. At one point to progress it needs to "reuse" the sprites. If it finds out that the best reuse is by placing it to overlapping area of previous sprite position, we have a bug.
  3. https://gitlab.com/camelot/kickc Currently aiming C64, but open source and looks very promising. Some capabilities of C language are removed (recursion, unions etc.), because just supporting them prevents many optimizations in the compiler for 6502. Some useful features (multidimensional arrays) are still missing.
  4. For anyone interested how Another World works internally: https://fabiensanglard.net/anotherWorld_code_review/
  5. The easiest way is to learn by examples - take a look e.g. here:
  6. Seems that C64 SMB is using flickering to bypass limits of too many objects, which especially in case of flames is acceptable: https://youtu.be/6jIrR9Iqq4Q?t=1518
  7. Does anyone knows how many sprites and of what sizesSMB requires on screen at the same time?
  8. Could you share the C code? I wanted to port it once myself and could be useful for the others too, as a prototyping base before moving to asm.
  9. Try knoll dithering for pictures with big gradient areas.
  10. I agree with Pirx. As always people discuss mockups while this is the least important thing to have a full game. Guys, play Limbo if you didn't and think how you are going to address all the physics related puzzles that make the game.
  11. The game is fine. Incognito / U1M is unusable for this game
  12. 1. Make a few alternate paths in the maze and a few objects that you have to collect till the exit (snake-like) 2. Add some additional rules to the levels like in game "The Witness" - e.g. one color of dots must be on one side of the line.
  13. This is great! Do some writeup of the development process, please!
×
×
  • Create New...