Amiga.org
Operating System Specific Discussions => Amiga OS => Amiga OS -- Development => Topic started by: bbond007 on March 17, 2012, 03:14:17 AM
-
I decided to try and implement a photoshop style toolbar in an application i'm creating. Because i'm using double bufferening and i did not want to draw the toolbar on every frame for performance reasons I decided to try and use sprites. I also thought it wold drag really smoothly which would add polish to my app. I have included a screenshot of what i'm trying to do incase i'm not explaining it correctly.
My toolbar is 2 sprites(or 32pixels wide) and the first thing I noticed is when I move the screen all the way to the left both sprites disappear on my 1200 (but not UAE) and on my minimig only the rightmost(sprite 3) disappears. Some searching led me to the fact that it is a hardware limitation caused by my overscan settings being set to max.
so anyway, I added this code so at least the screen would center and the toolbar would be there by default. Seems to work well enough. Would be nice is there was a way to put a limit on the leftmost position so as not to cause the sprite issue at all, but that is leading into my first issue.
QueryOverscan(DisplayID, &overscanRect, OSCAN_TEXT);
if (!(screen=OpenScreenTags(NULL,
SA_Left, (overscanRect.MaxX - 320) / 2,
Is there a way to pin these sprites to a screen or get notification that a screen is being dragged so I can make the toolbar(the sprites) move in sync with the screen? I'm coming up blank on my searching. I see MoveSprite() takes a ViewPort param but that does not really seem to do what i want. I got all excited at first. Hopefully whatever method of doing this will also allow me to hide the sprites when the screen is not visible.
Ok, finally all of the examples seeing use the following API calls.
FreeSprite(), ChangeSprite(), MoveSprite(), GetSprite()
fantastic. what could be simpler? and the examples work well enough on my Minimig but on WinUAE and my 1200 no sprites actually show until you drag the screen any amount. I'm calling MoveSprite() which all i understand i need to do...
Is there something else I'm supposed to call? RethinkDisplay() (like with Vsprites) or something?
These sprites are pretty lame. Perhaps i should just switch to the blitter.
thanks...
nate
Thanks.
-
Some searching led me to the fact that it is a hardware limitation caused by my overscan settings being set to max.
Rule #1: Never use any overscan at all, and definitely not max.
Overscan dramatically slows down the Amiga. And it eats sprites.
-
Is there a way to pin these sprites to a screen or get notification that a screen is being dragged so I can make the toolbar(the sprites) move in sync with the screen? I'm coming up blank
Don't come up blank. Come up vertical blank. :D
Here is how u do it:
1. Determine the entry in your struct screen (or whatever) that stores the current offset of your screen. By "offset" I do not mean memory location I mean how much Y the screen has been dragged. I am too lazy 2 look it up 4 u :)
2. Set up a Vertical Blank Interrupt.
3. Your vblank interrupt server will automagically run 50 times a second and check if your screen has been dragged. If so then it will call MoveSprite() appropriately.
4. Profit. :D
Later on u can use this same vblank routine to animate your sprites if u wish.
-
Rule #1: Never use any overscan at all, and definitely not max.
Overscan dramatically slows down the Amiga. And it eats sprites.
its no so much that the application is using overscan, just I have overscan prefs set to 728x283 because that is how I run workbench. I guess that causes programs with smaller screens to be able to be moved side to side.
Anyway, I can live with that but, but I'm still trying to solve the other issues.
I'm not sure overscan even slows down the Minimig, but it looks a lot better as it completely fills the LCD and actually gives a pretty good pixel aspect ratio... On the A1200 I run 640x480x16 color no overscan but i did max it out to test...
thanks
nate
-
its no so much that the application is using overscan, just I have overscan prefs set to 728x283 because that is how I run workbench.
I understand that. :) And I am saying that on a real Amiga you should never do that as it dramatically slows down your Amiga, eats sprites, causes jerky animations in other programs, etc.
Of course on an Unreal Amiga such as WinUAE, Natami, Minimig, etc. it might not (should not) cause any problems.
-
Just to be clear. Setting Overscan prefs on Workbench affects the whole system. All OS-Compliant programs get affected in some way.
-
Don't come up blank. Come up vertical blank. :D
Cool, I was just looking at the Screen, looks like TopEdge is probably what i want.
I'll look into the vblank interrupt to sync up the sprites... I could probably use that vs WaitTOF for driving blitter stuff.
if I'm going to go through all this trouble with sprites maybe i should use 4 and get 16 colors.
Any idea why they don't display by default on the 1200 or UAE until i move the screen? thats bizarre.
thanks for the help :)
as for #4 Profit I don't know how I'm going to do so on a OCS 3D engine for Amiga OS... I will say that I may have my 3D engine complete before that "Aladdin 4D 6.0 Technology Preview Video" finally gets posted as promised. Maybe i should rename it "Aladdin 5D 7.0 OCS Classic"
-
Just to be clear. Setting Overscan prefs on Workbench affects the whole system. All OS-Compliant programs get affected in some way.
Thats ok, maybe as long as i have that vblank interrupt i'll just see if the user has moved the screen over too far and move it back :) make my program overscan compatible. I have not really noticed too many issues. I guess not many programs i run for WB use sprites...
-
Before u start loading up ur vblank with a million features, just take care that any OS functions that you call in your interrupt are "interrupt compatible". I suspect that moving the screen cannot be called from an interrupt. Once again, I am 2 lazy 2 look it up :)
vblanks are really great for sprites. Sprites were designed to be manipulated during the vertical blank interrupt.
But if u r going to go Rambo and start doing a lot of other stuff then u may have to simply create a subtask (or process) that does WaitTOF() and do it that way.
-
You could just disable screen dragging. That would be a much easier solution than doing all that other stuff :)
-
Before u start loading up ur vblank with a million features, just take care that any OS functions that you call in your interrupt are "interrupt compatible"..
Hopefully I'm on the right track here. This is a real PIA because this code cashes my computer(hard) every single time, and every single time i have to wait for the HD to validate for whatever reason. In fact, i'm going to backup my minimig before i continue down this road.... This code was i guess was a commodre 1988 example and i found it here:
UPDATE:
switched to IDCMP_INTUITICKS for now vs vblank.... looks kinda crappy but works :)
http://www.oifii.org/ns-org/nsd/ar/cp/midi_cmt_cmu-midi-toolkit/CMT321/CMT321/LIB/PROP1.C
static struct Isrvstr vBlankServer = {0x00}; /* zero out struct */
vBlankServer.is_Node.ln_Pri = -127l;
Forbid();
AddTOF(&vBlankServer, VBlankServerFunction, 0);
Permit();
static long VBlankServerFunction(VOID)
{
POINT2D point2D;
/*
point2D.x = spriteToolbarPosition.x + screen->LeftEdge;
point2D.y = spriteToolbarPosition.y + screen->TopEdge;
*/
point2D.x = 10;
point2D.y = 10;
MoveSprite(&screen->ViewPort, &spriteToolBarLeft, point2D.x, point2D.y);
MoveSprite(&screen->ViewPort, &spriteToolBarRight, point2D.x + 16, point2D.y);
return 0;
}
.... cleanup...
Forbid();
RemTOF(&vBlankServer);
Permit();
thanks...
-
Does ur compiler give u any warnings about uninitialized variables?
What compiler are u using?
I have never used AddTOF() I never knew it existed! Or I went lame and forgot :D
I use AddIntServer() and things work for me. I do my animated overlay sprite, music playback routine and some other stuff with it.
-
Does ur compiler give u any warnings about uninitialized variables?
What compiler are u using?
I have never used AddTOF() I never knew it existed! Or I went lame and forgot :D
I use AddIntServer() and things work for me. I do my animated overlay sprite, music playback routine and some other stuff with it.
No warnings related to that section of code... I'm using SAS c 6.48
I'll look into AddIntServer(), I found almost no code snippets illustrating the use of AddTOF() except for that one i linked which does look suspect.
I think i'm going to make the toolbar actually do something now and look at that later... i have has enough crashing and validating for now
thanks...
-
I use AddIntServer() and things work for me. I do my animated overlay sprite, music playback routine and some other stuff with it.
IDCMP_INTUITICKS appeared to work at first (but if window looses focus...).. oh well, it looked crappy anyway.
I don't know what i'm doing wrong with AddIntServer() but i get an instant guru like with AddTOF(), in fact, it causes the dreaded disk validation as well. I found that if I copy the EXE to RAM before running most of the time I don't have to do disk validation. But 40 or so crashes later.
I have a feeling that the issue is with the declaration of "VBlankServerFunction". The Interrupt struct says it should be void and not long , but every single example i see in google search.... i tried it as void and i get the same crash.
I'm also not understanding vBlankInterrupt.is_data is used for. Is it like DOS where when you have an interrupt you have no clue where your data segment points? That can't be right.
static struct Interrupt vBlankInterrupt =
{
{
NULL,
NULL,
NT_INTERRUPT,
0,
"NATETRIX"
},
NULL,
NULL
};
vBlankInterrupt.is_Code = (APTR) VBlankServerFunction;
AddIntServer(INTB_VERTB, &vBlankInterrupt);
static LONG __saveds VBlankServerFunction(VOID)
{
/* do absolutely NOTHING
POINT2D point2D;
point2D.x = spriteToolbarPosition.x + screen->LeftEdge;
point2D.y = spriteToolbarPosition.y + screen->TopEdge;
MoveSprite(&screen->ViewPort, &spriteToolBarLeft, point2D.x, point2D.y);
MoveSprite(&screen->ViewPort, &spriteToolBarRight, point2D.x + 16, point2D.y);
*/
return 0;
}
thanks...
-
I use AddIntServer() and things work for me. I do my animated overlay sprite, music playback routine and some other stuff with it.
i compiled and linked this in without even changing one line...
just called vblank_start(). not doing anything with the signal....
instant crash.
http://ftp://ftp.back2roots.org/pub/back2roots/cds/xetec/fish_n_more_vol3/fishdisks/101-125/disk_105/drunkenmouse/vblank.c
so the i tried this program:
#include
int main()
{
vblank_start();
scanf("%c");
vblank_end();
}
this is really discouraging.
-
scanf("%c");
That for sure can crash. It reads a char and places it to random location in memory.
The example code is very very old. It lacks __interrupt __saveds for the interrupt code (vbinter).
I'm also not understanding vBlankInterrupt.is_data is used for. Is it like DOS where when you have an interrupt you have no clue where your data segment points? That can't be right.
is_Data is used to pass a user controlled data to the interrupt routine (it arrives in A1 register). Typically this is used if the code cannot use static variables (and thus __saveds cannot be used), for example where there might be several different interrupts added, each with unique instance data.
-
That for sure can crash. It reads a char and places it to random location in memory.
The example code is very very old. It lacks __interrupt __saveds for the interrupt code (vbinter).
yeah, too bad it crashes before i type the char... i'll try __interrupt (i did have __saveds)..
thanks!
as an interesting note, i see that i don't have to worry about screen->TopEdge it seems, MoveSprite always positions the sprites relative to the screen. so just calling it is enough to get the desired effect.
I ended up just replacing my Wait(signal) with Delay(1) so my main loop constantly runs (calling MoveSprite) but that is not good form i'm sure.
UPDATE:
__interupt fixed the problem!
i bet it would even have fixed the AddTOF() method....
thanks! results look better :)
-
I was going to mention __interrupt as soon as u said SASC but when I searched my 100,000s of lines of source code I could not find it anywhere. (?) So I got puzzled and forgot about it.... **scratching head**
as an interesting note, i see that i don't have to worry about screen->TopEdge it seems, MoveSprite always positions the sprites relative to the screen. so just calling it is enough to get the desired effect.
hehehe kewl trick. I might possibly use that one myself.
-
I found out why I have no __interrupt in my sources.
Because Real Men(tm) code their interrupts in asm! :D
-
I found out why I have no __interrupt in my sources.
Because Real Men(tm) code their interrupts in asm! :D
assembler, blah... i have had enough crashes for now.
i did get my sprite toolbar working... happy with the results.
thanks for the help!