Re: [ql-users] New WMAN (was: GD2)

2002-11-14 Thread Phoebus Dokos

??? 14/11/2002 1:12:14 ??, ?/? Wolfgang Lenerz [EMAIL PROTECTED] ??:

Are the sources available?

BTW, QPTR pratically doesn't need to be updated - I've done some 
work on that, and, provided one or two new functions are used, to 
reduce 24 bit colours to 16 bit and set the correct MS bit, you can 
use it to produce high colour PE windows from Basic.


There is a distinctive problem there provided you've used just what I call bit 
cropping... ie removing by brute-force the highest order bits from each colour...
The problem (on which I ran into while developing my all around Windoze bmp 
converter is that once you start chopping bits left and right you are killing the 
displayed picture... that's not important for sprites for example (well for me it is) 
as 
for artificial images you can have the colours pre-arranged so they won't use the 
whole 32 or 24 bit gamut, but nonetheless I think that we should come to an 
agreement on how this function should be performed... there are plenty of 
algorithms to go around, but the fastest (albeit not the most correct ;-) is to scan 
your bitmap and statistically adjust it... this can be done extremely fast if using 
the 
FPU (anybody use S.G and G.G's FPUFNs ? ) but for slow QL systems (ie Aurora - 
which hopefully will have it's rendition of the GD2 once I get a: The SGC and b: 
The sources) this is impossible to make at a decent speed :-(... Maybe we should 
restrict colour rounding to high colour systems only (All High-Colour systems, 
including QPC do have FPU support or they are sufficiently fast to perform this)...



I'm trying to finish an article for QL Today for that

We're all waiting :-)


Just a couple of questions here:
1 - Does button mean the buttons in the button frame, or also 
(other) loose items?


I call a button every loose item.

My 2 (euro) cents (pennies) regarding WMAN/PE in general.

With the major updates that happened to the PE, using a different Window Manager 
should become redundant I would think It would be a good idea on restructuring 
it a bit (without losing compatibility) to accept add-ons... Since the PE in general 
provides a good enough (and known enough most important) framework a new gui 
(for which I strive for so long) will be a lot easier to construct. AFAIK, attaching 
bitmaps (ie skins) and high-colour (or should I say multi-colour) icons (sprites) is 
already possible so by polishing it up a bit every one could build his own window 
manager in a sense...

As for my GuiDemo (Norman, Wolfgang and others have seen it so far), once I 
started using FPU-Presence benefiting instructions the whole thing is flying! (and on 
high-resolution, high-colour as well). Even interpreted S*Basic is burning rubber... 
(Generated some 5 Hi colour, 3D shaded Windows in about 15 minutes which is 
NOT BAD at all)... (Regular speed without FPU is about 2 windows on a Q40)
Now if mine can do this, imagine how fast the really optimised (and written in 
assembly) PE can go


Phoebus






Re: [ql-users] New WMAN (was: GD2)

2002-11-14 Thread James Hunkins


On Wednesday, November 13, 2002, at 11:50  PM, Phoebus Dokos wrote:


My 2 (euro) cents (pennies) regarding WMAN/PE in general.

With the major updates that happened to the PE, using a different 
Window Manager
should become redundant I would think It would be a good idea on 
restructuring
it a bit (without losing compatibility) to accept add-ons...

Interesting idea, to allow for add-ons.  Would it be possible to make 
it so that not only would it allow add-ons but also allow 'replacement' 
functions, just like S-Basic replaces old with like named pieces?  That 
would allow updates or modified window routines to be written that a 
user could choose - talk about custimization.

Also, would it be easy to add additional structures/objects within PE.  
I am using several custom pieces in QDT that I wrote.  It would be nice 
to eventually make them part of the standard PE setup (I said 
eventually - QDT comes first!).

Jim Hunkins



Re: [ql-users] New WMAN (was: GD2)

2002-11-14 Thread Marcel Kilgus

Wolfgang Lenerz wrote:
 I hope so. I want to tie up some lose ends like this WMAN thing before
 concentrating on the university project. After that I hope others are
 sufficiently familiar with the code to start contributing, too (it's
 BTW not only SMSQ/E. EasyPtr should be updated as well, for example.
 Any volunteers?).
 Are the sources available?

IIRC somebody asked Albin and he said that he would give them away.

 BTW, QPTR pratically doesn't need to be updated - I've done some 
 work on that, and, provided one or two new functions are used, to 
 reduce 24 bit colours to 16 bit and set the correct MS bit, you can 
 use it to produce high colour PE windows from Basic.

Good. I've never used the QPtr BASIC interface, so I've no idea when
it comes to that.

 Just a couple of questions here:
 1 - Does button mean the buttons in the button frame, or also 
 (other) loose items?

Loose items. But another entry for the button frame thingies is a good
suggestion.

 2 - I often give my application subwindows different colours to my 
 info subwindows.

Ok. How would you call the entries?

Marcel




Re: [ql-users] New WMAN (was: GD2)

2002-11-14 Thread Phoebus Dokos

??? 14/11/2002 3:46:51 ??, ?/? James Hunkins [EMAIL PROTECTED] 
??:
Interesting idea, to allow for add-ons.  Would it be possible to make 
it so that not only would it allow add-ons but also allow 'replacement' 
functions, just like S-Basic replaces old with like named pieces?  That 
would allow updates or modified window routines to be written that a 
user could choose - talk about custimization.

I can't see why not :-) Then again, I've yet to see the sources :-) Nonetheless 
first: all guesswork from Desktop developers (HIIN) would be eliminated and 
second: Why re-invent the wheel?

Also, would it be easy to add additional structures/objects within PE.  
I am using several custom pieces in QDT that I wrote.  It would be nice 
to eventually make them part of the standard PE setup (I said 
eventually - QDT comes first!).


That would be possible if using the add-on idea... Maybe it's already possible... I 
can't tell (yet). and not only that, that would shorten your QDT development by 
months :-)!


