07 November 2018, 12:38 | #161 | |||
Registered User
Join Date: Jun 2009
Location: Dublin, then Glasgow
Posts: 6,343
|
Quote:
I do remember the standard commands working for me many years ago, though it was very picky about the format. Try saving the animation as a different format if possible. Do you have a bitmap set up already? BitmapToWindow can then be used to display the bitmap the animation is rendering to in a window. As previously mentioned, palette information will have to be set for the screen for this to look right. It might be worth looking at the RIAnim library of commands. I haven't used it, but apparently it supports other animation formats, and seems a bit more useful (uses fast RAM and can blit the animation at any position on a bitmap for example). Quote:
Even better practice would be to declare some constants, and use them instead of just numbers for the ID. This will make your code far more readable in the future, and will help to reduce the chances of bugs even further. For example: Code:
#MainWin = 0 #DebugWin = 1 #PrefsWin = 2 #OutputWin = 5 Code:
WindowOutput #OutputWin If EventWindow = #PrefsWin NPrint "Prefs Window was used" End If Quote:
|
|||
19 November 2018, 17:04 | #162 | |||
Registered User
Join Date: Sep 2018
Location: Elsfjord / Norway
Posts: 31
|
Quote:
Quote:
This program started as a text adventure kind of game, just that I wanted to add a GUI to it. That is the main window of the program, showing some short messages, navigation and a few other buttons, inventory and active objects. And then I added some images to this, so that window is now more than 500 pixels wide. I was trying to make sure that the program could work on screens from 640x512 pixels, so to make room for the longer messages I do use additional windows. Quote:
A different matter: As discussed earlier, the executable size is reduced when compiling many times in a row, even when "Make smaller code" is selected. In my case it starts at 784kb and after nine compiles is reduced to 636kb. When Compiling, I usually use the keyboard combination Amiga+E, and Amiga+O to do this quickly. But in the Compiler Menu, there is another selection, "Make minimized executable". If I use that, the executable will be dramaticly reduced, down to 450kb. I wonder, is it just the time it takes to compile that is the downside of having the small executable, or is there another catch here? |
|||
19 November 2018, 22:31 | #163 | |||
Registered User
Join Date: Jun 2009
Location: Dublin, then Glasgow
Posts: 6,343
|
Quote:
Quote:
Quote:
|
|||
20 November 2018, 11:37 | #164 |
Registered User
Join Date: Sep 2018
Location: Elsfjord / Norway
Posts: 31
|
Is there a GT equivalent to MenuColour?
If I use GTMenu I notice that my menus will show black text on black colour on the WB screen. |
20 November 2018, 12:26 | #165 |
Registered User
Join Date: Jun 2009
Location: Dublin, then Glasgow
Posts: 6,343
|
This is because the menus are using the old OS2 look, but the text colour is coming from the screen's properties, meaning they both end up black. You need to turn on the New Look flag when opening the window to avoid this. Add #WFLG_NEWLOOKMENUS to the Window's flags when you open it and it should be a white background.
|
21 November 2018, 12:25 | #166 |
Registered User
Join Date: Sep 2018
Location: Elsfjord / Norway
Posts: 31
|
Thanks, that did work fine.
Do you happen to know the value for the #WFLG_NEWLOOKMENUS ? I did look at the amiblitz.de programmers guide, and many of those other window flags are listed with their value, but this one was not listed. Probably due to that the guide seem to be a copy of the blitz 2.1 manual, and not updated for AmiBlitz. |
21 November 2018, 12:53 | #167 | ||
Registered User
Join Date: Jun 2009
Location: Dublin, then Glasgow
Posts: 6,343
|
Quote:
Using the values directly is a little old-fashioned, though that is the approach taken by the Blitz manual. It will make your code a little harder to understand later on when you can't remember which value corresponds to what feature. The Autodocs from the development kit also include the various constants that you can use, along with a description of their function. You can read them here for window opening flags, and in general from http://amigadev.elowar.com/. I would recommend having a look Quote:
I would recommend bookmarking the autodocs so you can have a read of them when you need to. There's a whole host of extra information that you might find useful, even though it's primarily aimed at C coding. |
||
23 November 2018, 15:09 | #168 |
Registered User
Join Date: Sep 2018
Location: Elsfjord / Norway
Posts: 31
|
Thanks, thats a lot of useful reading there. Although a bit confusing to navigate in the material if you don't know where to look.
But I did learn one thing new. I did read about that GIMMEZEROZERO flag earlier, and did understand that it would prevent the window borders from being overwritten. So I did use that flag ( $400 ) for my windows. Now I see that flag is the reason for that my gtgadgets does not use the same x,y reference as wlocate x,y does. If $400 is set, then 0,0 for a GTButton moved just as much from the inner window border as the border thickness. On AmiKit X there are quite wide borders, and then the button will be offset 8,30 from the inner border. I don't quite see the purpose of this offset, and I wonder if this is an unwanted sideeffect of GIMMEZEROZERO ? Is there a known problem with gadtools in the 2.x kickstartrom and BlitzBasic? I can get my program to run on all setups I've tried, from WB1.3 and up to 3.9, and even OS4.1 classics and MorphOS, exept for if I use kickstart v2.04 or v2.05. It will run on WB2.1, but only if I use the 3.0/3.1 rom. On kick 2.x it will freeze the system as soon as the first window using gadtools is opened. |
23 November 2018, 15:45 | #169 | |||
Registered User
Join Date: Jun 2009
Location: Dublin, then Glasgow
Posts: 6,343
|
Quote:
Quote:
Quote:
I'd suspect your issue is in there somewhere. I'm not familiar with the GadTools add-on for OS1, but I suspect it's based on the KS3 version if your code works fine. |
|||
23 November 2018, 21:31 | #170 | ||
Registered User
Join Date: Sep 2018
Location: Elsfjord / Norway
Posts: 31
|
Quote:
Quote:
|
||
23 November 2018, 23:34 | #171 |
Registered User
Join Date: Jun 2009
Location: Dublin, then Glasgow
Posts: 6,343
|
Oh, that's odd, because it's a difference I've had to compensate for when moving my code from AB3 back to BB2. I guess there might be a difference in the command library versions we have then - perhaps it was "fixed" in a previous BB2 update that I don't have installed...
Hmmm, sorry about that. The best I can suggest is to get familiar with the various tags that GadTools uses, as some are OS3-specific, and it's possible that there's one that's applied automatically by Blitz that's tripping it up. Try stripping it down to just one gadget, see if it works, and start adding back the items one by one until you find the problem, and maybe that can offer some clues as to what's going wrong. |
24 November 2018, 12:46 | #172 | |
Registered User
Join Date: Sep 2018
Location: Elsfjord / Norway
Posts: 31
|
Quote:
I did install some update to my blitz2 installation, but I can not remember where I got them from. That did fix the issue I had with the GTButtons did not update automaticly when setting GTEnable /GTDisable. gtdisable For the OS2 thing, I only use gtstrings and gtbuttons in that window. I guess I can make two small programs just with a single button and another with a single string to see if they freeze as well. Now, regarding that animation issue mentioned earlier. I did not need a real advanced animation, just wanted to have something moving on certain events to make it look cooler. First i did this variant, which did work well on my test system. Notice I did use image 0 for every frames, because I asumed it would save memory. So here is my attempt at a system friendly "animation" Code:
Repeat If image_Load{0, "images/frame_1.iff"} image_Blit{0, 360, 315} EndIf VWait 10 If image_Load{0, "images/frame_2.iff"} image_Blit{0, 360, 315} EndIf VWait 10 If image_Load{0, "images/frame_3.iff"} image_Blit{0, 360, 315} EndIf VWait 10 VWait If image_Load{0, "images/frame_4.iff"} image_Blit{0, 360, 315} EndIf VWait 10 Until MButtons = 1 Then I did this, since it would be faster to load all frames into memory before displaying them. I know those nested if's looks a bit dubious, but that was to avoid problems if any of the files refused to load. This did play much faster on the slow system. Code:
If image_Load{0, "images/frame_1.iff"} If image_Load{1, "images/frame_2.iff"} If image_Load{2, "images/frame_3.iff"} If image_Load{3, "images/frame_4.iff"} Repeat image_Blit{0, 360, 315} VWait 10 image_Blit{1, 360, 315} VWait 10 image_Blit{2, 360, 315} VWait 10 image_Blit{3, 360, 315} VWait 10 Until MButtons = 1 EndIf EndIf EndIf EndIf Last edited by amyren; 24 November 2018 at 12:58. |
|
24 November 2018, 15:06 | #173 |
Registered User
Join Date: Jun 2009
Location: Dublin, then Glasgow
Posts: 6,343
|
Yep, that nested setup looks fine, though you can't really do much else when the loop is running. In some cases that's fine, but just in case you wanted to incorporate the animation in your main loop, you can use a frame counter that updates every frame, and then check it in the main loop:
At the start of your program: Code:
SetInt 5 framecount.w + 1 End SetInt Code:
If framecount >= 10 framecount - 10 image_Blit{currentframe.w, 360, 315} currentframe + 1 If currentframe > 3 Then currentframe = 0 End If |
24 November 2018, 21:48 | #174 |
Registered User
Join Date: Sep 2018
Location: Elsfjord / Norway
Posts: 31
|
It took me a moment before I understood what that code was doing. I did not know anything about interupt codes and vertical blanking so I had to look that up in the blitz manual. But it looks good.
But for that to work, the main loop have to run continuously and uninterupted. Wouldn't that take a lot of CPU and slow other things down? And I use waitevent in my main loop, so the loop will halt while it waits for user input (to press a button in the main window). I guess to be able to use that routine in my program, I will need to find another way to detect those button or menu events. |
24 November 2018, 22:49 | #175 |
Registered User
Join Date: Jun 2009
Location: Dublin, then Glasgow
Posts: 6,343
|
Yes, you're right, it's not a solution for every situation, just an alternative to bear in mind. It all depends on what your main loop is doing. Sometimes main loops can run continuously, e.g. when your program does some sort of processing, or in the case of most games. You can limit the amount of CPU time your program uses in a loop like that with VWait, or the Delay_ system call.
Another friendly alternative for programs that do use WaitEvent, is to add the #IDCMP_INTUITICKS flag to your window's IDCMP list. This triggers an event roughly every 0.1 seconds, making it useful for animation and other tasks in a program loop that uses WaitEvent, however it will only work while the window is active. |
25 November 2018, 11:11 | #176 |
Registered User
Join Date: Nov 2004
Location: Germany
Posts: 629
|
Hello, i would shorten the code by doing something like this:
Code:
For x=0 To 3 If image_load{x,"images/frame_"+Str$(x)+".iff"} = 0 Then Goto donothing Next Repeat For x=0 To 3 image_Blit{x, 360, 315} VWait 10 Next Until MButtons = 1 .donothing: Last edited by Dan; 25 November 2018 at 11:17. |
25 November 2018, 13:17 | #177 | |
Registered User
Join Date: Sep 2018
Location: Elsfjord / Norway
Posts: 31
|
Quote:
I just tested using Delay_ in place of VWait in my nested loop example, and there was a big difference. Also testet adding VWait 1000 into a program, and while that was processing I could hardly move a workbench window around. The same test with Delay_ 1000 and the system was very responsive. I just need to test Delay_ on other systems to check if its system friendly, and then I will replace all vwaits. For the waitevent, I asume I just can use Event instead of waitevent if I want the mainloop to cycle without stop. It did not seem to be to CPU intensive. And to make things smoother, I could add a Delay_ 2 into the mainloop. Regarding that animation, as you can see from my example above, I use MButtons to stop the animation and continue the program. That works well enaugh, but MButtons will only detect this if the mouse is inside the window, and not hitting a gadget. This is in the main window, and the user might try to press buttons to continue, and then it will seem like the program is stuck in that anim loop. I don't know if there is a command to detect general window mouse activity, so I tried this, which seem to work. It will detect menu access, gtgadgetbuttons, closewindow as well as presses in empty areas in the window. It also detects presses in the gttext gadgets, but for some reason only double-clicks. Code:
animstop = false Repeat ev.l = Event image_Blit{0, 360, 315} Delay_ 10 image_Blit{1, 360, 315} Delay_ 10 image_Blit{2, 360, 315} Delay_ 10 image_Blit{3, 360, 315} Delay_ 10 If MButtons = 1 Then animstop = True If ev > 0 Then animstop = True Until animstop The particular usage is if I want to display more text than the size of a window allows. |
|
25 November 2018, 13:39 | #178 | |
Registered User
Join Date: Sep 2018
Location: Elsfjord / Norway
Posts: 31
|
Quote:
That would save even more code if I decide to add more frames later. I could use that, but I would like to add some check that all the frames are loaded before trying to blit them. Code:
loadfail.b = false For x=0 To 3 If image_load{x,"images/frame_"+Str$(x)+".iff"} else loadfail = true endif Next if loadfail = false Repeat For x=0 To 3 image_Blit{x, 360, 315} Delay_ 10 Next Until MButtons = 1 EndIf |
|
25 November 2018, 16:37 | #179 | ||||||
Registered User
Join Date: Jun 2009
Location: Dublin, then Glasgow
Posts: 6,343
|
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Yes, this is the way I would do it too regarding loading. The code Dan posted would avoid blitting the shapes if they weren't loaded, but would also skip anything else happening in that loop. Your method allows the rest of the program to work if necessary (and avoids a Goto, which is generally a good thing...) |
||||||
13 December 2018, 12:59 | #180 |
Registered User
Join Date: Sep 2018
Location: Elsfjord / Norway
Posts: 31
|
Regarding my previous problem that my program did crash when run on kickstart 2.x, I now figured out the problem. As Daedalus mentioned, it does have something to do with the gadtools acting differently in kick2.x.
At the beginning of my program there are some buttons defined, and by default some of these are disabled by using eg. GTDisable 0,21 Furtther down in the program the gtlist is attached to the window, and this did work fine exept in kick2.x. The solution was simple, just move the GTDisable lines below after the gtlist is attached and it now runs under kickstart 2.x systems as well. My gadget ID's are still below 50, but that did not cause any problems so far. |
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
[blitz basic] How much amiga-blitz friendly is this? | saimon69 | Coders. Blitz Basic | 105 | 21 April 2022 19:45 |
Blitz Basic (1) | Retro1234 | Coders. Blitz Basic | 9 | 18 February 2016 17:54 |
Blitz basic 2 Help | Havie | Coders. Blitz Basic | 30 | 08 September 2013 09:15 |
Blitz Basic 2 anyone? | jobro | request.Apps | 12 | 28 November 2005 18:15 |
Blitz Basic 2 | LaundroMat | Retrogaming General Discussion | 5 | 24 July 2001 08:10 |
|
|