Probably not the right place to ask this, but, how exactly are pict and rled/rle8 graphics encoded.

PICT is a 1980s format dictated mostly by the hardware of the time, which grew by accretion — very few people find it worth their trouble to write their own decoder. (That’s why EV Nova for Windows requires QuickTime installed, and the experimental Windows version of MissionComputer can’t handle PICTs).

RLE is a SpriteWorld format, for which the documentation used to be readily available, but I can’t find it online any more. I’ll take a look through my files and see if I have anything that might help.

Seems like the fastest encoding/decoding would be no encoding/decoding, but then again HDs were small and expensive around that time. Also, when did RLE sprites become available, because I remember reverse-engineering a slew of OS 9 games with ResEdit (including EVC), and they all used PICTs for graphics.

@reclusiveone, on 28 June 2012 - 09:00 AM, said in MissionComputer: The Saga Continues:

Seems like the fastest encoding/decoding would be no encoding/decoding, but then again HDs were small and expensive around that time.

I believe the original format was designed to be as close as possible to the actual instructions that were drawn to screen. We’re talking about low-resolution 1-bit images, so file size wasn’t as much of an issue as you might think even on 400 K floppy disks, but processors and graphics chips were so much slower that the issues involved were quite different from today’s.

And the format was expanded over the years to support colour, higher resolutions, and various forms of compression. So there’s really no predicting what sort of data a PICT file might contain.

@reclusiveone, on 28 June 2012 - 09:00 AM, said in MissionComputer: The Saga Continues:

Also, when did RLE sprites become available, because I remember reverse-engineering a slew of OS 9 games with ResEdit (including EVC), and they all used PICTs for graphics.

RLE is not a standard Macintosh format; it’s something that was developed for later versions of the SpriteWorld framework to allow for better speeds and smaller file sizes. EV Nova was the only one of the EV games to use it, even though I believe its re-written graphics engine is no longer directly based in SpriteWorld as those of the earlier games were.

It’s also my understanding that EV Nova ignores much of the fancier run-length encoding features from which the format takes its name, and uses it primarily as a way to produce 1-bit transparency without requiring separate mask data. Essentially, PICT-based sprites required a separate black-and-white image telling the engine which pixel was transparent, whereas in RLE a long row of pixels can simply be omitted.

Thank you for clearing that up, there is so much I don't know about graphics and resources.

Any updates on the PC port, David Arthur?

How goes the Windows version?

And I'm confused as to why the dude editor wants you to always have 100%, since due to ship OnAppear it can go all over the place anyway.

Actually, that's present in the Mac version, too. I believe it will let you save the resource with values that don't add up to exactly 100, but I'm not sure what would happen if you tried running EVN with that resource.

@evweb, on 18 November 2012 - 10:03 PM, said in MissionComputer: The Saga Continues:

How goes the Windows version?

It’s improved a bit, notably gaining support for all the resource editors that can practically be implemented without substantial structural work. Sometime I ought to package a new version, as it’s unlikely to progress significantly beyond its current state.

@evweb, on 18 November 2012 - 10:03 PM, said in MissionComputer: The Saga Continues:

And I'm confused as to why the dude editor wants you to always have 100%, since due to ship OnAppear it can go all over the place anyway.

The format no longer requires that the values add up to 100%, but I suspect that a resource in which they were unintentionally imbalanced could produce unexpected results, so I’ve maintained the tally in order to avoid surprises. In keeping with MissionComputer’s noninvasive design philosophy, you aren’t obstructed from saving a resource with a different sum, just given a low-key warning.

Unexpected results? The rates for my dude resources have almost never added up to 100, and they seemed to work fine. I figured the game engine just used simple ratios in order to calculate which ship it had to spawn.

Hi David,
I have a feature request. Is it possible you could add the ability to save all resource types as separate JSON or XML formatted text files?
eg.
JSON:
flët.JSON

  {128
    {LeadShipType: 128,
    EscortType1: 128,
    EscortType2: 129,
    EscortType3: 130,
    EscortType4: 131,
    ....
    }
  },
  {129
    {
    ....
    }
  }

This post has been edited by nil0bject : 18 April 2013 - 10:10 PM

I’ve thought about things like that in the past, but it seemed like a lot of work for something that ConText and ResStore already do. It would be technically possible, but actually disassembling the resources into a plist like that would require a rewrite of every resource codec. I suppose using the TMPLs might help in that respect (you could probably even create templates for derez!), but there would still be the question of how to handle unrecognised types.

dusts off the dust bunnies off this thread

Sup guys. Long time no dev hehe. In anycase, I was wondering if it's possible to improve on that one idea I suggested a long time ago that when opening special files, that each files would name out whatever resources resided in them. Here's what I was thinking, a checkbox of all the resources to further help narrow down which file you wanna open. Also, can we do something about preventing each resource worlds from splitting apart down to the next line? It can get confusing in the long run.

Hey, David. Serious, longstanding documentation error:

wëap resources have a Decay field. The mouseover text in MissionComputer currently explains the field as:
"How many damage points to remove each frame (1/30 sec) after the shot is fired"

This is absolutely wrong. (Otherwise, for example, the 150mm railgun, with 10 shield damage and a Decay of 20, would deal zero damage to shields unless it hit within one frame.) The Nova bible explains:

Quote

Decay: How fast to decay each shot's power.
-1 or 0: Ignored.
1 and up: Remove one point of mass & energy damage every time this number of frames goes by (1 frame = 1/30 sec).

In other words, it's the multiplicative inverse of what the current mouseover text says. (Thus, the 150mm railgun will deal 9 damage after 2/3 of a second, 8 damage after 4/3 of a second, and so on, which sounds much more realistic.)

Thanks for a nevertheless amazingly useful tool!