Phoebus





Re: [ql-users] New WMAN (was: GD2)

2002-11-14 Thread Wolfgang Lenerz

On 14 Nov 2002, at 2:50, Phoebus Dokos wrote:


 There is a distinctive problem there provided you've used just what I call bit 
 cropping... ie removing by brute-force the highest order bits from each colour...

err no, the lowest oder bits of course...

Anyway, the problem you describe is, IMHO, irrelevant here, since 
you are designinbg a wiondow, and can thus choose any colour 
scheme you like.
It's not a question of displaying a bitmap in this respect...


 I'm trying to finish an article for QL Today for that
 
 We're all waiting :-)
 
You mean, you are all programming with QPTR...?



 With the major updates that happened to the PE, using a different Window Manager 
 should become redundant I would think It would be a good idea on restructuring 
 it a bit (without losing compatibility) to accept add-ons... Since the PE in 
general 
 provides a good enough (and known enough most important) framework a new gui 
 (for which I strive for so long) will be a lot easier to construct. AFAIK, attaching 
 bitmaps (ie skins) and high-colour (or should I say multi-colour) icons (sprites) is 
 already possible so by polishing it up a bit every one could build his own window 
 manager in a sense...

Actually, it is pretty easy to do so, within some limits. I have here 
a small progs I use for keeping my dvd colection. This displays the 
dvds (I scanned the sleeves) and uses, for example, a green 
triangle as a button (that lights up when the pointer is over it).

this was done entirely in Basic - only, it uses RPTR instead of 
RD_PTR(T) and thus is responsible itself for handling things like 
pointer in/out of the window/loose item etc...

I was able to display higher colours even before Marcel changed 
WMAN (it also works on the Q60, for example) since it doesn't use 
WMAN, just the Pointer interface...

Wolfgang
-
www.wlenerz.com



Re: [ql-users] New WMAN (was: GD2)

2002-11-14 Thread Wolfgang Lenerz

On 14 Nov 2002, at 13:54, Marcel Kilgus wrote:

  2 - I often give my application subwindows different colours to my 
  info subwindows.
 
 Ok. How would you call the entries?
Info window colours...
Appsub window colours...

Wolfgang
-
www.wlenerz.com



Re: [ql-users] New WMAN (was: GD2)

2002-11-14 Thread Roy Wood

In message [EMAIL PROTECTED], Marcel Kilgus 
[EMAIL PROTECTED] writes

Wolfgang Lenerz wrote:

I hope so. I want to tie up some lose ends like this WMAN thing before
concentrating on the university project. After that I hope others are
sufficiently familiar with the code to start contributing, too (it's
BTW not only SMSQ/E. EasyPtr should be updated as well, for example.
Any volunteers?).

Are the sources available?


IIRC somebody asked Albin and he said that he would give them away.

I would like to suggest that the sources be given to Rich Mellor who 
could work on them and maintain a cheap commercial release for them.


--
Roy Wood
Q Branch, 20 Locks Hill Portslade. Sussex. BN41 2LB. UK
Tel : +44 (0)1273 386030 Fax : +44 (0)1273 430501 (New number!)
Mobile +44(0)7836 745501
Web : www.qbranch.demon.co.uk




[ql-users] New WMAN (was: GD2)

