Hires cellvalues 32-63 (and w hibit) - USE?

[jsk]

As we know the ORIC ATMOS graphics is a simple "natural" extension of the text-mode color attributes; quite clever in one way; but in another way, very complicated in practice.

For reference of these values see Chart 11 on https://thespider.oric.org/oric_hires_colour.html

On the other hand, sometimes encoding quirks can be used to achieve and or encode advanced features. Like how, twilite used HIBIT (inverse) to also means that his sprites were always behind them (thus didn't draw in the cell with hibit set), if I remember correctly.

However, the values 32-63 and 32 more with the "inverse" bit set, seem to have very limited usage. Even detecting that range by itself is rather costly, but it means 1/4 of the range of the values of a hires 6-pixel cell is wasted. From encoding perspective there could be an alternative interpreation by the OCULA (ULA replacement) for example. I know some are against such extentions, so I'm looking for clever hacks of usage

[iss]

so I'm looking for clever hacks of usage

Neo: "Colors. Lots of colors."

[Symoon]

HRC, which is a RLE Hires compressor, is looking for the longest sequence of unused and consecutive byte values inside the HIRES picture it's trying to compress.
The idea is to use this range of values a as counter for repeated bytes. By fixing the counter values inside this range, the Oric will be able to know if it's reading a graphic data, or a counter. This allows a better compression, compared to RLE methods requiring to always store data+repetition counter (2 bytes per graphic byte, thus not ensuring the compression will save room!)

So for instance, if values 32-63 are not used in your HIRES picture, the compressor will use them as a counter: 32=1 repetition, 33=2 repetitions, up to 63=32 repetitions.
When the decompression routine (which is specific to each screen, varying according to the unused values in each picture) reads a value outside 32-63, it knows it's a graphic data to be displayed. If it reads a value inside 32-63, it will repeat the previous graphic value, as much as the repetition counter value indicates.

So that's not really a specific use of the 32-63 values, but that's an example of how to take profit of unused values in general

[ibisum]

I'm hacking around with these attributes in my SOUNDTOY project. I've set the goal of making the most colourful Oric game I can, (also the most noisy), and to that end I'm experimenting with the inverse and colour bits.

At the moment SOUNDTOY is just an experimental playground - I'm basically building the functions I'll eventually use in a final program - so its all a bit hacky, but you can check it out anyway since it gives a C/Assembly code-base to work from:

https://github.com/seclorum/soundtoy

(key files are gencode.h for the displayInstructions assembly hack, and toy.c for the various animation and colour/attribute analysis stuff. at gen_rnd_colors() you can find a spot to strip/select for the 32-63 bits .. and see what happens when you turn them on../off)

The text interface is for exploring sound, the hires interface is for exploring .. graphics .. you can hit "G" to go back and forth between them.

In the current hires code, the first thing that happens is that SOUNDTOY generates a bitmap field at the top part of the screen. It does this through standard random (meaning its reproducible, lol), checking if any of the 'dangerous' bits are set on the random value -> YES: discard, continue, NO: poke to the HIRES screen.

This results in a fairly dense colour field with some interesting characteristics. Sufficiently weird that I then use the X/1 value of this random graphics field, to source 'sprite characters', which aren't really sprites but rather 1 row of 8 bytes, sourced from each horizontal line in the quadrant. This means, the random graphics playfield can be used to source 'sprite' characters, which then get randomly/not-randomly animated on the rest of the screen.

These sprites are kind of cute and colourful and there are many, many interesting body parts in the random field to play with.

There are, for example, very clearly useful bricks and tiles and other building/landscape-like monochrome 'spritechars'. There are also very colourful ones, too. In fact there are of course also a nice combo of mono/colour in the mix, it's a really interesting source of 'random but recognizable' little play figures.

Anyway, I will next build a 'ruleset' for how to deal with any of these sprites being 'near' or 'adjacent'-compatible to each other. Like, a way to recognise the graphical impact if either of these two spritechars approach each other on the field.

These rules might then become the basis for a game engine of sorts.

Anyway, just saying, if you want to dive into deep colour on the Oric, SOUNDTOY is at least a working experimental lab for it .. nothing production-ready, but I do enjoy hacking on it every now and then ..

[jsk]

Yes I remember you used them for that, it's good usage as they don't need to the hires... For my compression doing RLE with those attributes (for hires) first and then other simple compression gave best result.

HRC, which is a RLE Hires compressor, is looking for the longest sequence of unused and consecutive byte values inside the HIRES picture it's trying to compress.
The idea is to use this range of values a as counter for repeated bytes. By fixing the counter values inside this range, the Oric will be able to know if it's reading a graphic data, or a counter. This allows a better compression, compared to RLE methods requiring to always store data+repetition counter (2 bytes per graphic byte, thus not ensuring the compression will save room!)

So for instance, if values 32-63 are not used in your HIRES picture, the compressor will use them as a counter: 32=1 repetition, 33=2 repetitions, up to 63=32 repetitions.
When the decompression routine (which is specific to each screen, varying according to the unused values in each picture) reads a value outside 32-63, it knows it's a graphic data to be displayed. If it reads a value inside 32-63, it will repeat the previous graphic value, as much as the repetition counter value indicates.

So that's not really a specific use of the 32-63 values, but that's an example of how to take profit of unused values in general