stan@hpcvca.CV.HP.COM (Stan Gibbs) (05/17/89)
I have been working my way through all of the Intuition functions, writing simple programs to test my understanding. I have been having real trouble with the Image structure and DrawImage() to create an image in a window. For all my effort, I can't seem to generate an image that corresponds to what I want. I have included the errant code below, and would appreciate any help. I am trying to simply create an hourglass shaped field inside a 16x16 image boundary. I can generate a solid field by setting PlanePick to 0x0000 and using PlaneOnOff to select the color -- no problem. But when I try to display the image data, I get an image which both does not correspond to what I think I'm asking for and is not constant, that is, from run to run the pixel colors are different. I'm not using any special compiler (LC5.0) or linker options. What am I missing? Pointers to example sources would be very useful. Thanks. ============================================================================ | Stan Gibbs | | stan@cv.hp.com || {hplabs,tektronix}!hp-pcd!stan | ============================================================================ #include <exec/types.h> #include <intuition/intuition.h> struct Window *NoBorder; struct RastPort *r; USHORT imagepts[] = {0xffff,0x7ffe,0x3ffc,0x1ff8, 0x0ff0,0x07e0,0x03c0,0x03c0, 0x03c0,0x03c0,0x07e0,0x0ff0, 0x1ff8,0x3ffc,0x7ffe,0xffff, 0xffff,0x7ffe,0x3ffc,0x1ff8, 0x0ff0,0x07e0,0x03c0,0x03c0, 0x03c0,0x03c0,0x07e0,0x0ff0, 0x1ff8,0x3ffc,0x7ffe,0xffff}; struct Image picture = {0,0,16,16,2,NULL,0x0003,0x0000,NULL}; main() { ULONG flags,iflags; SHORT x,y,w,h; UBYTE c0,c1; extern VOID delay_func(),OpenIntuition(); OpenIntuition(); /* opens intuition, contains window support routines */ x = y = 0; w = 640; h = 200; c1 = 0x00; c0 = 0x01; flags = ACTIVATE | SMART_REFRESH | BORDERLESS; iflags = NULL; if ((NoBorder = (struct Window *) make_window(x,y,w,h,NULL,flags,iflags, c0,c1,NULL,NULL)) == NULL) { printf("Window Open Failed\n"); exit(); } picture.ImageData = imagepts; r = NoBorder->RPort; DrawImage(r,&picture,50,50); delay_func(100); CloseWindow(NoBorder); }
c60c-1ea@web-1c.berkeley.edu (Yen Yuanchi Hsieh) (05/18/89)
In article <1410018@hpcvca.CV.HP.COM> stan@hpcvca.CV.HP.COM (Stan Gibbs) writes: >I have been working my way through all of the Intuition functions, >writing simple programs to test my understanding. > >I have been having real trouble with the Image structure and >DrawImage() to create an image in a window. > >What am I missing? A compiler option. You need to set the HUNK types correctly during link. There should be a +Cd option or something like that. Refer to your manual -- you need to put your defined data into CHIP memory... David Navas c60c-1ea@WEB.Berkeley.Edu
stan@hpcvca.CV.HP.COM (Stan Gibbs) (05/18/89)
Nevermind... >> What am I missing? I found my answer while reading the "New Keywords" section of the Lattice 5.02 Manual. The addition of the "chip" keyword to ensure that data hunks are placed in CHIP memory was what I was missing. I have 1Meg of Fast RAM in my 1000, so the default was to load the image data hunks in Fast RAM. Changing my image data declaration to: USHORT chip imagepts[] ... ^^^^ gave me exactly what I wanted. Works for sprites, too! 8-). ============================================================================ | Stan Gibbs | | stan@cv.hp.com || {hplabs,tektronix}!hp-pcd!stan | ============================================================================
rss@ece-csc.UUCP (ML) (05/18/89)
In a previous article stan@hpcvca.CV.HP.COM (Stan Gibbs) wrote:
[Questions about Images not appearing correctly on display...]
...
Stan, your image data points must go in CHIP memory, so that the
blitter chip can deal with it. It is fixed very simply, with
Lattice C 5.x:
USHORT chip imagepts[] = {0xffff,0x7ffe,0x3ffc,0x1ff8,...
^^^^
Add "chip" keyword directly before variable name.kevin@uts.amdahl.com (Kevin Clague) (05/18/89)
In article <1410018@hpcvca.CV.HP.COM> stan@hpcvca.CV.HP.COM (Stan Gibbs) writes: >I have been working my way through all of the Intuition functions, >writing simple programs to test my understanding. > >I have been having real trouble with the Image structure and >DrawImage() to create an image in a window. > >For all my effort, I can't seem to generate an image that corresponds >to what I want. I have included the errant code below, and would >appreciate any help. >I'm not using any special compiler (LC5.0) or linker options. > >What am I missing? > >Pointers to example sources would be very useful. Pointers is the problem... hee, heee You need to move your image data (not the structure) into chip RAM. You can either allocate chip RAM and copy imagepts into it, or use the LC5.02 chip keyword. > >Thanks. > >============================================================================ >| Stan Gibbs | >| stan@cv.hp.com || {hplabs,tektronix}!hp-pcd!stan | >============================================================================ > >#include <exec/types.h> >#include <intuition/intuition.h> > >struct Window *NoBorder; >struct RastPort *r; > >USHORT imagepts[] = {0xffff,0x7ffe,0x3ffc,0x1ff8, make this USHORT chip imagepts[] = {0xffff, 0x7ffe, 0x3ffc, 0x1ff8, and everything should work better. Kevin -- UUCP: kevin@uts.amdahl.com or: {sun,decwrl,hplabs,pyramid,seismo,oliveb}!amdahl!kevin DDD: 408-737-5481 USPS: Amdahl Corp. M/S 249, 1250 E. Arques Av, Sunnyvale, CA 94086 [ Any thoughts or opinions which may or may not have been expressed ] [ herein are my own. They are not necessarily those of my employer. ]
cmcmanis%pepper@Sun.COM (Chuck McManis) (05/19/89)
Generally, problems with images can be traced to the image data
not being in Chip ram. With the Lattice 5.0 compiler you can
declare them as
chip short ImageData[] = { .. };
And that will insure that they are placed in Chip RAM when loaded.
This has the benefit of not placing *all* your data into Chip ram
which is what the -cD switch does. The other problem with images
is displaying them in X plane screens when your image is Y planes
deep. You can avoid suprises by providing all of the image planes
although the PlaneOnOff feature is pretty neat (if somewhat limited).
--Chuck McManis
uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com
These opinions are my own and no one elses, but you knew that didn't you.
"A most excellent barbarian ... Genghis Kahn!"bartonr@psu-cs.cs.pdx.edu (Robert Barton) (05/19/89)
In article <1410018@hpcvca.CV.HP.COM> stan@hpcvca.CV.HP.COM (Stan Gibbs) writes: > But when I try to display the image data, I get an image which both does >not correspond to what I think I'm asking for and is not constant, >that is, from run to run the pixel colors are different. It sounds like your bit-plane data (picture.ImageData) isn't in chip memory. This will produce exactly the random color effects you mentioned. (* -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- *) (* -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- *)
utoddl@ecsvax.UUCP (Todd M. Lewis) (05/19/89)
In article <105674@sun.Eng.Sun.COM>, cmcmanis%pepper@Sun.COM (Chuck McManis) writes: > Generally, problems with images can be traced to the image data > not being in Chip ram. With the Lattice 5.0 compiler you can > declare them as > chip short ImageData[] = { .. }; > And that will insure that they are placed in Chip RAM when loaded. Does Lattice add a #pragma to do this as well? In this Age of Standards I don't like the idea of adding keywords to a language that provides another (standard) way to do nonstandard things. > --Chuck McManis > uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com _____ | Todd M. Lewis Disclaimer: If you want my employer's ||\/| utoddl@ecsvax.uncecs.edu ideas, you'll have to || || _buy_ them. | || |___ (Never write a program bigger than your screen.)
jeh@elmgate.UUCP (Ed J Hanway CUST) (05/19/89)
In article <1410018@hpcvca.CV.HP.COM> stan@hpcvca.CV.HP.COM (Stan Gibbs) writes: >I have been having real trouble with the Image structure and >DrawImage() to create an image in a window. With Lattice 5.0 or better, just say USHORT chip imagepts[] = {0xffff, ... ^^^^ Only the image data itself needs to be in chip memory. The Image structure can be loaded in fast memory. -- Ed Hanway Eastman Kodak Company ...{cornell,rutgers}!rochester!kodak!elmgate!jeh
karl@sugar.hackercorp.com (Karl Lehenbauer) (05/23/89)
In article <1410019@hpcvca.CV.HP.COM>, stan@hpcvca.CV.HP.COM (Stan Gibbs) writes: > ...Lattice 5.02 ... > USHORT chip imagepts[] ... ^^^^ I am turning green with envy. Signed, an Aztec 3.6a owner, waiting and waiting and waiting for the new release... -- -- uunet!sugar!karl | "Nobody hipped me to that, dude." -- Pee Wee -- Usenet BBS (713) 438-5018
limonce@pilot.njin.net (Tom Limoncelli) (05/24/89)
In article <1410019@hpcvca.CV.HP.COM> stan@hpcvca.CV.HP.COM (Stan Gibbs) writes: > 5.02 Manual. The addition of the "chip" keyword to ensure that data hunks > are placed in CHIP memory was what I was missing. I have 1Meg of Fast RAM > in my 1000, so the default was to load the image data hunks in Fast RAM. > > Changing my image data declaration to: > > USHORT chip imagepts[] ... To be 100% ANSI conformant (that is, when ANSI gets officially adopted and products can really be ANSI conformant) wouldn't they NOT be allowed to add a keyword like "chip"? Shouldn't it be "_chip" to conform to the namespace requirements? (venders can use all the symbols that begin with "_") -Tom -- Tom Limoncelli -- tlimonce@drunivac.Bitnet -- limonce@pilot.njin.net Drew University -- Box 1060, Madison, NJ -- 201-408-5389 Standard Disclaimer: I am not the mouth-piece of Drew University
riley@batcomputer.tn.cornell.edu (Daniel S. Riley) (05/24/89)
In article <May.23.14.52.22.1989.3122@pilot.njin.net> limonce@pilot.njin.net (Tom Limoncelli) writes: >In article <1410019@hpcvca.CV.HP.COM> stan@hpcvca.CV.HP.COM (Stan Gibbs) writes: >> USHORT chip imagepts[] ... >To be 100% ANSI conformant (that is, when ANSI gets officially adopted >and products can really be ANSI conformant) wouldn't they NOT be >allowed to add a keyword like "chip"? Shouldn't it be "_chip" to >conform to the namespace requirements? (venders can use all the >symbols that begin with "_") In a word, yes. They actually support 2 versions, "chip" and "__chip". The "__" version is "intended to allow for an ANSI conforming program, while we offer the non-ANSI version for more readable code and some compatibility with MSDOS based products" (from the 5.0 User's Guide, quoted without permission). In think they should not allow "chip", but at least they are aware of the issue, and most of their extensions do begin with "__". -Dan Riley (riley@tcgould.tn.cornell.edu, cornell!batcomputer!riley) -Wilson Lab, Cornell U.
wade@pnet01.cts.com (Wade Bickel) (05/26/89)
riley@batcomputer.tn.cornell.edu (Daniel S. Riley) writes: >In article <May.23.14.52.22.1989.3122@pilot.njin.net> limonce@pilot.njin.net (Tom Limoncelli) writes: >>In article <1410019@hpcvca.CV.HP.COM> stan@hpcvca.CV.HP.COM (Stan Gibbs) writes: >>> USHORT chip imagepts[] ... > >>To be 100% ANSI conformant (that is, when ANSI gets officially adopted >>and products can really be ANSI conformant) wouldn't they NOT be >>allowed to add a keyword like "chip"? Shouldn't it be "_chip" to >>conform to the namespace requirements? (venders can use all the >>symbols that begin with "_") > >In a word, yes. They actually support 2 versions, "chip" and "__chip". >The "__" version is "intended to allow for an ANSI conforming program, >while we offer the non-ANSI version for more readable code and some >compatibility with MSDOS based products" (from the 5.0 User's Guide, >quoted without permission). In think they should not allow "chip", but at >least they are aware of the issue, and most of their extensions do begin >with "__". I think it was a good idea for Lattice to support "chip" as well as "__chip". After all, the routines which use it are Amiga specific and will need conversion during a port anyway It saves me #defining "__chip" to "chi, to make my file more readable. Just put the ofnding routines in a seperate file and use conditional compilation flags to control it. Thanks, Wade. UUCP: {nosc ucsd hplabs!hp-sdd}!crash!pnet01!wade ARPA: crash!pnet01!wade@nosc.mil INET: wade@pnet01.cts.com