More on foreground

I had a bit of time today to finish the new foreground design mechanism, along with the foreground save routines for LN.
I was testing the result when I noticed something was not as I expected it to be. My saved version of the foreground data for level 1 showed that screen 8 did not have any foreground. That is not quite right, but even in edit mode Integrator 2012 was not showing it. Now this is due to the new design logic and to a very innocent mistake that was done on the C64 🙂

The mistake consists in the fact that the foreground list for screen 7 is not properly terminated. As a result of that, there’s an alien foreground bit (framed in black below):

Foreground for screen 7 by Luigi Di Fraia

Foreground for screen 7

The extra element belongs to the foreground definition of screen 8. So basically the list for screen 7 falls through to the one for screen 8. Once I understood that I was able to modify the read routines to take it into account, even if it is just a mistake. Now the foreground of screen 8 shows as it should (item framed in black again).

Foreground for screen 8 by Luigi Di Fraia

Foreground for screen 8

What I noticed is that the foreground item for screen 8 is also slightly misplaced so it does not overlap perfectly with the tree it is meant to designate as foreground. Anyway, that is not what this post is about.

The above experience made me think of a third mechanism to designate foreground that would not only minimize the amount of information saved (which would still work with the original game engine), but also allow maximum flexibility as after a foreground list is built for one screen, the trailing part of it would be available to use for a different location where that trailing part would be common to the two screens and complete for the second one.
It is true that the original engine allows this degree of flexibility, but it is also true that the non-terminated list is obviously a mistake and the chances to have a foreground definition that includes another one are slim (identical temple locations at level 1 are not an exception as these are assigned the same foreground definition list).

I will have a thought about this as I think I am pushing it too much now. Besides the extra flexibility would result in a slightly awkward design process and I already commented on the fact I care about usability of the interface.

I guess that in the end I might keep the current design strategy and just report the issue while reading the foreground data, offering users the option to fix it 😀

This entry was posted in Retrocomputing and tagged , , , , . Bookmark the permalink.

7 Responses to More on foreground

  1. Didi says:

    Looks like your Integrator will become a data preprocessing-editor for the best LN-engine ever made, including the elimination of all those “one pixel”-bugs you are constantly showing up.

    I wonder if you´ll be able to find a way to save even more memory (e. g. by using some modern data-compression), to make bigger levels (more locations/action-elements/music) possible? Not that there´s bad need for that, but I am sure you could do that trick. 😉

    • Didi says:

      I wondered how many additional locations could be gained by using fastest lossless (not JPG etc. 😉 ) data-compression (already hinted a bit mouth-watering by your answer at
      https://luigidifraia.wordpress.com/2013/01/13/more-on-the-foreground-editor/ ).

      To easily get an estimated value, I played around with 7Zip and your memory-dumps of all LN levels (included by the Integrator 2012). If you assume a buffer of 1 kB for depacking plus 3 kB for the depacking code, there will be still around 4 kB in memory savings, which would mean about 4 additional locations per level (as an average value)!

      Maybe you want to prove this anytime more exactly, to mark one design-corner of any future LN engine?

      • luigidifraia says:

        Well I guess the issue is indirection. I’ll explain what I mean.

        Suppose you have a compressed Integrator file in memory on the C64. As soon as you need to access the object shapes in order to decide the sprite clipping mask on the fly, you have to unpack the data again. At the moment, object shapes stored in the Integrator file are accessed at each and every movement of any of the sprites. The code would have to be changed so that the clipping mask is decompressed only once and stored in memory. Bear in mind that there is a trade-off when compression is used: buffering and CPU power at least (while interrupts keep going, e.g. music playback).

        Now, I know this is not quite as exciting as compression, but on the C64 we can take advantage of cartridges. Back in the 80’s cartridge versions of games have not been very different from the disk/tape version (if different at all), but the advantages of using a cartridge and memory bank switching are surprisingly good if the technology is mastered. We don’t even need to have access to an EPROM programmer nowadays, e.g. see the EasyFlash cartridge 😀

        Thanks for your feedback as usual! BTW, did you manage to run I2012 at all? I remember you had issues while opening Integrator files as the application would just hang halfway while decoding? It would be a shame if that was still the case 😦

  2. Didi says:

    You are right, there must be additionally some RAM, where the currently used data (foreground objects & sprites) has to be stored temporarily for this single location. Maybe this would take up all of my estimated won 4 kB, but one day I´m sure we will find out… 😉

    About bank-switching, I was proud back then, having my beloved Magic Formel V1.2 cartridge with lots of additonal software on it. Nothing wrong with that technology, it´s still the old software-challenge the C64 also stands for. Recently I watched the 6502 CPU reverse-engineering video (2011) from Michael Steil, and it´s crazy how far people are going until today. This must be love.

    I2012 dated 2012-11-05 runs fine (although level memory-dumps might still contain some errors), but I think we users can be happy to have these betas, just because a bird in the hand is worth two (ninjas) in the bush. 😉

    At least here´s another foreground-possibility aside your modern transparency solution: How about good old 80´s 3D? 😉

    http://c64screenshots.com/3d/index.php

  3. luigidifraia says:

    The latest binaries are 2012-12-11, as per https://luigidifraia.wordpress.com/2012/12/11/new-demo-available-for-integrator-2012-2/
    Have you checked them? The Integrator file for LN2 level 6 was fixed and the archive rebuilt 🙂

    I must admit that this 3D idea is not bad at all. Probably something for the PC version!

    • Didi says:

      Sorry for missing the “Reply”-button in my last comment, I´m not too much experienced in forums, threads & modern blogging systems. 😉

      Also I didn´t provide the link to all the 3D-options! There´s a ZIP-file there, including 4 variants, just for getting inspired:
      http://c64screenshots.com/3d/images/lastninja/lastninja.zip

      Concerning the LODD (location on demand decompression) there already exist two cross-platform projects: PuCrunch (last update 2008) & Exomizer (2013)
      http://www.cs.tut.fi/~albert/Dev/pucrunch/
      (complete with a full documented assembly-listing for the 6502:
      http://www.cs.tut.fi/~albert/Dev/pucrunch/#Decompressor )
      http://hem.bredband.net/magli143/exo/
      (Additionally there´s a nice old thread (2005) about what´s best to take:
      http://compgroups.net/comp.sys.cbm/is-pucrunch-the-final-word-in-c64-compression-pa/260640 )
      Maybe the developers would be interested in supporting the implementation?
      The code is already there, the only complicacy is about the bulk of options that have to be set properly to get the best possible compression!

      Since I´m still in my winter hibernation 😉 , I can´t tell when the next I2012 release will get some playful examining. Due to it´s all about real (& great) nostalgia, I won´t mind if anything about that´ll take years to show-up. Our generation has another 30 years time to wait for & have fun with the LN! 😉

      • luigidifraia says:

        I know both compressors and my favourite is Exomizer. Honestly I would not go down that compression route as I think the cartridge use can alone do a lot for a new game. Besides, there are a number of programmable cartridges available for the C64 that do not require special programming tools as they are flash based: EasyFlash, RR, even the 1541U 🙂

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s