HDTenEightyP/NetNews huggingface dataset:
From: Lee_Robert_Willis@cup.portal.com
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Icon dragging fun (Hmm?)
Date: Tue, 29 Dec 92 15:50:47 PST
Organization: The Portal System (TM)
Distribution: world

>Hello out there in programmation land...
>
>...does anyone know if it's possible to have your program become a *source*
>for draggable icons (ala NeXT apps), and if so how to pass different types
>of information between apps this way?  It would be extremely user-friendly
>and neat-o-keen if this were possible, but as far as I can tell CBM's only
>set things up so that the Workbench is the only source of draggable icons,
>and an app can only be a destination, and the only type of information that
>can be passed is file info.  This is kind of restrictive!  Is there any OS
>support for custom draggable "stuff"?  Thanks!
>-- 
>::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
>Jake Rose               :: Every cloud has a silver lining.
>jaker@csugrad.cs.vt.edu :: Every silver lining has a cloud inside it.
>::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
>

Hi Jake,

As far as I know, you can't put icons onto the Workbench screen. But you can
create your own drag & drop interface on a custom screen. AmigaVision does
this for its icons. I've also done this in my FreeWare program
'Precognition'.

Check out the 'Bobs' section of the RKMs.  I could probably dig up
some sample code if your interested.

Lee      Lee_Robert_Willis@cup.portal.com
Xref: sparky comp.sys.amiga.programmer:17675 comp.sys.amiga.hardware:21930
From: amipb@amipb.gna.org (Philippe Berard)
Newsgroups: comp.sys.amiga.programmer,comp.sys.amiga.hardware
Subject: Re:  Attn Commodore: You are making a Big Mistake (Hardware
Date: 20 Dec 92 02:08:10 GMT
Organization: IWANIMA
X-NewsSoftware: GRn 1.16e (7/4/92) by Mike Schwartz & Michael B. Smith

In article <alien.01q6@acheron.amigans.gen.nz> alien@acheron.amigans.gen.nz (Ross Smith) writes:
> In article <1992Dec3.173703.25379@ifi.uio.no> perod@ifi.uio.no (Per Christian \deg}rd) writes:
> >
> >* No you would NOT make more money! Who would buy a slow game that they knew would be
> >  at least twice as fast if the programmer had accessed the hardware direcely?
> >  None of the A500/A2000 owners anyway, and they dominate the market. Maybe your game
> >  would run at an acceptable rate on A3000, but how many people owns it? And any other
> >  sim they'd got would be faster or more detailed. And why bother with multitasking
> >  anyway. It't great for utilities, but if the game can return to Workbench, most (all)
> >  players would be satisfied. Accessing hardware directly and TEMPORARILY shutting down
> >  the system, you can guarantee a steady frame update (which lots of arcade games
> >  require) and you can read have you own interrupts that you KNOW will execute every
> >  fifth of a secound and you'd have a SAFE environment. In the multitasking world, you
> >  can't be sure of anything. What's good about having fast reflexes if the game can't
> >  catch up?
>
> Again, you're talking about *arcade* games. Some of us prefer *interesting*
> games. If you want to test your reflexes (yawn), buy a Sega or Nintendo or
> something, and quit crippling the Amiga by insisting that yet another
> scrolling shootemup is more important than real applications.

    Who has said that fast scrolling with big copperlists and fast moves are
    only done for *ACTION* games ? Noone. There are some adventure games
    that use these features (just look at Drakkhen). Again, we don't need
    anyone to make a judgement on which games are crap, and which aren't,
    as many people like both action and adventure games (or am I so alone ?),
    but we would only like to know why CBM destroys what makes them live.
    
    BTW, if RTG was the reason of the 'non-HRM' syndrome, an allowing people
    to do what they want with the BitMap structure, I think RTG will break
    on the graphic cards like the VIVID or the RAMBRANDT, and all the ones
    that have external Video-Ram.

                                   -- Philippe