2002-11-13 Thread Marcel Kilgus

TonyTebby wrote:
 He started getting more into the concept of GD2 !!

 How can anyone do this - has this man a brain the size of a planet?
 I can't understand it and I wrote it!

I just said I'm getting more into it. Not how much :-)
I gather information here and there and it's often enough to do some
changes (like the new buffer-less background colour code or the 16bit
shadow), but that's it. I wouldn't even dare thinking about other
proposals from the list, like background redrawing.

 If I remember right, the sprite cache routines check the address of
 the sprite (which is likeley to be re-used either if you are editing
 the sprite or if you are loading the sprite into the chank of
 memory) and the sprite cache version number (pto_vcch in the sprite
 header)

Argh, I have totally overlooked that you introduced a cache version
(so much for my knowledge). Of course, this way it's easy. And it even
works! Thanks for the hint.

 WMAN should really be updated to GD2 - any volunteers?

That'd be me again, then... In fact I'm almost done. Since yesterday
all routines accept the new colour word definition, only a few more
lines for the system palette are needed. And some sensible defaults
for that palette (which'll probably be the hardest task).

While I'm at it: last call for comments! I'll attach below the new
WMAN specification the way I did implement it. Any suggestions for
changes should be done exactly NOW before it gets official!

 Until then would someone like to modify the WMAN scroll sprite
 generation code to use a new cache version number instead of 0 each
 time? There must surely be a byte spare somewhere in the (a2) block
 to store the last value used.

Yes, there is, I called it ws_scach. And yes, I'm not good at names.

 Will this open source software idea ever catch on?

I hope so. I want to tie up some lose ends like this WMAN thing before
concentrating on the university project. After that I hope others are
sufficiently familiar with the code to start contributing, too (it's
BTW not only SMSQ/E. EasyPtr should be updated as well, for example.
Any volunteers?).

Marcel

-

| |
|  Vector $7C   WM.SETSP  |
| |
|   Set system palette entries|
| |
|  Call parameters  Return parameters |
| |
|  D1.w start index D1   preserved|
|  D2.w number of elements  D2   preserved|
|   D3+  all preserved|
| |
|  A0   A0   preserved|
|  A1   pointer to palette entries / 0  A1   preserved|
|  A2   A2   preserved|
|  A3   A3   preserved|
|  A4   A4   preserved|
|  A5   not used by any routine   |
|  A6   not used by any routine   |
| |
|  Error returns: |
|   IPARIllegal index number / invalid number of elements |
| |

Set the entries of the system palette to the values in the buffer, beginning
with the index in D1 (counting from 0) and ending with the index D1 + D2 - 1.

If A1 = 0 then the entries are taken out of the default table. Otherwise
the buffer must hold an array of words with the colour values of the
different items. The colour format is the standard WMAN colour format as
described elsewhere.


| |
|  Vector $80   WM.GETSP  |
| |
|   Read system palette entries   |
| |
|  Call parameters  Return parameters |
| |
|  D1.w start index / -1D1.w preserved / item count   |
|  D2.w number of elements  D2   preserved  

Re: [ql-users] New WMAN (was: GD2)

2002-11-13 Thread Wolfgang Lenerz

On 14 Nov 2002, at 1:35, Marcel Kilgus wrote:

  WMAN should really be updated to GD2 - any volunteers?

 That'd be me again, then... In fact I'm almost done. Since 
 yesterday all routines accept the new colour word definition, only 
 a few more lines for the system palette are needed. And some 
 sensible defaults for that palette (which'll probably be the hardest 
 task).

Three cheers for Marcel! Please be reminded that his work will 
benefit all platform physically capable of it!

 
 Yes, there is, I called it ws_scach. And yes, I'm not good at names.

You're pretty good at everything else


 I hope so. I want to tie up some lose ends like this WMAN thing before
 concentrating on the university project. After that I hope others are
 sufficiently familiar with the code to start contributing, too (it's
 BTW not only SMSQ/E. EasyPtr should be updated as well, for example.
 Any volunteers?).

Are the sources available?

BTW, QPTR pratically doesn't need to be updated - I've done some 
work on that, and, provided one or two new functions are used, to 
reduce 24 bit colours to 16 bit and set the correct MS bit, you can 
use it to produce high colour PE windows from Basic.

I'm trying to finish an article for QL Today for that


 System palette entries
(...)

Just a couple of questions here:
1 - Does button mean the buttons in the button frame, or also 
(other) loose items?

2 - I often give my application subwindows different colours to my 
info subwindows.
I'm not sure whether I'm alone in that. If not, we (you!)  should, 
perhaps, provide for it.
Wolfgang