The Sinclair QL Forum

martyn_hill wrote:Whilst Per has moved on to to fry bigger fish

I warned you at the start: There are many questions. I have moved on, but in a spiral fashion The question will be re-visited but for now Ive got enough working possibilities to get on with. It seems I was not the only person in need of such a routine. As it very well can be done as a project in its own right, if anyone is at a loose end, please fell free to have a go! Ill be happy to put it to good use

I thought I'd close the Mode4/Mode8 'sample-point' conversation...

Should anyone find it of any value, the address offsets (integer) for a set of 127x test-points forming a spiral, based on the 32k QL display can be found attached as a .txt file and saved as spiral_offsets.zip

The pattern itself looks like:
spiral_testpoints.png

Of course Ill have a think on it. But the (temporary) conclusion Ive come to is as I stated earlier: a distributed statistical sample (I dont have the language, but I know what I mean ) seems to be the most efficient approach. For now Ill settle for the brute force "methodology", as I reckon that itll be a one-off cost in most instances, applied to mainly older, unchanging files. A user making new screen dumps would then hopefully learn to use _scr4 and _scr8 extension names in the future..
Confucius say: "By three methods we may learn wisdom: First, by reflection, which is noblest; Second, by imitation, which is easiest; and third by experience, which is the bitterest." I trust that these forces will be at work here too..

Confucius also said:

Woman with skirt held up runs faster than man with trousers down.

And:

Man who defecates on weighbridge craps on a grand scale.


Allegedly!

Cheers,
Norm. In bed. Full of cold. Drugged to the eyeballs! Wheeeeeeeeeeee!

NormanDunbar wrote:Confucius also said:

Woman with skirt held up runs faster than man with trousers down.

And:

Man who defecates on weighbridge craps on a grand scale.


Allegedly!

Cheers,
Norm. In bed. Full of cold. Drugged to the eyeballs! Wheeeeeeeeeeee!

Thanks for your contribution, Norm. I hope you get better soon! Are you sure youre not confusing Confucius with someone else?
Actually, I was not indulging in a bit of frivolity: The Confucius quote is part of my "strategy" to improve recognition of file types! If it works it will improve detection rates to ~100% in ~0 seconds, ~99.9% of the time!

Morning Per,

I blame the drugs. Sorry. Mind you, it might have also been my "strange" sense of humour.

I fully agree with your Confucius quote though, that one makes total sense.


Time for more drugs!


Cheers,
Norm.

tofro wrote:

martyn_hill wrote: I wonder if anyone (Nasta?) knows whether the 8301 starts flashing in the _next_ pixel having detected a FLASH bit set, or on the current pixel?

That's in the Technical Guide, no need to bother Nasta

The Technical Guide is not precise on this, I had to try out myself for the Q68 implementation of FLASH. From actual hardware, I can confirm Jan is right.

BSJR wrote:

mk79 wrote:

pjw wrote:The sprite format is a very nice and versatile image format that also sports compression. The best thing about it is that it is supported by the OS. However, it is not designed as a picture format, although it can be manipulated to serve, if required.

Actually I have specifically improved it to a point where it could and should be considered the de-facto picture standard. The last missing piece was that sprites have a mask, which is additional data not needed in pictures. That has been removed, you can just use a null-pointer for the mask and then the sprite is a solid picture. What would be the advantage of yet another picture format?

To fully use sprites as image format we need some of the functionality of WSARS (EP4) or PREST (QPTR) that allows you to show sections of a PIC, making it fit a window with pan & scroll options. The current SPRW (EP4) and WSPRT (QPTR) don't allow a partial viewing of big sprites.

Sprites can relatively easily be converted, however, the padding to an even long word at the end of each line is a bit of a nuisance, and is one of the reasons why I feel the sprite format is not the ideal, de facto standards for general image files. Padding makes sense for sprites, which need to be displayed rapidly, but for picture files, the padding would have to be removed on loading - at least if it is to conform with the current wman etc (am I right?) and added again on saving to the spr format.

What would be a great help was if those lovely conversion routines that are used to convert a sprite to the appropriate native format for the platform it is displayed on, could be made accessible as general graphics utility routines, eg by extending the new con driver vector set. I, for one, would be happy to throw something in the hat if one were passed around, if that is what is required..

This is why I have written my graphical game word-aligned.

pjw wrote:Sprites can relatively easily be converted, however, the padding to an even long word at the end of each line is a bit of a nuisance, and is one of the reasons why I feel the sprite format is not the ideal, de facto standards for general image files. Padding makes sense for sprites, which need to be displayed rapidly, but for picture files, the padding would have to be removed on loading - at least if it is to conform with the current wman etc (am I right?) and added again on saving to the spr format.

As the WSARS & PREST commands allow you to set width and height of the section to show, this will automatically cut off any padding even if set to the x-size from the header. There is no need to remove or add it on Load or Save.
Only if the original is a _PIC, may padding need to be added for _SPR conversion.

Bob

Dave wrote:This is why I have written my graphical game word-aligned.

Sadly, real-world images arent always so obliging