.----------------------------------------------------------------------------.
|  Philippe Berard  (French Amiga User)       |                              |
|  "They hold a cup of wisdom,                | UseNet : amipb@amipb.gna.org |
|   But there is nothing within" (Kate Bush). |                              |
`----------------------------------------------------------------------------'
From: bloc1469@ee.ee.uwm.edu (Gregory R Block)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Chunky Pixel Mode for Low End Chip Set?
Date: 24 Dec 1992 07:06:00 GMT
Organization: Electrical Engineering Dept. University of Wisconsin - Milwaukee
Distribution: world
NNTP-Posting-Host: 129.89.2.33

In article <Karsten_Weiss.0n2o@ibase.stgt.sub.org> Karsten_Weiss@ibase.stgt.sub.org (Karsten Weiss) writes:
>High End Chip Set Commodore is developing at the moment. I was very happy
>to see that Commodore finally decided to implement a chunky pixel mode
>which is very important to me. However, I recognized that the chunky mode

First, I'm curious:  Why on Earth is a chunky pixel mode that
important to you?  There -ARE- some tricks...

>I think it is very important that the Low End Chip Set will get the
>chunky mode as well because that would make it possible to convert games
>such as Ultima Underworld I + II, Comanche, Strike Commander, etc. with
>FULL SPEED!!! It doesn't help very much when only the High End will get
>chunky because the Low End Chip Set will be in the 'game computer' of the
>future - not the High End!

By using a little ingenious programming, some intelligent
depth->palette routines, and stuff like WritePixelArray8, things like
Underworld become EASILY possible.  There's absolutely NO reason that
you can't do real-time texture mapping with a planar system.  As a
matter of fact, when the amount of depth goes down, some intelligent
palette-selection routines will get you a mapping that looks good in
whatever resolution is chosen, allowing the same code to work for both
AGA and ECS/OCS machines.

>Any other opinions?

>PS: Don't tell me it is possible to code such stuff with compareable
>    speed on the current Amigas...

Well, I didn't read this till just now.  Sorry.

If you don't believe me, ask Chris Green, who works on the graphics
stuff at C=.  He was one of the programmers for Ultima Underworld, and
he's given lots and lots of pointers on how to do RTTexMaps under a
planar system.  It's possible.

Anyone happen to keep those on file?

Greg


--
(: (: (: (: Have you overdosed on smileys today?  Why NOT!?! :) :) :) :)
(: "Our father, who art in Iowa, Hollow be thy head, Thy ideas run    :)
(:  Thy will be done, At Commodore as it is at Apple"  -Dan Barrett   :)
(: (: (: (: (: (: (: (: (: (: (: (: () :) :) :) Wubba, the Dark Angel :)
From: Paul_Trauth@agwbbs.new-orleans.LA.US (Paul Trauth)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Subliminal Messages
Distribution: world
Date: 2 Jan 93 22:23:03 CST
Organization: The Amiga GateWay BBS * New Orleans, La.

In a message dated Sat  3 Jan 93  1:48, Gene_ruebsamen@republik.fidonet.org
wrote:

 G> I am trying to figure out a way to get my A3000 to flash a text
 G> message on the screen for a brief period of time (about 1/15th to
 G> 1/30th)
 G> of a second, and then wait a few seconds and flash the message again.
 G> Can I just display the text and then quickly clear the screen? or is
 G> it
 G> more complicated than that, must I time the message with the screen
 G> interupt so that I am sure that the message is displayed?

You'll probably want to be beamsynced.

I remember one utility for the C64 that attempted to include a subliminal.
Every so often, it would flash, for one frame, the words "Support
Shareware!" at a point on the screen. Once i discovered this, i quit using
it...

-- Via DLG Pro v0.995

- be zorch, daddi-o --------------- paul (raccoon) trauth ----------------
--------------------------------------------------------------------------
Internet -> paul_trauth@agwbbs.new-orleans.LA.US        \\\///\\\///\\\
Usenet   -> rex!agwbbs!paul_trauth                      \\\///\\\///\\\
--------------------------------------------------------------------------
  "eagles may fly, but a weasel will never get sucked into a jet engine"
From: paulk@terapin.com (Paul Kienitz)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: New hardware reference guide?
Date: 21 Dec 92 20:13:05 PST
Organization: BBS

> What 25Mhz AGA chip?  AGA still runs at 14Mhz.
 
Great.  I heard from about 29000 people that the ones in the 4000 ran
at 25 mHz, and told 29000 more people this "fact" ...
 
> Alice only has 16 data pins, if you noticed.
 
Then where's the 32 bit bus at?
 
 
On the other hand, this is good news because it means it can be
attached to the A3000's existing chip memory!  (?)


Durn, the more I learn about AGA the less impressed I am ... why wasn't this
done in 1989?

Someone once told me that C= has a lower R&D budget *for its size* than its
competitors do.  If that's true you guys have done amazing amounts with no
resources but sheer human talent, but DAMN it sure would have helped to put
more into the effort and get it done sooner.
From: jtp@cs.hut.fi (Jukka Partanen)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: LockIBase
Date: 27 Dec 1992 17:35:13 GMT
Organization: Helsinki University of Technology, Finland
Distribution: world
NNTP-Posting-Host: laphroaig.cs.hut.fi
In-reply-to: ry41@rz.uni-karlsruhe.de's message of 23 Dec 1992 12:20:03 GMT

In article <1h9lhjINNk0p@nz12.rz.uni-karlsruhe.de> ry41@rz.uni-karlsruhe.de (Bernhard Moellemann) writes:

> Simply don't touch other peoples screens. Then all is easy and clean.

	Well suppose one would want to write a commodity to activate
	the window under the mouse pointer on keypress. Restricting
	this to public screens only would in my opinion render such a
	program totally useless. 

	jtp

Zippy quotation:
Now my EMOTIONAL RESOURCES are heavily committed to 23% of the
 SMELTING and REFINING industry of the state of NEVADA!!
From: Lee_Robert_Willis@cup.portal.com
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Chunky Pixel Mode for Low End Chip Set?
Date: Fri, 25 Dec 92 20:26:01 PST
Organization: The Portal System (TM)
Distribution: world
  <jbickers.0m2n@templar.actrix.gen.nz>

Gregory R Block writes:

> First, I'm curious:  Why on Earth is a chunky pixel mode that
> important to you?  There -ARE- some tricks...

I don't know about him, but I'd like chunky pixel mode so I can
do image processing (part of my job) on my Amiga.  Image processing
is much easier when you can treat pixels as just big arrays of numbers.

Lee      Lee_Robert_Willis@cup.portal.com
Newsgroups: comp.sys.amiga.programmer
From: alex@bilver.uucp (Alex Matulich)
Subject: ASL and GadTools under 1.3 - can this work?
Organization: W. J. Vermillion - Winter Park, FL
Date: Mon, 28 Dec 1992 03:23:15 GMT
Summary: A couple of ideas for supporting 1.3 users with 2.0 software
Keywords: 2.0 compatible 1.3 compatibility


Hello.  I have an idea about how it might be possible to write software
for AmigaDOS 2.04, that uses 2.0-specific features, and yet still runs
under 1.3, with the same features!.  Someone please tell me if this will
work.  (I'm new to 2.0).

Specifically, my application must use many gadgets, of different kinds.
The task of writing this program in a 1.3-compatible way is much too
daunting for me, and I would MUCH rather use the gadtools.library.  I will
also be using the ASL library for a file requester.

Neither of these libraries are available under 1.3.  BUT... tell me if
these workarounds will actually work.

ASL.library
-----------
This is actually disk-based, so I assume that by merely having the
asl.library file in the LIBS: directory, a 1.3 user can use this library.
The only problem is that I suspect the ASL library makes calls into the
gadtools library....

gadtools.library
----------------
This is in ROM.  My proposal is to link this library at compile time.
I notice that if I use the pragma include files, the linker (SAS 5.10b)
will NEVER link amiga.lib.  If I leave out the pragmas, it gets linked in.
Upon using OML to list the contents of amiga.lib, I notice that it
contains all Amiga functions, including the gadtools.library functions!

This would imply that amiga.lib contains duplicates of the 2.0 ROM
functions, and linking it with my software would make my software bigger,
but the extra baggage would be all the 2.0 stuff it needs to run in a 1.3
environment.  I would, of course, provide in my package a "real" 2.0
program without the baggage; the fat prongram would be for 1.3 only.

Will this work?  My 1.3 beta testers are clamoring to keep my software
compatible with 1.3.  But I dearly want to use GadToolsBox to design my
user interface, which works only in 2.0.

Thanks in advance for any replies.  PLEASE shoot down my suggestions, and
make your own!  This has got to be possible somehow.

-- 
 _ |__  Alex Matulich    alex.matulich@oau.org
 /(+__>  Unicorn Research Corp, 4621 N Landmark Dr, Orlando, FL 32817
//| \     UUCP:  alex@bilver.uucp   {peora|ge-dab|uunet!tous}!bilver!alex
///__)     Internet:  alex@bilver.oau.org | alex%bilver@peora.sdc.ccur.com
From: paulk@terapin.com (Paul Kienitz)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Chunky Pixel Mode for Low End Chip Set?
Date: 30 Dec 92 21:58:54 PST
Organization: BBS

> Well cbm's Lew said it will have chunky mode without losing its
> bitplane nature.  take that as you might interpret it.
 
Yikes.  That's the sort of prophetic pronouncement that could keep a
whole town full of medieval theologists busy for months.
 
I wonder if he means that there'll be some kind of address
translation and WritePixel and WritePixelLine8 in hardware, so you
write a byte to a fake address and the hardware splatters the bits
out into the appropriate physical planes?
 
Yikes.
From: rock@lakes.trenton.sc.us (Rockerboy)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Hardware/Amiga 1200.
Date: Mon, 21 Dec 92 05:21:02 EST
Reply-To: rock@lakes.trenton.sc.us (Rockerboy)
Organization: Lakes Public Access

hjalmar@cbmswe.se.so.commodore.com (Peter Hjalmarsson Sweden) writes:

> Here in Sweden we have just had a demo competition. We received almost
> only "euro-style" demos, but with a twist: As a rule we stated that all
> demos had to give back all resources, be stoppable by the right menu
> button (can you say button B on the CDTV remote), be harddisk installable,
> and more.
> 
> So although much of the effects in "euro-demos" might be impossible to
> do without "taking over", there seems to be no problem to make demos
> that at least runs under the OS well enough. All it takes is some
> incentive, like the A3000 that was first prize...
> 
> A world-wide compo like that, but for AGA instead might be a good idea...

Except that, without the hardware man for AGA, it will _remain_ an 
idea...
But I will confess to being somewhat curious as to just what _can_ be 
done through the OS as far as demos/games.  Certainly, _my_ future 
purchasing decisions will be based largely on the impression I have to 
such beasts.
Newsgroups: comp.sys.amiga.programmer
From: danb@shell.portal.com (Dan E Babcock)
Subject: Re: Chunky Pixels vs. Bitplanes (was: Chunky Chip Set...)
Organization: Portal Communications Company -- 408/973-9111 (voice) 408/973-8091 (data)
Date: Thu, 31 Dec 1992 23:53:55 GMT

In article <1992Dec31.174137.10865@mpifr-bonn.mpg.de> mlelstv@speckled.mpifr-bonn.mpg.de (Michael van Elst) writes:
>In <C03uC5.15o@unix.portal.com> danb@shell.portal.com (Dan E Babcock) writes:
>>In article <1992Dec31.011428.2926@mpifr-bonn.mpg.de> mlelstv@specklec.mpifr-bonn.mpg.de (Michael van Elst) writes:
>
>I am talking about a single blitter architecture. The simple point that
>you need less memory for less bitplanes makes an operation faster.
>
>>No, the VRAMs contain a color register. The "1" expands to whatever color was
>>previously loaded. Again, this allows text writing and polygon filling to be
>>done 4 times faster than usual.
>
>So you write a bitplane to VRAMs and get the whole pixel depth ? Would
>be identical to write to several bitplanes at the same time. I can't seen
>anything chunky or bitplane specific here. Just a method to increase
>bus bandwidth.

No, it is specific to chunky. There's -no way- to write several bitplanes at
the same time except by using seperate memory banks for each bitplane.
With chunky all the information is local, which enables you to take advantage
of the structure of DRAMs/VRAMs. Notice the problems with AGA: screen shifted
to the right, limited overscan. This is a result of the amount of fetching
and buffering that has to go on before the first pixel can be sent. 

Dan
From: HETLAND@gribb.hsr.no (Hetland, Thor H.       7-95)
Newsgroups: comp.sys.amiga.programmer
Subject: Code to reach CHECKPOINT strings
Date: 22 Dec 92 11:06:15 GMT
Organization: Rogaland University Centre



OK, I just can't fint the trick to read the string in the CHECKPOINT gadget, 
how do I reach that point?  Wnd-> ++++


Totto-92
From: jbickers@templar.actrix.gen.nz (John Bickers)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Chunky Pixel Mode for Low End Chip Set?
Date: 30 Dec 92 10:15:21 PST
Organization: TAP

Quoted from <paulk.2za1@terapin.com> by paulk@terapin.com (Paul Kienitz):
> > I don't see how flood filling can be faster with planes. The
> > classic method is mostly ReadPixel() and WritePixel() operations,

> The area fill operation built into the blitter doesn't go one
> pixel at a time, I'm pretty sure.  Unfortunately the line-drawing

    On the other hand, the Blitter's "fill" mode isn't a flood fill,
    and it needs to be set up strangely. Every time I'd looked at
    using it, I've run into a problem drawing the boundaries that it
    wants.

    Also, it's been deleted from the thread, but we have been talking
    about CPU-driven operations.
--
*** John Bickers, TAP.                   jbickers@templar.actrix.gen.nz ***
***    "Radioactivity - It's in the air, for you and me" - Kraftwerk    ***
Newsgroups: comp.sys.amiga.programmer
From: mlelstv@speckled.mpifr-bonn.mpg.de (Michael van Elst)
Subject: Re: Going to the metal
Organization: Max-Planck-Institut f"ur Radioastronomie
Date: Sun, 3 Jan 1993 14:40:42 GMT

In <mXgswB1w165w@lakes.trenton.sc.us> rock@lakes.trenton.sc.us (Rockerboy) writes:
>mlelstv@speckled.mpifr-bonn.mpg.de (Michael van Elst) writes:
>> With a 95% chance a game will require exactly a specific version of that
>> library.

>Agreed, but that is not unacceptable.  Many utilities require certain 
>libraries, such as reqtools, etc.  Certainly, a software solution would 
>be better than hardware, and would be a compromise that would satisfy 
>almost everyone.

What I meant was that a 'hardware banger support library' as was suggested
but which comes in lots of flavours is not acceptable. It is very likely
that some program (game or demo or the like) will require a specific version
(due to side effects or bugs in the version of the library that the programmer
used).

Look at the number of slightly incompatible MOD players out there to
get an idea of the problem.

Regards,
-- 
Michael van Elst
UUCP:     universe!local-cluster!milky-way!sol!earth!uunet!unido!mpirbn!p554mve
Internet: p554mve@mpirbn.mpifr-bonn.mpg.de
                                "A potential Snark may lurk in every tree."
Newsgroups: comp.sys.amiga.programmer
Subject: Re: HELP - malloc, realloc
From: jbickers@templar.actrix.gen.nz (John Bickers)
Date: 22 Dec 92 13:23:38 PST
Organization: TAP

    You may be able to circumvent all this by changing the way you
    handle your array. For example:

    typedef struct MATRIX3 {
        char    *p;
        int     ni,nj,nk;
    } MATRIX3;

    MATRIX3 *matrix3(ni,nj,nk)
    int     ni,nj,nk;
    {
    MATRIX3 *m3p;
        m3p = malloc(sizeof(MATRIX3));
        if (m3p) {
            m3p->p = malloc(ni * nj * nk * sizeof(char));
            if (m3p->p) {
                m3p->ni = ni;
                m3p->nj = nj;
                m3p->nk = nk;
            }
            else {
                free(m3p);
                m3p = NULL;
            }
        }
        return(m3p);
    }

    char    getel(m3p,i,j,k)
    MATRIX3 *m3p;
    int     i,j,k;
    {
        return(*(m3p->p + (i * m3p->ni) + (j * m3p->nj) + k));
    }

    void    putel(m3p,i,j,k,ch)
    MATRIX3 *m3p;
    int     i,j,k;
    char    ch;
    {
        *(m3p->p + (i * m3p->ni) + (j * m3p->nj) + k) = ch;
    }

    MATRIX3 *rematrix3(m3p,newi,newj,newk)
    MATRIX3 *m3p;
    int     newi,newj,newk;
    {
    MATRIX3 *np;
    int     i,j,k;

        np = matrix3(newi,newj,newk);
        if (!np) uh oh

        for (i = 0; i < MIN(np->ni,m3p->ni); i++) {
            for (j = 0; j < MIN(np->nj,m3p->nj); j++) {
                for (k = 0; k < MIN(np->nk,m3p->nk); k++) {
                    putel(np,i,j,k,getel(m3p,i,j,k));
                }
            }
        }

        free(m3p->p);
        free(m3p);
        return(np);
    }

    If what you're trying to represent is a two-dimensional array of
    zero-terminated strings, you can get some speed back if you get
    rid of the "k" parameter in getel(), putel() and rematrix3(), use
    character pointers rather than just characters, and use strcpy()
    instead of just '='.
--
*** John Bickers, TAP.                   jbickers@templar.actrix.gen.nz ***
***    "Radioactivity - It's in the air, for you and me" - Kraftwerk    ***
Newsgroups: comp.sys.amiga.programmer
From: Todd_Lewis@unc.edu (Todd M. Lewis)
Subject: Re: Help reading particular Pixels
Organization: UNC Office of Information Technology
Distribution: na
Date: Mon, 28 Dec 1992 15:22:22 GMT

In article <BzvIv4.G2o@uceng.uc.edu> rbatra@uceng.uc.edu (Rajesh Batra) writes:
> I am trying to use 
>   BltMaskBitMapRastPort(...,minterm,bltMask), 
> where minterm is 0xc0 (exact copy) and my bltMask contains only 1's
> where I want to read the information.

The minterm is probably your problem.  BMBMRP() is more complicated than
it looks, and the minterm is used in a more complicated way than it is
in other functions (BltBitMap() for example).  There are only two
useful values for the minterm for BltMastBitMapRastPort().
The autodoc for BltMaskBitMapRastPort() lists them:

	minterm - either (ABC|ABNC|ANBC) if copy source and blit thru mask
	          or     (ANBC)          if invert source and blit thru mask

Those constants come from <hardware/blit.h>, to wit:
  /* definitions for blitter control register 0 */
  #define ABC    0x80
  #define ABNC   0x40
  #define ANBC   0x20
  #define ANBNC  0x10
  #define NABC   0x8
  #define NABNC  0x4
  #define NANBC  0x2
  #define NANBNC 0x1

So, (ABC|ABNC|ANBC) == 0x80 | 0x40 | 0x20 == 0xE0, not 0xC0 as you might
expect.
--
 _/_/_/  _/     Todd_Lewis@unc.edu          You can lead a horse to 
  _/    _/     utoddl@guitar.oit.unc.edu   Mohammad, but you can't make
 _/    _/_/_/                             a mountain drink a mole hill.
Newsgroups: comp.sys.amiga.programmer